6 ways to save time in rapid prototyping

4 min read
Erin Young
  •  Mar 30, 2015
Link copied to clipboard

Rapid prototypes help ensure that you’re moving in the right direction, and let you quickly share that direction with teammates, customers, and prospects—without investing in the actual development.

But if you’ve ever tried to build a rapid prototype, you know it can can become a dev undertaking of its own.

That’s why my team at Slide UX has established a few simple guidelines to get more and invest less in the rapid prototyping process.

1. Think of a rapid prototype as a disposable artifact

Rapid prototyping tools give us an exciting level of freedom. With enough effort, you can build an entire product without waiting on a single engineer. Finally!

Unfortunately, reality sets in when you’re halfway through the prototype. Every change creates a ripple effect that touches two dozen unrelated screens and breaks a handful of others.

The goal of rapid prototyping is to gain feedback that guides the final design.Twitter Logo So the prototype is just a means to an end. You can toss it once you’ve learned what you needed to.

So avoid the temptation to prototype the full product unless you want to tackle all the day-to-day hassles associated with actually managing the product.

Instead, spin up specific prototypes as your team needs them. Limiting the scope of each prototype frees you to do what’s best at the time, without worrying about ongoing maintenance.

2. Establish a clear purpose for each prototype

As project artifacts, rapid prototypes are particularly useful for:

  • Gathering customer feedback
    Use realistic page interactions and animations to help users understand your ideas.
  • Getting executive buy-in
    Quickly and succinctly convey plans.
  • Sales and account management
    Share new ideas with prospects, key accounts, or potential renewals.

Knowing your prototype’s purpose will help you define project scope and the level of fidelity you need. Which leads me to my next point.

3. Define the prototype’s requirements early

As with most design projects, scope and fidelity determine a prototype’s cost and development time. In other words: how big and how real does a rapid prototype have to be to serve its purpose?Twitter Logo

You can talk about a prototype’s level of fidelity in several different dimensions:

  • Scope
    What screens does the prototype need?
  • Aesthetics
    Are we prototyping with quick, sketchy mockups, or do we need full-color comps?
  • Interaction
    Do buttons and other controls need realistic mouse-over states? On tap, will we just reload the page or do we need animated transitions?
  • Content
    Will we use “lorem ipsum” or professional, brand-approved copy? Do we need to tie into a back-end system or can we paste dummy data into our designs?
  • Code
    Will we build in the code (like HTML or Objective-C), or with a rapid prototyping tool like InVision?

Agree on your prototype’s scope and fidelity early to avoid stakeholder/client let-down and last-minute stress.

4. Stay in flat design as long as possible

Conventional wisdom says you should work on interactivity early, but this doesn’t always hold in the world of rapid prototyping.

Attention to UI design tends to increase as a deadline approaches. Teams start asking: Is this exactly what we want to test? Is this what we want to show our customers, or the executives?

Last-minute design changes can create a ton of work if you built out interactions too early.

So issue a final call for feedback before you start building, and save the interactions until as close as possible to the actual deadline. Your team will feel heard, and you can spend your time perfecting designs instead of rebuilding the prototype.

5. Test your prototype’s interactions while you build it

Developers have long been familiar with the best practice: Test as you go.

Weaving interactions into a prototype uses a different part of the brain than designing does. It’s easy to get lost in the rhythm and just tune out until you’re done. But if you forget to test the prototype along the way, your work may just be beginning.

At the end of a long prototyping binge, it can be hard to know where exactly you went wrong, leading to lots of bug-chasing. Test while you build to get done sooner.

6. Don’t expect your prototype to communicate all your edge cases to development

Prototypes always lead to great questions from the team. Sometimes they’re broad and strategic, but some are very specific.

Every product has a set of “edge cases” or “unhappy paths.” Edge cases impact the user experience and should be well-designedTwitter Logo, but they can be hard to spot in a rapid prototype. For these scenarios, separate development specifications make the most sense.

Working from a written list of edge cases, engineers can make sure they cover each one—without the frustration of clicking around to try and discover them all.

Keep your rapid prototypes … rapid

Whether you’re looking to collect customer feedback, get executive approval, or improve engineering accuracy, rapid prototypes help you ensure you’re moving in the right direction.

By following my team’s simple guidelines, you can avoid wasting your work and keep the prototypes, you know, rapid.

Collaborate in real time on a digital whiteboard