I’ve been learning and gaining expertise in service design methods since 2012. In 2015, in a Director of UX role, I started practicing all the elements of Service Design in my day-to-day. In 2017 it started to emerge as a discipline and job title in the United States. By then I’d studied and done enough work in the various areas of the discipline to call myself a Service Designer.
A Little History: Everyone has a Service Design 101 page now, even though the concept of a ‘service’ has been around for what, 200 years? Longer, probably.
What’s new is the application of design skills to how services are defined, constructed, provided and supported. My definition of it — an amalgam of what’s out there and my own experience in actually doing it — is this:
the uncovering of needs, strategy, design and creation of, orchestration around, and operational sustenance that supports the provision of a service that benefits people in their day-to-day lives over a period of time during which they need that service.
(This is not to be confused with product design — see below.)
The uncovering of needs
I deploy a wide range of research techniques to uncover what people truly need. It is a delightful thing to be able to do for a job because I learn so much about people and I’m always surprised because, people! Endlessly interesting.
I uncover what employees need to support the creation and provision of a service. Often, leaders in organizations don’t know what different parts of their highly siloed teams go through just to get something customer-facing out the door and nominally working, yet still resulting in a disjointed experience for end users. What’s worse, employees know they’re part of a chain of touchpoints that don’t fit together but don’t have the influence, process or mindset to connect the right dots and make it better.
My go-to’s are observation techniques, in-depth contextual interviews, content audits, quantitative data, strategic analytics, competitive and market research, and scenario planning (a personal favorite) to get to the truth of what’s needed. I seek out and learn new techniques all the time and use them whenever they’re the right thing to do. I use behavioral science theory and work with that tried-and-true scientific method stuff I learned in high school chem lab to do this work with rigor and discipline.
Communicating and gaining support for findings is the beginning of the change management part of what I do. People need to be able to see the truth of what I’ve uncovered before they’ll take the rest of this journey with me. So I have to be compassionate, thoughtful, strategic, straightforward and conflict proficient.
At this stage, my role is to win over hearts and minds, so it’s fortunate I’m highly skilled at research and talented at crafting the story that needs to be told so that I can gain the buy-in needed to move forward.
strategy, Design and Creation
Taking everything I just learned and working with a team or teams to come up with what a service needs to be in order to be effective is — well, the most fun part. It’s also the hardest, because as a designer I have to get everyone involved, including myself, to set aside preconceived notions, biases and perspectives on what’s needed by the providers and end users of a service. I have to bring the team(s) I’m working with along for that ride, too, which is another exercise in winning hearts and minds.
I use whatever ‘thing’ I can co-create with the team gets our message across — the message about what this service needs to be in order to be successful and beneficial to people. Sometimes that’s a lot of presentations and storytelling, or a workshop series (one of my superpowers is facilitation!). Sometimes it’s an enormous post-it journey map with sketches on a white board that we can walk stakeholders through. Sometimes it’s a service design blueprint more formally shared at big meetings. Sometimes it’s a storyboard with stick figures interacting over long periods of time. Whatever works.
The same change management principles apply here, especially as a service starts to become more real and concrete. Whether I’m leading the design of something completely new (which is usually why I’m hired) or evolving a current service (which is where most of my responsibilities actually lie everywhere I’ve worked since 2012), I’ve got to bring people along with me to make sure the vision and direction are shared. This stage gets everyone on board conceptually with what we’re going to do, and keeps us on the straight and narrow, ethically speaking.
Creating and conducting the building of a clear sequence of recursive touchpoints that an end user will interact with is the more tactical and obvious part of this work for me, because I’ve been doing it for 15 years. This is where product design and user experience fit in — the specifics of how, what and when people will do things with your service and how employees will take action to support them. This is also where design ethics rubber meets the road.
I use prototypes, user research, co-creation, design validation, and eventually, we build those things out. Many times this is done in an agile environment, which is a method that facilitates priorities and focus but tends to lose the thread of the larger point of view. My role at this point is to make sure research and validation still happen during the build to test our touchpoint assumptions — building the right way without losing sight of building the right thing.
A note about orchestration:
An awful lot of organizations want to start here —”we’re executing on the strategy” — skipping the part where we all uncover needs and design what meets them. Someone in the chain of command believes they already know what needs to be done, or maybe there’s an existing strategy that we’re supposed to snap to — even if that strategy is so full of buzzword-laced vagueness that it’s not even a real sentence, much less something to ‘execute against.’
I have a lot of experience doing work in this space as a result, with varying levels of… low success. Starting here means I’m retrofitting touchpoints, usually into a frankensteined digital experience. Doing things this way also tends to make things worse for teams, a huge factor in employee morale that isn’t always considered. Which is weird, because we all know that disempowered, unmotivated teams don’t come to work every day energized to make good stuff. In those cases I try to expand the footprint of the work to include other parts of the process, with varying results.
How a service will be run, supported and improved is the final piece of the puzzle in making sure a service will be successful.
I use measurement strategies and planning techniques to understand the health of a service, monitor its use and make sure it’s not being abused.
I also continue to build the body of understanding through research to ensure we’ve made the right thing the right way so that I can contribute to continuously improving the service we’ve built.
(Digital) Product Design
Wikipedia says digital product design is “an iterative design process used to solve a functional problem with a formal solution. A digital product designer identifies an existing problem, offers the best possible solution, and launches it to a market that demonstrates demand for the particular solution.”
In essence, digital product design (to distinguish from other types, like industrial design) is a subset and a smaller effort, but contains many of the same tasks as service design. Typically the questions I ask aren’t as wide-ranging about the audience or at the enterprise level for employees.
I use research techniques and think strategically, but at a more focused level of solving a smaller set of problems. I also use elements of orchestration and operational sustenance, focused on a single touchpoint within an ecosystem.
If I’m in a service design role, usually I’m leading a scrum or agile team/teams in designing and building a set of products that fit together into a service I’m co-designing with others (my work at Morningstar is a good example).
Some product designers focus mainly in the execution space, delivering mockups and code. While I know how to lead the creation of a design language and understand front and back end tech, I am not the person you want making those things.
This is the work I have the most experience in but it is not where I want to stay in terms of interest or career growth.
User Experience is the discipline I use to give form and flow to the service I am helping to design. It is the most concrete representation of how end users will interact with a given set of touchpoints, and as such it provides a team with direction in what to build when I’m in orchestration or sustenance mode.
It’s a field I have over fifteen years of experience in, nearly ten of those leading teams. There’s a long list of deliverables I could type out but that’s not how I like to focus this work — I like to focus on the outcomes related to the service I’m defining and building.
What I’ll generally produce when I do this work are pencil sketches and whiteboards created with a team, so that we all have an opportunity to contribute to making the best thing we can that meets the needs of people who need to use that thing.
And yet, with all of that experience, I can’t for the life of me figure out how to remove the footer at the bottom of this page. It’s made me crazy since I launched this Squarespace site.