Fitting Big-Picture UX Into Agile Development

Advertisement

The rapid pace of UX design in the agile world can lead to shortsighted design decisions. Focusing on addressing the immediate needs of particular user stories within the limits of a sprint can lead to neglect of larger design questions, which can come back to haunt UX designers later.

Sometimes, UX practitioners just need some time to work through big design issues that don’t fit neatly into an existing user story or an individual sprint. This article will explore one answer to these problems — namely, design spikes, an agile approach that I have developed for large projects. Design spikes, which are bubbles of time that allow designers to focus on complex UX issues, can fit comfortably within the scrum framework and can be an effective tool for designers who have holistic design questions whose answers could potentially invalidate the work being tackled by the team.

Tunnel Vision And The Problem With Sprint Zero

Since the wide adoption of scrum as a development methodology, designers have struggled to fit design practices into its framework. Scrum, with its iterative work ethic focused on a releasable product at the end of each sprint, tends to lead designers to focus on very small design questions that can feel divorced from a cohesive design vision or interaction concept. The result is design tunnel vision.

Designers have struggled with the need to step back and work on holistic concepts while at the same time supporting development teams that are actively moving forward on bits of functionality that, from a design point of view, cannot be easily divorced from the whole. For many designers, the process often feels like an effort to design an engine, wheel or windshield without really knowing in what kind of car these parts will need to be integrated.

To deal with this problem, agile organizations have come to rely on the concept of sprint zero, a preliminary sprint dedicated exclusively to preparing for the first sprint, during which design teams are generally free to address initial design concerns. For complex projects, however, sprint zero may simply not be enough to create concepts, perform research and imagineer complex systems. More importantly, as a one-time event that exists only at the start of the process, sprint zero assumes that the need for a design-centered thought bubble is discrete, as opposed to an ongoing concern during product development.

Although any sprint can theoretically aim to address design issues, the pressure on designers to not hold up the rest of the development team once normal sprinting has begun is enormous. However, the time needed to explore very complex design decisions could drastically slow down team momentum. Making short-term design decisions based on limited understanding could end up invalidating valuable chunks of team output, an outcome that should be avoided if at all possible.

Development teams have long had a reliable solution for taking extra time to work on thorny or ill-defined obstacles: the spike. Spikes, in their most basic forms, are time-boxed periods that are used for exploration, research and sometimes prototyping. The purpose of a spike is to explore information necessary to understand a development approach or a requirement or to make a story estimate more reliable.

With a few modifications, the spike construct can be adjusted to serve the needs of design teams while maintaining the overall structure of scrum and preserving momentum. I call it a design spike — a method by which design teams can address complex UX issues within the confines of the scrum process.

What Is A Design Spike, And What Makes It Different?

A design spike is a bubble of time during which the designers and potentially other team members focus primarily on design questions. Design spikes can take place at the start of a project or anytime during the normal scrum process, but the introduction of a design spike changes the nature of the working scrum team temporarily. A single project may have multiple design spikes, as many as deemed necessary by the team.

When a design spike is called, any development work that could be affected by the spike temporarily ceases. This is because design spikes inherit and create obvious dependencies in the agile process.

Spike Outline Diagram.
Design spikes drop into the normal scrum process and temporarily take the place of regular sprints.

Members of the development team who can move forward with work that would not likely be affected by design decisions may do so, pursuing non-dependant stories from the backlog during the spike. Remaining members can participate in research and design. Members also will contribute ideas to the design process, vet design ideas for feasibility, suggest alternative solutions and provide general estimates of work based on the designs being produced. Development insight is crucial to keeping the design process rooted in the reality of production. Again, the key point is that the team does not move forward with development work that could become wasted effort based on design spike decisions.

In organizations with additional UX and design resources, the team may also request to be temporarily augmented with new members. This is useful in situations where additional researchers or designers are needed for short turnaround testing and prototyping, but it is not required. These temporary team members would exit the team once the spike has ended.

So, What Happens To The Backlog, The Product Owner And The Traditional Sprint Artifacts?

The design spike inherits the product owner of the project but also adds another decision-maker: the design owner. The design owner will usually be a senior member or manager of the organization’s design staff brought in from outside the scrum team, such as a UX director or VP, although the spot could potentially be filled by a decision-maker from marketing or product, depending on the organization’s structure. The key is that the person in this role needs to have a design vision for what is to be built and the capacity to make decisions about a design’s viability relative to broader design considerations in the organization (e.g. other products, design patterns, style prerequisites, etc.).

The design owner is also partially responsible for approving the done-ness of a design sprint’s results. Both the product owner and design owner must agree on the done-ness of backlog items before the item may be considered done. The definition of “done” is decided during the design spike’s initial sprint planning meeting and is an agreement between the team, the design owner and the product owner. For most spikes, the definition of done will probably be tied to the definition and completion of design artifacts, research results and prototyping endeavors.

Why bother adding a design owner? In mature organizations with multiple product offerings that share a unified visual, interactive or brand language, design owners may be responsible for consistency issues that extend beyond a given project. Design decisions and product decisions might be at odds, and making transparent the process of these two constituents discussing and exposing the acceptability of solutions is key to the transparency of the design sprint. Formalizing the involvement of a design owner helps to ensure that the work being done in a design spike is being vetted and approved by senior design stakeholders and decreases the likelihood of later contradictions.

The design spikes also inherit the scrum product backlog, and the design team selects stories from the same backlog and accepts them into the spike, trying to complete as many as possible during a design sprint.

Design sprints work just like normal sprints but focus almost exclusively on design decisions. Design spikes should prioritize work to resolve the biggest unknowns in the current design first, and they do not need to follow the backlog’s priority order. For instance, if a high-priority item calls for displaying data in a certain widget, but a lower-priority item calls for including more data than the widget can currently accommodate, then the design team may select the lower-priority problem in order to think about how this change could affect the widget’s overall design downstream. Again, design prioritization is a different beast than product prioritization.

Importantly, because the spike focuses only on the design portion of backlog items and not the development portion, backlog stories are completed only from a design point of view. When the normal scrum cycle resumes, any stories calling for development work will still be alive on the backlog list, ready to be selected for a normal sprint.

The duration of the design spike is not generally time-boxed, but the team should aim to end the spike as soon as possible so that team resources are not left idle. The product owner may elect to time-box the design spike if necessary, although anticipating how long it will take to work through complex design issues can be difficult. The goal of each spike is not to produce potentially releasable code, but rather to provide actionable design decisions in the form of wireframes, mockups, prototypes or research. 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. The spike would continue in the form of design sprints until the product owner and design owner decide that the spike has reached its goal or is no longer of use. All effort would then be made to return the team to its normal sprint schedule as soon as possible.

Design Sprint Structure Diagram.
Each design spike may contain one or more design sprints, which work very much like normal scrum sprints but are focused simply on design.

As in a typical sprint, the design spike process retains all of the milestones that you’ve come to know and love: product backlog grooming, effort estimates, sprint planning, sprint reviews, sprint retrospectives. Those all stay the same, but the focus here is on design, not building, and all of those artifacts now track the design work that the team is aiming to finish.

When Do Design Spikes End, And What Happens Next?

When the product owner and design owner agree that the design spike has reached the point at which the normal scrum process should begin or resume, the spike ends. The design artifacts created during the spike are carried over into the normal product scrum to serve as starting points for the detailed design process.

The designers who were part of the design spike (some of whom might transition to be part of the scrum development team) serve as a resource to the development team on any open questions and design issues, and the scrum process starts anew. Importantly, these design artifacts are not set in stone. The development team still functions as an autonomous decision-making unit. They simply now have the benefit of a holistically designed foundation on which to build.

Design Spikes Let You Zoom Out, And Then Zoom Right Back In

In conclusion, design spikes give UX teams a framework to conduct big-picture 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 emphasize.

The design spike gives the team the opportunity to explore systematically rich UX questions from a macro level, and allows the team to break out into design-centric thinking at any time for the purpose of solving larger UX challenges. With the addition of the design owner as a decision-maker in the process, design spikes also offer large, mature organizations the opportunity to incorporate senior design stakeholders who can lend expertise and guidance on important design solutions.

With the adoption of design spikes, UX teams can leverage some of the flexibility that development teams employ in the agile process, while gaining the immensely important time needed to address design concerns that simply might not fit neatly into the hyper-focused needs of standard scrum sprints.

(al)

↑ Back to top

Damon Dimmick is a user experience designer, agile ux advocate, and ux evangelist based in the metro Boston area. He has spent his career advocating for and designing efficient and pleasant experiences for complex products built by global companies. He is currently the Manager of Interaction Design (Global UX) for Monster.com where he helps jobseekers and employers find each other through the use of sophisticated job search and hiring tools. Damon is also a founding partner of the Subforum design group, a think-tank of UX professionals that advocates grassroots ux research, continuing design innovation, and design responsibility. Damon also shares his thoughts via Twitter.

  1. 1

    Fantastic read, thanks for sharing your thoughts. I like the diagrams… is there a specific application you used for those?

    1
  2. 3

    Interesting article. In almost all of my previous work, I was the sole design team working with very small groups of developers on new projects, so this was less of an issue. Recently, however, I have started working with a completely new, much larger group to do UX Design on a large scale application. The challenges are certainly different and it was nice to read an outline of what I am facing as well as ways to overcome it.

    2
    • 4

      Hi Rob,

      Glad you liked it. Feel free to reach out if you have any implementation questions. I’m happy to share my experiences.

      0
  3. 5

    Hi Damon,
    A very nice read. Two questions:

    1. How do you compare design spikes to the approach where you include backlog grooming (and thus design) during every sprint, where UX prepares user stories that are scheduled for the next sprint? The advantage in this approach could be that you continuously keep development ongoing.

    2. Do you agree that the spike is some kind of “jidoka” (toyota production system), where you make the decision to stop and fix problems as they occur rather than pushing them down the line to be resolved later?

    Bart

    3
    • 6

      Hi Bart,

      1. Spikes can live happily alongside regular backlog grooming. You only need to use them when you hit a big-picture problem that doesn’t seem to easily divide into smaller stories easily. When that happens, you just press pause on the normal sprints, insert a spike, and get back to normal sprints as soon as possible.

      2. Yes, it certainly has similarity to the jidoka production pillar concept. Obviously it doesn’t scale in the same way, but the idea here is to realize when you’ve hit a “big-hairy-problem” and need to step back before you perpetuate an issue and cause bigger obstacles to occur later. In that sense, it has a lot in common. Thanks for the insightful comment.

      -Damon

      3
  4. 7

    An excellent article. Definitely describes some situations I’ve been through.
    I didn’t read it fully, but I’ll be reading it carefully over the day and study what I can use to improve things in my work.
    Thank you so much for sharing your thoughts.

    0
  5. 9

    Have you considered just work in parallel with development? To me design spike interrupts development and slows things down. Not good.

    0
    • 10

      Hi Michael,

      Yep, the basic scrum process remains the default. This methodology is really only for when you hit something that requires a big-picture design consideration, something that could really impact development and production efforts. As noted, non-dependent dev tasks can continue, but if you really are dealing with an issue that could throw a wrench into development, you’ll want to take the time to make a coherent decision, otherwise you’ll have to do more dev rework later anyway. The spikes should be as small as you can get away with, and used sparingly!

      0
    • 11

      Oh also, I’d hope development would actually be -involved- in the Design Spike. Dev has valuable insights to share too, even in the field of design.

      1
    • 12

      Michael, it’s unfortunate when I see the perception that the only valuable artefact a team can produce is code, and that design is essentially worthless.

      Not that I want to put those words in your mouth – but slowing things down can be a good thing. Not all development effort is spent pushing a product in the right direction. I’ve seen tens of thousands of dev-hours wasted on implementing features that are never used, products that flop, interfaces that look and feel quickly hacked together and that don’t align with the goals and needs of users.

      I’m not saying it’s a choice between the steering wheel OR the accelerator pedal … we can do both. But taking time out to think and ensure you’re on the right track is absolutely worthwhile.

      5
  6. 14

    The one things I’ve noticed is that alot of velocity can be lost if UX teams aren’t given the domain knowledge of features and functionality. This is imperative so that the users get a journey of what they do and not what the UX designer “thinks” they do. Focus groups throughout the lifecycle of the project iron this out, so that managers, developers and UX don’t become stuck addressing design decisions later and later in the project.

    1
    • 15

      Yes, and as much user testing as you can get away with. Not doing so leads to instinct-driven design, which you can get away with if you have awesome, talented designers who have a superb understanding of the user, but even so… you still have to be lucky. Have you had some experiences where “genius design” fell through completely?

      0
  7. 16

    Great article!

    Perhaps the most important observation in this article is the fact that the agile-scrum movement is – more and more – acknowledging its fundamental shortcoming when it comes to UX design and requirement analysis: “design tunnel vision”.

    Based on my experiences in scrum teams I’ve come to the conclusion the “design tunnel vision” is a property of the Agile-scrum methodology. The Agile-industry, the evangelists, people giving courses on the matter… stubbornly try to come up with solutions to proof that it doesn’t coincide with fundamental design problems (Yes, you can “Fit” design in…see title of this article )

    On the ground floor however it’s just business as usual and Agile is interpreted as just a result (read “feature”) driven development methodology that needs this tunnel vision to reach its goals.

    The value of the suggested “Design Spike” lies in the fact that some people may acknowledge the fact that Agile has its limitations.
    Will it solve the fundamental incompatibility between design and Agile? No it will not.

    2
    • 17

      You hit the nail on the head. Culture is the only long term solution when it comes to integrating good design culture. The Design Spike is a tool to help triage and treat within the existing agile scrum model.

      0
  8. 18

    Interesting article. I think I see the issues you talk about when considering consistency and UX-cohesion in large-scale agile organisations, the sprint and task-focussed mentality inevitably leads to fragmentation – but having a design spike still feels like a hack on top of a process which is fundamentally unsuited to the aims of UX designers. Sure a spike will give you a fleeting design imperative, but it is still a halting interruption to what in an ideal world would be an ongoing agile UX process working in sync with an agile development process. I have never seen that work though, so the hack is appealing in its absence.

    1
    • 19

      You sound like you’ve had similar experiences to those that I’ve encountered. There are deeper challenges for UX in scrum, for certain. Design Spikes are a fix, a little hack to win the UX side of the table a chance to break out of the quick-churn decision cycle, but it’s not a cure all. Thanks for the comment!

      1
  9. 20

    One of the concepts of Agile that is often left out in the “Agile is hard for designers” conversation is the opportunity found in Release Planning. Release Planning (“RP”) should happen before Sprint Zero, and is intended to give everyone on the team the opportunity to visualize the whole product, and identify areas of concern (i.e. see your spikes ahead of time). As a designer, when we’re ideating through epic stories in RP, I’m visualizing UX patterns in my head – “Okay, we need a bunch of forms, refining, data tables, etc. There are pattens for everything here. But how the hell are we going to pull off [X]?” Right there, I’ve identified relative difficulty, and I can begin planning for how I’m going to design for it over many iterations.

    Release Planning, Sprint Zero, and Spikes are 3 awesome tools for everyone on the team (not only designers), and in my experience as a Product Design consultant with many companies, they’re already widely accepted. When approached optimistically, “architectural level” design challenges can be addressed in Agile. We just have to embrace the method, and be agile ourselves :)

    4
  10. 21

    Hey Damon,

    Nice post. Evidently, I’ve arrived late to this party. My concern is around the team. You mention that they may be able to be repurposed, but I worry about momentum and a sub-optimal (if not countervailing) contribution. I realise that the problem you are trying to solve is real—I encounter this issue frequently enough—and don’t know that I have a better solution, per se, but it feels that there is a better solution out there. Perhaps this could be done in concert with a hardening/refactoring cycle.

    Take care, Bry

    0
  11. 22

    Interesting article Damon! Now that I have only one month with this new company based on agile development, where I am the only UX designer… I’m interested to know your thoughts on who should I start with and include in these design spikes from a team of 1 UX designer, 3 visual designers, 4 producers, 2 social media, 2 digital marketing, 1 Product Manager and 1 Digital Director? The challenge I’m facing is more in the way of thinking around here, not being able to bounce ideas without being criticised and that a team can do more than one person…

    0
  12. 23

    How and where do you fit in usability testing in the Agile process without lengthening a sprint?

    0
  13. 24

    Interesting concept, but it feels a bit abstract and theoretical. Why not give real world examples of this situation? It would help to make this more concrete I think.

    0
  14. 25

    Great article about design spikes – and how to take it to closure. Could there be situations where the “regular” team and the “spike” team work in parallel?

    0
  15. 26

    Could the developers be fixing defects if they are at a loose end during the Design Spike?

    0
  16. 27

    Very useful, I am a web designer and this discussion helps me much when working with agile teammates. Thanks a lot!

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top