Designer’s four roles in agile development
Design has four distinctive roles in agile software development. If you are a business owner, a design manager, or an individual designer, you must understand these roles and ensure that you have proper resources for each of them.
Design is agile’s heel
When the agile software development movement was conceived [1], designers weren’t there. Agile methodologies, such as Scrum, don’t really take into account that there’s a specific professional activity, skill set, and a role to design the customer-facing user interface for the software under development.
The traditional human-centered design process (see eg. [2]) is not really compatible with the agile process. Therefore, design activities have been retrofitted to the agile development process, resulting in a process that is not optimal for design.
The prevalence of current software development practices means that the role of design is not likely to change in the near future. Therefore, designers must make the most out of the current process and find the best ways to contribute and do their part in the agile development teams.
In case you are interested in digging deeper into this mismatch of development and design processes, I have written a longish series of posts on this topic [3].
Four roles of a designer
Design has four roles in the agile development team: concept design, product design, design support and design validation.
It is important to recognize these roles because they all directly add to the workload of the designers. Understanding the variety of design activities helps set the priorities and allocate time between the different roles. This is a prerequisite for the quality and the efficiency of design and the whole development team.
It is very difficult for one single designer to master all four roles simultaneously. There need to be enough designers so that they have the time and resources to perform well.
Design has a direct impact on the efficiency of the whole team, not just for the design quality. Under-resourced design means more development tickets put on hold, slower development of features, and more re-work and refactoring between releases. This underestimated impact of design could be a topic for another blog post later.
(Note: in this post I refer to development sprints. If you don’t use a sprint cadence, the same principles are still valid.)
Role 1: Concept designer
The first conceptual designs are usually designed outside the fast-paced sprint cycles of the development. This does not mean that the designs will be pixel-perfect and ready when the development starts — this would be the abhorred BDUF — Big Design Upfront. However, without a rough concept or user interface framework it will be difficult to start any development work or detailed design.
Quite often this concept design phase runs in parallel with the development, yet outside the development team. There will always be new major releases or new services coming up that require a proper concept design phase before they are ready for development.
This role includes a wide range of design activities, such as
- Setting the UX vision for the product
- Overall concept design: research, design, prototyping, validation
- Working closely with the product management (PO) with product definition
- Helping to split the designs into manageable parts and roadmaps for the product backlog
- Identity design and branding
- Design system development
In this role, the designer aims at defining the concept so that it fulfills the three lenses of innovation (see [4]): it is desirable, it is implementable, and it provides a solid business.
Role 2: Product designer
The detailed designs should be mostly ready before the implementation starts. The developers can get right to work without needing to wait for the designs to be finished. Any significant design changes during the implementation will mean unnecessary re-work for the developers.
This does not mean that the designs should be pixel-perfect and specified to the tiniest detail. It is much more efficient to fix small details during the implementation. Especially if the team has a good design system in use, it is enough that the designs are just indicative of the exact visual appearance or positioning of the UI components.
Quite often the teams agree to work in a manner that the designs are finalized right in the previous sprint before the implementation starts. Therefore, during any sprint, the designers will work on the designs of the next sprint or two.
It is not a good idea to design too much ahead of development. If requirements change in the meanwhile, these designs will need to be re-designed, which means wasting design time and resources.
When the collaboration with developers is smooth [5], you can use time more efficiently, adding hopefully some prototyping and user research in the tool palette. Unfortunately, during hectic development projects, there’s usually too little time for this. This is one of the symptoms of the incompatibility between the design process and agile development.
Role 3: Design support
The designs should be ready when the development starts, but as mentioned already, there’s no need to specify each pixel. Therefore, during each sprint, the designer needs to work closely together with the implementation to iteratively make the designs better, to fill in gaps, and to answer any questions that the developers may have.
This is often the most fruitful and enjoyable part of design: to work in a symbiosis with the developers to come up with even better solutions, iron out the wrinkles, and give the design the final polish. The final touch to the user experience is created in this phase by implementing the details just right.
This is, of course, takes a lot of designer’s time. It is also time-critical: you need to be available right there and right then when the questions, new ideas and opportunities arise. This means that any other work will be interrupted frequently.
Role 4: Design validation
When the designs have been implemented, it is a good practice to validate them. The validation can take several forms.
The implementation can be reviewed in the development or test environment. It is a good idea to include this into the “definition of done” — implementation is not ready until it has been reviewed and okayed by the designer.
Even better, if it is possible to arrange user tests using the implementation still running in a test (or staging) environment, this can give the product team and the product and business owners a good understanding of whether the implementation is ready to be released, among other insights to the user’s needs and desires.
The most reliable way for evaluating the designs is to test them in the wild: just release them. After this, you will have several ways for collecting the feedback: formal evaluations (f2f or remote usability testing), surveys, analytics, and optimization of the features with A/B tests. All of this requires the participation of the designer responsible for the features as they are the experts on the hypotheses, the success criteria, the potential alternative solutions, etc.
Recommendation 1: ensure enough design resources
At any moment, there are four roles that design must fulfill simultaneously: concept design for next releases, product design for next sprint, design support for the current sprint, and design validation for the previous sprints.
Imagine a development team that has only one designer. This designer is responsible for all four roles at the same time. How do they manage their time between all the competing activities?
I hope that visualizing the four different roles of the designer will help you to convince the management that one designer is simply not enough. In my experience, a relatively good working solution is to have two designers within the development team of 5–8 developers. Optimally, the designers have slightly different skill profiles: the other one more for interaction design (research, concepts, wireframes) and the other one more leaning towards the visual design (identity, design systems, detailed layouts, animations, and sound).
If there is more than one agile development team working in parallel with the same product or service, it makes sense to have one or more additional designer focusing in the concept design activities. On top of these full-time designers, it helps if there are further specialists available to help with copywriting, user research and testing arrangements, etc.
Having more than one designer in each team makes a lot of sense also for continuity and risk management. What if the single designer would leave? If you have two or more, you can ensure continuity for example introducing designer pairs like in the excellent case description of ODA [6]
Recommendation 2: stay as one team
The bad news is that according to my experience, scrum masters are often not so familiar with design as a profession so that they could facilitate the prioritization of design tasks.
Therefore, the designers must be very proactive in managing their own work. They often manage their own time and allocation completely outside the backlogs or Kanban boards of the team. A better solution would be to require that design activities are planned and tracked with the same rigor as for the development tasks.
There seem to be two primary models for planning design: separating design to their own track (so-called “dual-track model”, see [7]) or integrating design with the rest of the team. My strong recommendation is to aim for the integrated model.
Design and development should both be equally responsible for the quality and the efficiency of the team. When you truly collaborate, the designers and the developers feel equally the ownership and the responsibility to deliver high quality working software on time.
Separating them on different tracks will eventually mean mini-waterfalls within the team, and a mental split into two sub-teams instead of being one coherent and collaborating team.
Summary
Design has four parallel roles in agile development. All of these roles are needed in order to deliver high-quality products efficiently. It is important to allocate enough designers to the development, because taking care of these roles requires a significant amount of design time. It is equally important that the management and the facilitation of the development process take these four roles into account so that the design activities can be planned, tracked, and explicitly improved.
In this way, the designers in the team can work efficiently, stay committed, enjoy their work, and produce the best designs of their lives.
Literature
[1] “History: The Agile Manifesto”, agilemanifesto.org
[2] “What is Human-Centered Design?”, by DC Design, 2017
[3] “Re-thinking design thinking”, Panu Korhonen, 2019
[4] “Is your project too human-centric?”, Panu Korhonen, 2021
[5] “Designer’s Guide to Working with Developers”, Panu Korhonen, 2018
[6] ”Principles for building the Oda UX design team”, Mike Jones, 2021
[7] “Dual Track Development is not Duel Track”, Jeff Patton & Associates, 2017
