Summary: Rather than think of the wireframe as a low-fidelity, grayscale snapshot of a web page, embrace it as a thematically rich conceptual model.

When we make wireframes here at The Understanding Group (TUG), it’s often at the tail end of a larger engagement. They are typically one of the last deliverables in the lifespan of a project, coming after rounds of alignment, user research, benchmarking, modeling, etc.—all leading up to the launch of the new thing. After weeks of being immersed in the abstract, clients are often eager to get to the tangible. They want to see what the actual thing we’re making looks like — and so do we!

Often this means creating detailed wireframes, page-level schematics explaining how all the various elements come together. They are an expression of the information architecture, depicting spatial relationships, hierarchies, navigation, and available functionality. But in an effort to create a compelling and realistic vision of what we’re proposing, wireframes tend to also depict detailed interaction design patterns and sometimes even drift into visual design (albeit in shades of gray).

Details Can Distract

While this level of detail is often appropriate or even necessary for successful delivery, it shouldn’t necessarily be our default mode. Sometimes providing interaction-level details can distract from the structural elements and thematic concepts we are trying to convey. Especially so when the wireframes are trying to communicate all of this at once.

Focusing on bigger picture concepts before getting to lower-level details can help your audience understand what you’re proposing and get to alignment sooner. Even though we’re now working at the level of the individual page, there’s no need to abandon the conceptual models and strategic themes that we’ve introduced up to this point. We can continue to pull them forward, showing how they influence the structure, even as we’re pushing closer to the surface.

Rather than thinking of the wireframe as a low-fidelity, grayscale snapshot of what a page will eventually look like, coming further and further into focus as the design is refined, we can embrace a broader view of the wireframe as a thematically rich conceptual model — one that is now depicting page-level details, reinforcing previous models of the system as a whole.

A Quick Case Study

So how might such an approach work in practice? Let’s use a recent project at TUG to illustrate. Working with a client team to re-architect a large scale, public-facing site, one of our early recommendations related to content strategy. We observed many of the pages were text-heavy, difficult to scan, and offered few supporting visuals. We recommended that their core audience could be better served with a variety of content types and presentations, depending on the type of user, where they were in the lifecycle of engagement, and what type of task they were trying to accomplish.

We distilled the recommendation into three content themes:

• Think content aids understanding of key concepts by breaking them down into smaller chunks, supported with graphical representations like flow charts and color-coding.

• Feel content aims for an emotional connection with the user through multimedia, user-generated content, and scannable headings.

• Do content streamlines key task flows by removing non-essential navigation and providing ample contextual support.

These three themes could then be combined in various proportions to suit the needs of any given page. Later when it came time to create detailed, page-level wireframes, we overlaid our themes on top of the wireframes to illustrate how the themes could come to life in context.

This approach was well received and helped both to clarify our thought process and build trust in our recommendations. And we hope it will continue to deliver value, serving as a playbook for content strategy and migration efforts, in addition to the wireframes’ primary role as structural blueprint.

Exploring Possibilities

From here, we can imagine various other strategic or conceptual themes that could be visually woven into our wireframes. We might highlight structural properties of our navigation and wayfinding systems, noting which areas navigate within the current section, point out to related external content, or orient users within top-level sections.

Or we could use a heat map treatment to highlight parts of an interface that are more or less complex to implement, which could be quite helpful in scoping large-scale development efforts.

Referencing back to user research, we might also map content or features that are especially relevant for certain user archetypes or scenarios.

Out of the many types of models we may employ, even just considering the often monolithic wireframe, we’ve seen there is actually a wide spectrum of possible approaches to consider. On your next project, try adopting a more expansive view of what a wireframe can be and push the boundaries of what they can communicate.