What do users want? Organizations typically capture user demands in extensive documentation commonly known as ‘requirements’, align technical departments with ‘the business’, and start their development process, hopefully making some changes based on learnings along the way. Easy enough, right? Wrong. Ideas about what to build become waste when they run out of step with the demands of people using a product or service. Luckily, organizations are warming up to the idea of co-creating products and services that truly cater to user demands. This post describes an increasingly popular product management tool for co-creation: Service Design. What is it and should product professionals care?
From design thinking to design doing
In October 2022, I attended a 5-Day Executive School ‘This is Service Design Doing’, hosted by Marc Stickdorn, Adam StJohn Lawrence, and Markus Hormess. These three gentlemen are part of the group of people spearheading the field of Service Design, which aspires to create customer-centric innovation towards new value propositions. Service Design deploys a broad variety of methods and tools, such as ethnography, journey maps, business model canvases, and facilitation skills that tap into the power of theatre. Various exercises that made use of this rich toolbox were presented to the Executive School’s international audience, which featured people with backgrounds ranging from interaction design to management consultancy.
Figure 1: DesignThinkers Academy in Amsterdam
The exercises really came to life due to the venue of the Executive School, the building of the friendly people of the DesignThinkers Academy in Amsterdam (figure 1). A large open space with plenty of wall surface to work on plus a plethora of posters, sticky tape, post-it notes, action figures, and Lego, helped to ensure fruitful collaboration between participants.
“Customer Experience Is the New Competitive Battlefield” (Gartner Research 2015)
“Customer Experience Is the New Competitive Battlefield” (Gartner Research 2015) Taking these words as a battle call during his lecture on the first day of the Executive School, Marc Stickdorn quickly tackled any semantic confusion the audience might have. “It doesn’t matter what you call it. It matters that you do it”, the first of the ’12 Commandments of Service Design Doing’, ensures that it doesn’t really matter whether we call our customer-centric approach ‘Design Thinking’ or ‘Service Design’. What’s important is that we persistently put the user and their experience center stage, scrutinizing our biases and output along the way.
I see services everywhere
Service Design doesn’t look at services as a collection of ‘touchpoints’, i.e. moments of interaction with a product. Let’s say I’m a travel agency that aspires to provide enjoyable travel experiences by train in Europe. The people that interact with my booking platform typically book a ticket, perhaps purchase some additional services on-line like a window seat, and after the trip they might leave a review. Service Design would not only look at the interaction between users and the booking platform but would also look also at the steps around these interactions. It’s worthwhile to examine what motivates people to travel by train, how they spend their time waiting for a connecting train, and what they do once they arrive at their destination. These are all aspects of someone’s experience around the booking platform, so it makes sense to take a holistic approach. As a Service Designer, you really put yourself in the shoes of the user and a holistic perspective helps to do that.
“It’s all services”, the twelfth commandment of Service Design Doing, proposes that Service Design can be applied to anything and stresses that we need to cast the net widely when doing Service Design. Although products provide (sometimes very tangible) connections between people using the product and organizations offering the product, they’re also increasingly embedded in services around it. Failing to address those experiences around the touchpoints with the product (looking for a product on-line, making a purchase, etc.) compromises positive impact on the customer and the organization building the product/service. Put differently, purely focusing on the product or service introduces blind spots in the understanding we have of what users are doing, thinking, and feeling, all of which shape their experience and the value they’re getting out of a product or service.
I believe there’s an additional reason why “it’s all services”. If I buy a nail, chances are my journey towards that purchase and afterwards will have some digital service-oriented counterpart. What if I buy the nail, but my actual demand relates to upgrading my home improvement skills more generally? Paraphrasing Theodore Levitt, I don’t want a quarter inch drill, not even a quarter inch hole – what I really want is to make my living room more stylish according to the latest standards so that I can show off my collection of (mostly unread) books. My local DIY store would be missing out if they wouldn’t at least be aware of my intent, and I’d be missing out myself if I wasn’t offered a chance to grow as a handyman and home decorator. Offering customer experiences without aligning the layers around the core offering compromises value delivered.
Journey maps and beyond
The no-nonsense and pragmatic approach to services advocated by Stickdorn, Hormess, and Lawrence functioned as a guiding principle throughout the Executive School. After learning the basics of research methods and formulating research questions, we headed out to talk to random strangers about their experience of the public transport system in Amsterdam. After reflecting and refining our first observations, we mapped the interactions of our research subjects with Amsterdam’s public transport system on so-called ‘journey maps’, visual representations of sequences of steps a person or a group takes when interacting with a company, product, or service. Figure 2 shows a journey map template provided by Smaply, a company co-founded by Marc Stickdorn and Jakob Schneider, both of whom co-authored the This is Service Design Doing book together with Adam Lawrence and Markus Hormess. Figure 3 provides an example journey map from tourism.
Figure 2: Journey map template provided by Smaply. Source: www.smaply.com
Figure 3: example journey map from tourism. Visit the Smaply website to explore the journey map in more detail. Source: www.smaply.com
“Journey maps make intangible experiences visible and facilitate a common understanding between team members.” (Stickdorn et al. 2018, 46)
Journey maps proved to be of pivotal importance, functioning as an instrument for interaction around users and their world. When created and used by a group of people from various disciplines, journey maps are useful for documenting insights about what users do in a given journey, creating backlog items of potentially valuable work, and engaging in fruitful dialogue across organizational silos and disciplines. By taking the user’s experience as their starting point, journey maps detail a user’s existing experience or a planned / future-state experience. Thus, journey maps not only articulate the current understanding of a user’s journey and the possible shortcomings of our current understanding, but also envision future services that might be worth pursuing.
When mapping out the user’s journey from their perspective, written and visual information is added to truly bring the journey map to life. Visual material helps to empathize with the user and allows for faster and more effective communication. There’s also room for different channels, which allows room for multiple platforms through which users might interact with a service (e.g. an app, a website, etc.). The pace and rhythm of the user’s experience is reflected in the ‘dramatic arc’, which shows the user’s engagement at each step, and allows Service Designers to create room for ‘thrill’ (high engagement) and ‘chill’ (low engagement). Both have their value and should be in accordance with a user’s needs (Stickdorn et al. 2018, 48).
Looking at the user’s experience invites work on frontstage actions – ways in which users interact with a service that are also visible to them. Frontstage actions can be accompanied by backstage actions, such as order processing, creating a list of recommendations to customers, order handling, and anything else a company needs to have in place to cater to a user’s demands. For me, this is where the journey map really shines for two reasons.
First, the user’s perspective is leading, not any preconceptions we might have because of existing technologies or features that are already on a product backlog or strategic document somewhere. It’s very tempting for organizations to immediately jump into solution mode without really understanding how users interact with their service and using journey maps could help to remedy that (more on my reservations later).
Second, the different layers of a journey map create a reference point for different disciplines to collaborate, whilst staying focused on customer impact. Companies should be focused on changing the world of the customer in a positive manner because this is proof of their ability to take away pains, create gains, or provide the means to get a job done. Organizational silos now have a common goal: to change the world of the user in such a way the relationship between disciplines is complementary and synergetic, rather than conflicting.
Feedbackception
The chances you hit the nail on the head when designing some solution to a problem is practically zero. New insights emerge as you go along and after a few interviews, journey map sessions, and prototypes, it’s likely you’ll be persuaded to go back to the drawing board to do more research or create a different prototype. Service Design embraces this wholeheartedly in its second commandment: “make shitty first drafts”. We should make that shitty first draft as soon as possible, gracefully accepting the fact that we’ll probably be wrong, but that the only way to find out we’re wrong is by taking that first step. The value of being courageous and audacious is at the heart of Service Design and features prominently in the diverging-converging double diamond of Service Design (figure 4).
Figure 4: diverging and converging to deal with complexity. Source: www.oreilly.com
Service design involves the interplay between diverging (investigating and branching out many opportunities) and converging (deciding on what to do next). ‘Discover’ and ‘define’ take place in the problem space where Service Designers take a problem statement or research question as a starting point. They discover by talking to people, collecting data, observing, or any other means necessary to investigate the problem at hand, building deep familiarity with the domain and users they are trying to understand. The subsequent define phase reveals patterns and distills the information collected to some problem definition. The problem statement feeds the subsequent develop phase. We have now entered the solution space, where the ideas collected and explored earlier are taken up by interdisciplinary groups who prototype, test, and refine potential a range of potential solutions – ideally in collaboration with actual users. Patterns will emerge, giving clarity on what solution has the most potential to maximize user outcome and business impact. The final deliver phase moves from experimentation and testing to production, ensuring the organization is equipped to deliver the service that caters best to customer demands and business needs.
Iterative and adaptive design enabled by divergence and convergence helps to find an ideal mix of desirability (“what do users want?”), viability (“is there a good business case?”), and feasibility (“can we build it?”). Additionally, designing products and services in this manner helps to recognize when the fruits of our hard labor run out of step with a world that’s VUCA (volatile, uncertain, complex, and ambiguous) (Stickdorn et al. 2018, 84).
Rather than offering a cookbook, Service Design stresses the importance of persistent reconsideration of proposed solutions and the problem definitions on which these solutions are based. We can solve a problem right, for example by building a technologically advanced solution, but are we indeed solving the right problem? Our perspectives on problems will inevitably introduce bias and we need to remind ourselves of this consistently. Although it’s not uncommon for Service Designers to introduce overarching project-like structures in business environments that appreciate predictability and structure, there’s no implication of a perfect sequence to do Service Design. Thus, Service Design makes use of feedback loops of iteration and adaptation and is ‘auto-reflexive’ because it’s subjected to such feedback loops itself.
Boundary objects
As indicated earlier, Service Design opens the design process to a variety of perspectives that mingle to converge towards a shared effort to deliver valuable experiences. Stickdorn refers extensively to work on ‘boundary objects’ (e.g. Star & Griesemer 1989), which looks at how different social groups engage in practices around a particular object or technology. Boundary objects coordinate the actions of people that inhabit different social worlds (such as people from different disciplines) and manage tensions between these groups. Boundary objects provide the means for different perspectives to interact. These differences are not overcome by means of some uniform translation of various interests but interact in unpredictable ways around the boundary object. The power of collectively working on a problem from different perspectives should not be underestimated. For complex work, there are no experts, as I wrote earlier. It’s unlikely a single professional or individual holds the key to the solution on how to create maximum value for customers and the organization, making it necessary to collaborate and validate our assumptions, learning new things about the complex domain in which we’re working as we go along.
Figure 5: Boundary objects
I’m reminded here of Jeff Patton’s work on ‘user story mapping’ (Patton 2014), a technique he developed to help people involved with building a product or service develop a shared understanding: “story mapping keeps us focused on users and their experience, and the result is a better conversation, and ultimately a better product.” (Patton 2014, xxi) When developing products and services, ‘requirements’ create a sense of finality about what users want. The danger is that desperately holding on to requirements might prematurely stop conversations with the user and between people that have different perspectives, which disincentivizes teams to look at the user problems they’re solving. However, when our job is to “change the world” of the user (Patton 2014, xliii), we might need to take a second look, build a shared understanding, and iteratively move forward from there. In a similar vein, a journey map “helps people from different backgrounds and communities of practice to collaborate on a common task.” (Stickdorn et al. 2018, 43)
Product leadership
A shared goal in the form of value (customer outcomes and business impact) not only aligns multiple perspectives around the boundary objects provided by Service Design, but also helps to overcome resistance. Tangible proof about what users want help to get things moving in a direction that people agree with. That said, true statements are not always sufficient in moving things forward. Resistance may emerge when opinions are second-guessed or outright not accepted because of the nature of the professional relationship. Truly building a culture of experimentation requires a culture that works towards a big and audacious vision, a persistent focus on what’s valuable, and a strong desire to validate steps taken towards the vision, which could mean criticism or the introduction of new ideas by anyone. As Scrum famously propagates, the inspection and adaptation that accompany value maximization in complex domains requires transparency, which is in turn based on trust.
As Peter Drucker has argued extensively, culture eats strategy for breakfast. Without a culture of experimentation that fosters trust, organizations will not succeed in maximizing value in an iterative and adaptive manner. Even impeccable facilitation will ultimately not help to overcome strict hierarchies in which new ideas never see the light of day due to rigid governance and fear of conflict. This puts organizations incapable of aligning themselves with the uncertainties related to what customers want and how to build it in a vulnerable position. There’s a challenge of product leadership here: to what extent can organizations foster an environment in which iterative design and delivery of products and services becomes not only possible, but also successful?
Related to this question, I reflect on behavior I encounter on an almost daily basis that strongly impedes the value of Service Design:
- Limited UX capacity: In my experience, UX professionals have a hard time in many organizations due to high demand and not being situated within a team. They become generalists that hop from team to team or from project to project, which causes misalignment with the work they’re supposed to support, lack of expertise related to the area and/or product, and handoffs. This becomes a dire situation if UX is a likely source that introduces methods that empathize with users, including (but not limited to) Service Design
- Seeing customer-centric innovation as a one-off: “Now that we’ve done the empathy bit, we’re done right?” No, you’re not. Empathizing with users needs to happen frequently and continuously to prevent running out of step with customer demands. Empathizing with users as a one-off can be due to lack of capacity (see risk 1), but might also be a symptom of cultural dynamics that culminate in fear of the great outdoors (i.e. the world of the user). It sure can be scary to have your assumptions validated, but what other options do you have really?
- Ineffective governance models that encourage top-down decision-making and introduce ‘death by committee’. Without someone in the capacity to decide based on insights acquired by Service Design-related activities, it will be difficult to act and make necessary (and sometimes tough) choices, especially when a committee of people needs to agree to get things moving. Indeed, Service Design can become a one-off in such situations (see risk 2). “Yeah, that didn’t really work for us. Back to business as usual.”
- Delivery lock-in: once organizations commit to building a product or service, all kinds of reasons to pursue that direction will emerge. Think of the fallacy of sunk costs or the fear to take accountability for ‘failure’. Killing features or a product hurts, but can be the best choice you have
- Welcome to the jungle: Service Design doesn’t exist in a vacuum. Its introduction may be complicated due to suboptimal Agile implementations and project thinking that becomes popular in times of need to achieve some sense of (supposed) control. The organizational trauma involved can compromise the enthusiasm with which Service Design is approached
Conclusion: why I care a great deal about Service Design Thinking
These reservations notwithstanding, I’m happy to have Service Design in my product management toolbox. More specifically, I see it as a strong ally in making organizations more product-driven by means of concrete instruments that build shared understanding. Service Design embraces empiricism by persistently looking for data that supports ideas about what to build, without refraining from critique on itself.
There appears to be a very organic connection between Service Design and Scrum, which teaches the value of empiricism to maximize the value of products and services. Scrum is purposefully incomplete and offers ample room for additional practices like Service Design to inform the work teams are doing in Sprints. And yet this is also where things become tricky. A culture that fosters innovation is certainly not a given and many organizations struggle to really incentivize experimentation and validation of assumptions. In such cases it helps to have a strong and appealing ally like Service Design to get things moving. This may not win the entire war but provides one hell of a promising starting point that I’m happy to use in my day-to-day work.
References
- Gartner research 2015
- Patton, Jeff. User Story Mapping. Sebastopol, CA: O’Reilly Media Inc., 2014.
- Star, S.L., and J.R. Griesemer. “Institutional Ecology ‘Translations and Boundary Objects: Amateurs and Professionals in Berkeley’s Museum of Vertebrate Zoology, 1907-39.” Social Studies of Science 19 (1989): 387-420.
- Stickdorn, Marc, Markus Hormess, Adam Lawrence, and Jakob Schneider. This is Service Design Doing. Sebastopol, CA: O’Reilly Media Inc., 2018.
