SDGC17: Pattern Language for Service Design

Harnessing service design and management of designed services in large complex systems.

Service Design has been developing and spreading with fantastic speed over the past few years. It has become an important topic among designers and business managers.

Currently, I see developments for Service Design predominently in two directions: First, change and transformation programs where Service Design is integrated into overall progam as a tool to achieve customer centricity (this stream includes activities in domain of digital). Second, innovation and rethinking of the world around us. And that is good, as it pushes the workd forward and creates better environment for all of us.

But sustainability element of Service Design and design management, needs more attention. How to ensure that design sticks and is embraced by large organisations? That it is lived daily and further improved over time?

All internal design teams are ACTIVE designers. That mean they are pushing for improvements and changes throughout the company. Being ACTIVE designer one develops understanding of human impact on business. They design service (and events) that trigger emotions, emotions trigger customer behaviour, and that behavior creates positive or negative impact on business. I emphasise ACTIVE as opposite to INVITATED. Invited designers are those being invited to resolve challenge (when somebody else already did the digging and defined problem/impact area).

And in reality, ACTIVE designers, start the design cycle at the end — from business challenge that must be resolved. As internal designers are not owners of the operations, they must work with the organisation to resolve the issue and implement new solution. And sometimes this bottom up approach of talking and discussing with many managers is hard and long lasting. This approach is not efficient neither sustainable.

Furthermore, currently available tools are also not supporting the effort of embedding design into the organisation.

All service design tools are created with primarely design effort in mind — but not for scale. And there are several challenges:

Linearity — Companies are not delivering service in a linear way. Linearity within customer journey maps or service blueprint is great for designing, but it prevent us from effective implementation. One employee’s work place may be positioned on intersection of many journeys, or it may involve several journeys at once in a single situation. Usual situation is that employees understand all aspects of service while being presented with design at the workshop, but as soon they return to their work place, they are not able to adapt it to their reality.

Abstract — Designed solution is usually too distant from employee’s daily work perspective. Customer insights, anxieties and challenges are often too far to understand.

Reach — Current tools are designed for co-creation. And that means workshops. Unfortunately it is not possible to put several thousands of people through workshops and expect effective results.

Ownership — Customer journeys are touching many departments within the company. But there is no single responsible department or a group for it. Each manager tends to focus on service elements only under his or her responsibility.

Consistency — As for all co-creation tools, the output depends on the quality of inputs and research involved. Unless managed properly, there is a tendency of inconsistency.

Focus — service depends on details. And unfortunatelly those details are hidden within the massive blueprints of journey maps. They are usually missed as everybody’s focus remains on the overall service flow.

Languague — this is the biggest challenge. We are missing the words and a languague to discuss what we are actually designing. If I ask you what did you actually design (not how, WHAT!), usual response would be: “a service”. Or maybe “a solution”. If you cannot name WHAT you designed, how do you expect from others to promote it further?

Languague is important. Other creative industries are much better at it. Let’s take for example fashion. Not that there are pants as a garment, but going deeper: formal trousers, chinos, jeans, boy shorts, etc. Each of the name signifies social occasion for each type to be worn, how to mix it with other clothes, when to wear it etc. To go even further, ladies know the difference between daily casual dress, coctail dress and evening formal dress. There is huge difference among them and ladies would not mistake one for anohter. And whole distinction among those 3 dresses is already expressed through name. Now imagine for a second that we use the same level of language complexity as we use in Service Design. We would call our pants and dresses “a solution for impact and warm protection”, wouldn’t we?! Because we would not have anything better for naming. That’s how bad we are with language in Service Design.

But on the other hand, language of Service Design is mostly focused on tools. We have developed a great vocabulary for methods and tools, but not for content we actually design. To be honest I do not expect that Service Design language enters people’s everyday language. I expect that it enters business language among employees within the organisation. The discussion about service, design and impacts must be pushed to all levels within the organisation. And it should be present on the daily basis.

So this leaves us that we need a top down design management system and a languague.

So this leaves us to introduce a Pattern Languague. To be more precise, a DESIGN SYSTEM to ensure consistency across the company and that we are able to manage it.

The concept of pattern language is not new. It was first defined for architecture by Christopher Alexander in the seventies. He defined a pattern as: a rule which describes what you have to do (and think about) to generate an entity the rule defines. It is that the system of these patterns that forms a language. He defined a system of 253 architectural elements for which he describes a quality — what needs to be addressed or taken into account when designing it

Let’s examine an example of a pattern: Entrance Transition. “A place where you make a transition from external unprotected to internal protect. A place to make a pause and create the psychological switch between the two.”

No building inputs there. Just how to make an entrance that FEELS RIGHT. Each pattern provide sufficient information to give direction how the element should be built, but leaves sufficient freedom so you can design your own solution.

The approach to build such DESIGN SYSTEM, or a Pattern Language would be that patterns are built through 3 levels.

First level is the SYSTEM level where patterns are identified on the level of the system. I would argue that companies within the same industry (e.g. mobile operators) would have very similar system of patterns. In general you lay out your customer journeys and quickly the patterns will emerge. In telecom, that could be “Waiting for broadband line installation”. The structure and granularity is more-less on the level you prepare when doing the customer journey mapping or basic service design, taking into account customer concerns/needs. You describe all conflicts and challenges customers are experiencing in this particular pattern as the element of the service or journey (fears, anxieties, conflicts, and other important elements). This level each pattern is defined with all interactions, conflicts, relationships, challenges and general context. Similar as Christopher Alexander defined his patterns.

After that each pattern is further enhanced on what we call DESIGN level. That means that original pattern is extended (or improved) based on brand attributes, your business capabilities and customer principles. At this level, each pattern is defined the meaning, the affordance and quality. So “Waiting for broadband line installation” becomes “Anxious-less waiting”, or whatever you want to achieve with this waiting pattern. Key here is to provide a name that implies expectations how to deliver, because employees would be grasping those names.

Next step is to create a solution for a pattern (service design).

But of course, there must be additional layer so the pattern can be shared with other managers — BUSINESS level. That means you have to address it with what managers understand: KPIs, measures, reports, etc. On this level you define the pattern as an entity with its own measures and KPIs. There is one important thing to mention: what and how you measure. There is 3 main things: operational performance, customer behaviours, and sentiment (if you can). Very important that you put dependancies between patterns where you know that poorly executed one pattern can lead to problems in the other (e.g. misinformation during contracting, can create anxieties which are recorded during waiting period for broadband connection). This interconnection will enable you to immediately know where to look for clues in case of poor performance. And it will make owner of one pattern aware, what impact does that particular pattern create for the experience on whole service.

To conculude: a pattern languague is a way to design, communicate and manage service in large systems. I strongly believe that we must embrace a design system to properly manage a business system.

This post is an edited transcript of presentation given at Service Design Network Global Conference, in Madrid, November 2017.

More info on humanact team is available on http://www.humanact.design