Which fidelity are you wireframing?

I once worked with an Information Architect who insisted on building his wireframes with exceptional attention to detail. Years before the availability of modern, time-saving prototyping tools, he assembled massively multi-layered, full-color prototypes in Visio. Obsessively documenting each and every interaction in what was, admittedly, a very complex system, his final documentation resembled not so much a rough sketch as a Tibetan mandala.

 

Such rigorous attention to minute detail required far more time to complete than was allotted for that phase of the project; the designers and developers had begun their build-out long before wireframes were complete. A UX vision was lost, swept away like so much colored sand, replaced instead with a less elegant solution which boasted one characteristic that no wireframe could ever match, no matter how detailed: it actually worked.

 

In my own practice, I lean towards lower-resolution, rougher wireframes that focus far more on function than form. Taken to an extreme, this sometimes means specifying an interaction with little more than a rectangle labeled “Sign-in Form Goes Here.” This might be viewed as an abdication of an Interaction Designer’s responsibilities, were it not done with an eye towards the nature of the collaboration to follow. In this particular instance, my aim was to create a framework for a conversation – we had a sign-in form that functioned well for desktop web-based interactions, and there were more pressing interaction design challenges to solve for the mobile app in the short amount of time available.

 

Mastery of any tool brings with it a certain level of pride in one’s craft. It seems only natural to use one’s ability to detail a vision of how an interaction should be designed. When a  tool becomes second nature – when you can whip up prototyped interactions in a flash, create masters-within-masters that accommodate even the most complex topical hierarchies, even create adaptive wireframes that preview functionality across platforms – it may seem like an imperative to do so.

 

The mark of a truly skilled artisan is the ability to choose the right level of detail for a given situation. And in an endeavor as collaborative as the creation of a digital experience, your expertise is best deployed judiciously: punch above your weight by focusing on defining those interactions which are unique, novel, or otherwise likely to result in widely-varying interpretation if their definition is left vague.

Injudicious interaction design can lead to a prototype which defies maintenance. Your lean, flexible, easily-adapted wireframes will grown into an ungainly beast, with workarounds and hacks to rival the most mature full-featured systems.

What happened?

It’s likely that, if you look back, you will be able to pinpoint a juncture where you started to demand of your prototype more than it was ever supposed to do. Maybe what began as “let’s throw together some ideas and see if we can get some feedback,” morphed into “let’s do an in-depth usability test with 25 customers over the next three days.” Or maybe “the devs just need a rough idea of what this page will look like,” soon became, “the wireframes need to be a full specification of all of the functionality we’re supposed to build before we can begin.”

The road to high-performance prototyping is plagued with good intentions (to mangle a phrase.)

When you begin to layer complexity onto a prototype, do so with your initial intentions in mind: does the complexity serve you, or is it an excuse for not collaborating with the other people on your team? Could you communicate the intent of your interactions and let others bring them to life in the full splendor of their own visual design and code? Are you using prototyping to support rapid, flexible iteration – or are you supporting a waterfall-centric model of development that has few, if any, opportunities to incorporate dynamic feedback and learning?

Prototyping should focus on quick iteration and production of artifacts that can be disposable. If building a fully working demonstration app or website were possible with the same or fewer resources – either time or people – why would you prototype or wireframe? Sketching the outline of an idea, to help communicate the essence of a concept, will always be faster than building the thing. Anyone who claims otherwise is missing the point; if the concept could be built as fast as it could be prototyped, then it is by definition not novel.

 

If you are not prototyping or wireframing a novel interaction, you’d do well to ask yourself: is there a simpler way to communicate the intent? Can you reference an existing example? Can you describe your intent, rather than demonstrate it? (You are, after all, not a novelist: it is perfectly acceptable to “tell”, rather than to “show.”)

 

This is also an opportune time to think about the useful longevity of a set of wireframes. Once the team’s intent has been agreed upon and communicated, you’re faced with a new challenge: during the next iteration of design or development, when visual design and code begin to coalesce, do you attempt to keep the wireframes current? Or do you discard your carefully-crafted work (or at least “freeze” it as an artifact of a moment in time?)

 

To a large extent, the answer depends on what’s most needed in subsequent rounds of iteration. As complex products evolve, you may want to keep your wireframes current – even if that means backfilling what’s been released in code. Resist that urge, however: backchanneling de facto designs into wireframes will force you to either amp up the fidelity of the wireframes to match the finished product, or to discard evidence of design decisions that could only have been made in the process of building an actual product. Either way, you wireframes no longer embody your team’s intent; instead, they end up documenting the “intent we should have had.”

 

Furthermore, this kind of retroactive wireframing consumes another precious resource: the time you might have had to prototype your product’s next iteration.

 

As your team’s intent and products evolve, keep an eye on the fidelity of your wireframes:

  • Be wary of overly-detailed wireframes; they tend to second-guess decisions that haven’t yet been made, or unnecessarily constrain designers and developers.
  • Keep focused on the core purpose of a wireframe, and prototyping in general: to support rapid iteration of novel ideas.
  • Take care when updating wireframes after subsequent design and development cycles; are you adding complexity to an artifact for a specific reason, or distracting yourself from the next cycle of innovation?

 


Ben Levin

Ben Levin is a UX writer and content strategist at HotGloo. He’s    been building and leading UX and Design teams for the last 15 years – including 2 long stints at interactive agencies.
You can find Ben on Twitter.