The four main roles of a designer

” The traditional human-centred design process is not really compatible with the agile process. ”

Therefore, design activities have been retroactively integrated into the agile development process, resulting in a process that is not optimal for design.

As current software development practices are widely used, the role of design is unlikely to change in the near future. Therefore, designers need to make the most of the current process and find the best ways to contribute and play their part in agile development teams.

The 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 know these roles as they all directly contribute to the designers workload. Understanding the diversity of design activities helps in prioritizing and allocating time between the different roles. This is a prerequisite for the quality and efficiency of the design and the whole development team.

It is very difficult for a single designer to master and perform all four roles simultaneously. There must be enough designers so that they have the time and resources to do a good job and divide it among themselves based on their strengths. Design has a direct impact on the efficiency of the whole team, not just on design quality. Under-resourced design means more development tickets are put on hold, feature development is slower, and more rework and refactoring is required between releases.

(Note: In this post I refer to development sprints. Even if you dont use sprints, the same principles apply).

Role 1: Conceptual designer

The first conceptual designs are usually designed outside the rapid sprint cycles of development. This does not mean that the designs are pixel perfect and ready when development starts - that would be the hated BDUF - Big Design Upfront. However, without a rough concept or user interface framework, it will be difficult to start development work or detailed design.

Often this concept design phase runs in parallel with development, but outside the development team. There are always new major releases or new services that require a proper concept design phase before they are ready for development.

This role covers a wide range of design activities, such as

• Defining the UX vision for the product
• Overall concept design: research, design, prototyping, validation.
• Working closely with product management (PO) on product definition.
• Support in breaking down the designs into manageable parts and roadmaps for the product backlog
• Identity design and branding
• Development of design systems

In this role, the designer aims to define the concept so that it meets the three lenses of innovation: it is desirable, it is implementable and it provides a solid business.

Role 2: Visual design

The detailed designs should be largely ready before implementation begins. Developers can get to work immediately without having to wait for the designs to be finalised. Any significant design change during implementation means unnecessary rework for the developers. This does not mean that designs have to be pixel-perfect and specified down to the smallest detail. It is much more efficient to correct small details during implementation. Especially if the team has a good design system, it is sufficient if the drafts only hint at the exact appearance or positioning of the UI components.

Often the teams agree to work in such a way that the designs are already completed in the previous sprint, before the implementation starts. Therefore, in each sprint, the designers work on the designs for the next sprint or the sprint after that. It is not a good idea to design too much before development. If the requirements change in the meantime, those designs have to be redesigned, wasting design time and resources.

If the collaboration with the developers runs smoothly, time can be used more efficiently and hopefully some prototyping and user research can be added to the toolbox. Unfortunately, there is usually too little time for this in hectic development projects. This is one of the symptoms of the partial incompatibility between the design process and agile development.

Role 3: Design support

Designs should be ready when development starts, but as mentioned earlier, it is not necessary to specify every pixel. Therefore, the designer needs to work closely with implementation during each sprint to iteratively improve the designs, fill gaps and answer any questions the developers may have.

This is often the most fruitful and enjoyable part of design: working symbiotically with the developers to find even better solutions, iron out the wrinkles and put the finishing touches on the design. The final touch to the user experience is created in this phase by getting the details right.

This, of course, takes a lot of the designers time. It is also time-critical: they need to be available exactly when questions, new ideas and possibilities arise. This means that all other work is frequently interrupted.

Role 4: Validating the designs

At the latest when the designs are implemented, it is good practice to validate them. Ideally, a first or more round of validation takes place before implementation. Validation can take different forms.

Implementation can be validated in the development or test environment. It is a good idea to include this in the "definition of completion" - the implementation is not complete until it has been reviewed and approved by the designer.

It is even better if it is possible to do user testing with the implementation still running in a test (or staging) environment. This can give the product team and product and business owners a good understanding of whether the implementation is ready for release, among other insights into user needs and wants.

The most reliable way to evaluate designs is to test them in the wild: just release them. After that, you have several options for collecting feedback: formal assessments (f2f or remote usability testing), surveys, analysis, and optimising features with A/B testing. All of this requires the involvement of the designer responsible for the features, because he or she is the expert on the hypotheses, the success criteria, the possible alternative solutions, etc.