Optimising Agile for user-centred design
A few weeks ago, I overheard a conversation on a train between two, let’s call them ‘seasoned’ consultants, who were raving to each other about this wonderful new methodology they’d discovered called ‘Agile’ and how they were super excited to learn more and put it into practice. Using all the Agile buzzwords, they obviously thought Agile was the answer to all their problems.
I was surprised that anyone didn’t know about Agile. In digital design and development, it’s been the default methodology for many years and reached a point quite a while ago where the general feeling is, if you’re not running Agile, you’re not running an optimised project.
It’s not hard to see why Agile is popular. Agile, when run well, is designed to deliver results quicker, provide greater flexibility, enable change and achieve higher quality results than previous methodologies. But Agile is not always run well.
Agile is not a ‘fix-all’ solution
Agile solves some problems but it also introduces some significant challenges that are easy to overlook. If these challenges aren’t recognised and resolved, Agile projects can cost a lot more and deliver worse results than other methodologies.
One challenge we come across often is, how far ahead should the design be before development can begin?
Using traditional methodologies (Waterfall for example), there’s a distinct design phase before development starts. During this phase, designers work through key challenges to arrive at a design that is robust enough to begin development with confidence that no major (and expensive) design changes will be made. Developers do start working before design completes but their initial focus is on ‘technical design’ rather than development.
An Agile methodology doesn’t have a distinct design phase. Instead, ‘Design’ is an activity that can take place through the 4 phases of Discovery, Alpha, Beta and Live.
Agile is sold as faster and more nimble (more agile…?) than previous methodologies and, because of this, it’s often assumed that designers and developers start on day 1 and work in parallel to shape a new digital service together.
Design should start before development
Although some aspects of development can start straight away (e.g. platforms, security, service setup), if we start the development of anything relating to the user experience of a digital service then we’re likely to hear the following conversation pretty quickly:
Developer: “What would you like me to develop?”
Designer: “I don’t know, I haven’t designed it yet!”
It’s important we recognise this because, although Agile aims to cost less, if we start front-end development sprints too early, we’ll have a development team up and running before we have a robust design backlog ready to feed them. This is expensive, inefficient and negatively impacts project morale.
Design needs to be ‘stable’ first
User-centred design has always been Agile. The creative process is non-linear and it involves a lot of trial and error. As designers, we have to be prepared to try out a range of solutions and test them with real users to understand if they’re usable and meet their real needs.
What this actually means is that UX designers need to be prepared for the following in the early stages of design:
- Designs may need significant change if feedback from users, or the client, is not positive.
- Sometimes our ideas just don’t work, regardless of how confident we were. We can’t be precious – if an idea consistently doesn’t test well with users sometimes we just have to throw it away and try another approach.
- We shouldn’t design any element in detail before we’ve designed the bigger picture or we risk ending up with a puzzle with perfect pieces that don’t fit together.
- The design of one element affects the others. When we refine one component we often need to revisit many of the other components to ‘bring them inline’ with the latest design.
Change during development is great if it’s not significant or avoidable.
Significant change, especially in the early stages of a project, is a good thing for designers and we don’t think of this as wasted effort. It’s an important part of the creative process that leads us to find the right solution. We use prototyping tools that enable us to make (and test) significant design changes quickly and at low cost.
But for developers, if they’ve just spent a week developing a new component and are then told by the design team that it needs significant change or, worse still, that it’s no longer required, then this is frustrating and an expensive waste of time. I’ve yet to meet a developer working in Agile that is happy that everything they’ve worked on for the last week is no longer required.
If design starts before development and is, for a while at least, free from the pressure of delivering finished designs, then we can quickly model the end-to-end experience at low-medium fidelity and make sure the overall design solution works for users.
This means design should start before development but should not get too far ahead. At the point where the overall design is ‘Stable’, development can start while the design team is then focusing on providing the detail required for development.
This is where the process becomes fully Agile. We understand and can demonstrate how the overall solution will work. We have identified all the pieces of the puzzle (features) and understand how they work together but we haven’t yet spent time designing each feature in detail.
Development can now begin with confidence that there’s no major changes on the horizon. Features can be prioritised and developed rapidly with design working slightly ahead (usually a sprint or two) of development to fill in the details the developers require.
4 principles to optimise Agile design and development
By adopting some simple principles we can optimise the Agile process without compromising design or development:
1. Allow time for the design to stablise
We give our UX design team time to explore ideas and get to a stable design that is proven to work well for users without pressure to make any final decisions. Most of this is done in the Discovery and Alpha phase.
Our optimal point to begin is when the design is ‘Stable’ but not complete, this allows for the right level of change during development and is often at some point during the Alpha phase.
2. Involve developers in the design process
Even though they may not begin developing, we always involve developers in the design process to make sure any design is developer ready and to spot opportunities to make the best use of any opportunities the technology offers.
3. Test the developed solution as early as possible
We test a working solution with users as soon as possible during development. Although the design is stable, there are always nuances that can only be picked up in a working system with real data and the earlier we can discover these, the lower the impact of any changes.
4. Embrace change
Above all we encourage a mindset that embraces change. Changing something that’s already been developed can be frustrating but that’s the nature of Agile.
By starting design before development, we greatly minimise the risk of significant change yet remain open minded and flexible enough to make positive changes during development.
And that’s Agile, optimised.
Guest post by Paul Lakin, founder and managing director of Fluent Interaction
