Wireframes have always been an important part of the work I've done inside any team. Recently, our team at Tenable had the opportunity to change some of the process 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.
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:
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 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 whiteboard sketching to get design and engineering on the same page. You can see some examples of the sessions we did here.
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 often involve a lot of work so the decision to build them should carefully be weighed. One of most compelling reasons to build a clickable prototype is usability testing. At Tenable Axure has been our primary tool for building clickable prototypes. It's enabled us to build hyper realistic prototypes engineers and stakeholders can refer to when building new or improving existing features. Framer and UXPin are other solid tools to use when building clickable prototypes. If versioning and team collaboration is important you should take a look at UXPin. If mobile is primarily where your team will design and build the product you should take a look at Framer. If your team works tightly with front end engineers HTML prototypes could be the best option.
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 more then other project document will be the most read document. Using short annotations and go a long way in helping teams understand things like behaviors and user scenarios. Pay attention to your length of 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 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 you're team is remote posting wireframes for the team to review can be a paint 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.
A multidisciplinary designer based in Nashville who is passionate about solving hard problems with human centered design. Read more.