Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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.

share|improve this question
    
What application(s) are you using to create your mockups? –  wootcat Oct 16 '13 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 Oct 16 '13 at 15:34

3 Answers 3

up vote 0 down vote accepted

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.

share|improve this answer
    
Does this work with SaaS applications where the interactions aren't always super obvious? –  Jon Oct 17 '13 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. –  Stewart Dean Oct 18 '13 at 11:05

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.

share|improve this answer
    
Ah, but this assumes an in-house team. What about consultants? –  usingtheinternet Oct 17 '13 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 Oct 17 '13 at 13:57

Axure can generate a separate specifications document to accompany your prototype. In addition, changing the annotation order is automatic in Axure. If annotation 5 is now number 7, Axure will automatically renumber the other annotations appropriately. In addition, annotations are accessible inline via the generated prototype.

share|improve this answer
    
This is true. However, annotating in Axure can be quite tedious. And because it's somewhat hidden in tool pallets, I've found that when there are multiple people working on the Axure project, things get updated but the annotations do not, leaving things out of sync. So just be wary of that. –  DA01 Oct 17 '13 at 5:15
    
Sounds like they weren't very detail-oriented if they missed the ability annotate a wireframe! –  usingtheinternet Oct 17 '13 at 6:37
    
I wouldn't say that (though do argue that wireframes shouldn't be overly detailed) as much as that even though it's in Axure, it's still this separate bit of documentation that everyone has to remember to keep in sync every time they change the wireframe. Not impossible, of course, just something to watch for. –  DA01 Oct 17 '13 at 13:58

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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