There’s a scene in “Raiders of the Lost Ark” where Indiana Jones winds his way through a Cairo marketplace. Suddenly, the crowd parts, and Indy faces an assassin brandishing a wickedly curved blade in a series of expert flourishes. The expectation is that the two will engage in an epic swordfight—except Indy wearily pulls out a gun and shoots the assassin dead. Done. Instant classic.
Perhaps you know of this famous scene already. But what you might not know is how it came to be…
The script did originally call for a long, carefully choreographed fight that would have taken three days to shoot. But Harrison Ford, who played Indiana Jones, had an agonizing bout of dysentery at the time and needed to take a break every 10 minutes. Ford recalled in an interview posted on Reddit: “I was puzzling how to get out of this 3 days of shooting, so when I got to set, I proposed to Steven [Spielberg, the film’s director] that we just shoot the son a bitch and Steve said ‘I was thinking that as well.’ So, he drew his sword, the poor guy was a wonderful British stuntman who had practiced his sword skills for months in order to do this job, and was quite surprised by the idea that we would dispatch him in 5 minutes. But he flourished his sword, I pulled out my gun and shot him, and then we went back to England.”
What does this have to do with prototyping? Like the swordsman who spent months training and preparing for his scene, we sometimes labor over prototypes so polished that people mistake them for the real thing. Instead, the project demands called for a simpler, faster prototyping solution to communicate your ideas.
While high-fidelity (or hi-fi, for short) prototypes are certainly fun to play with—and even more fun to make—they can sometimes be overkill, leading you astray if you’re not careful. This article will go through four common prototyping traps, along with advice from a few design pros on when using lo-fi prototypes a quick, easy shot is best. For other occasions, our experts also offer tips what to do to keep your high fidelity prototypes simple and elegant.
Trap #1: The Visual Distraction
Test subjects and clients are so distracted with the way it looks that they start critiquing the look—rather than how it works.
“A lot of people want their prototypes to reflect every nuance and every pixel of the product, but you risk eliciting reactions that aren’t useful,” says Jeff Harrison, Sr. User Experience Consultant at Evantage. “The classic example is in usability testing, when you’re trying to optimize the flow. If the prototype looks too good, people will often spend all their time talking about the colors.”
A lot of people want their prototypes to reflect every nuance and every pixel of the product, but you risk eliciting reactions that aren’t useful
The solution, Harrison advises, is to use simple images, minimal color and plain backgrounds to help subjects focus on the specific task you want feedback on. “Some of my greatest prototyping achievements for clients look completely mundane and not at all colorful,” Harrison says.
Trap #2: The Forest for the Trees
High-fidelity isn’t just about visual design—it can also refer to the functionality of the prototypes.
With so many things to do, it may be hard to focus. Clients and test subjects wander from tree to tree, getting lost in the beautiful forest you’ve created, making it hard to get focused feedback.
One piece of advice from Guy Meyer, a Senior Designer at Digital Telepathy, is to isolate the trees. “I build components rather than pages,” Meyer said. “Then I build these isolated sections out and not worry about the entire site. It just helps with focus.”
Define the task you want to work on, and build a prototype of just that feature or interaction, Harrison recommended. “There are usually two reasons to make a prototype,” Harrison said. “The first is to communicate something better than words. And the second is to answer some kind of question. When we make a prototype, we try to call it something. A user testing prototype. A navigation prototype. It helps you draw attention to something in particular and to focus on why you are building it.”
Later, you can start grouping features to gauge more complex flows and dynamics, Harrison said. This approach works well with several current design methodologies such as atomic design, object-oriented design and structured content modelling.
Trap #3: Design Overkill
Prototyping software tools have become so powerful and sophisticated that it’s tempting to layer on the bells and whistles. But such efforts are costly. They take time, not just to create, but also to update when the designs need to evolve.
In his seminal article on Lean UX in Smashing Magazine, Jeff Gothelf, advises, “Pick the core user flow (or two), and prototype only those screens.”
Next, “get the prototype in front of customers. Bring them in regularly to test the workflows, ideally once a week,” writes Gothelf, who authored, “Lean UX: Applying Lean Principles to Improve User Experience.” “Collect feedback. Figure out what worked and what didn’t. Tweak the prototype. Hell, gut it if you have to: That’s the beauty of Lean UX. The investment you’ve put in at each phase is so minimal that rethinking, reconfiguring or redesigning isn’t crushing in workload or ego-bruising.”
Another way to scale back the tendency to over-prototype, is to focus on the minimum viable interaction, with the smallest number of steps to accomplish a task. Think of it as the Goldilocks Principle of Prototyping—not too much detail, but also not too little. Just right…
“The key is that the prototypes should contain just enough information to get the job done,” Martin Smith, co-founder of Axure Software Solutions, writes in his article on prototyping in an agile environment, “not too much fidelity taking up too much time, and not too little leaving ambiguity in the design.”
Trap #4: Creating a Monster
Sometimes, it’s necessary to reach for high-fidelity.
“When it comes to selling a concept to an executive team, we have to go high fidelity because it really helps people to grasp the ideas,” says Russell Wilson, Partner & Head of Design at Microsoft Business Intelligence. “Some people aren’t able to see where you’re going without it.”
When it comes to selling a concept to an executive team, we have to go high fidelity because it really helps people to grasp the ideas
If you need go down this route, there are a few tricks you can deploy to make sure your prototypes don’t freeze, crash or otherwise blow up on you during a crucial presentation.
The first: Constantly test your prototype on all of your target machines, advises Kip Mitchell, the Head of Customer Support at Axure Software. If you’re designing on a top-of-the-line Mac with the latest browser, your prototype will feel zippy and light when you preview it on your machine. But if your client works with a three-year-old computer running an older browser, they might have a harder time loading and interacting with your prototype, Mitchell explains. Testing on target devices is good practice whether you are building your prototypes in code or or using software tools that export to code.
To prevent bloat, you can also streamline your prototype by finding ways to reuse assets. If you’re programming your prototypes directly, try to reuse code to avoid too much copy-pasting. If you’re using prototyping software, many will let you build frequently-used elements once and then deploy them multiple times throughout your design. Also, think about places where applying a global style would make sense. If you’re hand-coding, no doubt you’re already using Cascading Style Sheets (CSS) to define a unified style. Most established prototyping software will also let you establish a single style that can be reused throughout your project.
If you have a dozen interactions, you can put them on separate pages—thereby helping to keep your pages simple and uncomplicated.
Are your pages still feeling sluggish? Add zip to your pages by separating your interactions rather than jamming them all onto a single page. “Focus on the one or two cool things that you want the page to do,” Mitchell suggests. He calls those “hero interactions.” If you have a dozen interactions, you can put them on separate pages—thereby helping to keep your pages simple and uncomplicated. “It’s okay to have another page that looks exactly the same,” with each page highlighting a different hero interaction, Mitchell adds.
Marc-Oliver Gern, who worked on the “Madden NFL 25” property when he was Lead User Experience Designer at Electronic Arts (EA), encourages his designers to think like a performance front-end engineer. “We usually have a checklist that we go through,” says Gern, who now designs products for Brilliant Basics. Gern’s list includes such things as image optimization, designing with the correct screen size and Web resolution and using global styles.
Steering Clear of the Traps
In general, most designers we talked to said that it’s best to start with low fidelity prototypes, and then gradually layer on more detail as you go along. Develop simple components separately, then hook them together to test flow.
“Everyone wants to do hi-fi, and that’s understandable. The idea is that the more accurately you can communicate, the better,” explains Jason Broughton, Head of User Experience at Zappos. “For us, the best practice is to keep things lower fidelity. Early on, you want to be as loose as possible. As you get closer to the final hand-off and deliverable, you’ll want to have higher fidelity.”
Everyone wants to do hi-fi, and that’s understandable. The idea is that the more accurately you can communicate, the better,
“It also depends on the project,” Broughton adds. “If you’re pitching to an executive team, you might want high-fidelity. It’s not black and white. It just needs to adapt to the circumstance.”
That’s a lot like knowing when to stage an elaborate swordfight… and when to just pull out your pistol—and shoot.