Getting better at talking about service design and interaction design

Better models for understanding roles and capabilities

Since starting working in UK gov in 2015, I’ve seen the rise of service design in government. This isn’t a bad thing — there are lot of opportunities for service design.

However, I’ve got increasingly worried about what people think service design is.

Is a service designer just a better interaction designer? 

Many delivery teams seem to think that a service designer is a senior interaction designer who can also design offline tasks. This isn’t true. 

Unfortunately the current Digital, Data and Technology (DDaT) Profession Capability Framework doesn’t do much to resolve this ambiguity.

While the titles for the two roles suggest the differences:

Service designers design the end-to-end journey of a service. This helps a user complete their goal and government deliver a policy intent.
User-centred design: service designer, GOV.UK

Interaction designers work out the best way to let users interact with services, in terms of both overall flow and at the level of individual design elements.
User-centred design: interaction designer, GOV.UK

in reality, when I looked across the different levels and compared them to each other, they had the same skills at the same levels, with the only differences as :

• interaction designers are a bit better at prototyping code (for example, a senior interaction designer is an expert, while a senior service designer is practictioner — as is a working level interaction designer)
• service designers are a bit better at strategy (a senior service designer is an expert, while a senior interaction designer is practitioner — as is a working level service designer)

I also noticed that strategic thinking covers both roles as including ‘determining patterns, standards, policies, roadmaps and vision statements’. It’s not clear from the model who does what and to what level.

Better models

I know of 3 models that are helpful here.

Lou Downe’s initial what designers do in government diagram

Lou’s post about different types of designers has a lot of nuance that got lost in the DDaT framework. However, what I do find interesting in this is that the blog post says that ‘all service designers prototype in code’, yet the example doesn’t include that. Hmm.

Jason Mesut’s UX Spectrum

I’ve been a fan of Jason’s work for a while, and I’ve appreciated his work on UX capabilities. His ‘blobs’ (as he calls them) allow for mapping out of capabilities.

PolicyLab’s design and context radiators

This is one that the excellent PolicyLab use for showing the different areas that particular design ‘zooms out’. I like this for making it clear that extra breadth also means losing attention to detail — it’s just on a different scale.

Using this to redesign government models

With this in mind, as a starting point, I’d go back to Lou Downe’s diagram and add an element of ‘focus’ vs ‘required’.

Spreadsheet on Google Docs.

I’ve also changed a few things:

• narrowed in the content design focus (the only reason I could think of it being in is for things like writing API docs maybe?)
• removed user researcher as I don’t think that fits in this model

I’ve also left the model as is to say that service designers aren’t required to prototype in code, even though the article says that they do. If anything, I’d suggest that service designers prototype everything that isn’t in code, in other words, experience prototyping.

Using this focus concept in practice for interaction and service design

While it’s fine to say that interaction designers focus their professional capability on interactions and journeys, while service designers focus on process and purpose, this can feel a little abstract. 

So I’ll suggest the times when a service design or an interaction design level of focus is helpful.

Times when a service design level of focus is helpful:

• projects designing policy or other more speculative projects — huge amount of co-design, even if the ideas are digital they’re largely at concept level. Policy Lab are great at this.
• discovery phases of digital services — it’s important to understand the whole service. It’s also a chance to start building relationships with the wider service ecosystem through service mapping and co-design
• spanning digital services that form part of a common journey — being the glue and even the facilitator can help the designers on the separate teams stay aligned. Marc O’Connor has done good work in this space on the access to childcare space, as has Marie Cheung in the bereavement space
• doing experience prototyping and developing service patterns — I haven’t seen this done to date though (and will comment on this more later)

Times when an interaction design level of focus is helpful:

• when you’re doing more digital processes than end-to-end service transformation — this involves pragmatism from the team about the actual scope. This may be particularly true if you’re delivering something to a tight deadline
• alpha onwards on a digital service — both in creating different alphas (yes, it it about creating different options, not just one), and then having the attention to detail to make sure they follow best practices
• design systems/design ops work across digital services — helping understand common interaction patterns

Followup thoughts

What happened to service patterns?

One thing that I’ve noticed reviewing old posts from 2016 is that there was a lot of talk about service patterns. That’s gone quiet. I suspect that these patterns became actual services — Verify, Notify, GOV.UK Pay. Unfortunately, when I’ve asked about seeing evidence about the design decisions I’ve been told it’s been lost.

In the meantime, service communities have started up (often unified under a step-by-step pattern), and service patterns have started to pop up in local government (for example, FutureGov’s service patterns for local government). It could be that the communities will start surfacing service-level patterns at some point.

A more agency-style approach to UCD capabilities?

As a former agency UXer, above interaction design, I’ve got reasonable skills in most other UCD roles. However, in central government, this is at best ignored and at worst seen as threatening. This is unfortunate. 

Andrew Travers has rightly pointed out that well-rounded seniors can support a junior on their team in an adjacent role rather than relying on doubling up. It would also mean that when there are skill gaps, particular people may be able to step in and temporarily act as cover. He also points to the key task that has to happen — UCD heads of role better collaborating and acknowledging those whose skills span multiple roles. At its most extreme, it also means addressing some UCD roles commanding higher day rates than others. Why would an interaction designer temporarily help do service design when someone with the official title gets paid more?

Let’s not forget about the other UCD roles

UCD roles also include:

• content designers
• front-end developers
• performance analysts
• user researchers
• business analysts

With the exception of potentially user research, I know that all of these roles also have challenges of understanding. While I can’t cover them here, this is a reminder that they too need to be included in wider discussions about roles and focus.

Endnote: in the process of writing this blog I’ve been told that the DDaT framework is in the process of being rewritten, partly because of the said confusion about roles not being clear. I’m looking forward to seeing what the new revised role descriptions look like.

Further reading

• The different types of designer in government, Lou Downe. An interesting starting point, and I also believe the 
• Shapes of UX designer, Jason Mesut. Also have a play with his UX spectrum online
• Mapping Service Design and Policy Design, Andrea Siodmok. A whole lot of excellent diagrams in here including the levels of focus on design
• Units and silos, Andrew Travers. He’d already identified the silos causing issues, and suggests great things such as making sure the hiring panel for UCD roles extends beyond just said role
• Service patterns for local government, Future Gov. Not much there as of December 2019, but it’s worth keeping an eye on.
• What service communities are achieving across government, GOV.UK. A snapshot of the emerging service communities in UK government. 
• GOV.UK Design System. While there are some patterns there, on the whole I’d say that they’re at the interaction level rather than the service level.