Schmo is the personal website of Stuart Curran, a UK-based designer.

Limits of service design

Given the sheer number of conferences, blog posts and job roles that include the phrase service design you’d be forgiven for thinking that this is the most popular flavour of design right now. Nowhere is this more true than in government in the UK where service design has found a natural home amongst the strategic and systemic challenges faced by government departments delivering modern services for citizens with digital-first expectations.

The trap of expectations

Much like UX design before it, service design is following a hype curve of raised expectations, not driven by the volume of digital solutions in the hands of customers (although undoubtedly a consequence of this) but by the volume of complex problems confronting public service organisations. Whenever there is a problem that appears multifaceted, it seems that service design is the solution, or at least the approved method for tackling it. 

This is not a criticism of service design as a way of practicing design. If anything, the popularity of service design represents a rising tide that is raising the value of design in general from the perspective of those who have decision-making power over what gets done. In many ways, this is a great time to be practicing design. We have interesting problems to solve and a growing respect for the value we bring.

But when you hear people saying “we need a service designer” as the default response to every challenge faced, you do start to worry about whether the role of the service designer is becoming reified at the expense of say, a team or widespread participation in the design process or even other design perspectives. God forbid that we ever reach a stage where service design becomes a verb in the same way as “UXing” did for a while. 

Audiences for design

The essential problem in organisations facing ambiguous situations that require some form of change to occur, is that there are multiple audiences for design. For example, some people are deeply interested in the reasons and evidence, the why of change, and place great value on the sensemaking outputs of service design that simplify the user needs and journeys. Others however, are immersed in the detail, in all its complexity, and simply want to get started on something, to know where to begin the change. Service design is great at dealing with the why, through an emphasis on user research and understanding the context that frames the work to be done. I would argue that it’s not so great at translating this into clarity of action. Often this is where product managers take over, translating needs into capabilities.

Now of course you could argue that in the context of a team, differences of perspective would naturally resolve themselves. In many ways, service design should perhaps be viewed as a team sport, to mirror the way in which user research was promoted as everyone’s concern. Unlike roles however, teams cannot be prescribed easily in a shorthand way that guarantees a particular type of outcome. Perhaps this should be the case and there are certainly some interesting attempts to do just that in the form of team topologies. 

Service logic versus service design deliverables

At least if you hire a service designer, you will get some service design. That sounds good, right? Yes, up to a point. And it’s a crucial point. The logic of service is different from that of UX or product-oriented design. If you simply deliver some service design you are following the logic of deliverables not service. Service is relational. It’s true value is in connecting things together. Sometimes in obvious ways, sometimes in disruptive ways but always connecting, always in motion, following the flow of value from provider to recipient and back again. This service logic is powerful but obscured by the idea of service design as a means of delivering a prescribed outcome.

The perspective of experience

Feedback without fuss