Difference between low fidelity and high fidelity prototypes

Question

What are the unique qualities that distinguish one type from the other?

How and when should I use each to use them properly?

Answer 1

"Low fidelity prototype" refers to a prototype i.e sketchy and incomplete. You basically collect data analyze & check the feasibility at the early stage.

Whereas "high fidelity prototype" refers to a fully functional prototype wherein you provide click-through interfaces. In simple terms, it's the actual product that will be shipped.

You should always start with a low fidelity prototype because this is a point wherein you collect data analyze and check its feasibility. You resolve all the issues at the early stage. Easy to carry out iterations.

For reference:

• High-Fidelity & Low-Fidelity Prototyping: What, When and How?

• Prototyping 101: The Difference between Low-Fidelity and High-Fidelity Prototypes and When to Use Each

Hope this solves the problem. Let me know if you have any doubts.

Answer 2

It's also helpful to consider what kind of fidelity you're referring to so that you don't get into the wrong kind of mixed fidelity.

"High fidelity" often mistakenly refers to only the graphic design aspect, i.e. static screens and screen states that look more or less production-realistic and not obvious mock ups. The problem is that when evaluating interaction design, graphic fidelity really only considers visual design.

Interactive fidelity considers the interactive action-response narrative of users interacting with the design. You can accomplish this with a flow chart, a wire flow (screens with arrows and annotations,) or with true support for actual interactive evaluation via prototyping tools. The closer you get to the actual working software, the higher the interactive fidelity. (That's why some companies actually design and prototype using branches of production code.)

I've seen all kinds of approaches employed, but in my experience mixing high graphic fidelity with low interactive fidelity results in the most churn. It puts emphasis on the static screen design details, which are valid to consider but lack the interactive cause-and-effect state change context to be considered properly.

That's aside from the fact that static screen designs that look too "perfect" tend to inhibit blunt feedback from people you show them to (acquiescence bias, anyone?)

There's also the aesthetic-usability effect which can muddy the waters further when trying to evaluate an interaction design properly.

Focus not just on high- vs low- but on employing the right kind of fidelity.

Answer 3

In addition to low-fidelity mockups being quicker to create and modify than hi-fi, they help you focus the discussion on functionality and navigation rather than colors, fonts, layout, etc. You generally want to get sign-off on the Interaction Design before discussing Visual Design.

Answer 4

Low fidelity prototypes are often wireframes that are stitched together. These are easier and faster to build which allow you to receive feedback earlier. And they allow for faster iteration (changes).

High fidelity prototypes are more detailed. When made into a clickable prototype, an outsider might not even notice it's not a real product. The downside to these prototypes is that they take time to create and to change if necessary.

Use low fidelity prototypes in the early stages when you want to test hierarchical stuff like navigation and the positioning of elements.

Use high fidelity prototypes in later stages, when most design decisions have already been made.

Don't confuse low fidelity prototypes with wireframes. Prototype suggests you made a clickable demo with programs like InVision or Marvel, or you created a paper protoype.
Wireframes, however, are the loose screens of which the prototype exists. The ones you discuss with your team or Product Manager.

Answer 5

From a software guy's perspective ...

The difference is the question each answers

In appearance and format, the "fidelity" of a prototype is relative to the team producing it. I've worked with teams that can produce a hi-fi prototype in about the same time another team needs to produce low-fi. The key differentiating factor is what each is intended to do.

Low-fi

This stage is about discovering as quickly as possible if you are solving the right problems in the right way.

Are the workflows effective and efficient?
Do users have access to the features needed to complete their job?
Is there anything you can add or remove to make your users more successful?
Did users struggle to understand or discover a feature?

Hi-fi

This stage is focused on getting as close to the real thing as possible without investing the time needed to build out the full architecture and make a definite commitment to the technology.

Does everything you learned in the lo-fi still hold true?
Do users respond well to the visual solution?
Is the visual hierarchy of elements clear?
Are all the finer points of the application accounted for?
Can Engineering begin building efficiently based on this prototype?

The process is not linear

Some teams misunderstand the process as a linear progression. Even with a fairly simple product, this is rarely the case.

Prototypes are more successful when focused on a single or small set of problems.

You'll build a lo-fi that tests well …
Progress to hi-fi and find some issues …
Step back and test a sub-set in low-fi …
Reintegrate with the hi-fi again …

Then you'll repeat that whole process for another workflow or feature set.

This cyclical process is where the hi-fi shines. To minimize distractions (either for users or the team) you don't always want to test your new idea in the context of the full app. However, before you fully develop that hot new thing you'll want to make sure that it integrates well within the broader system. In this way, you can think of the hi-fi proto as an "integration test", for the devs in the audience.