Thoughts on Wireframing

Wireframes have always been an important part of the work I've done on any team. Recently, our team at Tenable had the opportunity to change some of the processes within our team so I was compelled to pen some thoughts on how I define wireframes and to also document some practical tips on building them.

What Is a Wireframe?

Wireframes have often meant different things to different people. The best comparison I can make within product design has been architecture. Wireframes, in particular, have always reminded me of architect's blueprints. In product design wireframes serve as a draft visual representation of what the user interface could eventually look like. But more importantly then defining what a wireframe is, we should think about what kind of questions a wireframe answers. So I believe a wireframe should answer 4 questions:

  1. How will the product work and how will people interact with it?
  2. What is the structure of the navigation and information architecture?
  3. What is the layout and hierarchy? Where will the elements be placed?
  4. What will the content look like and will it be placed on screen?

Through the various teams I've worked on in the past there has been a constant and steady debate about the various types of wireframes and which one should be built at which stage. I believe it's important for teams to categorize what the different types of wireframes are and when they should be used. I have always grouped wireframes into 3 categories:

Hand Drawn Sketches

Hand drawn sketches are always a great way to start any project. Sketching is a great way to flesh out ideas on your own or with your team. They have the advantage of being fast to easy to create and you can quickly iterate on them. Sketches are also great when you have to collaborate with outside stakeholders who may not have the time or skill to invest in higher fidelity wireframes. At OpenPeak we primarily used board sketching to get design and engineering on the same page. You can see some examples of the sessions we did here.

Traditional Wireframes

Traditional wireframes are really useful when explaining your product and what you're building. Flat wireframes can be highly designed or just be rough impressions of what the final interface will look like. In the past, I've often been asked what I think the best wireframing tools are. Really, tools shouldn't matter as long as the end result meets the need. But in my own personal experience Omnigraffle, Balsamiq, Illustrator or Sketch have worked really well. I'd feel confident recommending them to any team or individual designer. In the end, you'll most likely choose the tool dependent on different factors like size, team location, and scope of the project.

Clickable Prototypes

Ultimately your wireframe should convey just the right amount of detail and not more. So here are a few practical tips I've found handy when building my own wireframes.


Annotate your wireframes. People are visual creatures so wireframes will be the document they read the most. Using short annotations and go a long way in helping teams understand things like behaviors and user scenarios. Pay attention to your length of the text. It's easy to go overboard. Long and verbose annotations can be tedious to read and can cause team members to tune out.


Use grids to build structure, simplicity, and consistency into your wireframes. This will help set the course for the final layout and help engineers think through the various views needed to build the project.


Speed and simplicity should be key to wireframing. In the end, your team might throw out your wireframes so in most cases they may not need to be highly polished or pixel perfect.


Soliciting feedback early in your wireframing process can be one of the best ways of generating great results. If you're working in an office with a team pinning wireframes on a common wall or in your office can be a strong signal to the rest of the team that feedback is welcome and encouraged. You would be surprised at what kind of constructive conversations are generated from just having something for people to look at. If your team is remote posting wireframes for the team to review can be a pain point in the process. Thankfully more companies and ideas are spinning up to meet this need. At Tenable we've experimented with Mural and are constantly looking at other options.

Writing this has been a good exercise for me to think through some thoughts I've had about wireframes for years but never attempted to document. Hopefully, some of these thoughts can provide some value to your process.

Jun 19, 2017