Tips for Creating Great Wireframes

In this post, I want to discuss some concrete ideas about how a wireframe should be built in order for it to be useful. At the end, I’ll also link to some further reading and resources.

First of all, I’ve created a fun little example wireframe for your perusal. To download it, click here. I’ll be discussing its various features in this post. For this example, I chose to pretend we were working on a photo sharing/organizing service along the lines of Flickr, Picasa Web Albums, or Photobucket. The application contained in this wireframe is very simplified (because to build a robust one would have taken many days instead of a couple of hours) but I’ve gone far enough to give a good idea of techniques I use and some best practices.

Practices for Creating Useful Wireframes

1. Give your wireframe some context by displaying it within the browser or device you are creating for.

I have found it helpful to build wireframes within background graphics which denote context, such as a browser window, an iPad bezel, or a phone handset. (In this example, I’ve used a Safari window.) I think this is a good way to do it for several reasons. As a designer, having a context helps me to think about how an application will work and look within its platform. It is easier to envision the proportions of objects and figure out how a layout will work in a given screen resolution when there’s external information (such as a handset’s button or a browser’s address bar) to compare it against. Furthermore, when I am showing the wireframes to a client, having the context of a browser, iPad, or phone helps them to envision the application more easily than if I just showed them some content in a square on a page. People often are very excited to see their sketches and ideas laid out in a window so it really begins to look like something.

2. Annotate like crazy.

Links, dropdowns, buttons, and other functionality should be explained and called out. As I place an element on a page, I think about what it is, why it’s there, and immediately create a note of explanation if it’s necessary. If appropriate, you can reference other wireframes within your document (for example, “See wireframe #2.” — This is why I always number my wireframes). The goal is to avoid clients, developers, or designers asking somewhere down the line, “What did this thingie do again??” For a particularly complex application, it might make sense to color-code or otherwise differentiate between different types of notes.

3. Use greyscale or monochrome.

This cuts down on visual noise and makes sure the focus is on the functionality of the application, which is where it should be at this stage. The wireframe should look nice, and be well-organized, but it should be clear from looking at it that this is merely a blueprint, not a full-fledged design. Keeping page elements in greyscale also makes it easier to annotate your wireframes, because you can use color to emphasize various annotations.

4. For complicated workflows, show what you mean, don’t tell.

One big reason we build wireframes and keep them around is because they help us remember the decisions we made when it comes to complicated workflows and multi-step processes. In order for a wireframe to be useful in this regard, it is important to be as specific as possible and flesh out every detail of the process, including intermediate states. Adhering to a high level of specificity is helpful in other ways, too. It creates or confirms a consensus between designers, developers, and clients, and it also requires us to think through every step in the process, minimizing oversights.

5. Give each wireframe a number, and each page a title.

This makes it easy to reference the wireframes in discussion with team members and clients, especially if communication takes place over e-mail or a conference call. Also make sure you include a date, and maybe even a version number, so that it is easy to keep track of your wireframes if changes are made later in the process.

6. Use believable dummy data wherever possible.

For example, on my sample wireframe #4, I included landscape images and spoofed digital camera filenames as my dummy data. Again, this is a practice that will help designers, developers, and clients imagine how the application will act in real life. Sometimes you can achieve this effect with some educated guessing and make up data based on your knowledge of the client’s product. Other times, the client may be able to provide artifacts that will be helpful to include. There may be times when using “lorem ipsum” dummy copy is unavoidable. But when information is available, you should go the extra mile and use it.

Further Resources

  • Wireframes Magazine is the place to go for in-depth information on a variety of different aspects of wireframing and UI sketching.
  • Omnigraffle is what we generally use for making wireframes here at Atomic Object.
  • Graffletopia is a great source for UI elements and has stencils for a variety of different device bezels.