The web is a dynamic and fluid medium. As UX designers, we need to provide context and communicate design decisions to stakeholders to help provide clarity for our static concepts. Annotations allow UX designers to communicate to clients and developers why an interface element is placed in a specific location and what the interaction model is for the element. This establishes a clear information hierarchy for the design solution and creates a user flow that helps guide stakeholders through the road map of interactions to be translated into wireframes.

An annotated wireframe showing user flow between screens.
User flow. Image credit Dixie Pacheco.

Why are annotations important?

Creating annotated wireframes is time consuming, but communicating the overall picture of the user experience helps stakeholders see the benefit and rationale for your design decisions. Wireframes are both project documentation and a visual communication guide; make annotation part of your work flow to eliminate misunderstandings or confusion. Knowing your audience also helps you decide what type of information you should be incorporating into your annotations and what writing style you should use. It is always a good idea to get feedback on the level of detail required for the annotations from the project team, before presenting them to others.

There are typically five audiences for wireframes: clients (internal or external), developers, visual designers, copywriters, and, most importantly, your future self.

Dan Saffer, Sr. Staff Product Designer, Twitter

Clients will want to see the business benefits and what the (digital) experience will bring to their customers, so it’s important to use annotations to show how the user experience aligns with the client’s brand and business conversions. Meanwhile, developers and visual designers will want to see how the application works, so you’ll need to demonstrate messaging and the placement and styles for the interface (UI) elements for them, while copywriters will want to know what to write and how to adapt their tone to the target audience. Make sure to create notes for yourself, along the way. You may need to revisit the project and will want to remember why you made a certain design decision or specific annotation.

Design Tip: Test your initial sketches. Photograph your designs and import them into Adobe XD to quickly create clickable (interactive) prototypes. You can use XD UI kits to speed up the process.

Screenshots from the Wireframe Kit for Adobe XD.
Wireframe Kit for Adobe XD. Image credit Ahmed Hammad.

Using annotations to show context of use

Annotations provide context for how something will work. When designing wireframes, using them will illustrate not only the design itself but how it will work in a dynamic setting. The first place to start is with the user flow. Show and tell the overall logic and process of how the user will interact with the design. Where does the user start, what are the user’s options, and what will the user see? 

Interaction models help you provide context for navigation and list the different interactions needed within the application. Where do links take the user within the experience, what type of inputs does the user see, and what are the user’s options?

An wireframe of a page on a mobile web shop with annotations for each section of the page.
Mobile web shop. Image credit Olivia Gardiner.

Best practices for annotating your wireframes

Start making notes early on 

A simple text document or spreadsheet can help you organize annotation notes before implementing them into your wireframes. Use simple vocabulary and an active writing style to help keep notes and comments short and direct. Avoid using metaphors or figures of speech, and keep everything in context. Provide information that is useful for implementation, e.g., character limits, rules for pagination, and checkbox states.

Keep it clean

Keep both annotations and wireframes clean and uncluttered with a grid system for consistent layouts. Grid systems help with alignment and placement, and having page elements aligned with a numbered order and hierarchy further helps in communicating design decisions via your annotations. Focus the attention on the functionality and content layout.

Make design decisions in context with the client’s content

Skip using “lorem ipsum” placeholder text and design with real content. This will avoid any unnecessary confusion or the need to make extensive annotations regarding what specific content would be used on the page since it is already being presented.

Don’t skip annotating specific sections or pages

Annotate each page as though it is something new. Avoid generalizing by referencing previous projects or stating that the dashboard is similar to another website or app. Referencing past projects in your annotations can create bias or different expectations than those of the project at hand.

Leverage a legend

Create symbols to distinguish between content, functionality, and dynamic elements in your annotations. A simple legend for content and dynamic elements will provide clarity to the reader and help provide context for what is on each individual wireframe. Maintain a consistent ordering system. Use a two digit numbering notation 1.x, 2.x, and so on, so you can add additional notations if necessary rather than renumbering existing annotations. Annotation counts are page specific, so don’t continue the numbering from the previous page; instead, reset the annotation count with each new page of wireframes. Provide the reader with specific page IDs for reference to make annotations easy to follow from page to page.

A wireframe for a mobile interface with numbered annotations and a legend describing them.
Illustration of mobile annotations. Image credit Chaymae Lougmani.

Move from explaining general page elements to specific ones, and use the same naming convention when referencing wireframe elements and annotations. Make sure to provide visual space for each annotation, too; don’t clutter a page with numbers, arrows, and notes. Keep annotations and other notes on the right hand side as per these wireframe examples.

Consider the state

Remember to give attention to interactivity, micro interactions, mobile gestures, and modal windows, providing user actions and interface responses for each interaction. State where the user is taken on click or what happens when the user hovers on an element

An annotated wireframe for a mobile app.
Mobile wireframes. Image credit Volodymyr Melnyk.

What and when to annotate

When annotating wireframes, be concise and present ideas clearly. Address how something is used, why it is part of the design, and where it will take the user. You can use annotation notes to:

  • Show call to actions (CTAs). Highlight the labels, text, and location of the call(s) to action on each page or section. Login or sign up actions should be clearly defined.
  • Clarify elements and sections. Page elements and sections should be clearly defined and noted. Provide details if the element or section is a widget or section display is conditional, e.g., is the user logged in or not. 
  • Explain links and buttons. Illustrate and note where all links and buttons are on each wireframe and what action happens when clicked. Show where navigational elements take the user within the experience. 
  • Describe what dynamic elements do. When presenting wireframe concepts, give additional information and designs for dynamic page elements shown in static form. This would include dropdown menus and active and inactive button states. For example: “On click, a modal overlay window opens,” or, “on hover, a tool tip opens.” 
  • Show active and inactive states for page elements. Show how button states change once given conditions have been met, e.g., has the user acknowledged reading the terms of conditions or interacted with the captcha on the page?
  • Show page content that is hidden or modal. Design and illustrate content that is not immediately shown on the page. Hidden or modal elements of the wireframe can be shown with a supplemental page or in the margin. 
  • Provide supportive messaging and prompts. Give the user encouragement for successfully completing certain tasks and achievements. Let users know what should be done in certain sections through progressive disclosure or tool tips.
  • Provide error messaging and error states. Error messaging and error states require space and planning, so think ahead to what type of messaging is needed and where it should go as a page element. Error messaging should tell the user what needs to be fixed or done to correct the error.
  • Indicate page and element transitions. Show or describe how page elements are animated or toggle between active and inactive states. Describe animations and how they are used on the page. 
  • Provide notes for the project team. Write up actions or functional features to let designers and developers know when to show a loading message, how to paginate or scroll through content from search results, or where and when to use accessibility tags.
A wireframe with annotations describing accessibility requirements.
Accessibility Annotation Examples. Image credit Karen Hawkins.

There is no reason to repeat yourself. You should address each aspect of content or functionality once in your annotations. Add page references when a user interaction opens other pages or dynamic content that was previously annotated.

Be clear and concise

Avoid being vague with your writing, which can lead to misunderstandings and defeat the purpose of having wireframe annotations. Your annotations should be clear and precise to avoid the need to clarify their meaning. Annotations are not a substitute for speaking with stakeholders or holding a formal walk through with project teams.

Wireframe annotations are for providing context and communicating project concepts and ideas to stakeholders. More often than not, wireframe annotations are not read over in detail. Be prepared to speak to your annotations and answer questions from the client and project teams. Test and validate wireframes with feedback from walkthroughs and ad-hoc user testing. Wireframing is not done in isolation and putting design decisions in front of prospective users will provide context for interactions and help deliver project outcomes.