• Attention Matters
  • Posts
  • B2B Prototyping part 7: How prototyping saves you time and money

B2B Prototyping part 7: How prototyping saves you time and money

The seventh part of our series answers the biggest question stopping people from prototyping - can we afford to do it?

Welcome to Attention Matters, the newsletter from Storythings which gives you practical insights and tools on how to tell better stories and grow your audiences’ attention.

Graphic showing the word 'Prototypes" in bold font, with the phrase "Great ideas shouldn't sit around - they should get made." underneath

Hello!

This is the penultimate edition in this series about prototyping, which has been longer than most of others I’ve done on Attention Matters. I normally try and keep a series to 5 or 6 posts, but we’ve been doing a lot of work on building prototyping culture with clients at the moment, and I really wanted to get some of the key challenges and solutions written up in more detail, so that everyone can benefit from what we’re learning.

I want this to be a resource that all of us (including me!) can come back to when we’re prototyping format ideas. Which led me to wonder - would you like us to package up some of the series we’ve published on Attention Matters as PDF/Epubs/Physical books? If you’d find this useful, let me know by hitting reply!

As ever, I’d love to hear from you if you want to talk about how Storythings can help you with your B2B content formats. Hit the button below and we’ll get something in the diary.

To recap - this is where we are in the series right now:

- Create space in busy schedules to build and test prototypes
- Collaborate with internal and external partners on prototypes 
- Test these ideas with your internal and external audiences 
- Create metrics to measure attention and engagement
- Scale ideas from prototypes into full projects
- Know when to stop or kill and idea, even if you love it
- Demonstrate how prototyping saves your company money and time (that’s this post!)
- Build a sustainable workflow and culture for prototyping in your team

/

THE PROBLEM

So far we’ve mainly focused on how to solve the problem of making prototypes within your team, but we know that no team is an island, and you all operate within networks of departments that have their own needs, rhythms and deadlines. From our experience with our clients, the biggest challenge for comms and marketing teams is that they become ‘service’ departments for other teams, responding to a constant stream of requests and pressures from the rest of the company.

In this kind of environment, saying no to requests so you have time to prototype is really, really hard. Your team is no doubt working at capacity already, and everyone else needs stuff from you yesterday. How can you convince stakeholders and partners that taking more time for prototyping is going to benefit them? Because if they don’t understand and see the benefit, you’re not going to get the cooperation you need.

THE INSIGHT

Fortunately, there’s a really good role model, from an organisation that is, trust me, WAY more complex and sclerotic than your organisation. In the early 2000s, I was lucky to work at the BBC with Tom Loosemore, who along with Mike Bracken, Ben Terrett and many others, went on to build the Government Digital Service set up by Martha Lane-Fox in the 2010s. Lane-Fox recognised that the way government’s civil service was doing digital projects - multi-year, waterfall contracts that always ran over time and budget - was out of step with the iterative, test and learn approach of the best web 2.0 companies.

The very beginnings of the project started with some prototypes - rough sketches and wireframes that helped them ‘think out loud in pictures’. That attitude to making an idea quickly and testing it became the heart of the GDS culture, and transformed the way the UK government approached digital services. The GDS service manual has a detailed section on how to make prototypes, with a intro that is the best distillation, in my opinion, for the value of prototyping:

“You must make prototypes of your service to explore, share and test different designs before you commit to building anything.

You can quickly make and test multiple prototypes and discard the ones that do not test well.

Making prototypes is important because it:

  • improves the usability of your service

  • helps you to make sure you’re building the right service for your users

  • helps your whole team to get a shared understanding about the future of your service

  • allows your team to explore design ideas much faster and at lower risk than using your production code”

There are a couple of insights to pull out from that short intro. First of all, the use of the word ‘must’ in the first line. Prototyping is not a nice to have - it’s a fundamental step in making great digital services. The list of reasons why they prototype are interesting as well. The first is about making better services; the next two are about communicating ideas with end users and your team; and then the final one is about reducing risk and time.

THE ACTION

Each of the four reasons is as important as each other, and together they are a brilliant summary you can copy and use within your own organisation. Prototypes will make your content better, more aligned with your audiences’ needs, help communication and decision making with your teams, and make your content workflow faster and less risky. When you put it like that, it’s much harder for people to argue that you don’t have time or resources to prototype. So my first suggestion is simple - steal from GDS, and use that list to build a case for prototyping in your organisation.

Here’s five things you can do to create hard metrics for the impact of prototyping:

1. Time Savings:

Prototyping lets you identify potential issues quickly, and test them quickly. I went into this in more detail in the episode on testing, but as you discover and fix problems, estimate how much time you’ve saved doing this in prototype stage rather than with the live project.

2. Cost Savings:

Same as above, but for money. Compare the cost of creating and testing prototypes against the potential cost of fixing the same issues after you’ve launched.

3. User Satisfaction:

Run user surveys after prototyping, and compare them, if you can, to user surveys on a format that you didn’t prototype. If you find higher user satisfaction or word of mouth recommendation from the services you’ve prototyped, shout it from the rooftops!

4. Iteration speed:

When your team is just churning out deliverables, it takes ages to know if they’re working or not, and then fix the problems. Measure the cycle of testing, feedback and iteration on a live format, and then compare that to the same cycle on a prototype, which will be much faster.

5. Measurement Framework:

Calculate the ROI of your prototypes by dividing the net savings of everything above by the cost of prototyping. The result is real money and time that you're saving your organisation by prototyping.

Measuring ROI for prototyping will help you win more arguments with finance teams and budget holders, and that is essential if you want to win the argument to build a prototyping culture that lasts. And next time, we’ll be looking at exactly how to do that!

Thanks again for subscribing and reading this series. If you’ve found it useful, please hit the button below and let me know - I’d love your feedback!

Next episode, I’ll talk about how to build a sustainable workflow and culture of prototyping at your organisation. This is really important - sometimes prototyping cultures emerge around a few champions, but they only exist as ‘bubbles’ before the people running them get frustrated and move on. We’ll look at why this happens, and what you can do to build a more sustainable and long lasting prototyping culture.

See you next week!
Matt