Annotate to Communicate

Someone once said, “if you have to explain the joke, it takes the fun out of it.” Well, the same can be said for designing a website. Explaining the important and sometimes technical details can be a tedious process many designers would avoid if possible. But when it comes to communicating the form and function of the user experience through wireframes, explaining each element can make or break the project. It’s always a good idea to include annotations.

Types of Wireframes

First, let’s start at the beginning to avoid vague deliverables. Does every UX designer you’ve met create similar looking wireframes? There are about as many different styles of wireframes as there are websites on the world wide web, so chances are the term ‘wireframe’ by itself really isn’t saying much to your client.

Most folks understand a wireframe to be a basic layout for a web page, in shades of grey. But other than that, what else should they expect? Will it be a basic paper drawing or a functional computer drawn detailed webpage? Usually the type of wireframe provided is based on the budget and pace of the project, along with considerations for the type of site to be built, the scale of the overall project, and the depth of the sitemap. Sometimes more than one type of wireframe is used when user testing is needed. Once the most appropriate wireframe approach has been determined for the project, it’s a good idea to convey the definition in your deliverable documentation. Here is an example:

Low Fidelity Wireframe

Can be paper sketches or computer drawn.

Abstract lines and shapes that represent spatial elements on the page.

No actual copy is used, just lines to represent text.

Descriptions for content and functionality (as needed) are included directly on (or near) the elements.

Medium Fidelity Wireframe

Copy inserted where available, otherwise lorem ipsum is used as a placeholder.

Presented in shades of grey with no styles or graphics applied.

Functions have labels.

Descriptions for content and functionality provided in annotations.

High Fidelity Wireframe

More details are included for each component along with additional views for features like modal windows or dropdown filters.

May include specific typeface choices to begin to show hierarchy.

Spacing between elements is further refined.

Determinations between image vs. illustrations may be eluded to.

Remains without color.

Why Annotations are Important

So you’ve just created a beautiful set of wireframes, had a great client presentation, and they’ve approved them. Great job! But that’s only part of it. Just because you’re ready to share the wireframes with the developers so they can begin their technical discovery, it doesn’t mean they have the same shared understanding about them as you and your client. Often times in an Agile development process, not everyone involved is present for every meeting during the discovery process due to the pace of the project and/or budget. Even when everyone is present, we don’t want to make them rely on sheer memory alone for how each component is going to be built or how it will function. That’s where the ever important Annotations come in. By providing fully annotated wireframes to both developers and your client will help to keep everyone on the same page for what to expect at launch.

The Art of Annotating

Once those medium or high fidelity wireframes have been created, it’s time to add the important information so we can ensure everyone has a clear understanding of the functionality that is expected for each component. The most important thing to remember when annotating your work is that it should speak for you when you’re not there.

Where Should The Annotations Go?

Typically, annotations are placed on the side or the bottom of a wireframe in a numbered list of descriptions with corresponding numbers next to the actual element on the wireframe. The language is kept brief in order to include as much information as possible within a limited physical space. It’s helpful to use color combinations that stand out from the wireframe to avoid confusion between elements. And when you have multiple audiences you need to address, it’s helpful to tailor your annotations by creating different sets for each.

Who Are The Annotations For?

Not that you need to include them all, but there are typically up to 5 different audiences who have different needs but may benefit from wireframe annotations:

The Client wants to understand how each element incorporates their business goals. When designing for Drupal, annotations are also the perfect place to highlight when certain components will be manually curated or fed automatically to ensure the expected maintenance after launch is clear.

The Front-End Developer wants to see where the images and icons are placed, what size and aspect ratio they are, defined page margins, amount of padding between elements, and the functionality for all interactive components.

The Back-End Developer can benefit from notes on image sizes, functionality for interactive components, manually curated elements vs. automatic feeds. They can also incorporate helpful tips for the content author with specific direction.

The Copywriter can write more freely if you’re able to provide recommended character counts for each section within the component: Title, subtitle, descriptive text areas, etc. Notes for optional elements will also improve the quality of the final copy. And when content will be auto-fed, note it so they can move on!

The Designer for those instances where wireframes and designs are handled by different people, it’s helpful to include design direction or live links to reference examples. You’ve been involved in conversations with the client during wireframe development and understand their vision. This is the opportunity to communicate that information.

What Information Should The Annotations Include?

Don’t think you’re being helpful if you annotate everything, without a cause. The last thing you want as an end result is a wireframe that’s so overloaded with annotations it looks like the plans for the next spaceship launch. It can actually be more confusing if too many notes are present. Smart wireframe design can alleviate the need for certain descriptive annotations when you include the descriptions within the titles of the element itself:

The title ‘Logo’ or ‘Icon’ sits inside of the circle.

The Button title reads ‘Optional, Editable Button’.

Required form fields have a red asterisk.

The opening ‘lorem ipsum’ descriptive copy instead starts with “This is an introductory paragraph that talks about scientific discoveries”.

What should you annotate?

Anything that is not obvious just by looking at the wireframe.

Conditional items: when and how to display them.

Cross-device differences. An example would be when an image may display on desktop but not on mobile. Or when an image may be replaced with one of a different aspect ratio on mobile, etc.

Messages and Modals

Numbers

Account for the longest number of digits that will be needed for any confined spaces. Example: Should it display as 100,000,000 or 100M ?

Titles and Labels

Account for the longest names potentially possible. Provide solutions for cases when the lines should not break: ie, within tables, accordions, filters, etc.

Tooltips

Provide visual reference and implied behavior for tooltips and try to account for the maximum characters that will be needed.

Gestures

Especially when annotating mobile wireframes, your intentions will not be lost if you add directional notes for specific gestures, such as:

Single-click (or tap)

Double-click (or tap)

Right-click (or tap)

Hover (provide mobile alternative)

Swipe

Pinch & spread

Drag & Drop

Default link for phone, email, map

External web links

Wrap it Up

Fully defining the wireframe process in the beginning of the project will clarify expectations for the client. Wrapping those completed wireframes in an annotated package will help to keep everyone involved working towards the same goals, and avoid disputes, disappointments, and costly reworks down the line.