Why I Prototype
(and why you should too)
I can single out the moment that made me stand up seriously and decide to focus on design as a career. It was at Google I/O 2013, and I was at the Agile UX Research Practice talk. Right at the start, Bethany Fong showed a slide that I’d never forget.
“For every dollar spent solving a problem in design, you save $10 in development and $100 in post release maintenance” — Clare-Marie Karat, Cost Justifying Usability
The quote has stuck with me since, and I’ve used it on several occasions to soothe the nerves of clients who are worried about spending significant amounts of money on design. In their experience, the value of code is tangible while that of design is not. This quote goes a long way to grab people’s attention.
Ultimately, of course, I need to justify to my clients how investing in design helps them save (and make) money. For this, I ask them a rather straightforward question: “have you ever released a product that you were absolutely certain solves a major pain point, yet it didn’t resonate with users?”
The response is a unanimous yes. I’ve had this happen to me in my product management experience as well. The problem is that far too often, the product management team identifies a problem and the solution, brings in design to sketch out the spec, and then brings in the development team to build it out. A couple of months go by before the users finally get their hands on it, and they aren’t enthused.
Fail fast, fail often
One of the reasons behind the failure of several products that look like they’re solving real problems is that the team often commits to one solution far too early. This commitment traps them from exploring other possible avenues of solving the same problem, avenues that might make more sense.
This is where prototyping can have such a major impact. To get this right, you want to engage with your designers at an early stage while you’re still coming up with various solutions, create prototypes and test them with real users. This is how you save money by investing in design: you discover things that don’t work early on, which helps you avoid investing in development. Additionally, you don’t incur the costs related to having a poor product out in the market, such as the impact that has on your brand and the poorer monetization of users you are acquiring in this time.
At this point, I should admit that this isn’t a particularly original thought — Google Ventures’ Design Sprint, for example, is structured around the same idea. What I try to spend a lot of my time on, however, is the final part: testing with real users.
Observing user behavior
A typical prototype requires a user to complete the task the product is meant to solve. Unfortunately, many prototypes can be biased — tap on the wrong place of an InVision prototype, for example, and it’ll show you the active touch points on that screen.
To generate insights from a prototype, you need to focus more on the user’s journey to completing the task, and not simply whether or not they could do it. You want to get them comfortable and talking, explaining their decision making while using your prototype.
It’s almost like when you interview a candidate for a job and present them with a problem to solve — you care more about how they’re thinking it through than whether or not they solve it. And just as you focus on what an interviewee says while deciding whether or not they’re someone you should hire, what the interviewee says while testing your prototype tells you if your solution actually works.
What should you be looking for in their responses? A multitude of things that vary from product to product. A general theme is to understand how they’re solving the same problem currently and whether they’re likely to make the investment in learning to accomplish it another way. People hate changing their own behavior, and the success of your product lies in whether or not they see sufficient value to make that kind of effort.
This, of course, falls in the realm of UX/Usability research. I highly recommend having someone in your team who has the skillset for that role. If you don’t, it might be worth bringing someone in, or entrusting your designers to learn more about it. Steve Krug’s book Rocket Surgery Made Easy is a great place to start.
If you’re looking for tools to help you perform usability testing on Android, do give my app Obsrv a try. It lets you test InVision, Marvel and Framer Team prototypes in one place, share an entire collection of prototypes with one link and record users as they go through your collection of prototypes.
