I am working on a big m-commerce project and trying to apply the principles of lean UX within my team. Unfortunately I am limited by the fact that the development team are not co-located with the designers and as much as I try to create weekly interactions they have expressed a preference for receiving a spec at the end of each sprint to work from.

I've been looking at ways to create a spec which minimises the amount of work that goes into this document without compromising the success of the project.

We are currently using Axure to lay wireframes, designs and annotations on interactions and all. We then create a PDF that we print for the developers. We find this to be really time consuming and ineffective as whenever there's a change to design or UX we have to re-create this document, print and etc.

Has anyone tried a different way of doing this? Ideally we would like to be able to have an online Wiki with the spec which is a living document that can be accessed by all, modified in real time and circulated to non co-located teams with ease?

Anyone has experience the same situation and has some insights?

  • 3
    " Ideally we would like to be able to have an online Wiki with the spec which is a living document that can be accessed by all, modified in real time and circulated to non co-located teams with ease?" - Why can't you use this approach then? It sounds ideal really. Don't create PDFs for everyone, give them a URL or something to the document and they can print it themselves if they want to.
    – JonW
    May 23, 2013 at 9:04
  • Consider switching to Confluence or just a plain Google doc, which you can share with them and discuss in the document's context. Just insert you wireframes in jpeg format as images. Bonus points: switch to Balsamiq and user their plug-in for either Confluence or Google Drive. May 23, 2013 at 9:32
  • You can either choose a tool that allows a more effective collaboration/sharing process, or get the devs involved in some of the design process so that you don't have to explain everything to them because they will understand the general principles and guidelines and then they can interpret a more static guide without exact details.
    – Michael Lai
    May 27, 2013 at 22:19

5 Answers 5


For the "Lean" part of this: dividing the design documentation into:

  1. Style Guide - Always up to date
  2. Individual Designs - Not kept up to date after they have served their purpose.

Wiki or Confluence is great for documentation since you can link from the designs to the Style Guide (and also in the case of using Confluence and Jira, link development tickets to designs directly)

If the dev team does a daily Scrum meeting, perhaps calling in over Skype, if it works for the team.

  • I have always advocated for the separation of design principles/rationale/strategy and implementation, because one will change more often (at least in theory) than the other, and coupling them too tightly together means that you create more work for yourself than you need to.
    – Michael Lai
    May 27, 2013 at 22:17

If you're using Axure, then you already have access to publish to Axure Share. The annotations and notes are still readily available on the page and anyone can access it at any time. When you update the wires and republish, it uses the same url - so it a bit like a living document.

I use this all the time and it's incredibly useful for sharing ideas/specs between teams. Note that you should be very clear about what you change from publish to publish. You can include this in page notes or whatever way is best for communication between your groups.

  • AxShare has been one feature that has let me warm up to Axure. It really is a good feature for distributed teams and has the bonus that it's not versioned (which sounds bad, but is actually good in that it helps emphasize that the UI is going to be fluid and changing constantly, so don't look at some outdated PDF)
    – DA01
    May 23, 2013 at 15:36

online Wiki with the spec

Look into using a 'component library'. They take time to set up initially, but can streamline projects down the road. The idea is to document individual elements. For instance, you may have a design pattern for a search field. You'd describe this pattern in the component library, add some visuals, and, ideally, maybe even have some sample presentation layer code. You then name/number this element and then reference that within your wireframes.

Anyone has experience the same situation and has some insights?

Yep. All the time. This is still (sadly) the 'norm' in corporate life. Corporate project management and development is still deeply tangled in waterfall methodologies. To them, 'agile' just means 'quicker waterfall' and as such, it becomes a document heavy system. Partly to CYA, but partly just because of stubbornness.

I have no magic solution other than to push back. Push, push, push and keep pushing. Some things we have done:

  • use 'sketchy' mode in Axure and show to developers early on. Insist they come to reviews so that they can help formulate the solution as it's being created. This puts more onus on them earlier than later.
  • Annotate in Axure (just add notes to the page directly). Insist that that is where you will put project notes and will not be making piles of other documents.
  • Avoid sign-off processes. That's another hold over from the waterfall days when there was a belief that design is 'done' at a certain point and then it's built. This is never true, and, as such, the concept of 'sign off' is antiquated.
  • Insist that UX/UI folks review progress with developers. Having a UI person pointing out UI issues before actual testing can save a ton of time and headache (especially since testing teams rarely have an eye towards UI)
  • Work on the Component Library.

I wish you luck. ;)

  • Thank you all for your feedback. We are currently playing with confluence and balsamiq plug-in for annotations. We went down the google site creation but it doesn't lent itself to versioning and marking which is no good.
    – Ana Monzon
    Jun 21, 2013 at 11:02
  • We have also created a style guide and a component library which will grow throughout the life cycle of the project. We are still undecided as to what to commit to but will keep you updated. Thank you very much to all for sharing your knowledge and experience.
    – Ana Monzon
    Jun 21, 2013 at 11:04

A recent trial project I've been working on I've been created mid level fidelity prototypes using Axure and then sharing via Axshare. This has allowed me to get quite far into the specification without need much written down. This is helped by daily stand ups. Then, when we get nearer the end, I get the designs created (in PSDs, not ideal but that's the way the team works) and then I create a PDF with minimal annotations for each of the screens. As someone who has created very detailed specifications in the past it feels ad hoc but, oddly, it works. All these are shared via drop box (base camp would be better in my view).

There is a system with stories on it but, in my experience, wikis etc tend to not get read. The few words and documents the more likely something gets built in the right way. Also daily meetings are vital to keep the pace of a project. The developers are working using agile and I'm doing a kind of version of lean. UX lies outside of the agile process and feeds the sprint (effectively supplementing the backlog). Don't try to run UX in sprint - that way lies madness.

This method you'll also discover gaps as the specification is not exhaustive, this is fine as these can be solved in a 'just in time' way providing the overall story is solid and major parts of functionality have been well thought out.

It's really about providing the right amount of information at the right time and not being scared of starting to build without having covered very single little detail.


"create PDF that we print for the developers..."

Why would one use Axure then? This is like using a machine gun to kill ants. Axure is good for demonstrating interactions which can't be achieved with a PDF or print.

When looking at how developers work it becomes clear that there is so much more than just drawing the UI, at least if it's not a relatively static site or app they're asked to develop.

Some problems with using just a clickable prototype are

  • user flow not clear (or corner cases easy to miss)
  • important interaction/functionality is easy to overlook
  • little feeling for "completed" the task
  • complicated and time consuming to demonstrate data input/output error handling

That said, the minimum set that should be provided to ensure you get what you ask for is

  • a flow chart of the user flow including main interaction/purpose of each screen (will also give a good overview of the project scope)
  • detailed description of the interactions on each screen
  • wireframes, or, even better, a clickable prototype
  • design details & assets (PSDs, CSS, logos etc.)

The tool for this is almost secondary. It helps if it's a tool that runs in every environment (i.e. web based preferred) and maybe supports existing logins (Google login for Google docs as an example). The lower the barrier is to use the tool the bet

"a living document that can be accessed by all, modified in real time and circulated..."

There needs to be some stability for development. You don't want to change things all the time because this will more often than not waste a lot of development time and lead to frustration. But maybe that was their experience or that's what they're afraid of and maybe that's why they (think) they like specs.

Often an open and honest conversation about the reasons behind the request for a spec or specific format helps to understand, address concerns and find alternative solutions.

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.