Most designers have experienced the following situation at least once in their careers: The stakeholders reject the proposed design because they don’t understand the solution it provides. Alas, sharing an asset that shows the concept of a design doesn’t guarantee a shared understanding of the concept.
It’s quite common that designs fail to get approved because their logic and benefits are not clearly communicated in the wireframes (e.g., static design artifacts that show the basic structure and hierarchy of key elements of the UI with basic boxes, lines, and shapes). Wireframes can be good for describing a user journey—a visual trip of the user across the solution—but unlike prototypes that demonstrate an interactive behavior and let the potential product speak for itself, wireframes often require clarification. It can be especially difficult to decode the meaning of a wireframe when the designer who created it isn’t around, which is often the case when stakeholders review your work.
It’s a designer’s job to communicate the rationale of design decisions to other people. When it comes to wireframing, annotations are a helpful tool for achieving this goal. Here’s how to get them right.
What are wireframe annotations?
Wireframe annotations are brief text explanations, typically on the side or bottom of a wireframe, that describe the functional purpose of individual elements or of the screens themselves. Reviewers, including client stakeholders, can read these annotations for clarity around the logic behind individual design decisions. The annotations help them understand why an element is where it is—and why it exists in the first place.
Annotations for UI elements typically include a brief description of the following information:
- What the element is (“A sign-up button”)
- What the element does (“Allows users to register a new account”)
- How it performs that action (“When users click on this button, they are directed to a new page with the sign-up form.”)
Recommendations for creating annotated wireframes
First, familiarize yourself with wireframing fundamentals, which will help you create a solid foundation for your design and make the annotation process more efficient. When you’re ready to start annotating your wireframes, follow these practical tips:
Consider your target audience
Wireframes are usually created for one (or more) groups of readers—visual designers, developers, and clients. Every group has its own needs, and you should consider each in order to make the most effective wireframes possible. Visual designers want to understand the elements they’ll have to design for individual screens/pages. Developers want to understand what they’ll need to code and how to tie it into front-end design. Clients want to understand how the design solves their business goals.
The best way to validate whether your annotated wireframes work for your target audience is to ask them. For example, if your target audience is a group of developers on your team, show one of them your work-in-progress wireframes. Note the questions they ask and adjust or annotate accordingly.
Design clear wireframes
While every design should prioritize clarity, it’s especially important in wireframes. The clearer your wireframe, the less explanation you’ll need to write-up in your annotations. One way to do this is to get rid of all unnecessary visual elements in the wireframe. Fewer visual elements mean fewer chances for bias during the review process.
Keep annotations short
The smaller the amount of text people have to read, the more likely they’ll actually do so. Thus, try to make your annotations short and to the point. Remove as many words as possible without losing the essential information. Strive for 25 to 45 words per single element that requires an annotation. If an idea requires an in-depth explanation and it’s impossible to relay the logic in a brief annotation, write a short annotation and link to a document that goes into further detail.
Write simply
Follow these rules when writing annotations:
- Avoid figures of speech. These are words or phrases that have a separate meaning than their literal definition (e.g., “It’s raining cats and dogs!”). This rule is especially important when working with an international team. Some people might not know the meaning of a metaphor or a popular saying, as many of these are culturally exclusive. Use simple vocabulary and literal descriptions so that everyone can understand your annotations.
- Avoid design and development jargon. Many readers are non-technical, and it’s vital to ensure that readers with all abilities can both read and understand the meaning of your annotations.
Number your annotations
The flow of annotations on a wireframe can either make it easier or harder to scan for information. Adding inline annotations is a common mistake many designers make; while this approach has its benefits (you can link explanations directly to their corresponding UI elements), it also introduces distracting visual clutter, which will interfere with or, worse, cover up content and functional elements that need to be clearly seen for an effective review.
It’s much better to annotate using numbers in circles. Here are some best practices when doing so:
- Place the annotations in numerical order from left to right. This will align with the way many people instinctively read.
- Color-code the circles. Annotation circles with a contrasting background or special color make it easier for reviewers to distinguish them from the actual design.
- Keep descriptions in one place. Organize the annotations’ text explanations either at the bottom of the wireframe or along the right-hand side of the wireframe. (The latter variant is preferred because it makes connecting the dots more intuitive for your users; it’s easier for the eyes to move side-to-side to match the design and explanation than it is to move up and down to make this connection, as they would if you put the annotation descriptions along the bottom of the wireframe.)
This wireframe uses blue pins for annotations, with the annotation descriptions presented in the right-hand column next to the actual wireframe. Image credit Edric Lapniramai.Annotate both content and functionality
Annotations for functionality are necessary for developers and clients, while annotations for content are necessary for copywriters and visual designers. Remember, all annotations should describe two things: what is being displayed and why. It’s also helpful to describe the benefit each design decision offers users (how it satisfies user needs) and business goals (how it leads to better conversion). When annotations describe the rationale behind individual design decisions, it’s much easier to run relevant critique sessions.
Annotate as you design
Some designers add annotations after they finish working on the wireframes. By following this approach, it’s relatively easy to miss important details. Instead, if you annotate as you design, you’ll be forced to think more deeply about the rationale behind every decision. Quite often, you’ll find a better solution in the process.
Make annotating an iterative process
Similar to other parts of design, writing annotations is better as an iterative process. Start by creating annotations for your wireframes on paper, writing brief notes that describe the basic logic behind your concept. Then, as you move to digital mediums, start to provide more detail in your explanations.
Collect feedback on your annotated wireframes
It’s easy to collect feedback on your annotations using digital design tools. Invite people to view your design and allow them to leave comments. They’ll likely ask questions about the visual hierarchy of individual wireframes, the types of elements you used on them, and request that you explain the underlying logic behind individual design decisions. These conversation threads allow for more in-depth communication and let you improve your approach.
Use a commenting feature in Adobe XD for high-fidelity wireframes. Image by Adobe.Four pro-tips to level-up your annotations
Take your wireframing annotation to the next level with the following pro-tips. These rules will make those design artifacts a valuable part of your design process.
1: Annotate interactive elements
Annotate interactive elements so it’s clear what will happen when users interact with each. Wireframes are static design artifacts, and when reviewers see an interactive element in your wireframe (e.g., button, link, toggle, etc.), they usually don’t know what that element does without an explanation. Of course, reviewers can make assumptions, but those assumptions can easily be incorrect and lead to their misunderstanding your design decisions.
2: Include the logic of conditional elements
Describe the business logic of every element that can have multiple states, and annotate the various states of the interactive element—define all possible conditions as well as the logic behind each condition change.
If wireframes have dynamic elements that only appear on the user screens in certain conditions (e.g., in-app notifications), ensure that reviewers have information about when and how the elements should be displayed. Also, include the state of the user (guest or logged-in, regular or admin) when it can influence the conditional elements.
3: Describe the design or technical constraints
Listing design or technical constraints will aid design implementation. For example, when you create a wireframe for a sign-up form, include an annotation about the requirement for password complexity and error-prevention messages. To better describe such constraints, think from the perspective of end-users and ask questions like, “What happens if I provide an incorrect password?”
4: Use annotated wireframes as functional documentation
Detailed wireframes can serve as documentation, and they can work especially well for fast-moving Agile teams that want to minimize the time they spend on writing documentation and focus their efforts on design and development instead. Annotated wireframes can become a single source of truth for such teams.
Conclusion
Many designers avoid adding annotations to their wireframes because they think it’s an extra, unnecessary step. They think that the design will explain itself. Unfortunately, this rarely happens in real life. In many cases, reviewers will rely on their assumptions and judge the design according to their knowledge, leaving room for major misunderstandings. Annotations are a solution that can communicate the value of your design. Strive to write annotations in a way that anyone can understand the rationale of your decisions.