- Under: Interactive Design
Service design is where operations meets customer service.
Imagine you’re buying a cup of coffee at your local Starbucks. You see the cashier, a few baristas, and maybe some equipment—but, do you ever think, how did the coffee beans arrive? Where are the stored? Who grinds them and when? When does new coffee and pastries arrive, and how often?
All of these questions are addressed with service design, because to create successful customer interactions we need a clear understanding of the front-line interactions and the behind-the-scenes workings.
At CHIEF, we’re a troupe of designers, strategists and modern web developers. We build brands that shape markets, technology that drives action and ideas that create the future.
When we got the call to join a client team to redesign a legacy government data portal, we were faced with a new challenge. The charge was to bring in user-centered design practices at scale for the first time to an agency where change was afoot and waterfall approaches were a thing of the past.
We started asking users what they needed and realized we had our work cut out for us.
Troves of institutional knowledge, confusing policies and countless legacy contractors led to an existing system where rules and regulations were inextricably linked to business requirements and often written into the code. This meant that a policy change could cause a yearlong software development cycle.
Writing clean code and installing a pretty UI were the least of our worries. We needed to understand how on earth all of these rules, systems, databases and laws interacted. Enter: the ‘discovery phase.’
Like any client engagement, deadlines were tight, stakeholder feedback was crucial and we had to keep the ball rolling on the project. Our first priority was not to come up with an exhaustive list of technical specs, but to build trust with our partners by articulating understanding of the complex challenge in front of us.
During one of our first all-hands meeting, the our team agreed on a mission:
“Deliver an understanding. Provide unique user insights.”
We then spent the next eight weeks conducting user interviews, sketching and collecting as much information as possible about the technology and the way it was being used.
We dug into our user experience toolkit to draft ideal users, word clouds and task flows that we gave names like, “Lifecycle of a(n) [insert anything we didn’t know about].”
Even as we began to make sense of these things, our understanding of the scope of challenge was coming up short—we couldn’t see the forest through the trees. Stuck in a room filled with sticky notes (as we typically are) during synthesis, we experienced a critical moment when we realized what was missing from this deep-dive analysis:
80% of the user experience takes place outside the tools we are building.
We needed a way to fully understand the scope of our product, while also understanding and applying the specifics of policies, stakeholders and current system architecture within one of the largest agencies in the federal government.
The sensemaking continued. We incorporated some of the techniques from John Kolko’s Exposing the Magic of Design, into our project. By applying the book’s exercises on making meaning out of data, we were able to use static workflows and word clouds to enhance our overall understanding.
This stage often feels repetitive, but we stuck with it because it almost always produces new, valuable insights. Finally, we were starting to draw loose connections among the data.
Ask The Experts–Or Become Them.
Another valuable technique in the service design community is called the Service Blueprint Template. The typical application of this template is to bring in your subject matter experts to brainstorm and draw the conclusions in real-time.
But our team did not have access to the subject matter experts. We had to become the experts. Because we had just spent weeks collecting and analyzing all kinds of data, we had an advantage.
Based on the freely available resources and the active Slack community of Practical Service Designers, we got the answers we were looking for by asking ourselves the below questions.
- Actors : Who does what and when?
We visualized the primary actors who participate across the use case, as well as where managers, administrators and corporate leaders intervene.
- System : Where does each step take place?
This was an important category where we learned most of the process takes place on paper (Hello, ‘Print’ feature!). And also where we need to be accomodating systems out of our control.
- Policy : What are the constraints? Statutorily or implied?
Another helpful category in this exercise as we were able to visual a bottleneck of policies.
- Idea/Opportunity : A place for participants to provide any feedback.
It’s no surprise, we saw the most room for improvement at the same step of the policy bottleneck.
For a full description of the blueprint, see image below.
With this scrappy due diligence in hand, we had a clear set of deliverables for the client: As-is and To-be Workflows, including the systems and actors outside their purview, and tactical recommendations for the new system.
By relying on high-fidelity maps to visualize the depth and breadth of the to-be product, we delivered an understanding of what we were building and the ecosystem where it would live. The result was the formation of trust between the client and their users, which is perhaps the most valuable result of all.
Want More? WHAT’S NEXT
- Engage with Share and Contribute to Practical Service Design’s Slack Channel—an open community for all levels of experience!
- Share your experience with service design with CHIEF on Twitter, LinkedIn or Facebook!
- Was this blog helpful? Subscribe to CHIEF’s newsletter for monthly insight on all things design, development, UX and more.