Working as the sole designer in an agile team is easy. You just have to be a time traveler.

The relationship between agile development and design is complicated. Let’s take Scrum as an example.

According to Scrum, user stories are written by the product owner (PO). Designers, developers, testers, etc. are all part of the development team, which works on these user stories during sprints. All responsibilities are shared inside the team, and the team is shielded from the demands of stakeholders by the PO so that it can do its job without distractions.

This sounds nice, but I’ve never seen pure Scrum in practice. In my opinion, there are there are two major issues that make Scrum unviable in its vanilla form.

Firstly, the development team should be shielded from stakeholders, but such communication is mandatory for designers who want to do their job properly. Thus, designers can’t really be a part of the development team.

Secondly, especially in larger organizations, development can be blocked if the designs aren’t ready on time. Scrum relies on the independence of the team to solve problems as they see fit, but designers rarely have such independence. 

The needs of stakeholders have to be taken into account in the designs, which can potentially take a long time. If this process ends up taking too long, the sprint will inevitably fail. An entire user story could even become redundant because of newly discovered business requirements.

There are other agile frameworks than Scrum, of course. Lean UX, for example, tries to bridge the gap between design and Scrum. But just like vanilla Scrum, Lean UX assumes that development teams have the freedom to solve issues completely by themselves, which they rarely do.

Day-to-day and long-term design

The two issues I mentioned earlier mostly arise due to one reason. Agile focuses on the here and now, but there are actually two types of design required: day-to-day and long-term design.

Agile frameworks tend to assume that most, if not all, of design is of the day-to-day kind. In Scrum, the product owner has already gathered the requirements and written the user story, so the only thing left for the designer is to draw screens, right?

Well, I’ve yet to see a project where the PO actually does all of this alone. In practice, the PO usually has a designer as a helping hand. Depending on the organization, the designer might even be responsible for most of this work. As I’ve heard one PO say: “Designers are a PO’s best friend”.

Long-term design includes things like user research, concept design, creating roadmaps, etc. The less long-term design is done, and the more rushed the project’s day-to-day design, the more likely the project is to accumulate design debt. This basically means that previous work will eventually have to be fixed because it doesn’t fit with new needs. There are clear benefits to having plans when moving forward, even if they change.

The fact that Scrum focuses so heavily on day-to-day design makes it clear that the method was created at a time when the importance of design in development was not properly understood. When looking at Scrum through the lens of the design maturity model, it becomes clear that Scrum is at the lowest level in this model.

And now we have arrived at the heart of the issue. How should design work be managed in an organization that wants to be agile?

There are two ways I have seen organizations try to solve this issue. In a nutshell, you can either become a time-traveler or divide the day-to-day and long-term design between different people.

The time-traveling designer

As suggested by Desiree Sy and Lynn Miller, one way to handle design is to have designers work one sprint ahead of development. In this approach, the project begins with sprint 0, in which development focuses on issues that are not dependent on UI. This gives designers time to work on the designs for the first actual sprint. When sprint 1 starts, there will be an initial spec ready for the user stories, and the development team can start working on them immediately.

This may sound logical, but the approach has multiple downsides to it. The most obvious one is that the designer is not really part of the development team. Designers are basically time-travelers who spend most of their time in the future and come back to the present every now and then to help the development team with its day-to-day work.

This approach leads to a lot of task switching, which is highly detrimental to productivity. It also runs the risk of turning into a mini-waterfall approach in which the specs are sprint-sized but basically locked in place.

The method has its problems, but in my experience, different variations of it seem to be the most common way of handling design in agile development projects.

The separation of concept and UX designers

The other way I’ve seen this handled is to separate the day-to-day and long-term design roles. This way, the day-to-day is handled by a UX designer who can truly be a part of the development team and focus fully on day-to-day design.

In addition, the role of concept (or service) designer is introduced. These designers are not part of the development team and usually work with the PO instead. They are usually responsible for creating long-term plans, obtaining customer insight, and designing concepts. 

When it comes to actual feature design, the concept designer will draw up the initial designs that have been approved by the stakeholders, and it’s the UX designer’s responsibility to make them real-world-compatible. This means figuring out if they can actually be developed by the development team and mapping out corner cases.

While this approach solves many of the problems that arise with the time-traveling designer, it also causes two new issues.

1. It creates an extra hand-off between the two designers. Even if this is done face-to-face rather than with documentation, a hand-off is always a hand-off, and some of the information, such as the full design rationale, will inevitably not be conveyed.

2. Who can change the design? As noted above, the Scrum development team should have the independence to solve problems as it sees fit, but with this approach, it’s not exactly clear who has the last say on design matters. If the concept designer has gotten a sign-off from stakeholders for a specific design, how much can the development team change the design before it has to be checked again? 

And if we are sticking with these roles, will the UX designer then tell the concept designer about these problems, and who will talk to the stakeholders about them? Either way, it creates an extra layer of complexity.

Also, having two designers is something that many smaller projects simply can’t afford.

The wrap-up

Small and nimble organizations can probably get great results with design-oriented agile frameworks like Lean UX. This is especially true for startups, which have few stakeholders and aim to build stuff fast and learn. 

In these cases, the need for long-term design is minor. But when the organization grows and becomes more complex, the need for more systematic long-term design increases, and this tends to break current agile frameworks.

I’ve discussed two of the most common approaches for solving these issues, but neither of them is perfect and each comes with its own set of problems. There is no silver bullet in this regard, and the best choice will always depend on the organization itself. As the agile manifesto nicely puts it: “Individuals and interactions over processes and tools”.