When designing for complex applications, what is the best practice in communicating to the development team the various states / conditions of every element within the application.

For example, in designing an email client such as Outlook, details such as how attachments are displayed, if a message is flagged as important, or if the message is part of an existing chain of messages, etc.

With these various states and dependencies I feel wire-framing and simple prototyping into an application such as Invision or Marvel cannot communicate granular level details.

Do I need to look into UML diagraming? What is best practice for a project of this complexity when transitioning from prototyping to development?


2 Answers 2


It depends if you are working agile or waterfall or somewhere in between.

If you have a tight team with great communication between you, then it will work. So long as you are discussing detail at a granular level, and making sure it is implemented the way you envisaged, it will work.

Document until it stops saving you time

If you're separated geographically, highly waterfall, have an inexperienced team or any of the many non-perfect envionments that we all work in, you could try something like this:

enter image description here

This is in Axure, and it applies Unique IDs to every element. Content is tracked on a spreadsheet against the UIDs. The wireframes have UIDs that are referred to in the use-cases and test-cases. Every interaction has its own example, in the form of a wireframe.


There are many ways to communicate your design to development, and while there are some design tools that can speed things up a little by allowing you to quickly create a working clickable prototype as well generating documentation (Axure does this), you can also communicate design "old skool" using nothing more than a white board, a marker and your voice, or pieces of paper with the design drawn on it plus your voice talking through the flows.

You chose of design approach will depend on many things, e.g.

  • Time to communicate the design (limited time vs lots of time to experiment)
  • Time to learn a tool (some tools are easy to learn while other take a lot longer to master
  • Budget to buy a tool (if there isn't a budget your choices are limited)
  • Location of the development team (co-located or distributed)
  • The skills of the development team (Expert UI developers or generalist engineers who think they understand how html works)
  • The development methodology (Agile, waterfall or hybrid of the two)
  • The type of software company (Agency, Small startup, Large software company)
  • The size of user experience team (UX Team of 1, Team of many UX Designers)
  • Stakeholder approach (hands on managing everything or hands off letting experts do their job

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.