NB: A version of this post, written with Justin Barrie, is also published at DMA/We Think
Recently at work we did some service prototyping with a public sector client. We wrote about it on our blog. It’s a topic I’ve often wanted to capture here because, in my experience, prototyping and service prototyping in particular can be a challenge for people to get their head around. It took me a while and then it clicked (I suppose being schooled by IDEO, and having the opportunity to mull as my full-time job did help ; )
What Prototyping is for
Prototyping is about visually and tangibly putting together a working model of a concept in order to quickly test out various aspects of a design, illustrate ideas or features, and gather early feedback. Prototyping is the language of design and its basic tenet is ‘make to learn’. It helps you move beyond talking and thinking towards action. The prototypes are not the solution itself; they represent ideas, before artefacts are created, code is written, components are developed, and solutions are implemented.
Creating a representation of a concept through a prototype, or a service prototype of the whole system, means you build something in a fast, cheap way and can test it with users – inviting real input – from your own reflection, to colleagues, to collaborative partners, to users themselves. Better yet, prototyping gives the means of creation to the users themselves.
It’s a little bit semantic, but from my perspective there are two types of prototyping:
Service Prototyping in particular
The potential of service prototyping runs the gamut from conceptually illustrating service experience through sketching or storyboards to isolating part of a system and trying changes in real time. Most people would be familiar with the concept of a pilot, where 90% of the end product is there and the intent is work out the kinks. Service prototyping can and should happen way before then.
Like prototyping, service prototyping is about learning, failing fast (roughly and cheaply) in order to design success. But service prototyping is method of methods – that is, it encompasses a number of tools and techniques. The key difference is that service prototyping is explicitly concerned with service design context itself – how it works, where it connects, who’s involved, what has to happen.
Service Prototyping in practice
So to our recent project. 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 was tight – only five weeks. We’ve done tight service design projects 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. It also meant service prototyping was invaluable to fast-track synthesis and engagement.
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 (some examples shown below – no artistic skill necessary!)
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
In this instance the timeframe 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.
Post-writing-This-Post Reflection
Early on in my service design career I would have said the value of service prototyping is something like “a technique that represents the most effective tool to rapidly process ideas in a collaborative way, engaging with business partners and customers.” Mostly because organisations still don’t like the idea of the user/customer being in control. But now I say, rough a service concept out, and then give the means to the users to prototype. They’ll amaze you, and the clients. And you’ll appreciate that you really can’t come up with the answers in the same way an actual user will. That said, you still have to do the service design – I ain’t saying users are designers, you’ve still got to design the service – but they and the prototypes will help you move more quickly from talk to design and towards an implementable solution. Which is the point.