Software development has been revolutionized by Agile development practices, but designers struggle to adapt to the very same techniques—despite suffering many of the same challenges that led to Agile. What exactly are these problems? And how can Agilists and designers address them?

When is Design Done?

Agile development preaches “Done means Done”. When a story is accepted by the Product Owner, it’s ready to be deployed out into the world. What does “done” mean for design? Automated testing guarantees that on every story, developers will enjoy Acceptance Criteria: a concrete measure of what counts as “done”. Designers, on the other hand, rely on subjective criteria to determine when they’re done. In the best case, this means the product team—or often, the designer working alone—if only they had a partner to pair with! In the worst case this is purely subjective sign-off from the client. While agile developers have access to tools like velocity to plan their work, designers have structural difficulties in estimation, and are consequently less able to plan. Consequently, questions like “when will that feature be done?” are more easily answered by a developer than a designer. That’s not because designers are less responsible than developers. It’s because it’s harder to know when you’re done with design—but that’s of little comfort to anyone who needs to budget time and resources to manage the project. Because Acceptance Criteria—or an answer to the question “what does ‘done’ mean?”—for design is in different units of work than “done” for development, there’s an impedance mismatch in coordinating between the two. Breaking design into units of work with more discrete Acceptance Criteria helps coordinate design work with development work.

What’s Wrong with the Deliverables Business?

Agile Developers ultimately deliver user-facing code, but designers output thinking: solutions to design problems, traditionally expressed via mock-ups or assets. How should the two interact? Should design stay an iteration ahead of development? What does it mean when a developer discovers an interaction problem in a design they’re implementing? Should they stop work? Developers are the tip of the spear when it comes to experience design: in the process of building software, they’re often the first people ever to use it. Sometimes this means they uncover interactions on UX problems that the designers didn’t anticipate. If the necessary design changes cascade into other work, what should the designer do: stop work and refactor (and fall behind), or come back to it later?

Furthermore, it can be difficult to determine how much design is required for developers to complete their work. The best design deliverable is the Simplest Thing That Can Possibly Communicate the Design Solution, and this can vary from team to team and design problem to design problem. Under ideal circumstances, an experienced designer may be able to reasonably estimate how long it will take to 1) solve the design problem, 2) communicate the solution, and 3) iterate on the problem / solution once it’s usable and testable as working software. But. BUT! That’s asking a lot. And it absolutely shreds the question “how far ahead should design stay of development?”.

Why do Designers Feel Unwelcome in Agile?

Let’s take stock: we’ve got gallant developers, accurately estimating stories and delivering working software, and the goofus designers, unable to tell you what they’re doing or when they’ll be done. Knowing “how much design is enough?” is hard. Knowing how much design to start with is hard. Reared in a culture that prizes individuality, that venerates Rock Star Designers, that applauds Working On It Til Its Done, that publicly shreds less-than-perfect work in Crit as a rite of passage, that (with the occasional exception) is alien to the notion of sustainable development—it shouldn’t be surprising that designers are uncomfortable. That starts to lead to discord on the team: designers hating agile; feeling rushed, feeling like they don’t get the benefit of iterative design; feeling that once they touch something, they don’t get to go back and refactor it. Let’s throw in a bit of rah-rah agile ideology, a few jargon-y IPMs and retros, promises that “we’ll come back and refactor that later”, and the creeping suspicion that this whole Agile thing is nothing but smoke, mirrors, and Kool-Ade. Is it any wonder that designers can be hostile to agile?

What can we do? Looking to the example that Agile Development sets, we can see several concepts that may help: Acceptance Criteria-delimited design stories. Meaningful estimation of work for design. A culture that values Sustainable Pace. Translating these ideas from development to design may do more than just help designers work more comfortably in Agile environments—it may help us practice better design.