Ask Marc – about methodology silos

This series was initiated as a place for you to learn more about service design and journey mapping software. Our co-founder Marc Stickdorn and the Smaply team share their experience on how to embed and scale service design in organizations. The sessions usually kick off with a short introduction to the focus topic to bring everybody to the same page, followed by your questions and deep discussions of best practice examples.

On this page you find the recording as well as the transcript. Additionally, the session is also available on Spotify, iTunes and Google Podcasts.

Check out the following session about measuring the impact of service design!

Overview

• [03:13] Introduction
• [09:20] Service design vs. design thinking?
• [12:20] Service design vs. product design?
• [13:55] What are UX designers duties and what skills do they need?
  
• [18:50] How to introduce or prove the value of customer journey maps to process engineers?
  
• [20:40] How to try and discern whether a company does the design process well?
• [23:45] Is there anything specific I need to learn if I want to become a service designer?
• [26:00] Activities, methods or tips that help to break out of siloed thinking
• [29:50] Resources for people who are learning on a done-well version of the process

Transcript

Introduction

Marc:

I would like to kick off with showing a few selected slides from a talk about that topic that I gave in 2016 at an experience design conference in San Francisco. The name of the talk is “This lean agile design thingy thing” which also describes how I see these things.

I think one of our core jobs when we work as service designers is to break down silos. I have seen loads of organizations embedding and scaling service design within their teams and one thing I often see is that organizations are actually building new silos I've been working with organizations who have a team for service design, but they also have a team for Innovation for UX Design, for Customer Experience and more. If we look beyond the labels and look at what they're doing – most of them were actually doing similar stuff. There were loads of political fights about who is allowed to use which tool. There are departments which are actually doing service design but they are not allowed to use the term customer journey or journey map because the team of customer experience has ownership of that. I think that is crap because our main job is to break down silos, but then we're building one our own.

On the note that there are so many different approaches out there – just a few as examples here: What we see also in organizations is that they try to bring all of them together and the result of that are these kinds of models. There are many of these models and I'm not a fan of them. It's not that I hate this one in particular, it's just – they are out there in general. I just want to give an example.

What you see there is that different approaches often result in different teams doing it. Then there is a team working on design thinking, a team working on lean UX, a team working on agile, a team working on growth hacking and then you have a team for lean startup. Often those titles become part of their job descriptions – which results in silos. What this model describes is not a real iterative process – what design actually is – but it's actually a linear process. Because it doesn't allow anymore to move between these different activities. If there are things where you need to do more research but your project is already with a team of growth hacking, the model doesn't allow you to do research.

And I think this really contradicts what we're doing in design. Being honest: how a design process works is not this lean design agile thingy thing. And frankly, I'd like to quote a very respected colleague of mine and she said:

”What we're doing is often common sense, but not common practice.”

and a lot of the stuff we do is exactly that because we have these silos in an organization, these teams with different responsibilities etc.. Why isn't it common practice? Well, some people still believe you can plan projects end to end before you start the project. Particularly in innovation, in design this doesn't work. And design processes can’t be squeezed in these models and silos. Otherwise they are not open and iterative anymore but follow a step-by-step linear process.

If we look behind all these different models you see that all of them share a few core components – if we look behind the labels, they all agree that whatever we work on is never really finished. It's just one version of it. There will be a next one and another one as we progress by doing many experiments. We test out things and then we improve and go forward. This we do by asking real people, humans. In service design teams and terms I think all of these approaches agree that we work in iterations. We do prototyping, we do research. That's the core thing behind all these models

‍

Nicole:

Lacey gave you the thumbs up when you were talking about these models. She says that models are really confusing for people who are learning. If you set five up in a line together and look at them, break them down – they're all talking about the same things. Maybe it's just how people try to organize their thoughts but I don't think you want to spend too much time breaking your brain over the models.

Design thinking or service design – what's the difference if we strictly just look at the definitions?

Marc:

There is no widely acknowledged definition of either of them. But so many different authors and  books have been written about the topics and they have various definitions. Agencies, organizations define it differently. Essentially I think it's pretty much the same. Some say service design is the application of design thinking on services. I personally don't restrict service design to services because a service often includes physical things like goods – physical or digital products, internal services or business models.

For me it's exactly the same but I'd like to quote another colleague. Adam Lawrence likes to say that there are lumpers and there are splitters in the world. Lumpers are people who look for similarities. If you compare service design and design thinking they look for similarities between them. Splitters are the ones who look for differences between those. Personally I'm a lumper so I look for similarities.

I think one core difference between service design and design thinking is that design thinking was kind of hijacked by consultancies and agencies. When you hear about design thinking they sometimes refer to a workshop format that is exactly 55 minutes or one hour or so, where you basically just put post-its on the wall. To me this is neither design thinking nor service design. So for me it's just a label for exactly the same thing.

Nicole:

I would agree and I think I like to always add on that they are the same thing when done well because – like Marc said – it has been hijacked. When I started in the service design world I had a friend who worked for a very large global software firm. She had done this "workshoppy" version of design thinking. I was so excited about this new world I was in. She said to me: “All I see is post-its on walls and nothing getting done.” That was eight years ago and stuck with me, because that's what it can look and feel like if it's not done well.

What are the differences or similarities between product design and service design?

Marc:

From an educational perspective it's really interesting because there are different job titles,  there are different study programs for it and it's a different focus.

In my opinion product design rather focuses on material things where service design rather focuses on immaterial things.

But then I see product designers creating awesome services  and I see service designers creating awesome products. If you look behind the label, the process, the basic way of working is the same. The difference is probably in nuances depending on what you're designing for. But it's the same within service design – there's service design projects which are completely digital, what's the difference then to UX design? I believe it's different fragrances but actually the core of what they entail is the same. It's just a different label and differences in nuances

What are UX designers duties in the industry and what skills are necessary?

Marc:

Don't get distracted by the title of a job or the job description. Rather look at what you really have to do. Often job descriptions are rather vague and rather general. If you then talk to the people you actually work with – so ask a lot of questions when you start working with someone. Then you realize what you really have to do. Sometimes the label UX design includes more research, but sometimes it also means a lot of UI design. I.e. crafting interfaces and going in the direction of graphic design. Sometimes it also is thinking about processes, flows and the customer experience of the entire process.

It's the same thing with service design. Everything that I've said also is true for the label of service design or the label of design thinking. So look behind that. UX design, just like service design, is a broad field. In fact it is a team sport. I'm struggling with “the”service designer or “the” UX designer because you might have someone who facilitates the whole process, who leads projects and they need different skills than someone who focuses on research or someone who focuses on crafting interfaces.

What do you want to do, what are your deep skills?

Think about the T-shaped person. Where is it enough to have a shallow knowledge to connect with your colleagues? UX design, service design is a team sport and you need loads and loads of different skills for different tasks within that. So it's probably not a nice answer. It would be easier to clearly define the skills, but that's not true.

Nicole:

It's not quite that clear. In my experience in an agency I’ve found that sometimes the only difference between people on our UX team versus our service designers was really maturity and experience. You have more time just working and understanding the way different businesses work. Also, having exposure to that, your ability to think more holistically and more broadly grows, so sometimes there's a little bit of life experience that can really kind of help bridge some of those perceived gaps.

Marc:

I would add to that that it can also be the other way around. For example, if you have an organization with a large UX team of 150 people: looking at the maturity of that team, it is amazing and well ahead of the newly established service design team. Or the customer experience team or however they call it. Again, look beyond the label and see where the maturity is. I think that is a great tip, but I wouldn't stick it to a label – I would rather look at how far these people came.

If you look into the early writings of UX design, if you talk to pioneers in UX design they never limited themselves to the screen. They always looked at the entire experience, also beyond the screen. Somehow over time UX kind of limited themselves to a screen. But there are still teams who don't limit themselves to the screen, who look at the entire customer experience and try to connect different channels and make sure that there is a consistent experience when you switch between channels, also non-digital ones.

Marc:

I also think that being confined to the screen within UX jobs often is a point of frustration of not being able to break beyond those boundaries. I think they know that they can provide value.

How can I introduce or prove the value of customer journey maps to process engineers that focus only on business process mapping?

First thing is add something to it that adds value to them. Often if you show someone the journey map and they don’t believe it’s of value to them, they often mean that the map does not include relevant information for them.

Think about adding certain lanes to a map, think about going in the direction of a service blueprint – here you don’t only map the customer experience, you also add what is happening on front stage and backstage.

Combining this with the caveat – if you follow this approach people will have a tendency to focus on the internal processes and tend to forget the actual customer experience. It’s your role to be an ambassador of the customer experience. Always ask about the customer experience at a specific point. Check how long internal processes take if there's a blank spot on the customer experience. If the customer is waiting there shouldn’t be a blank spot. How's the experience of waiting while their internal process is going on? You can nicely combine those together for sure.

What do you recommend one can do to try and discern whether a company does the design process well? Especially for someone early in their design career and applying for jobs.

We sometimes see big differences between certain things done well versus not done well. I think that is super relevant

I mean there is not a label or rating for companies concerning how well their design processes are, or labels like a trusted design organization. There are a few things I would recommend to look out for. One thing is – do they just look at the products, look at the website, look at how they work, do they use any dark patterns while they're doing that? And if yes, do they do it on purpose or do they do it rather because it just happened and no one realized that? If you see that they do use dark patterns I wouldn’t work with them. They still might be good, they might use a good design process and tools but I wouldn't work with them.

I would suggest you read Ruined by Design by Mike Monteiro.

If they use dark patterns but you see it's not consistently done or it's not done on purpose and it adds value to the organization, I’d say it's worth chatting with them. Try talking to people who are actually working there when you’re in a job interview. Because often in your job interview you talk to recruitment, you talk to HR, you might talk to leaders. Often being a design leader means you're not designing anymore. Then your job is to manage a part of the organization, you manage people. It's not a bad thing. It is just part of your job if you're really interested in it. If they are open to that they will let you chat to someone in the organization who's actually practicing design and then have an open chat with them.

I'm a UX designer and I think my skills are quite easy to transfer to service design. What's your opinion, do you think there's anything specific I need to learn if I want to become a service designer?

Marc:

It depends on what you understand under UX design. It could be that you're already doing exactly the same stuff. I typically see the difference in the skill of being a facilitator. You're actually working a lot with people in service design.

Your focus in UX design is probably your mouse and your screens. And in service design you focus yourself on people, processes, organizational stuff. A lot of the stuff we do is actually trying to understand organizations and change internal processes to create a certain customer experience. And for that you need to be a good facilitator.

On the method level: you might need to add slightly different research methods. So all that you know you can apply, you can use it. Additionally you need to use more ethnographic approaches where you actually shadow people, or where you are the fly on the wall and you try to understand people in their space. What are they doing? What are the processes? And the same with prototyping. Also there you need a slightly different method set and tool set

There's so much overlap that in my experience, there's so much like tools and language and ways of thinking that you're using already as a ux designer most likely that are just directly transferable it's really not going to be that different from the lens that you're using.

At my job we are starting to facilitate a lot of workshops to build out service blueprints and I often find it difficult to keep groups from thinking and ideating within their silos. Any activities, methods or tips for helping them to break out of their siloed thinking?

Marc:

The question is when do you need siloed thinking and when is it beneficial for a process and when do you actually need to break it.

Another example from my colleague Adam:

You have three different teams and each team consists of three people. One team is a team of doctors, one team is a team of rockstars and one team is a team of nuns. What should you do if you want to achieve a lot of diversity?

If you want to get really diverse ideas, should you combine them and mix teams so each team consists of one nun, one rockstar and one doctor? Or should you keep them distinct and have one team of doctors doing their ideation first, one team of rock stars and one team of nuns. The thing is – if you mix them they will restrict themselves to going into really extreme ideas. A rockstar will probably not go that extreme if there is a doctor and a nun. And the nun will not go extreme if there is a rockstar in the team etc. They actually block themselves.

On the other hand if you have the distinct teams the doctors will get very extreme doctor ideas, the nuns will get very far outreaching “nunny” ideas and the rockstars will get very “rocky” ideas. So they go much further. In a second step you mix them up once they went very far in one direction. You would actually create way more diversity because they first were able to go into their direction.

My tip is: if you have siloed people, use it to your advantage.

Perhaps let them first work in a very siloed approach. And in a second step mix the team. It's called a group puzzle where you then mix the teams and make sure that each group consists out of different people. They bring their very extreme, very thought-through ideas and observations and perspectives into the new group, where they can discuss them and hopefully create better and more ideas as a group. The question also is if you need many workshops. Do you actually want to create these kinds of artifacts, like a journey map or a blueprint, only with internal teams? What is the role of the customer? Shouldn't they be doing that as well? When do you include them again? If you think of a group puzzle, you can start with some groups and add them as useful throughout the process.

What are suggested resources for people who are learning on a done well version of the process?

Marc:

I already mentioned one, but there is another good book which I think is absolutely fantastic to understand services in general and start to differentiate what is a good service and bad service. It's called “Good services'' by Lou Downe. Absolutely recommend it, have a look at that. Beside that there are loads and loads of good learning opportunities. Have a look at the podcast platform “This is HCD”. This is human centered design. Also look into the online learning platform of “This is doing”, which goes way further than “This is Service Design Doing” because it's about all the innovation and designs. Also check out our own blog where we have loads and loads of different cases, examples from different industries etc.  

The service design show by Marc Fonteijn is really good as well. There are loads and loads of different interviews. That's just what's on top of my mind. Beside that join communities and talk with people. Join your local service design drinks, which is obviously happening more in the online world right now. But it's nice because you can access services and drinks from different places all over the world. Also there are conferences that are face-to-face but online as well.

Nicole:

That's a great answer and I think really what you highlight is that there's no one perfect model out there. At a high level they're all very similar but the more you're exposing yourself to all of these different points of view the bigger and bigger your tool kit and your bag of tricks come so that when you are faced with a unique problem you can think about what the right things to bring in are.

‍

And now, what's next?

Check out the other Ask Marc sessions about different topics of human-centric work, like multi-persona maps, creating CX insight repositories, and many more.