Yup, you read that right. Let’s talk about how Google Slides might be an even faster prototyping tool than pen and paper.
We all know that prototyping is a big deal. If you’re even remotely in tune with startup literature and holy gospel, you’ll have read The Lean Startup and be putting those principles into place wherever you can. We all know that getting great user feedback is what keeps us on track when we’re building products. For that, we need prototypes!
But are we doing the prototyping as effectively as we could be? Wikipedia defines a prototype as:
An early sample, model, or release of a product built to test a concept or process or to act as a thing to be replicated or learned from.
And here at Hanno, we’re always looking for new tools to speed up our prototyping. There are some great apps like POPapp and Marvel–both of them are fantastic and allow you to turn simple sketches and mock ups into fully clickable prototypes in order to gather feedback. We’ve used them on plenty of projects.
But what happens when even those apps aren’t fast enough?
A few weeks ago, we kicked off a 1 week product design sprint with the awesome team at Transcense. We’d been following these guys for a while as they’ve been building their product, which is a transcription and vocalisation app to helps deaf and hard-of-hearing people understand what others are saying around them. When someone speaks, the Transcense app will listen, and turn that voice input into text on the user’s screen. It’s a brilliant concept (and also one that we thought was a very worthy recipient of our first pro-bono product design sprint, as part of our move to doing social good).
We allowed ourselves 1 week, and in that week we had to cover as much ground as possible. We entered the project with most of the team having no previous knowledge of the app, or the users involved. Our brief was to totally rethink the onboarding experience. We would need to run through a full cycle of the design thinking process that we’d been intensively practicing on our team trip a few weeks before, and come up with a solid set of validated prototypes and learnings.
The Transcense team had already done a lot of great work with the app’s design, and knew a huge amount about their users. It’s unusual for us to kick off a sprint where we have quite as much great user research and feedback. But we needed to get even more.
They’d put together a set of fairly high-fidelity prototypes using another app, called Flinto, so of course, we initially thought it would be good to continue along that same approach.
So we started prototyping on day 3, and for the afternoon session, we’d also arranged a user test with a group of deaf and hard-of-hearing users to get real feedback on what we were doing. So however we chose to prototype, we had to be certain that we could get at least 1 prototype built, and a testing plan sorted, in just a couple of hours.
On top of the tight timeframe, we were also doing this whole thing remotely. Our four-person team was in Kuala Lumpur, Spain, London and Rio de Janeiro. The client was in San Francisco. And the initial test group of users were in Washington. The slower our prototyping process was, the fewer learnings we would gather.
We soon realised that we’d need to be a bit leaner.
I’d heard of people using Keynote and PowerPoint to prototype. There are even fully-featured templating systems for wireframing with Keynote. But the problem with Keynote is that while it might work for 1 person building a prototype, or for a group of people sitting around a single screen, it’s definitely not built for multi-person, asynchronous collaboration.
Even POPapp, which is usually extremely fast to work with, would have been a challenge to use. If we needed to make a change to a screen of the prototype, we’d have to re-draw that screen and upload the replacement into the prototype. That’s not an impossible task, but it certainly slows us down.
Don’t forget, we were trying to get as much learning as possible, in a very limited timeframe. The faster we could get those insights and iterate, the better.
We soon realised that just as we use Google Docs obsessively for collaborative wireframing, we might actually be able to use Google Slides for prototyping, as well.
Getting a first prototype together
We started off by grabbing a photo of a generic phone screen online, and created a new master slide. Dropping a coloured rectangle on top of this device photo would serve as the display area, and give us a simple canvas to work with.
And then for each new screen in our onboarding process, we created a new slide, applied this master layout to it, and dropped in the text we needed. In fact, once we had a single slide built, the fastest way to prototype our way through the app was simply to duplicate the slide when we were ready to move on to the next screen, and then make the edits we needed on the duplicated slide.
In total, we spent about 4 hours coming up with a prototype plan and script and an initial 6-slide, hacked together prototype. We also put together a script and guidelines for the user interviews, so that the client could also carry out some of these themselves. It was scrappy, but for what we needed to do, it was the most efficient solution. Sometimes you have to embrace a little messiness.
And so, we took that scrappy prototype to our users
Our first user testing session was a remote one, with a deaf user-group in Washington. We split the group into two and carried out a separate test on each group:
- In the first group, we tested a manual onboarding. Pieter from Transcense ‘manually’ explained the app to the group, and an interpreter signed his explanation to them.
- With the other group, we tested our automated onboarding. We relied solely upon our prototype to explain everything to the users.
Once the onboarding was out of the way, the users tried to use the real app, and we interviewed them to gather feedback on how each experience had played out.
All of the users we interviewed understood instinctively that this was an early stage prototype. There was virtually no confusion on their part about the feedback we were looking for. Even though we hadn’t specifically told them that this was an early stage prototype, they intuitively grasped this, and took that into account. Since the prototype was so simple and stripped back, the users felt comfortable criticising the flow, the text, and the emotional engagement, without getting bogged down in what it looked like.
That was a huge bonus, and helped us avoid one of the biggest challenges when trying to test prototypes. Higher fidelity prototypes often look a lot more ‘final’ and polished. When you show them to users, they can often be reluctant to give feedback which would lead to serious changes being made.
And it’s not just the users who are unwilling to make big changes when they’re working with higher fidelity prototypes. It influences the decisions of designers, too:
High-fidelity prototyping, however, may make designers reluctant to change designs and less likely to fully explore the design space (Goel, 1995; Wong, 1992).
Previous studies have addressed potential differences between low- and high-fidelity without manipulating the medium of the prototypes. There was no difference in the number of usability problems found by testing with low- and high-fidelity prototypes (Virzi, Sokolov, & Karis, 1996), and aesthetics did not influence perceptions of usability (Wiklund, Thurrott, & Dumas, 1992).
There’s a whole wealth of research which backs this up, and suggests that rapid prototyping might be a better option. It’s also far quicker–it’s a win/win!
So we stuck with the low-fidelity prototypes, and recorded how users interacted with these each time. Each test had two components:
- A prototype
- A set of topics that we used as the basis of a conversation with the user.
We weren’t trying to interrogate them, so we didn’t have a pre-defined interview script. Since the Transcense app is one which requires a lot of user trust and confidence in order to use, our goal was to try and build them up to fearlessly use it with others. That meant that getting emotional feedback was our top priority–not the sort of thing you can do effectively with a rigid interviewing script.
After the test, we’d regroup, analyse the feedback we’d received, and then think about how we needed to iterate or test further, to get more learning.
In one case, we actually iterated in between user interview participants. In the 5 minute break between interview sessions, we were able to open up the prototype and fix a couple of small issues that users had identified and were focusing a lot of their feedback on. We then ran the next user test, gathering further feedback. By doing this, we managed to effectively double our speed of iteration and learning at times.
In 3 days, we built and iterated through 10 prototypes, conducting a user interview for each one, and spoke to about 15 users.
By day 3, we were ready to make our prototypes slightly higher fidelity, so that we could validate some slightly more specific questions that we were trying to answer. These were based around the emotional engagement we were building inside the app and the persona we’d used to guide users through the onboarding. But even at this point, we were still designing inside Google Slides, and this forced us to avoid getting too carried away with visuals.
Here’s what a screen of prototype 7 looked like. You can see that it’s still simple and stripped back. There’s form and function, but we’re making no effort to make a realistic attempt to design the actual UI:
Tips and guidance
The beauty of using Google Slides for your prototyping is that it’s incredibly simple and intuitive. Anyone can pick it up and get started. The biggest tip we could give would be to go away and give it a try on your next prototype!
But here are a few extra hints…
- It’s possible to link elements of a slide, to other slides. So if you use the linking functionality in Slides (it’s exactly the same as the other Google Apps), you can link a button on a screen to a specific slide, making it easy to build simple routes and flows through your prototype.
- Using master templates (as I mentioned above) is a great idea and will make it even easier to edit your prototype and move fast.
- Consider starting to build your prototype as a plain old slideshow–as if you were going to show someone a pitch deck. An effective prototype on this sprint might even have been a set of slides explaining how the app works, just to validate whether we were using the right language.
And above all, let’s think in terms of MVPs: minimum viable prototypes
If you’ve read Creative Confidence, which is written by David and Tom Kelley of IDEO, they give a fantastic example of a hugely lo-fi prototype. When coming up with an iPhone game concept for kids, they built a prototype from foam-core, and acted out how the interactions might work. There’s a video and a Slate article which are definitely worth looking at. As IDEO say: never go to a meeting without a prototype.
The concept of a minimum viable product is a controversial one. Many people even advocate for minimum loveable products instead. But how about shifting our thinking and instead, considering the idea of minimum viable prototypes. This can really force us to cover a lot of ground and change our mindsets.
When we were running our design thinking workshops, one of the biggest learnings we had, was that we needed to stop defaulting to code for prototyping. As a bunch of designers with tons of web experience, we feel so comfortable with coding up prototypes, that we often jump straight into code editors and start prototyping away. We even have our own mini framework that we use to start building out products rapidly But even if we can code very fast, and produce great prototypes which can evolve perfectly into production code, this isn’t necessarily the right approach.
One of the best things about Google Slides was also how manageable the learning curve was. Even using a simple clickable mockups app (like Marvel or POPapp) would have required a little learning for new users, and at the very least, a few basic materials and editable access in order to make changes to the prototype.
By using Google Slides, our team weren’t the only ones who could contribute. The Transcense team could easily make changes to the prototype and get more involved. There was no need for anyone to be able to code, or even to sketch anything. Making changes to the prototype was as simple as clicking on a slide, and editing the text. When you’re a small team looking to get as much value as possible from limited testing time and resources, enabling everyone to quickly edit the prototype is a major advantage.
Principles for minimum viable prototyping
So we’ve come up with a few basic principles, based on these early experiences we’ve had with minimum viable prototyping
- Pick the simplest tool that will allow you to get a prototype out there.
- Favour tools which will allow you to iterate rapidly (in seconds, not minutes), particularly at the early stages of prototyping.
- Pre-book test groups and limit yourself with tight deadlines, so that you’re forced to prototype quickly
- Don’t prototype ambitious concepts–as soon as you have just enough of a prototype to test with users, go and run that test.
- Push back on ‘polish’. A prototype is supposed to be unfinished. As long as users can grasp what you’re showing them, visual finish doesn’t matter.
Google Slides is not a polished app that’ll help you build out beautiful, realistic prototypes. it’s definitely not cool. But it might well be the best tool for the job.
p.s. If you’re in need of help with rapid prototyping, take a look at our Playbook for more details of how we help clients to prototype MVP apps.