Frontstage, Backstage: How Service Design Really Works (with Marc Stickdorn)

What’s the real impact of service design on customer experiences?

In this episode of The Design Psychologist, host Thomas talks with service design expert Marc Stickdorn, PhD, author of "This is Service Design Doing," about the evolution and holistic nature of service design. 

They discuss the importance of community involvement and collaboration in shaping effective strategies and enhancing user interactions across various touchpoints.

WHAT WE COVER IN THIS EPISODE: 

- The role of community contributions in redefining service design.

- Examples of service design addressing real-world challenges, like improving grocery store experiences.

- Integrating digital transformation for cohesive customer interactions.

- Strategies to bridge organizational silos for better engagement.

- The importance of prototyping and feedback in the iterative design process.

- Adapting service design methodologies to navigate a VUCA (Volatility, Uncertainty, Complexity, and Ambiguity) landscape.

Find The Design Psychologist on your favorite podcasting platforms (or share this link with a friend): https://designpsychologist.buzzsprout.com/2395044/follow

If this show’s been useful or thought-provoking for you, I’d love it if you would do me a quick favor and let the Apple audience know! I know it takes an extra step—but it really helps new listeners discover the show, and it makes a big difference for us as we grow.

Just open Apple Podcasts, search for The Design Psychologist, tap the show, scroll down to the bottom of the page, and hit “Write a Review.”

Transcript

Welcome to The Design Psychologist, the show that helps you use psychology to design
better experiences. I'm Thomas Watkins, your guide to becoming a more powerful
psychology -informed designer.
What if you had to design a service that goes far beyond screens? Something
physical, like a curbside pickup system that might involve a text message,
but then it's also finding your way to the right parking spot, or an accessible in
-person voting experience, or even a family -friendly venue where kids play while
parents sip coffee nearby. There are countless real -world situations where a service
is being delivered. And those services don't just happen, they've got to be designed.
So where do you start with a project like that? Think about it. Think about a
system that might include screens, but the whole experience spans beyond that.
Things like buying tickets at a train station and finding your way to the platform,
or parking at a stadium, but then navigating your way to your seat. Or how about a
technician visiting your home to install some utility, like the internet? How does
that whole process play out? I mean, it's really anything. It's a baggage claim or
room service or a pharmacy pickup at a drive -thru. Is there a handbook that could
cover all these cases for designing experiences like these? Today, I'm excited to
share a conversation I had with Mark Stickdorn, who I'll introduce momentarily.
Together, we explore questions like, what is service design and how is it different
from UX design? How do you break down the rigid silos of an organization and create
a cohesive service experience? What does it mean to design the backstage as well as
the front stage? How do you actually implement service design in a real organization?
And how do you measure the success of a service after it's been implemented,
especially when the service spreads across so many different moving parts? By the end
of this episode, you'll be just a little more fluent in the wide world of service
design. And you'll also have some idea of where you might Again, should you be
lucky enough to lead one of such projects? So let's have a listen as I introduce
and speak with today's guest.
Welcome to The Design Psychologist. I've got a really special guest for today. It's
Mark Stickadorn, PhD. He is an award -winning author, a keynote speaker, a coach,
a trainer, and an expert in service design, which is our topic for today. Back in
2019, he published an award -winning book, This Is Service Design Thinking, co
-authored by Jacob Schneider. He teaches service design in university settings as well
as industrial settings and corporate settings. Today, he is CEO and co -founder of
More Than Metrics. He lives in Austria among the European Alps, and we will be
talking with him today about his more recent book he published in 2018 that he
wrote along with a total of four co -authors, the other three being Mark, I'm sorry,
Adam Lawrence, Marcus Hormez, and Jacob Schneider, and also along with a wonderful
community of service design practitioners who added important bits and pieces
throughout the book. And that book is This Is Service Design Doing, which is widely
regarded as the authoritative standard reference on the field of service design.
And we are speaking with author, Mark Stickdorn, PhD. Mark, welcome to the show.
- Wow, what an intro. Thanks Thomas, thanks for having me. - Yeah, what a career and
what a book. I can't wait to dive into this stuff. - I have to admit one thing.
I'm doing my PhD now since 12 years and I'm almost done, but I'm not yet done. So
- I can't use the title yet. - Gotcha, okay, so I did see it, no judgment, but I
did see in the book, I said, "I'm almost there." So I was like, "Okay, I'm gonna
say..." - I'm still almost there. - Yeah, yeah, no, if you're working full -time job
and you got that career, it's kind of, you know, two hours a week, you work on
your dissertation. So, is there anything in order for us to understand who you are
professionally, is there anything you'd like to add to that intro, any background for
the audience? Well, what some people think is interesting is, um, is my background,
where I'm coming from, um, because originally I was working in the tourism industry
and I, so I worked hands on the tourism industry. I, like many years ago,
I used to be a surf teacher and a snowboard teacher. And I, I managed like, uh,
sport camps and, and, and resorts and stuff like that, and I studied strategic
tourism management in school. Like, I'm not a designer in my first career.
I was like management, right? And then I worked in innovation, and I learned the
hard way that what I got taught at a very traditional German business school has
nothing to do with reality and innovation, right? What I learned at school was like,
write a business plan and execute. We all know that doesn't work like this. So I
found my own ways of handling things. And Jacob, the co -author of those two books
you mentioned, is actually a designer by training. And only once we had chats about
how he is working, I got into the field of design. And once I learned there's a
thing called service design, I finally found my community. And I really felt Like a
boy opening a box of toys like suddenly I had names for things and way more stuff
to do, but I Was working that way I didn't had a name for it and that's got what
really got me then into the into design and the PhD now is actually on Design
research and so and so also academically I got into the field at some point Gotcha.
And now it's really interesting. You bring up the co -author and then this book has
You know, as I mentioned before, the four co -authors in the big community, I love
that because it's like a tacit admission that no one person is going to be an
ultimate expert on such a wide field. This field is so huge in the application and
use cases. Tell me a little bit about that. You know, you talk a little bit about
it in the beginning of the book, but in terms of how that came together with
getting this big community of folks pitch in and add their knowledge to this work.
>> Well, it's exactly along the lines what you just said, like no one has the
authority to define what service design is and how it works on their own because
it's such a wide field and there are so many different ways to tackle things, so
many different tools and methods we can use, and there's no design pros that's
looking alike. So we needed to involve the community. And we already started with
that, with our first book that we published in 2010, where we at least invited 23
other co -authors. We thought we need more for this one. So we invited around 100
people who contributed case studies to the book, who wrote certain parts of the
book, besides the four of us who were, or the three of us as the main authors and
Jacob as the graphic designer of the book. And then we invited more than 200 more
people who reviewed the chapter. So what we've done is we put chapters that we
thought, okay, we're almost done. We're almost there now and put it on a Google
Doc. And per chapter, we invited 50, 60 of those viewers who then went through the
whole document and added comments to it and suggested changes. Sometimes there was
more text in the comments than the actual chapters because people had really long
discussions, academic fights about things like how things should be called and what
works and what doesn't. We tried to capture that as Well, if you look at the book,
you see site notes where we have expert tips and people saying, "Well, this is one
way to do it, "but this is another way to do it." Or, "I don't agree with this,"
or, "I agree with this." So we actually wanted to show this discourse that we are
having as a community. - Yeah, absolutely. And so, thinking about service design,
coming from a UX background and the audience in the show, We cover all different
kinds of applied psychology. Give us some examples of big problems and tiny problems
that would be solved by service design. - Oh, tiny problems could be,
well, think of any tiny UX problem and then think of other channels where this
problem could happen as well. What we do in service design is we look at all the
channels and UX, even though maybe not originally, but how it's applied nowadays is
dominated by the digital channel, right? Interfaces. That's what we're doing. And when
you look at tiny things, they're like, let's say, check out. Think about what are
other channels we could have the same issue? How is the checkout at a kiosk? How
is the checkout in a face -to -face conversation? So We try to understand and make
sure that no matter where people cross a channel, they have a similar experience, a
similar look and feel. But most importantly, make it work for them and for the
employees. So we always look at both sides, at the customer side and the employee
side. So it can be a tiny things like a detail at one channel, at one interaction
that we're focusing on. But it can be to a magnitude of a whole service that we're
building. Think about public services, think about public transportation, think about
air travel. The whole journey of air travel has so many people involved,
different services involved, different companies involved. It's actually an ecosystem of
services. So when you design it, you're not only focusing on one particular channel
or one particular company, but you need to look at what are all the actors that
play a role here? Who is important, which moment? And then most importantly, we use
tools like a journey map, like everyone else, but I think the most important
question of a journey map is not this is how it should look like, like a script,
but ask yourself at every step, what could possibly happen here? What could possibly
go wrong here? Could someone switch to a channel, might a channel not work and
they're forced to switch a channel? What are fallback solutions? So we look at every
step and think what can go wrong and then ask yourself, are you prepared for it?
'Cause that's how you win customers in the end. Not if a journey runs smoothly, but
if you're well prepared for any hiccup that people have on the journey. - Okay, so
let's do this example. I'm shopping at Trader Joe's. I don't - No, do you guys have
Trader Joe's over there? - No, we don't. - Okay. - But I know what it is. - You
know what it is. And so when you're checking out, you've got one really long line,
but at the end it splits into all the, you know, 10 different cashiers. So you're
in the long line, but it's going fast versus you're in another grocery store and
you've got lots of lines, some longer than others and you're trying to judge, okay,
that one's long, but it's going going faster, you know, there's someone that they
look like they might be slow. So it takes all of that out of there. That example,
is that a example that, you know, would fit firmly within service design?
Yes, it's a tiny problem. But yes, it is, it is. Like, I think most of our, like,
like most of the cases we work on is think about public service, you want to get
a new passport. How does this look like? You need to prolong your driver's license.
You need to apply for something. Whatever you touch with any public service,
often these are not designed yet. And actually, what we're trying to do is we try
to understand what's working well and what's not. And then it might result in a
tiny bit like, "Okay, it's only the cash out. That's the biggest problem. Let's
focus on that." Or you realize, "Oh, no, it's a whole sequence we're having here."
Gotcha. Okay. So, you know, it also reminds me of digital transformation. You know,
one of the, I think, few areas of UX where it might really resemble service design,
and I want your opinion on this, is, you know, a company decides, "Okay, we're kind
of, we need to update. The way we run Internally, we need to update processes,
but the digital component of that, that's going to be our digital transformation. It
ends up being an organization -wide thing. You have different job roles that see
different slices of data, and you have to understand workflows and things like that,
and that's just the digital portion. So should I think of service design as being
the digital and physical experience in a whole system.
- Yes, and what you mentioned is very much what we're doing. Often when an
organization starts working with service design, we're triggering transformational change
there.
I like to quote Thorsten Diggs, the former CEO of Telefonica in Germany. He once
said, "If you digitize a shitty process, you have a shitty digital process.
Now, this is what's happening in many organizations, right? We we use new channels
and then we put this old paper form on this new digital channel, like the same
crap, we don't use really digital transformation. It is just another channel. So what
we actually need to do is we need to rethink all the processes. And I think for
service design, it's really important to look at the front stage. So what are the
customer experiencing, but also what is happening backstage? Who's involved in that?
What are the internal systems involved in that? Use cases in Germany is really far
behind when it comes to digital transformation in government. We have cases where you
said we're now digital, meaning you send your application for something by email or
through form. But what's happening then backstage is that's no joke. They're printing
out like 60, 70 pages on paper. They put a file around it. They handle everything
in paper only in the end to scan it again and send it back to you as a scan.
That's not working digital right and these kind of cases are things we look at we
understand how do people actually work and how can we streamline improve all the
processes for everyone who's involved in it to make their life easier and to make
it in the end. Faster for customers better for customers but also more profitable
for organizations. Thinking about one of the is of walking into a workplace and the
way things are operating. Silos, you guys have silos as I think a central,
it's a very central concept in this book. And you get into Taylorism and total
quality management and how there's the sort of traditional way that worked in the
past in factory settings and things like that, where you've got these silos. But you
don't throw away silos. You seem to embrace it in a different way. And so can you
kind of break down for us? We know that silos are sort of obstacles, but how
should we even be thinking about them? And how should we approach the idea of
silos? - Nice question.
Many organizations try to become customer centric, and the reality is what they
actually CACTR is silo -centric because they measure success within their silos. They
have certain KPIs, they have budgets within silos. But the thing is, customers don't
care about silos. We care about consistency, authenticity,
and often when you start interacting with an organization, you interact with a
marketing silo, with communication, you then end up in the sales silo and you get
certain promises. And then you start using a certain service and you realize,
actually, that is again a different silo who's actually operating the business. And
then if you have an issue, you end up in the call center in IT tech support and
it feels like a different company, because you have a different tone of voice. You
have different standards. Like in the beginning, you get a certain promise, but then
service design is actually what helps you to keep this promise as my friend Damien
Kanahan said it, like marketing and sales is the promise you make, but service
design is the promise you keep. Make sure you can keep these promises. And the
customer doesn't care about your silos. You've got all your silos, they're important
to you, but we wanna have a holistic experience. - Exactly, exactly.
And I understand why organizations are set up in silos, and that's okay, but we try
not to break down and break completely away your silos, but rather connect it and
maybe understand success not as a single KPI within the silo,
but as something that is cross silo so ask customers how was your experience and
then if multiple departments get the same judgment it actually encouraged them to
work together with the aim of really improving their experience and not improving the
one KPI they K for. Now you talk about border objects and I don't know the origin
of the term border objects but it makes me think you Lilla, have you described what
that is for the audience, but that they exist at the borders between silos?
That's how I imagined the meaning of it, but things that can be used across silos,
I think. But could you talk about border objects? Oh, is they? Yeah,
so one of the problems, let me just slide this in there for the audience. One of
the repeated problems I have is, if I read a book, I've just read the book, so
everything's fresh on my mind. And that's when I interview authors, they're like,
wait, when did I say that? Oh, I know what you're talking about. So journey maps
and things like that. - Yeah. - Boundary objects. - Oh, I'm sorry. - Boundary object.
Yeah, that's what I'm talking about. - That's why, I used the wrong word, but he's
like border object, okay. - Boundary objects, the boundary objects, what are those?
- So, a Founder object is actually a term that's coming from sociology.
It's an object that has a meaning in different social contexts and different worlds.
So if you think of a journey map, a journey map is a very simple and
straightforward tool, and that is one of the superpowers of this tool. Everyone can
understand what a journey map is, and everyone can follow the experience of a
customer. So if you add relevant data to JourneyMap, map data that is relevant to
different teams in the organization, JourneyMap can act as a boundary object,
connecting different teams in the organization by looking at the same object, looking
at the same JourneyMap and understanding what this means. So having a common
denominator, but then also The ability to add very specific data that is relevant to
them on a journey map now think about. Teams that are very different organization
think about it and legal for example. It's sometimes hard to bring them together but
if you use a journey mapping you add relevant data to a map for legal think about
risk and policies and cookies and things like that. And then think about what
matters to IT. Like what are the systems behind it? Which processes do we use?
Which technology we use on an ACE? Who's responsible for it? All the way to very
detailed things where you can do user story mapping and add like different user
stories to it, different JIRA tickets to it, and so on. So they can look at the
same journey and suddenly they can really speak to each other because they have a
journey map as a boundary object making sure they speak about the same stuff. It's
a powerful deliverable and you know this dovetails on another question I want to ask
you about deliverables and the permanence of deliverables. Now sometimes in UX the
topic will come up that we work really hard on personas and journey maps and other
types of deliverables. But there is sometimes a lack of permanence with this
usefulness. It might be really useful in the beginning and really utilized in the
beginning when we're wrapping our heads around who are we building this for and what
are we tackling. But then they start collecting dust somewhere and then that
interferes with folks being able to see it as important. Do you have similar
problems in service design? Is it fundamentally different because of the nature of
your work, being more physical and including more elements. How does that come
together for you guys? >> It's the same issue. It's rather a governance issue.
If you understand tools like personas or journey maps as a one -off thing,
we tick off the box and we've done it and that's it.
Often, I walk into a creative space of a large organization. You see these beautiful
journey maps on there, and then you try to understand from when are they, and you
realize you're actually in a museum, because they are like five years old or
something, right? We keep them hanging because they have such a nice background, and
often you see then leadership taking videos in front of these very old journey maps,
because it looks so creative and nice, right? But they're actually useless. And I
think it's a different thing. When I talk about journey maps, I always talk about
three different use cases. Journey maps as a workshop tool, where it's really useful
during research to do journey maps with real customers, understanding their pain
points and so on, or future state maps and getting an idea about which part We
need a prototype and so on, but in these workshop settings, the journey map is just
a boundary object helping us to communicate. The map itself is not so important.
And often these maps are rather crappy and made to be thrown away. We work with
sticky notes on the wall or my removal and the whiteboarding tool you use. The
second use case are project -based journey maps. And State maps are things that last
a little bit longer, maybe several weeks or months. We fill them up with more
research data. We might spin off different future state maps, but once the project
is done, we don't update them anymore. And since a couple of years,
like maybe eight years or so,
the approach of journey management becomes increasingly important for organizations,
where we understand the journey map not as a deliverable, but as a living object.
We connect it to live data, so they actually become kind of a dashboard where you
see, in real time, how are we performing, putting in data from Google Analytics and
other platforms to really see how are we performing, but then also connecting it to
what are pain points we're knowing, what what opportunities we're having and we use
it then for prioritization. What should we be doing next? So we keep these maps up
to date. We set up a governance structure for it, where someone, either a person or
a team is actually responsible for it. And every month they review their maps and
keep them up to date because they become the basis for decision making. And these
maps are really, really useful for an organization. But you typically don't have them
in very detailed levels. Like you have it maybe on the top two,
maybe three levels. And then you still occasionally do your project maps if you
focus on a very specific detail, which you don't update them. But differentiate
between the three use cases at least helps me in conversation to understand what
kind of maps do we have? And does it actually make sense to keep them up to date?
Or is it okay if we now throw it away and move on? Okay. So some things you
throw updates, some things you throw away. And it's that really gets to the heart
of the practicality at the heart of service design. It really revolves around like
very real world, practical kinds of, you know, thought processes. And then there's
the constant updating side of things, which I think requires a culture of, of,
um, that accepts iteration.
different and they don't get that there's a constant aspect to things both in design
and in research. Can you talk about that a little bit?
I think iteration is one of the key aspects and no matter which bus would you look
at. Like if you look at Agile, it is also about iterations. If you look at any
form of design that's what you're doing. Innovation always comes in different
iterations, right, where you improve something. And if you don't improve your own
products, someone else will. And that means you go out of the market. So for me,
iteration is fundamental. And if you look at people who are really good at
something, they always talk about how their work, they always come back to iteration.
A quote from Ernest Hemingway, who was famous for the clarity of his language.
When he was asked how he achieves the clarity in his language, his writing style,
a quote from Hemingway is the first draft of anything as shit. But then I rewrite
every page up to 50 times, even 100 times, and that's how I achieve the clarity in
my language, and that is what we're doing in design. We try to iterate and we try
to understand what works and what doesn't work as quickly as possible through
prototyping. That is something that many organizations still don't get for services.
No one would buy a car that didn't go through multiple iterations, all the way to
prototyping, crash tests and they are only when we are really sure that this car
will not put any harm to my life, I'm going to buy it and use it. For services,
we just have an idea and throw it out there, and we don't care if it works or if
it doesn't work, even though it might really harm people, even more people than a
broken car. So what organizations need to get is that iteration actually is a risk
Reduction for companies because you try to understand when you do early prototyping
Low fidelity prototype you try to understand the biggest issues the biggest Box in
your concept and the earlier you find them the cheaper it is to change them Famous
architect once said I can use a rubber and a razor on my blueprint to change
something or a sledgehammer once the building is there. What is cheaper? So often we
use a sledgehammer instead of rethinking and prototyping, testing really with real
users, testing what works and then iterating our way forward. In some context,
service design is just called risk reduction because that's what we're doing in an
innovation process. We try to use the risk of failure. I like the modest kind of
goals too of we're not trying to always find the biggest grandest idea possible.
It's about making improvements and you have a whole chapter, I loved it about ideas
and the role that an idea plays and how this is conception that you hire a
brilliant person. They're going to come up with the singular, brilliant idea, and
then we're going to implement and, you know, we'll all be rich. But you have a
different role for ideas and thinking about ideation as the process,
as part of the process. Yeah, that's right. And actually, there's research about
this. Like, ideas are nothing without execution, right? And like, everyone has ideas,
but just few people actually make it reality. What we focus on then through
prototyping is how can we make this reality? As long as we look at ideas,
it's very hard to judge if this is going to work or not. Because it's just an
idea. We need to test it and to be able to test and challenge our ideas, we need
to prototype it because only that would really mean that we can test it. Now, If
we look at who do we involve into an ideation process, I don't believe in those
creative techniques and so on. I think fundamentally what we really need to do is
research and prototyping. If you do your research well, if you invite the right
people to do your research, you end up with a ton of idea and the question is
rather than to select which ideas, plural ideas, you're going to move forward into
prototyping because we're not good at judging the quality of ideas as long as they
are an idea. So we can't pick the one idea would be very risky again as the
saying never put all acts in one basket. So we take a few ideas and remove on
into prototyping. Now, if you look at who do you involve into these ideation
process, there is some research published in the field of an open innovation by
NASA, where you can judge ideas. The quality of an idea was research about
algorithms and so on, and you could really judge the quality of an idea by the
speed of this algorithm. Now, they involved a bunch of experts, and what was
interesting was those experts didn't came up with any crappy ideas. They were all
decent, but also they had no outliers. They were pretty homogeneous in their ideas.
They were pretty good, but there was no positive outlier. Now, what they then did
is they opened up the innovation process and they involved the community,
the open innovation community, and the result was they received a lot of crappy
ideas. Only very few decent ones, but Finally, this group came up with these
outlying really, really good ideas that exceeded the quality of the experts because
they had a different mindset, a different thinking. They brought in their own context
into it. So that means if we want to make sure that we get ideas that are good
enough, yes, we can work with experts. If you're really looking forward to ideas
that differentiate you're in the market, experts are not good enough, but you need
to involve your own user base, customers, and people maybe from a completely
different background in industry, the more diverse, the higher your probability is
that you end up with those outliers at the S. - And this seems to relate a lot to
the double diamond, right? And that's now a popular, more and more popular in the
past 10 years in UX.
And, you know, you talk about how you have the divergent process where you're
fanning out and you're getting more and more and more and more. And it's very safe
the process and there's no wrong answers kind of thing. And then you go through the
next process of like, okay, let's rune all of these stuff away that doesn't work.
And let's get down to a much smaller set.
You know, is that, you know, part of how you think of, you know,
idea generation and idea finding that you're building a system around it.
You're not just, depending on people being smart, you're making it a system so that
you can get to the ideas more reliably. Absolutely, yes. And we all know that
double diamond is fake. Like the reality is a chain of diamonds,
right? Because it's not just divert, convert, divert, convert, we're done, right? But
I really like what Dave Gray also added to it. Like he said, between diverging,
converging, there's what he calls the "grown zone" in between. And there's actually
also academic research on that. And I read one paper where They made a difference
between decision -making and decision -taking. I really like that because what's
happening is when you do research, you open up the idea space,
so you're diverging when you ideate and collect ideas, you open up the idea space.
But before you're able to take a decision, actually converge, you need to make sense
of what you're seeing. That is what they call decision -making, so preparing yourself
for the act, for the moment of actually taking the decision, which is rather a
moment in time, say, "Okay, that's what we're going to do." We use tools like an
opportunity portfolio, where we try to estimate the impact and maybe the reach or
the feasibility, whatever criteria and put all our opportunities on a portfolio to
also understand how might one opportunity impact another one to see connections
between that. And we're while we're doing that we're spending time with those
opportunities or with those research insights so we start empathizing with it we are
start understanding and developing idea of what might be the impact of it we're
preparing ourselves through this groan zone for the actual conversion moment for the
moment of decision -taking. - Let's dive into that groan zone for the audience. So is
this, correct me where I'm wrong, but you're facilitating a big workshop, you have
people come up with all these ideas, sticky notes everywhere, and people are proud
of their ideas, they're thinking about them, and then now you spoil the party by
saying, "Okay, all those ideas you came up with, most of them we're gonna throw
away. So let's start getting rid of them. And then people don't want to shift. Is
that the grown zone? Yeah. And then what are the the facilitation tools you're using
in this moment? Like getting rid of this ownership of your idea is one thing,
right? Let it rewrite, let it be rewritten by other people. So you lose your own
connection to it. Put it up on the wall, let and restructure and build this
portfolio and other people build their own ideas. There are different techniques you
could use for that until people lose ownership for it. Otherwise,
the idea whoever is the highest paid person in the room or the one with the
biggest power, magically this idea will survive till the And you said in the end,
well, why did we do it? If he pitched it, if she pitched it and we knew this is
what we're going to be doing, why do we do this theater? And I really don't like
like innovation theater in a sense. I have to be careful now because a good friend
of mine is using theatric techniques and design. And and I don't want to mean it
in a different sense, you mean it as in, "Oh, we're doing the design thing and
we're going to the process and it's like a play." Exactly. Like, theater can be a
really powerful tool, but in this case, what I mean is we are enacting something
that we shouldn't have done, because everyone knew what's going to happen because the
decision maker already made that decision. Now going back to the double diamond, I'm
glad you said that it's not really really real. And does that come out of the
design schools? Are the design schools borrowing things from service design? And we
all know as we're all borrowing each other's ideas from different fields. That's just
how it works. But is that kind of, does that come from you guys? Or the general
idea?
The Double Diamond comes from a British design council. And they published it many
years ago, and they made an update on it, I think four or five years ago now. I
like it, but I also think it's dangerous because it is a very linear visualization
of design. And I worked with organizations where they use the double diamond as a
basis for structuring their design process. And once a project was in a certain
stage, like your past discovery, people were not allowed to do more research.
And I think that is one of the fundament. Oh, I think we need you to repeat that
part. You said they weren't allowed to do more research. And that is one of the...
So they weren't allowed to do... Oh, my that is not stable, I just get a message.
Let me quickly check.
- Okay, let you work that out. - We can cut that out, right? - Yeah, of course,
yeah, we'll figure it out. - Sorry for that, and I'm just checking.
- Switching to a different one. - I think we're good again. - Okay, we were good the
whole time, it was just a lip. - Okay, so We were talking about an organization
using the double diamond very formally, and then the risk is they weren't allowed to
do, you know, I'll let you say it. Yes. So the risk is that a double diamond is,
because it looks very linear, that they use it, organizations use it as a way to
structure their design team. And I work with one organization where the design team
or the people who were responsible for discovery, for research, were not allowed to
do more research late in the process because they've already done discovery. And it
often has also to do with the language we're using. Like when I work with
organizations, I never use terms like, oh, we have to go back and do more research
because it feels like a failure. People hear, oh, okay, you missed this in the
first part of the process and now you didn't need to do more research because you
did crap work in the beginning. So instead, we always need to talk in a more
iterative way, where we say, look, we went fast until this moment, but we learned
at this moment that we don't have enough knowledge about this particular aspect. So
we're going to focus our research here to move ahead. So always looking into the
future. And if you do this, you know that a double diamond, like in a real sense,
you would jump between these different stages of it. But because it looks so linear,
people always see it and think, okay, you move back, so that's a failure, you do
bad work. So it's actually the opposite of iteration. Yeah. See if they manage
expectations around what research is, the role that it plays and all of that.
So I want to talk to you about value innovation. So when I started trying to get
into on strategy, how do I apply design thinking style methods to just business
strategy, right? And then that led me to certain areas like the Blue Ocean and
other things like that. And they talk about value innovation and they have all these
methods for making sure that you're not only innovating for innovation's sake and
doing technology push, but you're also trying to find the true value and you're
trying to mix the two.
How is that related to service design? Does it bleed heavily over into the strategy
area of things? How do you relate to ideas like value innovation? Yeah,
So service design can be used on a very tactical operational level when you focus
on tiny aspects of any service. But it can also move to a very abstract strategic
thinking, where you think about what is the vision of our company, where do we want
to be in Innovation Horizon 2 or 3, like thinking had 5, 7,
10 years. Often what comes out of such a process is a rather blur description of a
vision. And service design can help you to make this vision very concrete, testable,
prototypable. So you can then say, okay, if we want to become this company,
if these are the values we have, if this is the area we want to develop in,
how would it feel for a customer? What does the journey look like? Which aspects of
the journey are known to us today? Which aspects of the journey are unknown? Where
we have high risk, where we have low risk? So it can help you to make these
rather abstract thinking very concrete and testable. Right. So,
okay, and that's, it's a heck of a skill to have there, right? And, you know,
thinking about service design teams, who goes on a service design team? So, you
know, thinking about UX, you've got, of course, it's very eclectic. I know service
design is as well, but generally we'll have kind of research -y type folks who maybe
have a strong background in behavioral or social sciences. Then we have graphic
designers as two major, and then other people from just random places, sometimes
computer science and things like that. When someone is thinking about, "Hey, maybe I
should be a service designer," and go into that. What are some of the sub -rolls
they should maybe be thinking about, and what kinds of backgrounds lend to themselves
to being able to create value on a service design team? Well, let me first talk a
little bit about the naming, because I think it's important that while we're building
up service design organization, we don't start building up new silos. If an
organization has a team for UX, a team for design thinking, a team for CX,
a team for innovation, and then you build a service design team, I guess you have
a problem because you will fight over budget and basically you all do the same. So
one thing is we often hear service design we need to understand what is behind this
name because sometimes you have also organizations tell you yes we're doing service
design and then you ask them what they're actually doing and the worst answer I
ever heard was oh yeah we do service design every Thursday like turn out they do
like some sticky notes on the wall of ideas they're never going to do who um so
that I work with organization where service design comes under different names.
What I like about service design is it's an expert term for us as a community to
meet each other. And I would say a huge part of our community overlaps with UX.
We have loads of folks from UX who are now working service design roles. And simply
what the only thing that changed is they don't limit themselves to a They look
beyond the screen they they look at other channels and of all that and if you look
go back to the nineties. UX also didn't limit themselves to the screen right they
looked at at the broader thing but it developed into this limitation at some point
so. I don't care how we call things I have I have clients who call their service
design team UX because they don't limit themselves to the screen. I have others who
call it design thinking others others who call it innovation, others who call it CX.
It doesn't matter for me which label you put on there, as long as it resonates
well in the organization. - Yeah, I love that. Sorry, no, please continue. No,
no, sorry. If you look then at who is part of that, yes,
it is designers of different fragrances. Like we have UX designers, UI designers,
graphic designers, of course product designers, industrial designers, because it's often
also about building things and making things physical products. But then we also have
a strong representation of research and research, often rather qualitative research.
So coming from design research, anthropology, psychology, sociology, people who got
trained in of research and bring this thinking. Then we have people who are really
good at prototyping. So like who can tinker, who can think with their hands from
different backgrounds. But then we also have, I think, one of the biggest skills you
need to do service design is facilitation. So the ability to help a team making
progress and moving on, the ability to involve customers, and since we work a lot
backstage, a lot with the people who are running certain services in an organization,
we often work with different hierarchy levels or different departments. We need to
make sure that we can bring them together and work productively together. And for
that, the skill of facilitation is for me absolutely essential for service design.
- That was gonna be actually one of my questions, which is, 'cause facilitation is
such an enviable skill. I mean, we've all been to those really killer workshops
where you've got someone just actively facilitating and you break up into groups and
you've got the markers and sticky notes and it's fun and it's super engaging. And
it's hard to, you know, get a career where you're reliably doing that.
And I guess if you're, you know, doing consulting that it comes up a lot. But
would you say that that is kind of one of the core things involved in service
design? Is that facilitation activity? - Absolutely, and I don't limit facilitation to
a workshop setting.
In my company, we love to do stickers and maybe you've seen there some conferences
like bright yellow stickers that we pass on and one of them says 95 % of service
design is not a workshop. Because people often have this understanding that our work
is happening in workshops, but that's not true. And you can use facilitation for any
conversation that you're having in an organization. And that conversation might be
part of a workshop, might be part of a project, part of an initiative. In the end,
it adds up to how we're working to the culture of the organization, you're
facilitating every little interaction you're doing has impact on this overall culture.
But vice versa, your culture also impacts any conversation you're having. So you can
use facilitation skills throughout your work. And the majority of the work of what
we do in service design is not happening in workshops. But What we do is this
matchmaking organization, bringing the right people together, negotiating between
different departments or different hierarchy levels, and all of that comes down to
facilitation. One of the moments that I appreciated in the book was this discussion
of reflection out of action. It's in chapter six, and I think it's a section,
Satyam Yedin, and got a quote by Becky Carano. I Becky Carano, but can you describe
that for us? 'Cause we know about it and we know that there's tech spaces that are
designed to be comfortable and executives like to have their lives comfortable so
that they can come up with ideas, but you need to talk about reflection out of
action. - Yeah, it actually goes back to a Nobel Prize winner, Kahneman,
and he wrote the book thinking fast, thinking slow as well. And what it comes down
to is when we think about ideation, and I'm not, as I said, I'm not a fan of
ideation, right? And one of the reasons is that we often try to come up with ideas
in a time -constrained setting where we said, "Okay, this is the problem. Now we
have an hour. Let's come up with ideas." And we use methods like brainstorming,
brainwriting, crazy aid and what have you just to come up with crappy ideas very
quickly and none of these ideas will work and then people go out and are frustrated
because there were no good ideas in it and that might take one or two days and
suddenly someone comes up like hey, I had this idea and and suddenly you talk about
a much better quality idea if you can judge it even at that time, but what
happened was You did it out of context out of the situation where you were in
action like you had to calm moment you had usually it happens when we do very
boring repetitive tasks when we're in the shower on the toilet when we're out for a
walk things like that that's where we come up with ideas because we have time to
reflect and a lot of that is happening subconsciously And I'm not a psychologist.
I can't explain how it works. I can only see that it's working. So if you think
about, if you need to add like ideation as an activity in a project,
always think about, yes, you can have this trigger moments of ideation as a group
setting and so on. Maybe that helps to bring everyone the same page, but you
shouldn't end there. You should create a parking space for your ideas, and throughout
the project, over weeks and months, people can fill up this parking space, because
that's where you're going to find the good ideas, not in this one -hour workshop
setting. So prepare your projects for that by giving opportunities for people, and
often also participants need to know that it is okay to submit an idea rather late.
And it's okay to submit a crappy idea. So going back to the quote of Hammingway,
we have this concept of the shitty first draft. And it's an academic concept. This
is how it's called. I know the S word in the US is sometimes difficult. Sorry,
but this is an academic concept. It's called the shitty first draft. There are books
about it. There The academic papers about it and it's important to call it shitty
first draft because it frees you from perfection. It frees people up to submit the
idea to put it right down on sticky note and pin it up that idea that came up
while they had a shower yesterday evening. If we understand that every idea is
crappy we can then use iteration to understand which of these ideas make more sense
to actually pursue and reduce risk over time by increasing our investments into
prototyping and start really cheap and fast to understand which of these properly
make more sense to pursue. Yeah, I love it. And it kind of goes back to this
recurring theme throughout the book of sort of the safe space concept where you just
let everybody understand that their lives are not on the line, just because they
came up with an idea, that's not the greatest idea. You wanna question getting
toward the end here. There's this military concept reference somewhere in the book
and it, hopefully I'd describe it right, where it talks about unstable situations,
where there's a lot of unknown factors. I forget the acronym, there was an acronym
somewhere in there. - VUCA, could you talk about that a little bit? and how the
business world is becoming more and more VUCA. Yeah, so VUCA stands for it's an
acronym and it stands for Volatility. So actually the speed of change we're seeing
today, uncertainty that things are not predictable, complexity that there are often
more actors involved, more
Ambi -greet, embo, I can't pronounce this word. - It's late over there. - Sorry, it's
late over there, it's over early over here. - And I'm not a native speaker, yes.
Ambi -greet, I can't say you say it, you know what I mean. - Ambi -greet, yes, yes,
yes, sir, we've got you.
So potential misunderstandings, mixed messages and things like that. And it's coming
from the, I think it's the US Army in like late 80s or so. And it's used more
and more in business now as well, because the world is changing faster. We have
more technology coming in, different technology coming in, and it's really hard to
predict. Like it's not that how it used to be in the good old days in the 70s,
80s, where I had like very clear pathways what's gonna happen in the next five
years or so, although that was never the case, but at least it felt like it.
Nowadays, the world is changing so fast that we actually can't justify long linear
innovation processes anymore, because we need to be able to react on changes that we
discover while we're working on a certain topic. So working iterations and involving
real customers and prototyping is all the way to handle this acronym of FUKA.
- And to me that even feeds more into the importance of us learning methodology and
the underpinning as of why we do what we do because with the technology traveling
so fast we can't be overly tied to tools that are out there because it all is
just switching around so quickly. Mark, where can people find you and the work that
you do and engage with you? So you can you can find me on my website markstickton
.com. You can find our book on this is services and doing .com. Basically,
we also have a method companion, you find more than 50 method descriptions for free
that you can just download on the on the book website. And if you're interested in
any case of journey mapping, my company is called Smapply. And you find loads of
blog posts around journey mapping, journey management there. And find me on LinkedIn,
just connect with me. Nice. Awesome. Mark really enjoyed today's discussion.
Thank you so much for being here today. Me too. Thanks a lot, Thomas. Fantastic
chat. Really enjoyed it. So, to wrap up, Today's conversation with Mark Stickdorn
gave us an expanded view of what design really is, whether it's a mobile vaccine
clinic or a rideshare pickup zone at the airport or maybe the flow of hospital
visitors in and out of the building. When services are well -designed,
they feel smooth and intuitive, but Behind the scenes, there's so much more and
nothing about it is simple. There's the part that the user sees and then there's
everything else that makes the moment possible. Mark showed us that service design
really isn't just a set of tools and deliverables. It's a mindset. It's one that
brings order to organizational chaos and it sparks new ideas and it relies very
deeply on collaboration across departments to bring everything to life. Specifically,
we explored how things like journey maps and blueprints are not just visual
artifacts. They're decision -making tools. They're ways to connect the dots between
what customers need on one hand and what organizations can deliver on the other
hand. So whether you're designing a geofencing system that alerts workers when a
truck arrives, or building a class registration process that works both online and in
person, and feels like the same experience in both cases, or even rethinking how
kids get picked up after school. These services become a part of people's everyday
lives. Design isn't just about screens and products, It's about systems and services.
We all live with services every single day. And no matter how technology evolves in
the future, there will always be systems that connect people to what they need and
keep the lifeblood of communities flowing. When you really think about it, learning
to design services isn't just a skill. It's a contribution to how society works.