Agile UX
A playbook for integrating design into product teams.
The shift from a waterfall project management style to something more agile and lean can be characterised by the elimination of ‘Big Design’ upfront. But the void left by this means it’s harder for the teams to get the big picture they need. The result is a deconstructed design process where everything is broken down into small stories, which, when reassembled may not be the most cohesive experience.¹
While many teams have struggled with the move to agile methodology, some teams have made the jump successfully, producing exceptional experiences. A notable example is the Spotify model.
Integrating designers into the agile product development process is also a challenge because Agile from its inception concerned the delivery of code. While the definition of done is easier to articulate for development, (working code) and deliverables such as wire flows, UI and interaction specs, this question becomes harder for design activities that involve discovery work. Here we need to use a different process. In what follows are several approaches to help integrate design practice with scrum teams.
Discovery
In any delivery framework, we start with ideas. Some ideas may have risk attached and as such, they are open questions that need to be answered. Discovery work is essentially turning the risk into a question that we can answer with a test or with some kind of learning activity:
‘Will this feature be valuable to our customers? Let’s prototype several solutions that allows us to measure desirability”.
Like all backlogs item at the top are the most important, for learning it should be our riskiest assumption.
In the context of agile, this is similar to a spike where developers might look deeper into the technology. Here designers will look deeper into the problem space, refining from foundational to tactical research, what to build and how it should be built.
When designers conduct research or testing, the team acquires valuable data that will likely influence a direction or even change the original idea. Whatever the result, it de-risks our assumptions implicitly providing our customer’s with a higher likelihood of value and efficiencies for the business that increase ROI. This is how discovery works.
The learning backlog
Design Spikes
Introduced by Dimmick (2012, design spikes are pockets of time allocated to focus on complex UX issues. They can address holistic design questions that may impact the work being tackled by the dev team and should fit comfortably within the scrum framework. The result of this kind of spike should enable a user story to be in a more refined state.²
A design spike should be along the lines of :
“Hey Team, I may need 10 hours to research how to design a particular solution. Let’s add this item to our Product Backlog. Hopefully, this would allow me to get the answer to help us work on Story #1234”
When a design spike is in progress any development that has a dependency should temporarily cease. Only development work not affected by the design decisions may do so. Remaining members should participate in product/design thinking which involves any necessary research (brainstorming of testable hypotheses, validating assumptions through user research and or testing prototypes.) In general, the whole team should participate in vetting ideas for feasibility, viability and desirability.
In organisations with additional UX resources, the team may add an addition members called, traveller. This is useful in situations that require a short turnaround. Additional members exit the team once the spike has ended.
The design spike inherits the Product Owner of the project but also adds another decision-maker: the Design Lead who will usually be a senior member or UX manager. The key is that the person in this role needs to have a dependency on the vision of what is being built and the capacity to make decisions about a design’s viability relative to broader design and business considerations in the organisation (e.g. design patterns, style prerequisites, etc.)
In mature organisations with multiple product offerings that share a unified visual, interactive or brand language, Design Leads may be responsible for consistency issues that extend beyond a given project. Exposing the acceptability of solutions is key for alignment and a seamless end-to-end journey. Formalising consultation with a Design Lead also helps to ensure that the work being done in a design spike is free from later contradictions.
The design spikes may also inherit the scrum product backlog where designers select stories that may benefit from the spike, trying to complete as many as possible during the sprint.²
The definition of done for design spikes
This definition of “done” is determined during the initial sprint planning meeting and is an agreement between the team, the Product Owner and the Design Lead. For most spikes, the definition of done will probably be tied to a level of confidence required to move ahead with a solution eg. research confirms the hypothesis, probability of best, etc. Even when the research suggests a different path, this becomes a valuable pivot opportunity. But how much research is enough? Tom Kerwin has a great framework in his article, How much research is just enough?
Timebox the discovery
While scrum allows us to become better at predicting velocity, in discovery you can’t predict one experiment after another because what you learn on the first experiment will change what you do on the next and so on.
One strategy is to time box discovery. We can say this much time is allocated to do discovery based on the available time a designer might have. If we focus on velocity here, then this is learning velocity.
A quick note. Velocity is not an indication of value delivered or productivity. Story points or the number of Product Backlog items completed only provide some data points for Sprint Planning and Release Planning. If there isn’t a ‘Done’ Increment being delivered, velocity is zero. Therefore if your Spike is being used to gather more information and not to deliver the Increment this Sprint, therefore there’s no point in estimating it as it should not be part of velocity.
Nonetheless, Design spikes work best when they are of shorter duration, providing a greater number of sprint reviews in which feedback from stakeholders can be gathered. The recommended time length for a design spike is one to two weeks and dependent on the goal or desired outcome from the Design Spike. The spike would continue in the sprints until the Product Owner and Design Lead (if required) decide that the spike has reached its goal or is no longer of use.
Shortening the feedback loop
Proposed design directions should adhere to agile principles by asking, what’s the shortest path to implementing and testing in the wild?
A note on MVP, how pretty your design is will not make or break your product. The main thing that matters is product-market fit. The goal is to validate as fast as possible, with as little resource as possible so you can pivot and adapt accordingly. If you get really creative you can actually validate without a single line of code. Designers have literally built prototypes that link up to different services, products and websites with third-party tools that can be validated with users for product-market fit.
Designers, as a good rule of thumb, consider time boxing this also. Prototypes can and should be created in a day. Here we’re only looking for a level of fidelity that is believable. This places the emphasis on creative problem solving, which is your biggest strength as a designer.
Considering the scenario layer
Scenarios are specific stories that happen to users. For example, a scenario might read,
“Lewis, a loyal brand devotee, has ordered three new products directly from site X with the assistance of a chat consultant. He wishes to collect them in-store later in the day. Additionally, when he picks them up, he wants to try a new fragrance he’s interested in and is looking for a way to streamline these tasks.”
A scenario like this could involve several design spikes across different product streams, including creating alerts, developing a flow for fulfillment options, and booking a one-on-one consultation. Ideally, such scenarios shouldn’t be based solely on the team’s imagination but should reflect common experiences observed during research with real users.
Successful teams should discuss these additional layers throughout development, particularly during the decomposition of stories. Laddering up to a scenario or an experience vision is a more holistic and powerful approach to creating products and services. It also provide multiple teams a single north star.
Measuring and learning after you ship
To ensure the continuous delivery of value, it’s essential to engage in discovery and measure impact after the launch. We refer to this as post-launch discovery..
You might be thinking, “This looks an awful lot like a waterfall model.” It’s true that elements move from the discovery track to the delivery track, from top to bottom. However, this approach is far superior to the traditional big design upfront. As Patton (2020) explains, the concept of dual track is key here. Importantly, it involves two tracks, not two separate teams. Design is integrated within the scrum team and their sprint. For design efforts spanning multiple products, coordination is essential to manage dependencies on the same platform and design system.
A helpful workshop is Jeff Patton’s, Dual Track Development: Involving The Whole Team In Discovery And Delivery. UXDX Europe 2020
Evidence boards
Now that the entire product team is involved, maintaining visibility is crucial. Our primary strategy for this is similar to the evidence boards you see in crime shows. In the post-COVID era, these boards have transitioned to digital tools like Miro, Mural, Figjam.
Keep learning visible
It’s not just about your hypotheses; the most important aspect is identifying what we aim to learn next. We refer to these insights as “Deltas.” Making our learning velocity visible is essential, and this should be addressed at the end of every discovery cycle. The format involves asking: What did you confirm? What did you validate as true? What were you wrong about? What’s brand new information? We focus on the unknowns that have surfaced to plan the next round of discovery. These items can be added to our learning backlog as future design spikes.
Involving the whole team
Design isn’t a product that designers produce. Design is a process that designers facilitate.
— Leah Buley, author of The User Experience Team of One.
In successful teams, designers often involve the entire product team in the discovery process. In mature organizations, this practice should extend beyond the core product team to include marketing, business, and customer service teams. As a stretch goal, we even involve the executive audience.
A straightforward way to engage these teams is through design workshops, where everyone is encouraged to participate. UX playbacks are another valuable ritual that fosters involvement. While it’s important for everyone to contribute, we must remember that:
“Design by community is not design by committee” — Leisa Reichelt, Head of research Atlassian http://www.disambiguity.com
Just as we don’t want UX and Product Managers voting for the best code, we should apply the same principle on design.
Summary
In conclusion, design spikes give UX teams a framework to conduct iterative design within the scrum process. They allow for comprehensive design bubbles that focus on holistic issues, rather than the granular design concerns that scrum sprints sometimes emphasise. This approach allows teams to explore in a systematic way rich product and design questions and allows them to break out at any time to address these. Design spikes also offer organisations a mechanism for alignment, where senior design stakeholders can input additional contexts to important decisions.
Transparency in Agile teams cannot be overstated. As a designer, it is vital to involve the whole team in discovery tasks wherever possible and keep this work and its progress visible and updated. As such, sprint reviews and UX playbacks provide an impactful forum for this. Ensuring that your product team is across the hypotheses, and the most pressing questions will ensure better collaboration and agility in your design practice.
References and helpful reading
- Jared Spool, Essential UX Layers for Agile and Lean Design Teams, Centre Centre, UIE.
- Jeff Gothelf, 5 Rules for Integrating UX with Agile and Scrum
- Damon Dimmick, Fitting Big-Picture UX Into Agile Development, Nov 2012.
- Tom Kerwin, How much research is just enough?
- Jeff Patton, Dual Track Development: Involving The Whole Team In Discovery And Delivery. UXDX Europe 2020
- Professional Scrum User Experience resources
