Knowledge Base Articles > How to Start a Wireframe
A blank canvas. Full of potential, devoid of content.
You want the end result, a wireframe that takes the idea in your head and makes it real. And you know that at a certain point you'll get into "the zone" where the friction disappears and designing feels almost effortless.
But now it's still a blank page.
So, how do you go from nothing to something?
Here are a few tried-and-true techniques with real examples that we use to kick start our wireframing.
If you're having troubling imagining what it should look like, it probably means that you haven't answered some important questions. Instead of diving straight into the user interface, we often start by answering some basic questions that apply to any project. This is sometimes called a Brief.
In our Live Wireframing with Balsamiq sessions, we often ask these three questions before doing anything else:
Note: If you have a hard time answering these questions, you're probably not ready to start wireframing. In this case, we suggest that you go back to the gathering requirements phase.
Even if you are wireframing alone, it's useful to go through the step of explicitly writing down this information about your project. It will help you get back on track when you get stuck and will be a huge help to anyone looking at your wireframes later.
Here's an example from one of our sessions showing the actors and workflows, plus a rough workflow visualization.
Let's take a look at how this first wireframe developed in Peldi's wireframing session with Food for Change.
Designing with someone else forces you to make things explicit, but you can do the same on your own by "interviewing" yourself. Follow the same process as the video above, but ask yourself the questions.
Also, as shown in the video, feel free to jot down other relevant details, such as technical requirements, optional workflows, and unknowns.
In some cases the structure of the site clearly emerges from the process of writing things down. Or maybe you are modifying an existing site and there are some things that you already know are going to stay the same.
When this happens, it's ok to jump into a middle ground between words and visuals by creating a site map or flow diagram. This is a common effect of content-first design. The goal, though, is just to visualize how parts of the site or app are connected for your own clarity. It won't necessarily be reflected in the user interface.
In designing Bellies Abroad, Peldi and Kiersten write some notes about the project and then jump into a site map, which ends up like this:
Here's the full video:
Here's another example where Mike creates a site map and a user flow diagram before starting UI design work.
Watch the video here:
These examples make it clear that designing the interface becomes much easier when you visualize connections and how screens relate to each other.
Most design work in practice involves adding on to or improving an existing product. In that case, it's ok to start by wireframing what you already have.
It may seem like a waste of time to wireframe something that already exists, but what this does is open the design up to iteration in a way that using the real design in its implemented form won't. As we say, wireframes provide a look that nobody is afraid to criticize.
When designing billing features for Balsamiq Cloud, Peldi and Liz took a hybrid approach, combining wireframes with screenshots of the existing UI, like this:
Here's the whole process:
Another technique is to recreate the existing design from scratch and start from there. See how Peldi does this for the Fanfarenzug Academy redesign.
There's no shame in copying from what works. Copying is a great way to learn. For new projects in particular, it can be useful to think about how other apps or sites have addressed similar problems or use cases and start there. Most of the time you'll find that what you end up designing naturally deviates from the starting design enough that you don't feel like you're ripping it off (if it doesn't, you should probably reconsider what you're building).
We find that people often have a design in mind from a similar product and it's perfectly fine to start with that. Here are some examples.
This video shows the collaborative design of the version history feature for Balsamiq Cloud, which brings in Google Drive and Dropbox for reference. It just makes sense given how invested those companies are in the feature.
Here's the final design wireframe next to the Dropbox version history screen:
Here's the full video, which uses the other sites for inspiration very early on:
The most common mistake people make with wireframes is rushing through them. Too often they are treated as a checklist item in the design process workflow, resulting in a quick visualization of what the feature "should" look like based on customer feedback, for example. Then that design is rushed through to a high-fidelity comp, which becomes the blueprint for implementation by developers.
What happens next is usually negative customer feedback because the design doesn't actually solve a real problem for most users (or perhaps introduces new problems). This leads to weeks or months of development effort to make it better, which could have been prevented with a more intentional wireframing effort.
This frequent error can be traced back to not spending enough time in the ideation phase. The ideation space, where wireframing delivers the most ROI, is the best time for experimentation and divergent thinking. It's where user goals and workflows are synthesized into a plan for moving from the problem space to the solution space, and it shouldn't be perfunctory.
So, start your wireframes the right way by taking the time to reflect on and record who you're designing for, what their goals are, and how they can best accomplish those goals using your tool. It's mostly downhill from there.