Tailoring Annotations to Your Wireframe Audience

We know that annotations are a key component of wireframes. Annotations help explain what the wireframe is for, and how individual elements within the wireframe are supposed to behave. But when it actually comes down to writing them the two most common mistakes are over- and under-annotation. Both come from misunderstanding the needs of the wireframe audience (or of multiple audiences, which is more likely).

What do you need to capture?
When you sit down to annotate your wireframes, think about what sort of wireframes they actually are.  Are they storyboard-like sketches meant to help sell a concept to a client?  High-fidelity blueprints of rich and complex interactions meant to help developers understand the intended functionality?  The answer will help you figure out what you need to describe to the person who might soon be reading or reviewing your ‘frames.

In the first example (storyboard sketches), you might want to describe:
– user pathways or journeys through the site or feature set
– how the depicted features and functionality help users reach their goals
– how features map to personas (if they are being used)
– how the the client’s stated business goals are being met
– how specific business requirements are being addressed

In the case of wireframes used by developers and/or visual designers:
– the result of actions taken within the page (menus, buttons, links, etc.)
– alternate use cases, paths or conditions
– known design or technical constraints (e.g., “The business requirements prevent use of Flash as a solution here.”)
– pixel dimensions or design grid information (as needed)

Your wireframes might eventually land in the hands of clients, visual designer AND developers. What then?  One approach would be to write a separate set of annotations for each audience, and distribute the wireframe variations accordingly. That can cause additional work and headaches since some of your annotations may apply to multiple audience groups.  If you have to change something later, you’d likely have to edit it in several places.  You could opt to keep all sets of annotations displayed all the time, but color-code or add symbols to indicate which audience needs to read which set.  This may result in a real estate problem if you have more annotations than space on your page.

Let the pictures do the talking
A much more efficient approach is to take a critical eye to your annotations and to be discerning from the beginning about what you need to include.  What information needs to go on the permanent record? What can be offered during a verbal discussion instead? On any given page, the most likely candidates for annotation are unique functional elements. High-level notes that apply to all or most pages (such as design rationale) can be placed on a separate page toward the beginning of your document. The same goes for global elements and patterns – explain them just once, up front.

Introducing color-coding or symbols can provide a visual cue about a variety of issues and cut down on verbosity.  Use them to indicate relevant personas, “phase 2″ features, cross-references to other documents, content, data or module types, states or conditions, or other identifiers that will benefit from being mapped to your wireframe content.  Make sure that you also create a legend or key that is prominently displayed at the beginning of the document.

In some cases, creating additional wireframes to show an alternate state or use case may be easier for the reader to digest than additional paragraphs of explanation crammed into one page. For complex experiences, consider including a flow chart.  Let the pictures do the talking!  The more you can put into the wireframe, the less you need to use words to describe it.  Don’t feel that you need to nail down every pixel — wireframes provide an overarching structure and set of guidelines for the final product.  Too much detail may end up hampering you later.  The primary exception would be in the case of wireframes (and their annotations) used as an actual functional specification document.

In order to articulate your design to others through documentation, you have to understand both your own design decisions and also the needs of your readers.  Being aware of who those audiences are is a good first step.  Following through by including the information that stakeholders need and expect will create project efficiency as well as foster agreement, alignment and buy-in.

More News

| 15th Feb 2019

Isobar Good: Where We’re Headed

As our teams set their agendas for 2019, here’s a quick look at what each of our office leads has planned for an excellent year of Isobar Good.

| 13th Feb 2019

Get The Squeeze on Rudy Loo

Our people are what make us special, get The Squeeze on the Isobar team.

| 11th Feb 2019

Waiting Gains Us Nothing

Moving the needle for inclusivity one meeting at a time.