paint-brush
Things We Need To Rememberby@BromfordLab
156 reads

Things We Need To Remember

by Bromford LabJune 10th, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

<a href="https://twitter.com/adamstjohn" target="_blank">Adam St-John Lawrence</a>, Co-founder Global Service Jam

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Things We Need To Remember
Bromford Lab HackerNoon profile picture

Prototype, Prototype, Prototype!

“If you only do two things make them research and prototyping. If you only do one thing, do research; get off your seat and onto the street, talk to your customers and more importantly observe your customers”

Adam St-John Lawrence, Co-founder Global Service Jam

Over the past few months, we’ve been really busy facilitating discovery sessions and service design workshops to support programmeOne, the organisational transformation programme currently underway at Bromford. In itself, this has been a journey of discovery for the Lab. As well as doing the work involved in designing, facilitating, synthesising and communicating the output of workshops, we’ve also been working out how we best fit within the programme and where we can offer the most value. We’ve just rebooted our trello board to reflect the work packages which were the result of our discovery sessions and we’re currently busy pulling together stakeholders, filling out Change Requests and drafting Test Plans.

On Wednesday, we had a serendipitous conversation which allowed us to step off the hamster wheel for an hour and take stock of how we have been working. I felt more creative and clear following that hour than I had in weeks, so the first thing we need to remember is:

Time to reflect isn’t a luxury, it’s essential . . . and it’s proper work.

In our desire to move our post discovery session thinking forward, we’ve been really busy over the past few weeks defining work packages, drafting detailed Test Plans and submitting Change Requests to our Design Board. In itself, this is good; whilst Change Requests and Test Plans might seem like they add unnecessary bureaucracy, they actually don’t. They provide a structure which ensures that everything we test has been considered in terms of how and where it fits within the organisational strategy and it ensures that following the test we are able to demonstrate impact. However, the reason for the video catch-up which turned into our serendipitous conversation was that we were struggling to push all of our work packages through this framework. What was wrong? Had we lost our creative mojo? Why couldn’t we see what we needed to test? The answer, it appeared, was that there was nothing to test. . . yet.

PING! A light bulb, and a second point to remember:

Prototype, Prototype, Prototype!

We’ve long advocated to test more and pilot less, but before any of this we prototype. . . .or we did. A high fidelity prototype can work much like a test, but a low fidelity prototype could be a paper mock-up or even a doodle during a workshop. Prototypes can be anything from a sketch or storyboard to a morning sat on a bench in a park or an afternoon trying to sell people a service which looks real but actually doesn’t exist, in order to see whether you’ve got an idea that floats. Prototypes help us understand a problem and give us valuable insights that we can use to design tests (if we need to). So rather than trying to jump straight to a Change Request and Test Plan, for some of the work packages we just need to go much more low-fi, we need to get out on the street talking to people, start sketching screens on cardboard iPads or just start making something — if we’re stuck on a problem we just need to get out the pens, Lego and PlayDoh. Do we really need to run a formal test to see if we can fly our new drone and quickly produce formatted video, or did Paul just prototype it with his own drone (which is exactly the same) last weekend?

Which leads me on to our final point to remember:

It’s much better to show people how something could work than it is to try and explain it to them.

The mantra of the Global Service Jam is to ‘show not tell’ and ‘do not talk about doing’, essentially to use prototyping in order to both learn and communicate your learning. If you want to understand more about how people interact with driverless cars (it’s not on our own exploration pipeline by the way) you don’t need to develop an early version of an autonomous vehicle and file for all kinds of certificates and permits, you just need to dress up like a car seat and stick a GoPro to your windscreen. The inspiration and learning we get through ‘doing’ is much more useful than ‘talking about doing’ and arguably enables greater buy-in from stakeholders later down the line.

Comment

Originally published at www.bromfordlab.com.