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.”

5 Homepage Myths You Should Stop Believing

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.

Comments
  • Totally agree! While high fidelity wires and prototypes can be more fun to make, you suddenly find your usability testing turning into a discussion about whether it’d look better if the blue was a bit darker. Users are also so much more nervous of criticising the thing because it seems like so much work has gone into it…which, if it’s hi-fi…it has!

    • Thaisa Santos

      For me, low fidelity prototypes work just with my team: advertisers and programmers. Showing low fidelity prototypes to clients wasn’t a good idea simply because they could not understand, as much as my chief :/ When we need to present something, I have to turn in to a hi fi prototype instead and make things clear about the overall design. It’s still a “waste” of time if there are many changes on the appearance, but that’s the only way they can understand. Low fidelity works for us, but depending on who wants the project, they’ll only understand something closer to the final phase.

      • How strange. I’ve never found this to be a problem. I would always start by saying something along the lines of:
        “This is not a finished design and as such you will notice it is not very pretty. That’s because today we want to learn more about how you’ll use it, and whether things do what you expect them to – not about how it looks, because that comes later.”
        Of course you still need to have clarity in the wireframes, and as such I would not use many placeholder boxes or lorem ipsum; try to have some representative content.
        I’d be keen to hear more about the types of lo-fi prototypes you’ve had problems with.

        • Thaisa Santos

          Ooh yeah, I use placeholders a lot XD As for lorem ipsium, I try when possible avoiding it. Without much content it’s like designing a house without knowing which furniture you’ll buy. I’m still testing low fi prototypes, but usually make them in Axure. Perhaps a different way would make people outside the team to understand it. I’m doing experiments and using my chief as a common user xD

  • Adam @AxureThemes

    It’s rare I disagree with so many things in such a well written article. But I think this is UX logic circa 2008.

    For just one example: “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.”

    This is a good thing. Users are going to get lost on your actual site. No one is using websites in a focused way. People are mindlessly using them, half distracted by their life. Focused feedback is about as useful as a novice tennis player analyzing Roger Federer’s footwork. That’s not the users wheelhouse.

    Get them in front of something real and complicated, and you’ll get real feedback.

    • Alex Pham

      That’s a great point, Adam. A holistic approach to testing and obtaining feedback is absolutely legitimate and can surface interdependent issues previously not considered.

    • Peter Zalman

      I agree with Adam. I read through the article, and generally it is very well written and contains great points. But to me, prototyping is about exploring both form and function *together* on the same canvas. I don’t get these lo-fi / hi-fi discussions.

      Humans are not algorithms, that can focus on different abstract layers at different times using different artefacts.

      Please, focus on content and forget the visuals. Please, focus on the layout and forget about lorem ipsum.

      For me, this never worked out. Form and function are equal, and if you content or feature is amazing in lo-fi sketch but does not work on the real layout, then perhaps that content or feature is not so amazing, and you better figure this out sooner than later.

      • Alex Pham

        Thanks for the comment, Peter! I don’t disagree. Providing context makes perfect sense. Build just what you need to get the type of feedback and discussion you are seeking, but not more. It’s a balance, to be sure. I like what Jason from Zappos said: it depends on the circumstance; not every situation calls for a full-blown prototype.

  • Dan Hontz

    Couldn’t agree more. I’m from the product side of things, and I’ve been in early design-exploration meetings with executive teams where someone gets hung up by the shade of blue on a wireframe/prototyped nav bar. Although UI/UX-oriented folks understand what a prototype is (and what it isn’t) a lot of other people in the chain of developing a product need to be guided. Sure, when you’re near a final design, prototype the whole deal, end-to-end. But for concepts, early flow explanations? Focus.

  • Stay along with simplicity however don’t be simple.. 🙂

    • Alex Pham

      Thanks, Partha. Occam’s razor is always a good rule to live by. 🙂