Service Designers need to be able to actually design a service

When I talk about Service Design, I talk about the end-to-end process from the initial question to the iterations of the Service during its life. I find that a lot of people see Service Design as the discovery and design phase of the development of a new service. Most books on Service Design present a lot of tools to tackle the challenges in the fuzzy front end of the service innovation process. Many educational programs focus on user research, creative solution generation and service blueprints. This is all very valuable. Innovation means dealing with uncertainty and user needs. One of the great things that Service Design has brought the world are ways, tools, mindsets and methods to cut through the complexity of the fuzzy front end.

The Back End of innovation

Although there is a learning curve with all that, I experienced that this is the easy part. The back end of innovation is a lot harder. This is where your brilliant idea meets reality. This is where you find out that your design is just a first step on a long journey. This is the moment where the client has to put his money where his mouth is. The discovery and design phase were very inspiring, exiting and innovative. But after the initial excitement has settled, stakeholders and project members have to be motivated, technology has to be developed and organization processes have to be changed. Investments have to be sold, nay-sayers have to be turned and roadmaps have to be drawn. New insights, conditions and connected initiatives collide with your design. The quality of the design is not measured by how great it looks in the beginning, but how well it can function in the back end, how well it can provide a framework for discussions, engagement, connections and iterations.

Design as problem solving

Navigating through the back end means constant problem solving: technical, organizational and financial. Adapting the design to move around technical obstacles is a powerful way to move projects forward. Designing steps on the roadmap can help with planning and budget decisions. Changing the design to accommodate the organizational ambitions can help to smooth things along. Even designing tools that bring organizational problems that were invisible to the surface can be useful in the process. This is difficult work and places high demands on the strategic skills of the designer. Empathy for the user is just the beginning, you need to empathize with all stakeholders in the process. If you work with digital services, coding skills are a conditio sine qua non. But next to the language of developers, you also need to start speaking the language of business.

Value driven design

Harder means the opportunity to add more value. If you are driven by adding value, all the beautifully crafted service blueprints that end up unused in drawers are testaments of what Service Design is not about. If you design with the end in mind, any service design that is not realized is bad design. That is just smoke and mirrors.

Delivery based Service Design

The name “Service Design” points at the design of services. The problem with this term is that design ends with a deliverable for most people, something nice to put in a slide deck or hang on the wall. Design as a way to solve problems has not yet landed with most people. So do we need to call it something different? I heard someone use the term “Delivery Based Service Design” the other day. Maybe we can bridge the gap that way. Service Design faces a similar problem that interaction design faced years ago (sometimes still does): the hand-off gap. A designer designs something nice that is destroyed in the development phase because the designer did not know enough about the development to design something that actually can be built. The containers for the Lorem Ipsum were not suited for the real content.

The material of the Service Designer

Just like a good interaction designer needs to have knowledge of code and content, a Service Designer needs to master the material of which services are built. This usually involves:

• technology: not just code but enterprise IT landscapes and API’s,
• organization: the people that have to built the service ánd the ones that have to operate it,
• business: the business case for investments, the stakeholders with their agendas and alignment of strategic, tactical and operational goals.

This is the reality of Service Design. The empathic user interviews and beautiful customer journey maps are just the tip of the iceberg. Or as Gary Vaynerchuck likes to put it: “Fucking execute in reality.”

“Fucking execute in reality.” — Gary Vaynerchuck

If you can use design to link the business case and strategy to technology and other investments and tie that to the needs of the user and other stakeholders, you’re in the Service Design Value Game.

Big On the Little Things (BOLT) is a publication about the little things that make strategic design great. Dennis Hambeukers works as a Strategic Design Consultant at Zuiderlicht. For more content, you can follow me on Twitter or on LinkedIn .