Re-thinking design thinking part VI: Going agile

The current design thinking process is rigid, slow and focuses on wrong things. In the previous parts of this series of blog posts I have described why the current process is flawed and how it can be fixed.

During the summer there has been some quality time to catch up with past publications in design research, to discuss the process proposals with colleagues, and to let the thoughts about the process settle down a bit. In this post I will discuss how we can be more agile in design: what can we learn from the modern software development and can we use the ideas from there to describe better the new design process.

For those who have shorter attention span, I have drafted also a quite compact Slideshare version of the long story so far.

From a waterfall to agile

A typical way how design teams have organized their short and long term activities is so called dual track agile. The short term design is done in very close collaboration with the implementation team alongside their implementation sprints. A longer term design is required for designing larger concepts and more profound thinking, because these require significantly longer before the designs can be brought into the short term implementation cycles. The old phased design thinking process model has been intended for this up-front long term design.

The new design process for the long term track will also be inspired by selected tried and tested practices from the agile software development. Agile software has already introduced lots of useful vocabulary, visualizations and practices that we can use in the design process. Furthermore, my hypothesis is that if the design thinking is formulated as agile it will be easier to align with the product development processes in the long run.

The new design process can be visualized by turning the old design thinking process chart 90° degrees and split to sprints. These sprints are relatively short work packages. A suitable length of one sprint is 1–3 weeks. For each sprint, we decide which of the activities we do: do we empathize, define, ideate, prototype, or test (I’m using the old vocabulary here for clarity), and more precisely which methods to use.

You don’t need to do all five activities in one sprint. For example, in an early sprint you can do only a specific user study (empathize), and maybe a little bit of brainstorming for possible solutions (ideation) on top of that. In a sprint later down the process you may put most of the emphasis in designing the details of the service (ideate) together with iterative prototyping.

If you like, you can borrow more practices from agile, for example maintaining a backlog of tasks, in the order of priority. Naturally there’s no point in trying to use the whole Agile methodology, as it’s intended for other purposes than design.

Note that these sprints are not similar to the Design Sprint by Jake Knapp, where you solve relatively simple design topics by squeezing all activities to fit a mini-project that lasts less than a week.

This formulation of the new process highlights the fact that the methods that we use in design are still completely valid. The new process model doesn’t require any new skills or tools for the designers. It redefines how and when we select the methods and how we can fluently iterate the design at any time without being limited by the phases of the old process.

Using familiar terminology from agile helps us convincing our stakeholders to take the new process in use, because moving to agile has been generally accepted in software and has proven to be much better alternative to the old waterfall model.

Outcomes in the new design process

The old design process describes only activities but not the outcomes. Here above I intentionally ignored this point for a moment when describing the new agile design process.

In earlier blog posts I have described the design arenas that are collective co-evolving outputs of all the activities in the design process (and inputs too). In the beginning of the process the design arenas consist of initial assumptions, ideas and hypotheses. These will be evolved throughout the process. We will increase our confidence level in each arena through design activities and validations until at the end we have a solid set of the results of artefacts supported by the knowledge of the purpose, beneficiaries and the evaluations. Remember that the first description of the design problem is part of the canvases, and the problem evolves during the process just as the solution does.

As a summary, we can visualize the new process as follows.

Typical contents of the design sprints

It is up to you to decide what to do in each sprint. Choose the activities that best increase your confidence in the design arenas. Don’t let any of the design arenas to be left behind. Otherwise you will accumulate debt that you need to pay back later.

I think we will see some practices that keep repeating across projects. For example, in the first sprint — called sprint 0 similarly to the software development — we set-up the project. We list our assumptions, do inventory of existing materials, create the design arenas canvas and kanban boards (presented in the previous blog post), etc. In the following there are some ideas how to structure the sprints, but as said, it’s up to you.

**Sprint 0
**Who do we expect to be the beneficiaries?
What are the purposes of the outcome? How will it benefit the beneficiaries? What are the metrics?
Are there existing artefacts? Do we have ideas for the new artefacts? What are the technical, organizational and legal capabilities and limitations?
Are there earlier relevant studies and evaluation reports?
Create the first design arenas canvas and kanban board

Sprint 1…N-1
Select the items of least confidence among beneficiaries, purposes, artefacts, evaluations.
Review the available people vs. needs and time/resources left.
Plan the activities and select the actions and methods for this sprint. Plan tentatively ahead for the next couple of sprints.
Update the design kanban board
Perform the planned activities. Keep design arenas canvas up-to-date
Review sprint results
Arrange a sprint retrospective

Sprint N
Review and release the final version of the artefacts.
Review the status and initial designs for the next releases.
Review purposes as targets for post-release metrics and targets for next releases
Plan for post-launch evaluations with the beneficiaries: tests, surveys and analytics
Arrange a project retrospective

Still not convinced?

The typical argument against changing the process model is that the current model works fine: we just allow enough iteration back-and-forth between the phases. I still think that using the old process model is detrimental. It invites us to retrofit our process to the rigid, phased model. Visualizations and vocabulary are the tools that we think with. The least we can do is to update the process visualization to correspond to the way we design. Any improvement in the process starts from being honest.

If you are sceptic (which is fine, we need good debate and solid argumentation), try this small thought exercise: if you follow the old design thinking model, do you ever do two different phases at the same time? For example, do you ideate while you empathize? According to the old process model, you cannot do that: you are always in one phase at a time. I’m quite sure, however, that in reality you do many of the phases in parallel. The corollary question then is: what would be a better visualization for the process that would naturally allow and possibly encourage doing this? The old model certainly encourages you not to.

Another thought exercise that you could do: think through one of your latest design thinking projects. If you draw a timeline of that project and place on it all the design activities you did during the project, which process model better suits for describing what you do? Can you map the project better to the old process model or the new one?

Let me know and keep discussing and challenging the model! Good argumentation will help us all to understand and develop how we design and make us all better designers.

References

1. Dilemmas in General Theory of Planning. Horst Rittel, Melvin Webber, 1973
2. The New New Product Development Game. Nonaka & Takeuchi,1986
3. Design isn’t a Shape and It Hasn’t Got A Centre: Thinking BIG About Excellences in Post-Centric Interaction Design. Gilbert Cockton, 2013
4. New Process, New Vocabulary: Axiofact = A_tefact + Memoranda. Gilbert Cockton, 2017
5. New Language, New Design. Otso Hannula, 2018
6. Generative metaphor: A perspective on problem-setting in social policy. Donald Schön, in Metaphor and Thought, 1993

Panu Korhonen is a designer at Nordkapp who sometimes wonders why things are done the way they are done.

In his projects he wants to create designs that save the world.