Service Prototyping in 1 week, 10 minutes and 7 hours (in that order)
The focus of this post is some recent service prototyping activity we did with a public sector client; to share what we did, how we did it and what we got out of it.
Unfortunately, we can’t share what the topic was about (public sector budget sensitive), but we can share that it was a rare case (when we talk to other designers in the service space) of service design not concerned with improving an existing service, but designing a new service. Blank page territory and a fantastic opportunity with a keen public sector client.
We can also share that the timeframe for the entire project was extremely tight – five weeks from kick-off to full service design specification. We’ve done tight before but this was extreme. It meant there was some documentation compromise in terms of depth, but in terms of breadth it was still collaborative intent > research > analyse/synthesise <> prototype/iterate > define. It also meant working closely with the team and their trust in us was critical to get to the right outcome all round – a service design that represented the users, and a service design they could use.
The opportunity for the nitty-gritty of service prototyping occurred about Day 12 – Day 15. We had done the background research, and field research with actual and potential users in one-on-one interviews and exercises. Up to Day 11 we formulated with the client representatives (our team) emerging insights – both from the internal and external view, emerging design principles and a value proposition for our component of the service within a broader service program context. And we had design features we knew would and wouldn’t work for users based on considering existing ‘like’ services.
Working up the service prototypes
On Day 13 we worked up the service prototypes for the workshop to be held on Day 15. They had to be paper-based and mobile because the workshop was going to be interstate, and in a room we where we knew we couldn’t stick stuff on walls. Sidenote: why do so many event facilities not allow you to use the walls!?
We started with all the information in our heads, a wall full of the refined insights, what we knew were key design features, the design principles and value proposition. We talked a bit about what we knew, and what knew we wanted to explore. And what we knew was likely to be the shape of the service.
And then we gave ourselves 10 minutes to sketch out how the service might work.
A bit of this, a bit of that, a bit of interpretation, a bit of personal perspective, some sacrificial red herrings, but mostly a lot of evidence. We named our concepts, and then we told them as a story – drawing out how the concept illustrated the pertinent points we wanted to learn more from. They worked! We then spent the next three hours working them into presentable component versions that we could put in front of people in a workshop. These components would also give the participants the means to work up their own versions during the workshop.
Workshopping the service prototypes
The workshop itself was half a day. Deliberately short for the participants who were a 2:1 mix of real users and business team representatives. The tight time also meant we could focus the thinking and activity; this was to be divergent and blue sky, but blue sky with feet firmly on the ground. After some scene-setting and informal validation of our findings so far using brainstorming and discussion we introduced the service prototypes. Telling them as a story the same way we’d done in the office. The energy of the participants was palpable as you could see they were naturally were inclined to particular prototypes they wanted to explore. To do this we asked them to capture on the prototypes themselves:
- What worked
- What didn’t work
- What would they change or add
This quickly helped us test the basic precepts of the design principles and validate or discard key design elements.
After this first round we gave the participants the pens, paper and scissors and tape and asked them to design the service themselves. As designers it was a delight to see. Having had their appetite whetted with the ‘review’ and the means made accessible with the basic service component representations the participants weren’t intimidated. They were inspired!
Using the components from the original prototypes they built on them, coming up with their own user whose journey they plotted – exploring who might be involved, what tools they’d use, even giving themselves boundaries of service because it was a government service. To bring their prototypes together we asked them to:
- Name their service – which helps drill down into what it is at essence
- Describe it’s key features or benefits in their own language
- Describe what they thought might be some of the challenges – especially fruitful for their take on government service boundaries.
At the end, the participants had not only given us feedback, but had also seen and felt like they had been an active part of designing a service they would one day use themselves (hopefully soon).
The value of service prototyping
Prototyping workshops can be exhausting, thrilling, difficult (add in any number of adjectives) and this project was tight (have we made this point enough ;). But that meant it was critical to not compromise on what can sometimes look to the client like ‘play’. The value of the service prototyping enabled us as the designers, with the business team, to rapidly, roughly, and cheaply; propose, make, explore, discard, enhance, learn, and extract solution options in a few hours better than any individual crafting could have achieved.
Because the team representing the business and technology sides of the service were in the room and working with the users they were part of the conversation and saw how users interacted and talked and felt about the potential service experience. This gave them a better perspective of what was to be built. Not just what policy initiative or CabSub (that’s a cabinet submission for those of you outside of the public sector) needed to be met.
At a practical level, the service prototyping gave us and the client clues and direction to the ultimate service design in a very short amount of time.
At a client and service capability level, the service prototyping activities gave the client an exposure to the type of design thinking and practice that will help them approach their work differently because now they are thinking about humans using their service, not as use cases interacting with a system. This is perhaps best captured by a comment from the IT Project Manager in our project closure meeting:
“I came into this being very sceptical about service design, now I get the value of it.” We’ll take that!