Wireframes are an essential tool in the usability engineer’s toolbox. They can be created easily and support communication regarding fundamental layout and interaction design. Usually, little to no resources are spent on visually “styling” the wireframe in order to efficiently focus on the fundamentals without investing too much effort in visual details that are likely to undergo significant visual changes later.

If members of the design team / stakeholders lack experience with using wireframes, certain problems can occur that may impair a user interface design project, two of which shall briefly be described.

Imagining Visual Design…

For a non-designer it can be difficult to imagine the visual design of the final user interface based solely on a wireframe. In extreme cases, stakeholders may withhold feedback because they claim that it is still too early to seriously discuss the user interface. (This may be the point in the project at which the usability engineer points out to stakeholders that there is much more to a user interface than visual appeal.)

To help members of the project team envision how a wireframe could evolve into a visual design, it can be helpful to either apply some sort of “styling light” to a wireframe or to provide a real life “before-after” example of a wireframe and the resulting visual design. This supports stakeholders in getting a “feel” for the transformation a wireframe undergoes once a user interface designer uses it as the basis of the visual design. In the best case, inferring future visual designs based on wireframes is not such a stretch for stakeholders after they have seen an example as shown below.

…And Abstracting From Visual Elements

In other cases, wireframes incorporate visual elements, such as branding graphics or location bars, but not because those have already been designed – instead, they have been copied from existing interfaces or prototypes, e.g. for reasons of convenience and to “fill the space”. This may provoke inappropriate discussions of the “look” of the interface and some stakeholders may even outright reject the “inconsistent” user interface because they do not distinguish between the elements that make up the essence of the wireframe and those that are out of scope.

This issue shows that prematurely “spicing up” wireframes with visual elements can be dangerous if the status of the wireframe or its parts, respectively, is not communicated clearly. It is recommendable to deliver a “disclaimer” with the respective wireframes (either in written form or verbally, depending on project situation and audience) to make clear the scope of the wireframe to allow the audience a proper judgment of whether these details should even be discussed. It might also be a good idea to ask oneself whether the visual spice is actually necessary, and if not, to refrain from “overstyling” the wireframe.

To avoid issues like the ones described above, it can be helpful to provide stakeholders with a brief excurse on purpose and status of wireframes in order to establish common ground for design discussions. Setting expectations properly and helping the audience “stretch” their imagination a bit then can go a long way in putting wireframes to efficient use and create sound interaction designs that provide a perfect basis for the following visual design.