I'm working with our UX team to try and figure out a better way to communicate design ideas and interactions, to development, in our mockups.

Currently, we're essentially uploading two versions of our designs to a shared site between dev and UX/design. One version of the mockup has numbered annotations, which are then described in a numbered list to the side of the image. The second version is clean of annotations, simply for graphical presentation, which may eventually be used in documentation.

This is tedious. We have to create the numbered annotations. We have to export two images. We have to upload two images. We have to type out the annotations.

Is there a tool or separate approach that would make this process easier? Working prototypes aren't always an option, and flat images aren't always enough. Onion skinning helps, but that's further design work that must be done. Often times a description will suffice.

How can we make this process easier so we're not doubling our workload? If it's software, ideally it would be something we could embed into our already existing Wiki pages.

EDIT: After further consideration, it seems like what we need is some annotation software that is embeddable. Something like Bounce, but embeddable so that people don't have to visit a link to see our annotations.

  • What application(s) are you using to create your mockups?
    – wootcat
    Commented Oct 16, 2013 at 15:31
  • Fireworks and Illustrator. The mockups are then exported as PNGs and posted to a site that PM will reference for creating dev. stories. Devs will then reference these images as they are writing front-end code.
    – Jon
    Commented Oct 16, 2013 at 15:34

2 Answers 2


Finding the right output for the right audience is they key here. It'll depend on your organisation what works as there is definitely not on answer or solution. Using Fireworks and illustrator, for example, makes it harder to get to a prototyping stage compared to tools like Axure.

On a recent project we where experimenting with seeing how lean we could get our deliverables and I used a mid fidelity prototype (not pixel perfect but with graphics and colours in place) to communicate the interaction and how it would work with the stakeholders and team and we produced Photoshop final designs (PSDs) with minimal annotations in a companion PDF.

This method allowed us to get 90% to where we wanted without spending hours going through each detail and annotating it. We had remote developers and it was far quicker for the developers to talk to us each day via skype/online meeting tool. We could cover fine details and fix things that where not quite right that way in a few minutes. We where also available to fill in any gaps as they developed, answering if there should be a roll over state on a certain button etc.

As this project wasn't huge it worked well but the lessons I learnt where that there is no point annotating to a fine detail or creating large complicated documents as they take time and won't get referred to. Providing the big stuff is covered and there are UX people who are open and friendly and can talk through the small stuff or respond quickly then, regardless of if the developers are in the same room or on a different continent, the quality and speed of output can be maintained.

  • Does this work with SaaS applications where the interactions aren't always super obvious?
    – Jon
    Commented Oct 17, 2013 at 12:54
  • I would say this depends on the experience of the development team and the level of unique or unusual interactions you're defining. In general if something is not obvious then it makes sense for to define that interaction. This technique uses prototypes to explain complex behaviour (these need to be shown to developers to ensure understanding) and these are backed up by the lightly annotated 'jpgs' handed across in a PDF. The exact nature of you documents will be determined by the project you're working on. The aim is to get the level of communication 'just right' and not rely upon text. Commented Oct 18, 2013 at 11:05
  • Easier said than done. When your a vendor working for a big corporation ruled by high-rank managers and committees, you are often required, not requested, to provide your mockups annotated. You're in no position to educate them "let's get lean, and reduce documentation efforts". This is not always realistic.
    – Dvir Adler
    Commented Jan 22, 2015 at 17:59

This is tedious

Yep. It sure is.

And, sadly, is typical in a lot of organizations.

The solution, ideally, is to stop creating so much documentation. UX should be about improving things, not publishing copious amounts of PDFs that get sent to some lost vault inside of SharePoint. Frustratingly, UX teams--especially in large corporations--tend to be documentation teams more than anything.

Instead, create the wireframes to the fidelity that you (UX) need, and then share it with UX in some form of regular interactions. In an ideal world, your developers would be working side-by-side with UX. In a less ideal world, you can try having regular meetings where you help answer any questions on the fly. Akin to daily stand-up meetings in an Agile workflow.

The benefits of this is that you can immediately answer any questions that will inevitably arise. It also allows you (UX) to stay flexible as there are always things that pop-up in development that requires changes on the UX side. The less documentation you had up front, the less updates you need to make in all that documentations when these issues crop up.

Over time, you will realize that there are many parts of the wireframes that are getting reused. At this point, start building a pattern library. Over time, your pattern library will have a majority of the individual UI elements on any particular wireframe. This is where you can get more detailed in your documentation, as it's in a central location and completely re-usable.

  • Ah, but this assumes an in-house team. What about consultants?
    – erik_lev
    Commented Oct 17, 2013 at 6:38
  • The same 'ideal' solution still applies. The idea is to get teams working together more than they to reduce the amount of silo-ing of the process. That said, I do realize that it's an 'ideal' solution and that the realities of business often get in the way.
    – DA01
    Commented Oct 17, 2013 at 13:57
  • (Sorry, I have to repeat my comment on an essentially repeated answer) Easier said than done. When your a vendor working for a big corporation ruled by high-rank managers and committees, you are often required, not requested, to provide your mockups annotated. You're in no position to educate them "let's get lean, and reduce documentation efforts". This is not always realistic.
    – Dvir Adler
    Commented Jan 22, 2015 at 18:00
  • @DvirAdler I agree. It's always easier said than done. :/
    – DA01
    Commented Jan 22, 2015 at 19:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.