Annotated Wireframes & Flows

Can anyone share some examples of annotated wireframes? Either your own, or examples you’ve seen before?

There are 2 dimensions:

  1. The Look: design notes, dev notes, functional notes, etc. these can be cluttered and visually confusing.

  2. Methodology for Annotation: a formalized set of considerations or heuristics for each page, view, or element type. How do you decide what to note?

I have done this MANY different ways over the years, and I’m curious about ya’ll. This is an important aspect that I only hear mentioned by others. Never seen best practices, examples in training videos, etc

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 my last role where I was the only designer, I used to put annotations near the related content directly on screens and most feedback was directed to me verbally in meetings. This methodology posed a few problems:

  1. Comments were saved directly on the png/pdf file of the screen (wireframe or higher fidelity) and could not be turned on/off - could not be hidden.

  2. Annotations couldn’t be too wordy/large or they would interfere with or cover content on the screen.

  3. It took time to make the annotations appear as such and crafting them to both appear like annotations and not interfere with the other screen content.

  4. Only I (or anyone with access to the files) was able to comment. So I would need to color code or number the annotations to have a way of systematizing them for discussions or requesting feedback. Feedback was often “annotated” back via another tool like Marvel app or Paste app.

  5. Annotations could not be easily updated without re-opening the file, adding comments, re-exporting as a png/pdf, and re-uploading to the tool (email, Marvel app, Paste app) used to share the files & collect feedback.

However in my current role where I work on a team of designers, we use Abstract to manage annotations and comments. While this is definitely not a sponsored post, I like using Abstract for annotations & feedback for the following reasons:

  1. The ability to “annotate” a screen is easy to accomplish (by selecting an area, entering a comment and submitting) and keeping the annotations organized is done by the tool.

  2. The ability to see what part of the screen the comment is annotated to is clear for the end user because Abstract numbers the area on the screen and tags the related comment with that number. It is also designed to easily view multiple or overlapping annotations on one screen.

  3. It is easy to see the comment authors, and many users/authors can view/comment on the same files. Abstract also notifies participants on comment activity to keep everyone in the loop.

  4. Conversation threads can be created to allow for more in-depth communication and can be expanded/collapsed for easy viewing.

I wouldn’t say Abstract is the answer, but it has made communication via annotations much easier! And per the original query, Abstract handles ‘The Look,’ while our team/project/client needs dictate the ‘Methodology for Annotation.’ Hope this provides some helpful insight! I too am looking for any advice or formal practice/training insights so I can keep improving my process…any feedback is welcome!

1 Like

I annotate anything interactive. Wireframes were around before all of the digital prototyping tools we have now. You need to annotate the various states of the interactive element. The wireframe layout should indicate placement and size of elements. I usually indicate various notes by using color or shape of the annotation number.

Dan M. Brown has some best practices in his various books and blog posts. The Balsamiq article has a good summary of best practices (I wrote it :grin:).

Hope that helps!

1 Like

Personally, I tend to use wireframes to start invalidating/validating solutions for a problem area in an application. The goal being to catch potential issues and get stakeholders really thinking through the approach rather than a design yet. Because of this, I tend to use annotations to highlight:

  • Hidden states of the UI/workflow that affect current wireframe: service X performed Y, 15 minute GCM notification
  • State of the user: Logged in, Added to admins
  • Consequences/benefits of workflow/feature, I won’t call it out as an issue, but if something has a cost to it I’ll annotate it: Custom iOS component required, alerts all teammates
  • Links to highly relevant research and data: analytics engagement report, Jira ticket tracking epic/problems, user research projects/nuggets

For tools, I use Balsamiq markup or UX-Map + Axure RP for simple annotations. UX-Map has a good example similar to how I used annotations, click the upper right hamburger to view annotations.

I like the idea of using Abstract for annotations + discussion. I use Google Docs for the discussion piece, it lacks the ability to highlight a single part of an image so I have to slice up my wireframes into smaller segments. I have seen Sketch+Zeplin used effectively as well for discussions.


1 Like

Phew, thanks everyone!
I’m going to refer back to this when I’m read to chew :slight_smile: