Knowledge Base Articles > What Are Annotations and Why Use Them?
Annotations are brief notes, typically on the side or bottom of a wireframe, that attempt to describe each item placed on the wireframe. They have a challenging role: to speak for the wireframe’s designer when she isn’t there. In theory, when developers or clients want to know just why that link was placed in that spot, they can read the note on the document and understand not only what the thing does, but also why.
Annotations are the information provided by you, the designer, on how something on the screen should function. You can also include more details, such as design rationale, scenarios, edge cases, or examples.
The goal is to make the understanding of how and why something should work as clear as possible to anyone viewing the wireframes.
"There are typically five audiences for wireframes: clients (internal or external), developers, visual designers, copywriters, and, most importantly, your future self."
- Dan Saffer
It is your responsibility to communicate the rationale of your design decisions to your client (either internal or external).
Annotations help clarify how something should work that is in a static form. Your wireframe is static. While you can indicate something should be interactive, such as a button, the developer doesn't know what to make that button do without your explanation. When looking at a static screen it is easy to make assumptions about what something does or what the content should be for that element. Help out your developer friends, and be clear about what you want an element to do.
Separate your annotations into two main sections: content and functionality.
Developers will mainly look at the functional notes, copywriters the content ones, and everyone else will pick and chose between both.
Be smart about what you put in the wireframe and how. The clearer you make the actual wireframe, the less you will have to explain in annotations.
Annotations are often shown using numbers. The numbers in the wireframe should be a sharp enough contrast (generally with a circle around them) to stand out from the design. Then the numbers are listed again on the side or bottom of the wireframe with the text explanation.
Annotations have to capture not only what is being displayed (and where and when), but also why. The more you can document your thought process and the decisions you made, the easier it is to explain your work, defend it from criticism, or fix it in case you’ve made a wrong decision.
There is a vast difference between an annotation that reads, “Show first 10 new messages.” and one that reads, “Due to possible hundreds of new messages, only show the first 10.”
Sometimes the reasoning is too complicated to put into an annotation, in which case I usually create a separate, attached document that shows the decision process, usually in user flow format.
There are two minds of when to annotate your wireframes:
Annotating as you go along and are doing the design helps you think through how something is going to work. If you annotate after you have finished all of your wireframes, you may have forgotten how you intended something to work or what your thought process was behind a decision.
Like building a product or service, annotating your wireframes is an iterative process. Maybe you are in a brainstorming session and sketching on the whiteboard various ideas. You may have a few annotations to call out the functionality of what you are thinking at a first pass. Maybe you are sketching on paper and you are trying different layouts of a screen. Add a couple of comments so you know what you were thinking as you went through those ideas. As you move into digital tools, your annotations will become more detailed and laid out cleanly with your designs. When you talk with developers, you'll learn a bit more about what's needed and technical feasibility. It helps to add these notes to your annotations as well.
Level of detail:
Some key points to keep in mind when doing annotations are: