Be kind to future designers with annotations
Or: How to best use your time if your project isn’t being funded
Right now is when many UX practitioners, especially those in academia or government, are feeling lost.
The next fiscal year is around the corner, and sometimes that comes with the news that your project won’t be funded for the following year.
Sometimes it’s sudden; sometimes, you have weeks to process it. But either way, you may find yourself unsure what to do next: after all, it’s unlikely that any user research or designs are going to be tested or implemented at this point.
But there’s one thing that you can do that will be incredibly helpful in the future: annotating your designs.
Annotation is something we often don’t do because we may not have time in our work cycles to work on something like that constantly. But if you’re wrapping up a project, it can be something that you can use to properly address ideas, thoughts, processes, and more. And it’s essential for one main reason: you may not be around to explain your reasoning later on.
Creating a time capsule for the future
One of the most important things to realize is that projects can be vitally important to the organization, but they might still be cut “temporarily” due to budget issues. This means that there’s a likelihood that the business may revisit the project, but it’s almost a guarantee that it won’t be the same team. Sometimes the business will revisit the project in 5 or 10 years after you’ve left the company. Even if you are still on it, you may have to explain the reasoning, processes, and more to an entirely new set of developers, business analysts, project owners, and managers.
So the first essential thing to annotate is a date stamp of when we made these changes or decisions and why.
We may believe otherwise, but nobody in the future team is going to do a deep dive into meeting notes, user research, or more to understand the team’s rationale at the time. There are two places people will look to try and understand all of the features and things they need to take care of: they’re going to look at something like a prioritized backlog of user stories, which doesn’t have room to add context or much info…
https://www.scrum.org/forum/scrum-forum/35216/moscow-prioritization
Or they’re going to be looking for design artifacts or documentation. Having an annotated prototype (with specific design changes) can provide a whole lot of context, and can be incredibly helpful at getting them caught up.
https://uxdesign.cc/design-annotations-that-will-make-your-developers-happy-d376d4453d9d
These annotations are also a possible way to get people to read certain things, other than a long text document. This can be important because your annotated prototype can also serve as something else: it can serve as a central document.
Having a prototype as a central document
One of the most exciting features that design tools like Figma and Adobe XD offers is the ability to link to different documents as part of the workflow.
https://uxdesign.cc/design-annotations-that-will-make-your-developers-happy-d376d4453d9d
This allows a prototype to serve as a better starting point for many new people to the project. I can’t tell you how often I’ve started re-designing one of these projects, only to either be sent the ‘project goals’ document (which was created a year and a half before they stopped) or a backlog of features without much context.
Having a half-finished design prototype with links to specific documents in context can be much more helpful than rooting through folders and different documents. You can even embed links to a separate document with more lengthy and technical annotations.
https://medium.com/wayfair-design/design-basics-annotating-your-work-6eac0562097f
This can also be useful for one other reason: it can help compile a design or research rationale list.
Explain design rationale (design and research decisions)
“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
One last thing annotations can help with is explaining design rationale, especially when it comes to roadblocks that you may have encountered.
Sometimes, you’ve had to design something that runs contrary to what you might expect: perhaps there’s legal or organizational policy, technical limitations, or database issues. Or maybe the users have requested certain things that help augment their workflow that seem strange at first.
For example, I’ve encountered one thing that my users don’t like help buttons for fields mid-form. They don’t like it because they usually navigate through fields by hitting Tab (rather than clicking), and the Help button can sometimes mess it up.
Annotating these things and the rationale behind it can be a great way of explaining why items are designed the way they are (and having the future designer re-discover that and waste time).
https://balsamiq.com/learn/articles/wireframe-annotations/
But it can also highlight where to look for things if they want to learn more.
For example, if they wanted to learn more about the user research that led to this tab discovery, you could include a link to the exact user testing session (or findings) within the prototype. Or, if there’s an organizational policy that influenced how we designed something, you could link to that.
Including these things allows you to understand the rationale and read over the exact user research or design decisions that made this possible. This can be incredibly useful to pinpoint precise parts of the process.
So the question then becomes: How do you figure out what to annotate?
How to annotate your design in 3 steps
Step 1: Determine which format your annotation will use
While there’s no ‘right’ or ‘wrong’ format for annotations, there tend to be two main approaches to annotating your design wireframes: using numbers and using text boxes.
The numbered approach is usually used for mobile interfaces or places where there’s not much room to write out a complete annotation.
https://medium.com/wayfair-design/design-basics-annotating-your-work-6eac0562097f
Suppose you have additional room (such as when designing desktop interfaces), or you want to specifically talk about things in context (such as when specific interactions take place). In that case, that’s when text boxes can be a more helpful annotation process.
https://uxdesign.cc/design-annotations-that-will-make-your-developers-happy-d376d4453d9d
Which format you choose is up to you.
Step 2: Look for design elements and interactions that require explanation
Next is to review your documentation, such as your backlog, user research, and other older design prototypes, to look for specific design elements you should annotate.
Here are some things you should ask yourself to figure out what to annotate:
Agile Backlog/User stories:
Were there design elements/interactions that required separate meetings or discussions?
Did the team make certain design/product decisions? If so, why?
Were there technical issues/outstanding questions/parking lot items noted on the backlog?
Are there design elements that we customized (if you have a design pattern library)?
User research:
Did users specifically suggest/request certain design elements/interactions?
Were there elements or interactions that ran contrary to user expectations?
Are there policy/organizational issues affecting their workflow that might affect design?
Older design prototypes
Were there previous designs or interactions that changed between versions?
Did you run into issues with a design while user testing?
Are there business needs that weren’t being met with a previous version?
This is only a shortlist of things to look at, but this can help you uncover what you might need to annotate.
Step 3: Write out annotations and get feedback.
A good annotation, depending on the format, contains:
An ID that corresponds to the label in your design
A title that confirms this is the correct annotation
A brief description of functionality, or user expectations, or style requirements, etc.
Links to additional context, design rationale, or documentation.
However, we also want to make sure that our annotations are clear and concise. After all, we may not be around to answer questions about what we meant by this.
So one of the easiest ways of doing this is to rope in your team. You might often have a scheduled meeting on the calendar for the project that gets canceled because they’re not sure what to talk about. Taking one of those canceled meetings and getting them to come together and read over the annotations is a great way to make sure it makes sense to other people (and won’t be misinterpreted in the future).
But this begs two more questions, both of which are opposites: why not do design documentation, and why should I go through all of this effort?
Doing the most you can with the time you have left
The first question to ask is, why not do design documentation instead? After all, annotations are mainly for the details, while design documentation can capture the big picture.
The answer to this question is simple: you don’t have a whole lot of time. For many of you, you may have only found out that your project wasn’t going to be funded a couple of days or weeks ago. As a result, you probably don’t have enough time to start with a large-scale effort like design documentation, especially if you haven’t captured notes throughout the process.
But annotations are something that you can accomplish in that short amount of time that can make a massive difference down the line: it can capture the design decisions, team discussions, and context that went into design what you have.
As for why you should go through this effort: you may find yourself on the other side of this process at times. After this one wraps up, the project that you start might be a re-design picking up where someone left off a year ago. Again, having a centralized document with links to context-specific design rationale and proper documentation will allow you to get up to speed quickly.
You may never meet the future designer who will work on the project you wrapped up, but you may be the prospective designer of someone else wrapped up. And annotations are a quick and easy way to ensure that the details and context aren’t lost when handing a project off.
Kai Wong is a UX Specialist, Author, and Data Visualization advocate. His latest book, Data Persuasion, talks about learning Data Visualization from a Designer’s perspective and how UX can benefit Data Visualization.