Let’s be honest. One of the most difficult parts of any design project is having the right information available when making decisions about what to do. We’ve seen a lot of teams make the mistake of using a wireframe to discuss visual design choices, and teams spending crazy amounts of time updating high-fidelity prototypes when the workflow changes.
Keeping assets in the correct fidelity can help keep the conversation focused on the right things. Introducing a polished UI into a page structure discussion will derail the decision. Not having enough fidelity will make it hard to decide on subtle interactions.
This article should help you understand when to use sketches, wireframes, and prototypes, and how to manage the entire process so that you’re discussing the right things at the right times to make the best product design decisions.
What’s the difference between a sketch, a wireframe, and a prototype?
There can be some confusion around what sketches, wireframes, and prototypes are. What one person calls a wireframe might be what someone else calls a prototype. We have pretty strong opinions about this, and for good reason. When we all agree on what we call things we can focus on the decisions those things are intended to help us make.
What is a sketch?
Sketching usually happens on a whiteboard, plain printer paper, or a notebook. They are simple hand-drawn outlines of a screen and what will be on it. Sketches are intended to get a rough idea of the various views or screens the application will need and how things will be arranged on those views. The idea is to move fast and uncover as many issues as possible before moving into a digital tool.
What is a wireframe?
Wireframes are essentially a tool to formalize the sketches and make high-level decisions about how an application should function. We take what was agreed to in the sketch phase to create each screen showing the basic size and layout of the parts of the website or application.
This is when we would discuss details about the information and content that should be on the screen, where it should be, and start mapping out interactions. Adding interactions is what transforms a wireframe into a prototype.
What is a prototype?
Prototyping is when things begin to take real shape and feel like a functional application.
Start with a low-fidelity prototype, which is basically adding more detail about content and functionality, and some interactions to the wireframes. At this point you want to link wireframes for the parts of your application together so you can get a feel for moving between screens and how things will respond. It’s best to stay in black and white at this phase so you can stay focused on functionality and the usefulness of the content.
At this point most projects are ready to begin development. There is enough detail to show a developer what needs to happen and how things should work.
A high-fidelity prototype is essential for complex applications or established development teams. It will outline every detail of the interface including colors, font styles and sizes, placement of each element with pixel precision, and describe all the interactions that should happen.
Some prototypes are actually built as live websites so you can get sense of what it’s like to use before a developer has written a single line of code.
What kind of decisions should you make with wireframes vs prototypes?
Wireframes are good for:
- High-level decisions on major steps in the process
- What information and affordances should be on screen at each step
- High-level decisions on structure and hierarchy
Prototypes are good for:
- Same-page interactions
- More granular content structure and hierarchy conversations
- Clicking through a process to make sure the right information and functionality will be available to the user at the right time
But the C-Suite wants to see what the finished product will look like!
This is why a Design System is essential. Design systems allow you to have a conversation about the cosmetics of the app or website in parallel with your conversations about the functionality.
Form follows function
Louis Sullivan
Once you have a solid idea of what should be on each screen, you can overlay the design system components to give you and any executive team members a clear idea of what things will look like.
Here’s an activity to help an executive visualize the product:
- Set a meeting with the executive.
- Print out two sets of each design system component.
- Cut them out individually with scissors.
- Print out a mobile, tablet, and desktop device frame (Sketchize is a great option).
- Bring the print-outs to the meeting.
- Ask the executive to freely move the components around on the device frame.
This lets them quickly visualize where everything goes, while also engaging them in the design process. Expect to hear things like “this isn’t as easy as I thought” and “I’m not sure what to do.” This is very productive because it demonstrates your value and also helps the executive to think more deeply about the product design process.
If you’re both working remotely, there are a few additional steps:
- In the meeting description, explain that you’ll be working through a design exercise.
- You will lay out all of the design system components and ask the executive where things will go.
- Explain that this will speed up the product design process.
- Before the meeting starts, set up your camera to point down at a table with the print-outs visible.
- Do a dry run beforehand with a colleague to ensure everything works.
- When the meeting with the executive starts, communicate the goal of visualizing the product so you both have an understanding of the different components, where they should go, and what to cut.
Managing expectations
In almost every project, an executive stakeholder will want to see something in high-fidelity so they can get a clearer idea of what the end-result will look like. While it seems like a completely normal request, this can be dangerous.
Everyone on the team, especially executives, need to know the risks of derailing decisions by looking at the wrong level of fidelity for the decision being made. Wireframes and low-fidelity prototypes should be used for deciding about element size and placement. High-fidelity prototypes are great for discussing visual refinements, but not for more foundational decisions.
Creating a static image mockup of the UI screens (commonly referred to as a “UI Comp”) is the best option to get a visual idea of what the finished product will look like. But what about when comps aren’t enough for executives to get the clarity and confidence they need?
The best thing is for the entire team to embrace the entropy. Recognize there is a certain amount of change in every project. Expect it, plan for it, manage it.
How to handle this depends on the team’s timeline, budget, and tolerance for risk. Sometimes, when there’s enough time and budget, it’s okay to build a high-fidelity prototype early on to get buy in from key stakeholders. However, the stakeholders need to know that this high-fidelity prototype is likely to be wrong in some areas and should not be considered a template or specification for the final product.
We advise sharing the timeframes for both options and discussing which decisions need to be made and which level of fidelity is the best for making that decision. For example, the low-fidelity option will take one day to design and the high-fidelity option will take three days to design. Once leadership understands how long things will take, they usually select the faster option. With leadership’s approval for low-fidelity, this frees the team up to move faster while still working within the agreement everyone reached together.
Conclusion
Don’t beat yourself up. It’s very common for teams to struggle with when to use different types of assets and how to make the most of them.
To recap, make sure you match the fidelity of the work to the type of decision you’re trying to make. Download our cheatsheet and keep it handy as you work and help your team move faster with more clarity and confidence.
