What if..

An iterative design process is no straight line. Designing is like a river meandering to it’s end goal, the sea, yet for hundreds of kilometres it is unknown which sea that will be. This is hard for designers, but even more for clients and the rest of the outside world, who want to get a grasp of what ‘their’ designer is doing. It would be nice to have concrete goals to work towards during the design process instead of this vague fuzzy product which will satisfy the brief in some unknown way. How can designers pinpoint these goals during an iterative design process in order to better communicate their designs and give structure to their design process?

There are many ways to go about when designing products and interactions (van Boeijen, Daalhuizen, Zijlstra, & van der Schoor, 2013). The basic design cycle methodology for example highlights the different consecutive phases of a design process, and stipulates that each phase should be carried out one after the other (Roozenburg & Eekels, 1998). This linear process works well for the ‘ancient’ profession of industrial design where the product designed was often known and many formal requirements can be written down. However, it is more difficult to apply to current projects based on design for interaction, as the explorative nature of these projects does not work particularly well with a prescribed rigid structure. As a result other types of methods have been developed, more focused on concurrent phases carried out during the design process by multidisciplinary teams (Jaskiewicz, 2015). This method works very well when you are exploring different ideas and routes to solve your design problem, yet leaves out the start and end point of the design process. As there are no formal requirements, an evaluation of whether the design is finished is difficult to perform. The question that arises is: when is my design finished?

A way to solve this would be to build in reflection moments after every single iteration. These reflection moments include just three questions regarding the past, the present and the future. This will help to formulate better concrete subgoals to work towards, and allow for more structured exploring. The first step would be to consider the past: what have we done? Designers tend to always look forward, yet looking backwards is where you can gain interesting insights. First, you can learn from the mistakes that you made during the process. This can help you to become a better designer and it helps to avoid making the same mistake later in the process again. Secondly, you can trace back the road that you travelled. Which parts of the design did work, and which part did not? It can happen that the current concept is in a dead-end, so reverting back to an earlier iteration would help bring back the spark. But when you never take time to look back, it is very difficult to pinpoint those interesting iterations (or to even realise that you are in a dead-end).

When the decision has been made to move on with the current concept, it is time to explore the present: what have we got now? This question is usually skipped as it is deemed redundant, but it is essential when determining whether your design is ‘finished’. By taking the brief in one hand and the design in the other, the quality of the design can be determined. But of course the focus should not only lie on the brief and whether it satisfies it. Also the quality of the interactions embedded in the concept have to be well designed. User testing can help to see whether users understand the mechanism of the concept, and whether your design makes sense and can be appropriated by the user. If all these indicators are positive the design can be reckoned as finished.

But after most iterations it is not the case that the design can be considered as ‘finished’. It is then time to place a new goal on your horizon using the question: what can we do now? It is often a reflex when iterating to keep many factors constant. But when make some big changes this can spark interesting ideas. For example, what if we could use this mechanism in a completely different context. Or what if the use of the product can be for something totally different. Often the most ridiculous ideas result in the best concepts (after some iterations and toning down). The reflective question can in this case guide you to unexpected locations where you would have never gone when you did not specifically think about it.

Taking the time to step back from your design during the design process can help in many ways. It makes you a better designer by becoming aware of the mishaps that you made during the process. It also gives you structure through the use of intermediate goals, which can also help to better communicate your results and process to clients and other people. Finally it gives you handles on which you can define your design as finished without having to make a formal list of requirements. Reflecting can give you the necessary structure in the design process while still maintaining the freedom of an open and lean iterative process.

Written for the Interactive Environments minor, as part of the Design strategies course at the TU Delft.

Works cited

van Boeijen, A.G.C., Daalhuizen, J.J., Zijlstra, J.J.M., & van der Schoor, R.S.A. (eds.) (2013) Delft Design Guide. Amsterdam: BIS Publishers. page 17 – 37

Jaskiewicz, T.J. (2015) [Iterative design process]. Unpublished/Work in progress.

Roozenburg, N.F.M., & Eekels, J. (1998) Productontwerpen, structuur en methoden. The Hague: Lemma.