Design Thinking in Product Development

It doesn’t always have to be a workshop – design thinking methods in product development.

You don’t have time for design thinking workshops that last several days and can’t completely excuse a development team of five to seven people? It’s a good thing that individual Design Thinking methods can be specifically integrated into development processes. In the following I will tell you about my experiences with the targeted use of Design Thinking methods in product development.

A brief overview of Design Thinking

The topic of design thinking is no longer just an up-and-coming hype, but common practice in many companies. Behind it there is a framework process, a multitude of methods, but above all a mindset. It is about dealing with a problem, a design challenge, in an interdisciplinary team. The goal is to come up with really helpful, possibly unconventional solutions. In contrast to many other approaches, the team does not move directly in the solution space and collects ideas, but first penetrates deep into the users’ world of needs. What do they really need? What are their current pain points? What are their views, motives, reasons? Only when this information is made available is it possible to move jointly into a process of creativity, design and feedback, in which a lot of experimentation takes place, things are discarded, lessons are learnt and, above all, the process is built on one another.

To arrive at such solutions in the end, Design Thinking goes through a process with the five phases empathise, define, ideate, prototype and test. The most common way of doing this is to hold Design Thinking workshops or Design Sprints, in which the phases are run through at once. From my own experience I can say: this intensive work is definitely worth it! The resulting findings are always surprising and promising. Nevertheless, I also know: especially in projects there is often a time, budget and/or resource problem. It can be difficult to get a team of 5-7 people out of everyday project work for three or even five days at a time.

Does that make it impossible to use Design Thinking? Of course not. My experience is that individual Design Thinking methods can also be used specifically in the software development process without having to go through the entire Design Thinking process at once. How we do this at Itemis I like to explain using the example of our product development.

Design Thinking Methods in Product Development

Briefly to my background: I have accompanied the product development of the YAKINDU products at Itemis for almost four years as a usability engineer, i.e. my main task is the representation of user needs and the design of an intuitive user interface. From usability engineering I know how important it is to first deal intensively with user needs, as this is the only way to ensure that a product is accepted and being applied by the user. Design Thinking is therefore not at all new to me: it packs familiar methods from usability engineering into a somewhat differently structured process and supplements them with a variety of other methods. That’s what makes the topic so exciting for me. That’s why I decided to deal intensively with this topic and to continue my training as a moderator for Design Thinking Workshops. I find it fascinating to see how the participants in these workshops develop their own dynamics, motivation and energy over time to solve a problem.

However, when I think of my job in product development, in which I am responsible for several products, my teams and I don’t always have the time to hold workshops lasting several days. So I started to introduce individual Design Thinking methods into product development as needed:

Interviews – Targeted inquiry of user needs

When it comes to understanding what users really need, there is no way around contacting users directly. The best way to do this is through interviews. Interviews can always be used: if a new feature is to be developed, I can prepare guiding questions that address exactly this aspect. But even if I want to find out where users’ shoes are pinching, I let them tell me how they are currently doing their jobs and then drill into the depths to get to the core problems and needs. The advantage is that you don’t need a process or a long workshop to use interviews. You just do it.

When we develop the YAKINDU Model Viewer, a tool for viewing Matlab Simulink models, we address the calibrator user group, for example. We first wanted to understand how this user group works and what they do with the product. So we interviewed several calibrators and learned a lot, including that they travel a lot in the car and use the product on their laptops – without a mouse. Simple keyboard operation is therefore essential for this user group. This directly created a Design Challenge: How can calibrators interact with the YAKINDU Model Viewer exclusively with the keyboard in order to be able to quickly perform a malfunction analysis in the vehicle?

Creative methods in a team – collecting solution ideas

Once you have identified such a need, you can move on to the creative space. While interviews can easily be conducted by two people (an interviewer and a recorder), I believe that creative methods work best in an interdisciplinary team.

For the Design Challenge described above, we have set up a somewhat more extensive four-hour creative workshop because we wanted to address as many use cases as possible for keyboard operation. Participants were the project manager, three developers from the Model Viewer team, two usability engineers and one developer of another product. The basis for the workshop was the “tower of ideas” method: we set up ten stations on the walls of our room, each addressing a use case, e.g. the search in the model. For each use case, an idea was to be developed as to how keyboard control and visualisation could look in the tool. Each participant had five minutes to put their thoughts on paper for the Use Case. In the next round, the ideas of the previous station visitor were built upon and supplemented with their own ideas. In the end, many different solution ideas were developed for each station. At the end, these ideas were discussed, aggregated and finally prioritised as to which ideas we would like to continue working with.

It is precisely these and other creative methods that are known from design thinking that can always be used quickly in the development process. We regularly conduct design studios, for example, which last about two hours. In short iterations we scribble individually, present and evaluate the ideas to the team and then build on the ideas of the others in a next iteration.

Building prototypes and collecting user feedback

We have an idea, but what now? Design thinking is about making ideas tangible and comprehensible in order to gather feedback from users. The quickest way to do this is through prototypes. A prototype can look very different: it can be a quick implementation, a paper prototype, a click prototype or a play.

We constantly use prototypes in product development because they are easy to create and allow quick feedback. For example, we are currently working on optimising the tool start-up of the YAKINDU Model Viewer. We have developed a concept for this and implemented it in the “UXPin” tool as a click prototype. Such a prototype can be done by one person in a few hours – so there is no need for a large team and a workshop.

To get user feedback, we took our click prototype to a usability test dinner – an evening event where users evaluate applications and prototypes in short, 10-minute usability tests. Independent of such events, we also organise usability tests ourselves in order to get feedback. They can be integrated into the development process at any time.

Individual, outsourced methods – does that work?

I think, as you can see from the examples, the individual methods from Design Thinking can be used quite easily separately from each other – it doesn’t always have to be in one piece. And you don’t need a team for all methods.

But there are a few things that are important for it to work:

• there should be one method from each phase of Design Thinking. A start with creative methods without having understood the user’s needs increases the danger of developing completely without the user.
• Communication is everything: for the methods to work, knowledge transfer must be guaranteed. If interviews have been carried out, all project members should know the needs of the users.
• Creative methods should be carried out in a team – together they are more creative and can build on the ideas of others.
• All project members should have a basic understanding of the design thinking process so that they understand what makes sense when and how.

Sounds good? It is! And it helps to improve the products. But there is also a little “but”: Even though I have had very good experience with outsourcing methods, one thing is lost: the team dynamics and the incentive that arise in Design Thinking Workshops, where several days are spent working together in a concentrated manner, do not come out so strongly when the methods are shifted over time. However, this can sometimes be the decisive factor in finding a truly innovative solution.

Notes:

Information about YAKINDU can be found at https://www.itemis.com/en/products. More blog posts by Sandra Schering can be found in the Itemis blog at https://blogs.itemis.com/.

Sandra Schering has published another post in the t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.