As a designer, have you ever been asked questions about design specifications? Imagine that the project you are working on is approaching the implementation phase. The developers on your team begin to ask more specific questions. They may ask: “What happens to this element on hover?” Or “What happens between this screen and the next?”.
Fortunately, you already thought about these situations and quickly answered their questions. However, this happens more than once, and begins to take your time and effort to constantly answer these questions.
Many of these types of questions and negotiations can be avoided by being very proactive in their design specifications. One way designers can convey their ideas more clearly and proactively is through design annotations.
Design Annotations – A brief written explanation provided with the design results to identify and describe aspects of the project, Dan Lachapelle in “Design Basics: Annotating Your Work“.
Why make annotations?
Design annotations can eliminate a lot of uncertainty about how the application will work. And the best thing about them is that they exist right in context. The designer can please the developers of his team by adding annotations that will make things a little more understandable.
Login screen annotations
Recently, I have been thinking about how I can be more understandable in my design specifications by providing useful annotations, and I would like to share my knowledge. When you work with remote engineering teams like me, annotations can save you time by answering potential questions about your project in advance. Questions that would remain unanswered within 10 hours due to time differences could be resolved with simple annotations.
In addition, annotations are not only useful to developers – they provide context to all interested parties who can view your projects. They can even serve as a good reminder for you as a designer and help you articulate your intentions and arguments.
Design annotation versus documentation
To be clear, this article will not cover the project documentation, which is usually outside the design layouts and serves as a source of reliability of the project data, research and justification of certain design decisions that have been made. Annotations in no way replace the need for project documentation – they rather complement each other. In this article, I will talk specifically about design annotations that are actually built into the prototype or layout. You can read some good articles about project documentation, links to which are given below.
When to give annotations?
We cannot (and should not) annotate everything. Drawing up annotations requires additional time and effort, which you should always consider if you should invest in it. And the more annotations, the less important they become. However, there are a few specific cases in which adding annotations can be useful: Display errors and borderline cases
Description of off-screen processes
Making the case for such a design
Track changes and decisions
1. Display of errors and borderline cases
Suppose you are doing a design for a workflow in which a user uploads a file. If the download failed due to a server delay, you should show an error that the download failed. Since this is a relatively simple case of error, instead of repeating the process again, you can deviate from your main “happy path” to quickly direct the recipient of information back from the error state. This is similar to Choose Your Adventure, where certain paths lead to dead ends, but you can always return to the storyline.
I would like to demonstrate this with a switch annotation that stakeholders can use to turn on and off the error state. This ensures that they can always return to the main workflow.
Turn on or turn off error status using annotation
You can use the same technique for extreme cases. Returning to our file upload process, let’s say you have a screen on which the user can view their downloaded files. According to your research, 95% of users upload less than 5 files. However, 5% of users can still have hundreds of files. You can quickly show how this case is displayed with the same annotations. Moreover, for more complex errors and extreme cases, it may be better to make a separate, target prototype, rather than this simple switch.
2. Description of off-screen processes
Not all user interactions occur on the screen. Many workflows include events and processes that occur off-screen, even in the middle of an on-screen workflow. For example, a food delivery service is a physical process where a delivery agent delivers food to a customer. It starts with the fact that the client makes a request on the screen, then the delivery of food occurs behind the scenes, and ends with the delivery agent marking the delivery as completed and the client evaluating the service on the screen.
Although most of this process should probably be explained in detail somewhere in your project documentation, you can use annotations that reference the project documentation so that they are in the context of the workflow. Design annotations can even directly link to a section that talks about the corresponding off-screen process. This saves the time spent finding the right link and searching for the right sections to find the answers.
Link to project documentation using annotation
On the other hand, if the off-screen process is very brief and easy to explain in a few points, annotations may be sufficient.
3. Reasoning for such a design
If a certain part of your design raises questions, it might be useful to add annotations that explain its rationale. This is especially useful when you are faced with technical limitations, and you had to make compromises when designing.
Returning to our example with downloading files, let’s say there is a limit on the file size of 50 MB per file. Your ideal design shows the user immediate feedback before the file starts to download if the file is too large to download. However, it turns out that the developers in your team find it difficult to detect in advance. This is not ideal, but you are adjusting your projects accordingly to show an error after a file upload failed. This is a good opportunity to justify your design with annotations.
Conducting design rationale in annotation
In the above annotation example, you will see the “View Operations” link. For those who are interested, they can follow this link to see your previous actions, to better understand the essence of your design and what led you to the final design.
4. Track changes and decisions
When your projects change, it is sometimes useful to leave a mark on the date when these changes occur and why. This will help you and other people remember the context when and why it was decided to change the design.
Imagine that you had a business meeting two weeks ago, at which it was decided to change the file upload date (October 18, 2019) to the relative time elapsed since the file was downloaded (2 weeks ago). This is a small change that may go unnoticed by your developers who may or may not be present at this meeting. An annotation can help indicate a change, as well as provide a link to when and why this change occurred.
Date change mark in design annotation
Let’s make design annotations!
How to give annotations?
There is no “right” way to create design annotations. You could do them directly in your projects or on a separate sheet with numbered designations. You might be using comments built into any design tool you use for comments. Personally, I use comments more for negotiation than for comments, because comments are usually hidden by default and therefore not so noticeable.
You must do what works for you and your team. But if you have never made notes before, here several components of Figmawhere to start
Introducing your annotation system
Once you start adding annotations to your projects, have a short business meeting, or write something to present annotations to your developers and stakeholders. This will encourage them to start looking for your annotations and further build relationships with your developers as you work hard to make their work easier.
Otherwise, they may confuse them, or they may even think that this is part of your design (based on personal experience). I did not officially submit annotations to the developers in my team, and one of them eventually implemented a pink toggle button in our user interface, which was only for displaying the error status. At that time I was horrified, but looking back, I do not think that I really mind the pink button …
Pink toggle button
Design systems make it easy
It is worth noting that design systems reduce the need for annotations. They do a lot of hard work in terms of predetermining component behavior. Design systems ensure that certain components do not need additional explanation, because their behavior is already well defined and embedded in the code. This is an advantage and gives designers more opportunities to focus on explaining aspects of a real workflow using annotations. At VMware, we have an open source design system called Clarity, and libraries that designers can use to quickly create their projects. Here is ours Figma community pagewhere you can access our Clarity Figma libraries.
Annotations are trifles
Annotations may help, but they cannot explain everything. They may cover details, but the overall picture often lies in the design documentation. Although I use annotations to recall the details, I rely on design guidelines to cover the whole context.
We hope that these tips will help you succeed when using design annotations and, most importantly, make your developers (and other interested parties) happier.