Wireframing is not Prototyping

With the rise of UX role in the industry, wireframes have played increasingly leading role in the modern world. Its a simple way to validating user interface and layout and are cheaper and faster to produce than a final visual comp.

Over the last couple of years, the number of wire framing tools that have come up in the market is alarming. From a world of Visio, Omnigraffle and to a certain extent Rational Rose in the past, today you have options for any platform. You could do a google search today and you would be surprised to see the number of tools available today and with links to tell you the top 5, 10 & 20 tools for wireframing. With more options today, we run into more complexity.

Paper & Pencil have been probably the cheaper and faster way of evaluating the interface and layout, however I see very little of those today.

Today, there are applications that allow you to create wireframes that look hand drawn.

The last few years the wireframes have looked more and more different and detailed. Images, actual look and feel, every single mouse movement or tap or gesture and what happens next, etc. That definitely throws cheaper and faster out of the window.

Lets look at a classic definition of wireframe

wire·frame
ˈwīrˌfrām/

noun: wireframe; plural noun: wireframes; noun: wire-frame; plural noun: wire-frames
1. a skeletal three-dimensional model in which only lines and vertices are represented.

Exactly, a wireframe is a three-dimensional illustration of a page’s interface that specifically focuses on space allocation, prioritization of content, functionalities available, and intended behaviors. For these reasons, wireframes typically DO NOT include any styling, color, or graphics.

However, with the next generation of devices already here, and with users employing more touch-based system, a few changes should be made in the way we do classic wireframes. In spite of these progressions, though, creating wireframes should remain cheaper & faster.

Today we have taken to wire-framing to actually deliver a full blown spec. Do you think a developer is going to make sense of a step-by-step wireframe that captures every single gesture? (most of the developers/QA know what happens when you click a drop down or on tapping the button it turns blue from grey). These are not High-Fidelity wireframes (if that is your arguing point) but a spoon feeding document which runs into 100’s of pages.

A High-fidelity wireframe has increased level of details which should simply point out details like dimensions, behavior and/or actions related to any interactive element.

There have been some rules that designers need to consider while creating wireframe. Lets see how or what we can change so that wireframes are better suited for today’s interaction. It’s important to keep in mind to use wireframes as guides and not deliver a spec.

Some old school rules:

Do not use colors — If you want feedback on your functionality, do not use colors, however always use a different color to show highlights or selection. Stakeholders always get confused when they don’t see a selection color; in other cases avoid colors.

Do not use images — Images distract from the task at hand. Do not use an image unless it is part of your navigation and you cannot show any interaction with that image. Else just show a placeholder.

Typography — Use one font, but vary their sizes to differentiate.

Keep them short and to the point — Don’t spoon feed. Use annotations and try to capture your use cases.

One of the things old school wireframes always said was to show what things go where irrespective of shape and size since it was important to give the users an idea as to what content goes where. Later on it became important to do wireframes that would show details of content before the web page fold.

Today, users use more touch devices compared to desktops/laptops. Screen sizes have become more important and users don’t have to worry about the web page fold anymore. Every single pixel has become important. Thus making it even more important to deliver pixel perfect wirefames.

One of the biggest down side of delivering wireframes as a spec is that at times you do not know from where to start. Should I do the dashboard now? Oh but making an appointment is more important then looking at summary. At the end, you are scampering to get things done, with 100’s of wireframe slides and still no starting point.

A good technique that I have relied in the past is to write down high-level scenarios for your personas that you create. Once you have these written down; prioritize them — there you have your starting point.

Now take a single scenario and try to come up with uses cases, or business rules whatever you are comfortable with. Start with a single positive use case, document all the business rules. Do your wireframe, as minimal as possible and annotate them if required.

Create a summary page at the end of this, and capture all the negative use cases and error cases. Typically you wouldn’t need wireframes to show these unless you need a different interaction all together.

Keep your wireframes short, simple and annotated and remember to keep them cheaper and faster.