Global Service Jam 2019:
From Lessons Learned to Daily Business (2/2)

Jonas Lauf
DENKWERK STORIES
Published in
4 min readApr 30, 2019

Co-written by Jonas Laufenberg and Kei Ka-hei Cheung

A month ago, we denkwerkers participated in the Global Service Jam 2019 in Cologne, Germany. Within a weekend, we worked intensively with the Service Design framework on bringing problems to service solutions. We took some time afterwards to think of how we can bring the lesson we learned out of the Jam and put it to our daily business of a digital design agency. Here’s what we’ve got to share with you! ♥

This is the second part of our collective reflection of denkwerkers who participated in the Global Service Jam 2019 in Cologne, Germany. You can view the first part here.

Prototyping for non-graphical experiences

Building high-fidelity prototypes for a service? Think twice.

by Jonas Laufenberg

As UX Designers, we design experiences for interfaces. Historically, those interfaces refer to devices such as computers, tablets or smartphones. Thus, the word “prototype” for me always implied to be something that represents a graphical interface such as a smartphone screen. There is a growing list of prototyping tools and methods out there, which help designers to quickly build an interactive graphical UI experience in no time.

Prototyping a service, however, is a much more experimental exercise. How do you prototype and test experiences that don’t necessarily include graphical interfaces? More importantly, how do you test experiences that not only consist of a single touchpoint but a combination of various kinds? During the jam I quickly realized, there is no one-size-fits-all approach. Services are not tied to one single interface or technology. Instead, it can include multiple ways of interaction that go far beyond a device screen.

Image courtesy of Kadir Kara

For example: As opposed to UI experience, a touchpoint within a service may not be a digital device at all, but could be a human being or physical object. One way of prototyping such an experience could be role playing, where participants take over certain roles that are involved in your service. To test your prototype, you simply ask your participants to play their role and pretend to go “through” the service while you will be able to observe how the service performs.

While UI prototypes help identifying problems on a graphical interface level, a service design prototype such as a role play helps evaluate the experience of interacting with other human beings. Given the complexity and multidimensional nature of such an experience, it is almost impossible to prototype and test it as granular as we would prototype a graphical interface. Instead, it forces us to work with an abstract idea that is enough to get an overall feedback from participants.

Keep the recipe flexible

Design has become accessible these days, but also complicated.

by Kei Ka-hei Cheung

Design has become readily accessible. There are numerous tools, methods and articles out there and online about how to design, be it design thinking, design workflow, design mentality, design workshop — you name it. One (almost) does not need any qualification or hands-on experience to learn about design. At the same time, design has also become complicated. With these tonnes of materials, guidelines and toolkits, it is not difficult that one can feel lost when confronted by a problem amidst this generous pool of resources.

Giphy

In the Jam, I was familiarised with the Service Design methods. Through a weekend of trial and iteration, it worked out fairly well for our team (We made space travel sustainable!); so did it for the other jammers, but quite differently. This demonstrated how adaptable Service Design can be. But now, another design framework is added to the already lengthy list of how-tos. How can we aptly put it to work?

When it comes to application of design methods, project context and challenges are the crucial factors. Understanding them clearly is a prerequisite for any flexible implementation and for evaluating their implications. In the Jam, there were teams which tweaked the Service Design methods according to their own project challenge, the issues they were tackling, and the situation they were in. Things eventually turned out well, too. Amidst the pool of design techniques and preset recipes, we could easily feel confused. This confusion could further induce fear, especially of the uncertainty, blocking us from stepping beyond the line drawn for how we should go. This is the time to call back our (designers’!) critical thinking. What are we facing here? What do we have? What do we want to achieve? How can we do it? What are the pros and cons? How about mixing A and B? If we consider Service Design framework as a recipe, we ought not to forget that we, designers, are the chef. There are tens of herbs and spices in your pantry, ‘when to take which out’ and ‘how to dose it’ would be the questions to start with, for utilizing our kitchen furnished with design techniques.

Giphy

--

--