If you’ve read the Agile Manifesto you’ll have noticed that the word “user” doesn’t appear in there at all. And where they mention the “customer” they are specifically talking about the product owner. This is because the developers negotiate timelines and budgets with product owners. The lack of user centred considerations in the Agile Manifesto make it obvious that agile is a tool for developers and not for designers.
How are we supposed to design the best possible experience for our users/customers in an agile environment?
As a UX Designer there are 3 main types of projects you’ll find yourself in. Each one presents a different kind of challenge.
Established product, ongoing tweaks
About working on established products
The best UX-Agile situation is where you are working on an already established product. In this case your sprints (should) correspond to release cycles. You also shouldn’t be building any large components in one go.
As designers we often want to work on something new; designing something from scratch. While this type of situation might not help you with that goal, you get to explore a different side of design. Existing products mean usability optimisations and adding new features. The challenge is trying to keep the end-to-end experience in mind.
Structuring your sprints
In this situation you generally want to be working roughly 1 sprint ahead of your developers. In the first half of your sprint you can run any of the following exploratory research:
- Customer interviews
- Reviewing user feedback
- Surveying customers/users about how they use the product
- Usability testing the existing site
Each of these things can provide insight into what work the developers should do next sprint. Ideally stakeholders, product owners, and developers will all sit in on user testing sessions so that they can see issues first hand. From there you can identify issues to fix and put them into the backlog.
In an agile environment you want to consider the smallest possible changes that you can make. Each change ought to improve an issue that you’ve found (or add something new you’ve identified as a user need). For example you might find a form is problematic. Rather than redesigning the entire form you first consider if there are fields you could change that would add clarity.
It’s important for designers to work closely with product owners to negotiate what goes into each sprint. Together you prioritise the backlog (through “backlog grooming sessions”). You do this for both your work (1 sprint ahead) and the developers (the following sprint).
In the second half of your sprint you can start designing. If you have a good scrum master and a reasonable product owner you’ll have chosen bite-sized solutions to your biggest user/customer challenges. If these changes are small enough you might find that you can provide developers a simple sketch. With this you can sit together as they make front-end changes.
There are other things to consider during the second half of the sprint. For example you may want to A/B test a few options to see how they go. If you’ve decided to tackle a bigger design change you may want to properly prototype the proposed solution.
Factoring in long-term research
Depending on how pressing your user issues are you may also be able to add a “spike”. In Agile Scrum this means that you will do research that’s not necessarily related to any upcoming work. It is a chance for you to step out of the sprint and work on something more long term. So you might consider engaging in a diary study, ethnographic research, card sorting/other IA research, complex quantitative research, etc.
Common challenges
In this type of project you are going to face many challenges. Some will come from your stakeholders, some will come from limitations of Agile, and others will come from limitations of the UX process.
Your first challenge is fighting “feature-itis”. For whatever reason stakeholders will always be pushing for new features over improving what’s already there. If they are unfamiliar with User Centred Design they will want to add features without any user research. If they are unfamiliar with agile they will want to add features in big swaths without breaking them down into small prioritised capabilities. Unfortunately there is no one-size fits all solution for managing this problem. Your success as a UX’er is directly linked to how you manage your stakeholders.
Your second challenge is managing Information Architecture in an ever changing environment. As you add features and make minor modifications your original method of organising the site will stop being effective. At some point it is crucial to add a research spike with the aim of looking at IA. Card sorting, tree testing, and prototype testing are crucial. You may come up with a brand new IA but to think in agile terms you’ll need to find a way to slowly transition to it. And you need to transition to it in a way that if you only adopt some fraction of the new approach it will still be viable.
Your third challenge will be finding an effective way to work with your developers. The better your developers are at front-end the easier it will be to add a GEL/Design System and work collaboratively. The less experienced your developers (in front-end) the harder this is going to be.
Key takeaways:
- Work one sprint ahead
- During the first half of your sprint do exploratory research to understand what problems to tackle for the next sprint
- Work with your product owner on tackling small problems, ideally so small that you don’t need to design full prototypes to show developers
- In the second half of your sprint complete design work and any testing that you can (perhaps as simple as an A/B test)
- Periodically add a research “spike” to your sprint so that you can investigate larger/more complex problems
- Manage your stakeholders to prevent an obsession with adding features over improving the existing experience
- Ensure that when you do add features they are split into small stories which can be added to the product gradually
- Do periodic research spikes targeted at improving the IA otherwise your changes will spiral out of control
- Find a way to work with your developers through collaboration and design systems
New product/greenfield project
About greenfield projects
When building a brand new product we run into much larger challenges. Not just UX challenges but we also run into inherent difficulties with the agile process. Some of these are challenges with collaboration and mutual understanding, while others are just unfortunate facts about the universe.
Depending on how late you’ve been added to a greenfield project influences how many problems you can expect. If you’ve been hired after the developers start you are definitely in for a hard time.
Deciding what to build
If you are really lucky you are one of the first hires on the project. When that happens it’s easy to ask every UX’ers favourite question: “why?”. Why are we building this? Why do we think users will care? Why do we think this is the best solution to the problem? Why, why, why?
In a more typical scenario the project has started by the time the first UX’er is hired. The solution has been chosen without thinking about what problem is being solved, the medium has been chosen, and you’ll be asked to start designing immediately. This is the first shock that a lot of stakeholders will experience – you inform them that UX doesn’t work that way and that you can’t start designing until you understand the problem and actually interact with some users/customers.
In most scenarios you’re not likely to convince the client to build an AI powered drone that automatically visits customers and solves their problem in-person with natural language UI. You’ll probably be building an app or a website and this will have been decided prior to your arrival. What you’ll need to do is convince everyone to take that step back and make sure that whatever you are designing is going to help both your client and their end users.
Your first hurdles
If you are really unlucky you’ll have started after a backlog has already been created. One thing you’ll notice about agile is that there’s no talk about how a backlog comes into existence. Ideally a backlog is driven by customer/user research balanced with business priorities.
Far too often backlogs are driven by product owners deciding on their own (without research) what to build. User stories will describe what users “want” to see in the form of screens. Sometimes they’ll even have design components, e.g. “As a user, I want to see a table of data showing my widgets, so that I can see all of my widgets”.
You’ll advise the client that what you need to do is some exploratory research, come up with some design concepts, and test them with real users. Here is the first chance for pushback. The agile manifesto says “working software over comprehensive documentation” and things like wireframes and customer research sure sound a lot like documentation.
Your best bet is to sell your stakeholders the benefits of rapid prototyping and user testing. Explain how easy it is to change a wireframe. Give them a scenario in which you wireframe an idea and test it with users only to discover that the idea won’t work and isn’t an effective way to solve their problems. In this scenario any development effort would have been wasted. Wouldn’t it be better to make sure that our solution is right before we start building?
If you’re unlucky you’ll face one of two possible objections.
- “Isn’t that why we hired you? Shouldn’t we use your expertise so that we know what do design from the beginning?”
- “That’s how agile works, if we need to, we’ll change it”
The first objection involves educating them about the benefits of UX. The second objection is actually much worse. If they take this approach you run the risk of ending up with sub-optimal designs that cause a bad user experience. Later, when you ask them to add user stories to fix these issues they are de-prioritised in favour of new functionality.
Anticipate these problems and you stand a chance of avoiding them.
True agile vs waterfall in sprints
Your next challenge is related to what kind of greenfield agile project you are actually working on. There are two main types that I’ve seen:
- You start with a Minimum Viable Product or MVP with emphasis on the “minimum”. This is something so minimum that the first version could actually be built in the first one or two sprints. Your MVP is pushed to production and subsequent releases are based on a combination of customer feedback and user research.
- While there may be talk of an MVP your backlog describes a huge product. You don’t build in small releasable increments but instead gradually build-out future functionality. The product can’t be released in increments because every release relies on some future functionality that doesn’t yet exist. This is just waterfall in sprints.
If you are in a truly agile team then things get easier for you. Work on releasing the MVP as soon as possible then start refining it. From here refer to the previous section on working on an existing product with ongoing optimisation.
If you end up in “waterfall in sprints” your situation is much more difficult. Instead of “Working products over comprehensive documentation” you get no working products and no documentation. As you slowly build out functionality you start to realise that what you’ve already designed doesn’t work with the new functionality being added. You don’t actually have a product in production so there’s no progress to show and what you’ve designed is becoming a worse and worse experience.
In the second scenario your only hope is to work several sprints ahead. During this time you adopt a more typical UX approach: research, prototype, test, refine. If you work far enough ahead you can prototype the entire end-to-end product and identify issues early. The quicker you can get ahead the easier things will be.
Replacing an existing product
Can agile be used to replace an existing product?
This scenario involves completely replacing an existing product with something new. If you simply chip away at an existing product to redesign it then you’re actually in our first type of project (Established product, ongoing tweaks). This type of project only applies if the old product is going to be completely scrapped once the new one is ready.
In this case it’s unrealistic to actually do this project using an agile approach. Why? Existing products have existing features and you’ll almost certainly need to re-create all of those features. If you release an MVP to replace the existing product then a whole swath of features are going to disappear and customers will be unhappy. This means that you can’t actually release your new product until it does at least as much as the old one.
One of the key benefits of agile is that if design and development stop then at least you have working code that’s already in production and bringing value. If you are replacing legacy software you (almost certainly) won’t be replacing it with a half-finished product.
Where to from here
Your best asset is the legacy system being replaced. It’s existing capabilities act as a source of requirements. You can run user testing on the existing product to help you work out end users’ mental models and behaviours.
The biggest challenge will be finding enough time in a faux agile environment to actually complete research. This is especially true when you consider research around changing Information Architecture.