Wireframes come in different levels of detail or fidelities. Low-fidelity wireframes capture the interface layout and controls but don’t resemble the finished product very much, whereas high-fidelity wireframes look closer to the final product because they display the interface in greater detail.
This article discusses the levels of detail we have used when wireframing on our projects. I’ve used Balsamiq on these projects for the lower fidelity work whilst our in-house designer uses Sketch to produce high fidelity wireframes.
Low-fidelity wireframes - Quick, informal, and disposable
Low fidelity wireframes are very quick to produce and are usually simple black-and-white sketches of a screen layout. These identify the block elements required and where they will sit on the page. A lo-fi design concentrates on what needs to be on the page rather than how it actually looks - there is no visual design here.
Advantages of a lo-fi designs are:
- They identify the critical elements you need with minimal effort
- They stimulate conversations amongst the project team
- Major problems can be detected and fixed early
- They are easily discarded, this allows you to iterate more willingly in order to achieve the best result
- The tools used to generate them generally don’t require specialized skillsets to use them effectively
Disadvantages to consider include:
- They can look too primitive or abstract and the customer can’t visualise how the end product will look
- Using block elements runs a risk that your real content won’t fit in the blocks you’re designing
High-fidelity wireframes - Detailed visual design
High fidelity wireframes look a lot more like the finished product (although they are not necessarily pixel-perfect representations). These wireframes will generally involve colour and visual design. Gone a block elements, replaced with realistic content and UI elements. They show a lot more detail than a lo-fi wireframe and leave a lot less to the imagination. They include a level of detail that makes the form and function of the interface more apparent and make it easier to communicate details to the development team.
Advantages of hi-fi designs include:
- They require less customer imagination, it’s easier to visualise the final product
- They communicate form and function better than a block-level lo-fi wireframe
- The higher level of detail can persuade stakeholders as these are likely to be more impressive and better demonstrate the quality of your work
Disadvantages to consider include:
- In the initial design stages, they can distract stakeholders with too much low-level detail
- There can be a higher resistance to discarding them as there is a perception of more effort involved to create - this can stifle the design process
“Just good enough” fidelity
This is a somewhat subjective middle ground that falls between lo-fi and hi-fi. In an Agile project, the right level of detail for documentation is generally regarded as “just good enough” to convey sufficient information to the development team to achieve a successful result - working software. Similarly, this mindset can be used when wireframing. Wireframes that are “just good enough” can work well because it brings enough detail to the design process but it can often be done with a simpler tools (and hence by key stakeholders). The level of detail is also good enough for your designer to produce the very detailed pixel-perfect final proofs of the kjey design elements.
A design with just enough fidelity should still be relatively quick to produce and edit - it still needs to be something you can discard without emotional attachment, especially if you are doing a considerable amount of your design work at this level of fidelity. I think it’s also part of the overall design portfolio but in general you are going to end up with lo-fi and hi-fi wireframes as well (although the lo-fi designs may get discarded especially where they are refined up to “just good enough” levels).
So, how much detail?
It depends and it varies. In my experience, all of the above have a place and will to some extent or another be included in any design process. The lo-fi designs (right down to pencil-and-paper and whiteboards) are useful right at the start, and often a high fidelity collection is useful when presenting proposals to key stakeholders, who are more likely to be influenced by work that looks polished and lets them see what the finished product will feel like.
My usual approach is to start out with a fairly low-fidelity design that is quick to produce and concentrates on what will be on the page and how the user will interact with it. Often these designs are simple black-and-white sketches (and I’ll often draw them in pencil first). The aim of these lo-fi designs is to be able to initiate the conversations with the customer so that you concentrate on what is important early in the design process - the basic form and function without being encumbered with additional detail that does not have a bearing on what the page is expected to do.
Once the basic layout is established, I’ll generally identify key pages and move up to “just good enough” wireframes (mockups). The result is a mockup that has the basic look-and-feel of the proposed webpage, including approximate colours and block elements replaced with more realistic content. Generally this level of mockup is sufficient for a full design review and high-level design sign-off.
Finally a small collection of designs are often chosen for high-fidelity rendering. This work can be used for stakeholder approvals of the final look-and-feel. We frequently use Sketch for this level of detail which gives us presentation-quality designs and we’ve found that no higher level of detail is required as pixel-perfect designs can be developed using Sketch. In my experience you only need to identify a few selected designs for hi-fi rendering if most of your work has been at the “just good enough” level as generally you won’t need hi-fi renderings of every design.
For the sorts of projects I’ve worked on, which have tended towards functional and transactional processes, the “just good enough” fidelity level has been where most of the effort has been expended. This is especially so of transactional websites or apps where common controls for data capture are being used as the controls themselves can be templated once as a control library and you really don’t need pixel-perfect wireframes of every single page to convey application form and function.
A quick example
Here’s an example from a recent project we did for NZ Thoroughbred Racing. A few lo-fi designs were completed (often pencil drawings) before the main collection of “just good enough” designs were completed which were sufficient for the customer to sign off on the designs and for the development team to build the resulting pages. Some high fidelity renderings were also included, for example to differentiate how a given page would appear in the iOS and Android versions of the resulting smartphone apps.
On the left we have the “just good enough” wireframe which shows the proposed page layout and design elements. On the right is a snapshot from the finished website/mobile app.
We found that the “just good enough” level of detail was “just right” to conduct robust design discussions with the customer, perform meaningful iteration, and deliver a living design portfolio that could then be signed off (often with amendments as annotations rather than modifying the wireframe) for our development team to be able to produce the resulting application.
In the third and final part of this series, I’ll talk about what happens next once you’ve got your wireframes ready for development.
