Service mapping and ownership
Tags: Design Thinking, User Experience, Service Design, Mapping, Design Process

Service mapping workshop

(I was lucky enough to keep all my speaker notes to pull from the workshop to give you a glimpse of how and when this dialogue was struck)

Before springing this workshop, this new design jargon, and ultimately a large cognitive load; we started the conversation early on the appetite of building one together.

Why a service map? To discuss all of the parameters of the service so we can be aligned. It is good to be aligned to have some foresight in to the decisions we make for the [-name of tool-]. Every decision will have a ripple effect. This also gives us a view of the elements of the service we have no control over but still live within the ecosystem and will have a direct effect on what data you receive, how you receive it, and if it is ready to scale. 3 things to remember about good services: They start and end with people There is a transaction (a give and take) Everything is sewn together with verbs

I introduced the main pieces of the map that we were going to focus on together.

Actors: The people who engage, interact, and maintain aspects of the service.

Channels: The products, processes, and locations within the service.

Touchpoints: The interactions and engagements that happen between channels and actors — (or verbs).

(This is not the traditional way most service designers see channels, actors, and touchpoints. This is how I saw them as a way to bring focus to the relationships.)

Part 1: Find and log missing gaps

Prior to the workshop, we created a version of the service map that was created based around our knowledge of the reporting tool, our high-level knowledge of the back-end infrastructure, and our assumptions.

If this map was purely based on assumptions, that would have worked just as well. There is a benefit to putting out a Frankenstein and learning.

A way to track and measure a good service is by using a service map. We did an internal audit of what we know about the service and attempted to make a high-level map. This map has elements and relationships we have ownership over, and many we do not. However, because this service is evolving, every change will have a ripple effect. We would like to arm NC3 with the chance to see potential opportunities and mitigate risk as they scale. We would like to spend some time to see if there are any actors or channels that are missing in the current state of this map. This map is focused around the main actors: The victim and the investigator.

We made the map purely out of post-its to enable everyone in the room to peel them off and stick back on to the map when making decisions. Affordances in workshops are a hidden gift.

Part 2: Break

I know it sounds silly to add this, but allowing space for voluntary retrospection can really help a workshop vibe.

Part 3: What do we have ownership over, What do we not have ownership over?

Participants were asked to get up, look at the map, and draw a dot on the elements they knew they had full decision-making authority over and the elements they did not. (example: Facebook chatrooms and Reddit threads)

In this workshop example, participants created a new variable to measure: elements they had half ownership over as they were partnered with many other government institutions.

Part 4: How long do we estimate (no right answer) that the transaction of data for a high impact victim will take?

Everyone looks at the map and what they have ownership over. How long do you think it takes for the transaction to ideally be complete: where an investigator has eyes on an actionable complaint.

Once understanding that they did not have control over elements like Facebook chat rooms, Reddit threads, friends or family spreading misinformation, and victims getting lost in Google search results — that the likelihood of someone getting to the tool to create a well-informed report was a big blocker.

Part 5: What pieces have been researched?

We acknowledged the pieces of the service that are a priority and the pieces of the service that may need a bit more attention and intention now that we understand what can affect the desired service standard.