The Value of Wireframing

Wireframing is often the first step in transforming the idea for a website into reality. Before a developer can write the code that will determine the mechanics of how the website will work, a designer has to provide detailed style guides and mockups of what the website should look like. Before a designer can plan the specifics of exactly what various interface elements will look like and where they’ll be placed on a screen, a user experience expert has to decide what arrangement and combination of elements will allow a site user to be successful in completing a task. Before a user experience expert begins their contribution to the project, the team that first conceived the idea for the website has to be able to wrestle their imagined website into a physical reality that others can see. This is where the wireframe comes in; it’s the first crack at making the big decisions that will make a website work. Since a wireframe is rapidly drawn with a pen or quickly rendered with prototyping software such as Balsamiq, many iterations can be tried with little penalty in lost time. In fact, the more iterations created, the better the chance that a winning design will be selected.

Wireframing progression: ideation sketch (left), to low-fidelity mockup (center), to high-fidelity mockup. Sadly, this website does not exist and was only prepared by me as an exercise.

A Quick Case Study

I’ll illustrate with an example from a project that I recently worked on in which I was asked to overhaul a website used by company employees to manage their training requirements. The site was intended to help employees determine if their required training was up-to-date, and if not, guide them to the appropriate links that would allow them to either enroll for classroom training or allow them to complete required training modules online. The biggest problem was that the training website was designed by subject matter experts who understood the ins and outs of the employee training work flow. The site was littered with acronyms and insider jargon and made no accommodation for the casual user (which described the vast majority of the site’s audience). No one outside of the training department could use it—at least not without struggle and frustration.

After defining the discrete objectives proposed to make the employee user experience better and increase the likelihood that staff would successfully complete the top tasks we identified, it was time to start building the online interface that would support those top tasks. My customer in this case was the Human Resources Department. They had no experience in web design and had a hard time imagining how we could move from the site we had to the future state we wanted. The first step in getting buy-in was to show a physical plan that could be seen rather than imagined. I produced what Dan M. Brown calls a “page description diagram” using what Jason Santa Maria describes as the “grey box method.” That is, a wireframe containing four large, shaded boxes with labels. The largest box was labeled “Employee Information” and appeared at the top of the page followed by three more below that, each in separate columns labeled “Required Training”, “Career Development”, and “Get Help.” One button was also drawn in and labeled “Reports and Queries.” Without any detail beyond four grey boxes and one button, the basic information that the home page would transmit was captured in a single wireframe. It was so simple that anyone could understand it. This is one of the great advantages of a low-fidelity mockup, it’s very easy to get a group of people with different opinions to agree on a high-level, low-detail design.

Simple wireframe (left) showing content regions and a refined wireframe (right) showing region details

After making the point about which information was most important (the employee’s current training status) and which was important but subordinate, we were able to move beyond general concepts to detailed specifics such as exactly how the information in each of the main regions would be displayed.

Though high-fidelity wireframes may bear a close resemblance to the final website product, they differ in important ways. First, they generally don’t simulate actions that a user will make when they interact with the website. Some degree of imagination is required when evaluating a future work flow with a wireframe. The wireframe designer can (and should) indicate through text and notations what will happen when a page element is clicked, but the wireframe can’t really respond (though I should point out that screen-based tools such as Balsamiq support links that will simulate clicking links between wireframes that represent different pages). Second, a wireframe is not intended to include extreme detail on the website’s final look and feel—that portion of the project is left to the visual designer who will make subtle typography choices and decisions about color palettes and style sheets. Instead, the wireframe is best used to shape broad ideas and prove out concepts before committing to production.

Paper Prototyping

Paper prototyping brings wireframes into the physical world. It’s a low (or no) cost, low-tech method of simulating user website interactions through an interface made of paper marked up with pens. It’s a way to verify that users will respond to the interface in the way that the designer intended without going through the cost and effort of actual coding and development. Like wireframes, it’s far cheaper to find a flaw in the website while in it’s in the paper stage than correcting a significant flaw found in production. And as with wireframes, the physical appearance of the paper prototype is far less important than what it tells the design team about the user’s comprehension of the design and what information is most important in facilitating user success in task completion.

The idea of having a test subject interact with paper cutouts may seem whimsical, but even the biggest companies see the value in saving money on development costs…no matter the method used in achieving those savings. For example, in 2015 the Nielsen Norman group reported on Mozilla’s use of paper prototyping in redesigning the Firefox technical support site. The main goal of the redesign team was to determine which information was most vital to users in need of technical support. They wanted to collapse the number of clicks needed to reach a helpful answer to the absolute minimum. In their project, they turned their wireframes directly into paper prototypes simply by printing them out. The feedback they gained from testing design variants in a paper form with test subjects directly informed the design that was eventually approved for formal development.