Quite recently, I was faced with the problem of implementing my design process into the Agile methodology. The topic is as old as the hills, but in practice I came across Agile only when I worked as a front-end developer. Then the work process was quite clear and intuitive for me. But after spending 8 years as a responsible and independent designer, I discovered that the design process is excluded from classic Agile.
The key reason for such difficulties is in the own idea of the framework: it was created not so much to make the product more customer-oriented (for which design and UX are in fact responsible), but to speed up development.
After searching the Internet, I was pleased to learn that a solution to the problem has existed for a long time. And here I want to share it.
You're welcome :)
Actually, the problem itself is a combination of two development specifics:
1. Iterative work of developers. In Agile, developers build and deliver a project “piece by piece”, in separate iterations.
2. “Integrity” of the designers’ work. Designers involved in designing complex interfaces according to all the canons of UX prefer to think through and develop the entire concept. Accordingly, when the complete concept is ready, they transfer it to development. This approach forces designers to get out of the general rhythm, which creates problems with the distribution of working time.
Let's start with the fact that the design process itself can be thought of as an iterative process. According to the diagram by James Garrett.
Conditional division into levels (from basics to details):
- The strategy level is dedicated to getting such important information as customers’ and business users’ expectations from the product..
- The product functionality follows the strategy. On this level, it is crucial to understand what should be done and what should not. The functionality should help the customers and the business to reach their goals.
- The next thing after describing the required functionality is the information architecture and interaction design.
- Having a great structure for the product, we move on towards developing its functionality. On this level, we understand more about how the product will look based on how it works. The information should be displayed to the customers in a correct and useful way, and represent all their needs at the moment. It should be neither redundant not insufficient.
- The surface level is the most important one since it determines the product’s appearance. This is where the UI elements and the overall design is created (i.e., fonts, colours, layout). At this level, all the ideas described and clarified on the previous four levels melt down into a form.
So how to combine this design process and the work of developers in Agile?
The answer is design and development in two flows.
Initially, the project is planned including “Sprint Zero”, during which the general design concept is developed and elements for the first sprint of development are drawn. After that, during the first sprint, the developers deal with ready-made materials from the designers, and they create elements for the second sprint. And so on.
This turns out to be the following diagram:
Design reviews provide insight into future progress and help set priorities for both the product and the next sprint.
Design spike
When an unclear task appears in a sprint with a bunch of potential problems and undefinable complexity, a spike is taken on instead. A spike is the work required to provide an answer or solution, not to roll out a feature.
What's good about spike:
1. Helps to work in conditions of uncertainty and ambiguity;
2. Removes the need to “do something,” but at the same time motivates to eliminate uncertainty;
3. Eliminates under- or overestimation of unclear tasks.
Designers are constantly faced with unclear tasks: “design a dashboard”, “you need to make it convenient and attractive”, “try to play some more”.
Such tasks are difficult to evaluate because there is no understanding of what exactly needs to be done. The assessment can be made by eye, but there is a risk of screwing up deadlines or rolling out crude nonsense. In fact, this is additional time for research, studying information for a clearer understanding of the approach for further development and more accurate assessments of the current task.
Design are focused on design tasks from the backlog - development has nothing to do with this stage. The timing of design spikes is not regulated in any way, but the team should strive to complete the spike as quickly as possible. After completion, normal Agile continues.
Summary:
1. To integrate design into Scrum, it is enough to put basic design activities onto the standard Scrum process.
2. An in-house designer within the Scrum team is a prerequisite for integrating design into the Scrum process.
3. To integrate design into Agile, zero sprint and parallel flows are a good working solution.
4. Design spike is a crutch for teams that do not know how to communicate and verify requirements.
Sources:
https://medium.com/@smidesign/5-levels-of-the-user-experience-design-by-james-garrett-e90f4ee24b8d
https://www.smashingmagazine.com/2012/11/design-spikes-fit-big-picture-ux-agile-development/
https://medium.com/option-zero/what-is-a-design-spike-7906385663c2
https://jeffgothelf.com/blog/here-is-how-ux-design-integrates-with-agile-and-scrum/
