This post was written by Dano Qualls, a Fresh Tilled Soil apprentice.
One of the reasons I love design thinking is its emphasis on rapid prototyping. This helps you pick the right goals and designs early in the process. Getting it right early pays off: what costs $1 to fix in the requirements stage costs $3-6 to fix in design, $10 to fix in coding, and $40+ to fix after release.1 Rapid prototyping helps you answer questions quickly and inexpensively.
That’s all pretty standard stuff. What isn’t as intuitive is that you should be explicit about what you’re not testing when you build a prototype.
Perhaps the most natural way to approach prototyping is like a designer looking for feedback. You create an interface, outline a task, and watch a user complete the task. You see if it works as intended and take notes on how to improve it. Though this process may feel natural, it’s not the most effective way to test a prototype. Rather than approaching prototyping like a designer soliciting feedback, approach it like a scientist testing a hypothesis.
Before you put pen to paper and design a prototype, write down exactly what you want to test. Examples include:
- Does the user know to swipe the page to advance, or do they look for a “next” button?
- Is this feature where the user expects it to be?
- Does the user have that need while in this specific time and place?
- What social norms influence how the user experiences this service?
Next, write down what you are not testing right now. You can test all of these later, but ignore them for now. Your prototype shouldn’t answer questions you aren’t asking. The earlier you are in the design process, the more things you should not be testing. For example:
- colors, typeface, font sizes
- how to do X, Y, and Z tasks that you will test later
Knowing what you are not testing gives you the freedom to create the simplest prototype possible. This could mean testing after 10 minutes instead of two days. The benefit isn’t a faster design process, but a more nimble one. You can test a key concept before creating elements that build upon it.
This process catches problems before they snowball, and helps you to be okay with throwing away prior efforts. The more time you spend making something, the more you risk falling in love with it. If a test pokes holes in a concept you’re attached to, you may be less willing to scrap it and start over. Good designers create lots of concepts, knowing they will throw most of them away. Writing down what you are and are not testing forces you to create simple, focused prototypes for specific tests.
Don’t see a prototype as a way to prove the success of your design, but as a disposable tool to help you learn something specific.
1: Graham, R.J., & Englund, R.L. (2004). Creating an Environment for Successful Projects, Second Edition. San Francisco, CA: John Wiley & Sons.