Four techniques to start a wireframe project from scratch and ensure that you dedicate enough time to the ideation phase, where the success of your product begins.

The most common mistake people make with wireframes is rushing through them. Spending time in the ideation phase is where wireframing delivers the most ROI. It's where user goals and workflows are synthesized into a plan for moving from the problem space to the solution space.

An empty wireframe can be intimidating. 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 methods with real examples that we use to kick-start our wireframing.

Four techniques for starting a wireframe

1. Start with words instead of pictures
2. Create a site map
3. Use the existing design
4. Find inspiration elsewhere

1. Start with words instead of pictures

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 3 questions before doing anything else:

Questions to ask before wireframing

1. Who will be using it? (i.e., the actors)
2. What is their goal? What problem does this product or feature solve for them?
3. What are some of the actions or operations they are likely to perform? (i.e., the workflows)

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.

2. Create a site map

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:

For another example, watch Mike as he 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.

3. Use the existing design

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.

4. Find inspiration elsewhere

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 Bellies Abroad and Hope for the Caribbean wireframing sessions also start by using other websites for inspiration.

Conclusion

Too often wireframes are treated as a checklist item in the design process, resulting in a quick visualization of what a 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 by taking a more intentional approach to wireframing.

Including time for experimentation and divergent thinking shouldn't be perfunctory. Start your wireframes the right way by making 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.

Webinar: How to ideate like a designer

Watch the recording of our webinar about ideating like a designer.