Wireframes are visual representations of a user interface, stripped down to bare essentials. It’s a method of distillation so useful that we find variations of it across all design fields, from magazine layout to app development.
With wireframes, designers can take a first stab at arranging a site’s content and functionality, while proposing answers to questions both important and mundane. Should the menu reside at the top or the left? Where should the search box go? How prominent should the latest update be?
For those designers perennially disposed to jump straight to pixel-level detail, wireframes are a needed brake on their zeal. For developers focused more on function than form (or editors focused more on words than column-inches), wireframes represent the first tentative, rickety bridge built between content and presentation. Depending on those in the room, the process of wireframing can be a dance — or a bare-knuckled negotiation.
And as there is no real standard in wireframing practice, the range in what is considered a “wireframe” is incalculably wide. I’ve found that designers tend to adopt whatever wireframe format they’re first exposed to and then stick to it. It might be from a class in school, or more likely their first agency gig. Sometimes it’s just a rough sketch of block positioning:
Other times it’s a detailed blueprint of UI elements, hover states and responsive conditionals:
So any overview of wireframes by necessity must be broad and a bit vague. But what I want to emphasize in this post is not what fits in a wireframe, but how wireframes fit into the bigger picture of site ideation, development and design.
A wireframe is only as good as the insights that precede it. Here’s a partial list of what will ideally flow into any site or app wireframe:
- Functional requirements and limitations. Woe betide the designer (or account manager) who promises functionality that can’t be delivered on.
- Client needs and expectations. Through the discovery process there will be signals given by the client in terms of what they need and want — and what you have promised.
- Personas. These fictional representations of users should help you properly balance competing interests when determining position, primacy and interface patterns.
- User stories. Wireframes should take into account the myriad of distinct ways the end product will be used to solve user problems.
- User and back-end workflows. Crafting the most painless path from problem to solution for users should begin to manifest itself visually in the wireframing process, along with the workflows for those client-side who will be changing and updating content.
Wireframes are where the rubber hits the road, and all the airy and utopian ideas about the final product finally must start residing within real-world constraints.
This is why it’s so dangerous that many new designers still think of wireframes as the “first step” in the design process, and pat themselves on the back for not just booting up Photoshop or Sketch and diving right in. Small or pro bono clients, especially those unfamiliar with design, may not mind. But larger and design-centered clients, and more complex projects, demand a full discovery process with the wireframe not as a starting point, but embedded deep within a much larger process that takes place well before the first full mockup sees the light of day.
Photo by Johan Sonin via Flickr.