Wireframes are great for forcing us to think through how the UI will respond to user input—and capturing all of that information!
If you read our last installment in the UX Crash Course series, then you’re all caught up on how storyboarding can help pin down the high-level goals of a new idea—and why that’s the perfect place to start with the feature or product development process.
But what we didn’t discuss is what happens next in that UX → development process. When you’ve got an idea nailed down (and a storyboard to help communicate that idea to everyone you’re working with), then what’s the next thing you need to do to start turning that idea into an actual, interactive piece of software? The answer to that question is—you guessed it—wireframing.
If you’re a developer, you’ve almost certainly seen a wireframe before. Maybe someone showed you one during the design process to get your feedback on it—or maybe it was the deliverable you got handed, as a reference for building the website or application.
Wireframes can look very different, depending on their fidelity level, or how “finished” and detailed they are. Wireframes are generally categorized as low, medium or high fidelity; a designer may choose to make multiple wireframes of different fidelities as the design and concept evolves, or they may just make one and move forward. Each fidelity type serves a slightly different purpose, but they all still take time and effort to make. You may find that one medium-fidelity wireframe is enough for a small feature, but a full page design may move through several fidelities of wireframing as it’s tested, reviewed and iterated upon. Wireframe fidelity is often chosen on a project-by-project basis, depending on the needs and goals of the designer.
Image from https://decode.agency/article/low-fidelity-vs-high-fidelity-wireframes/
Wireframing is also the stage where we start to really think about the in-between stages in the design. What happens when someone clicks on that button? How does this appear on the screen? Are there animations or transitions involved? Good wireframes will also include notes and annotations, to capture as much of this information as possible.
Low-fidelity wireframes are very loose and sketchy, and don’t bother to define specific measurement units (such as pixels) or get every word in the copy just right. These are more about hashing out an idea and nailing down the core elements: the function of the feature/page, the general layout, the major headings and the high-level user flow. They can be done on paper or on the computer.
Low-fidelity wireframes are made at the very beginning of the design process. Because we know that, at this point, there will still be lots of changes and iterations coming, it’s not wise to invest lots of time and energy in highly detailed wireframes. You could spend hours picking fonts, setting colors, aligning everything to a grid … and then get feedback that it’s not the right direction and have to throw it all out. What a waste!
Medium-fidelity wireframes are the most commonly used because they strike the perfect balance between being finished enough to show clients/stakeholders while still keeping things simple enough to make that they don’t require a ton of time to make.
This is usually where folks make the jump over to the computer, although you can do this equally effectively on paper if you have a steady hand. Medium-fidelity wireframes will look cleaner and more polished than low-fidelity—no more sketchy lines or placeholder fonts. However, you’ll still want to keep things pretty high level here and avoid getting sucked into those very tiny details we talked about earlier: things like colors, images or body copy, for example. Think about finalizing the layout, structure and landmark elements.
If you choose to move to the computer at this point, you’ll find that most current design software offers wireframing toolkits, full of common shapes (cards, modals, menus and more), as well as icons for you to make use of. This can really speed up the process (especially if you’re limited by your current drawing capability), so definitely take advantage of it.
Sometimes referred to as “mockups,” high-fidelity wireframes are where we finally do get to those itty-bitty details. A high-fidelity wireframe often looks basically indistinguishable from a screen shot. As you might imagine, these take a lot of time to make—which is why we don’t want to start at this fidelity level.
So, what does justify this kind of time investment? Why make a high-fidelity wireframe at all, when a medium-fidelity communicates 80% of the same information? Two of the most common examples are 1) user testing or 2) getting client/stakeholder approval in high-budget or high-risk situations. When we put a high-fidelity wireframe in front of a user, we can get a lot of the same feedback we might get during usability testing—before the product actually exists! And if you’re working on a project that crucially important or extremely high-budget, nervous stakeholders might prefer to see a highly detailed view before approving the move to development.
Wireframes are great for forcing us to think through how the UI will respond to user input—and capturing all of that information! It’s important to be as thorough as possible because this when the design starts to be touched by people other than yourself—people who don’t know what’s going on in your head or what assumptions you’ve made about how things will work. Think of wireframing like writing documentation or commenting your code; everyone who looks at your wireframes needs to have a complete understanding of how your design works, even if you’re not there to explain it to them. By the end of the wireframing stage, your work should be able to stand on its own and effectively communicate your solution.
What makes a site especially usable (or especially difficult to use)? Try using Jakob Nielsen’s 10 Usability Heuristics as a basis for internal review—you might be surprised how much you’re able to improve the product before it’s ever touched by a user!
Kathryn Grayson Nanz is a developer advocate at Progress with a passion for React, UI and design and sharing with the community. She started her career as a graphic designer and was told by her Creative Director to never let anyone find out she could code because she’d be stuck doing it forever. She ignored his warning and has never been happier. You can find her writing, blogging, streaming and tweeting about React, design, UI and more. You can find her at @kathryngrayson on Twitter.
Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.
Learn MoreSubscribe to get all the news, info and tutorials you need to build better business apps and sites