I am in need of a fairly robust way to communicate Element, Component (& scaffolding) design specs. to Engineering.

At this point they are in a defensive posture and are asking for deltas and every detail (dimensions, colors, strokes, states, behavior changes, etc.) about each element related to an as-built MVP.

What are others using these days to accomplish this form of communication ... other than heavily annotated screen shots and spreadsheet with 17 columns per element? I've considered Axure, but my source files are in Fireworks. Plus, I think I'd end up just writing out a long list of notes for each object anyway. We are in the middle of creating an online pattern library... I guess I was hoping we wouldn't need to document 5 states of every pixel in every element there, but maybe I should. Just thinking out loud.


I deal with this sort of resistance all the time. The answer is partially culture and partially tools. Here are a few tips that have helped me:

1) Keep reinforcing that waterfall methodology with perfect specs is dying for a reason.

2) In my experience, engineers typically don't read every spec anyway (maybe I'm crazy)

3) Try a more interactive and collaborative approach. I love prototyping and there are 101 ways to create really great prototypes that gets everyone on the same page at the same time. Here is a great article: http://uxdesign.smashingmagazine.com/2014/03/06/building-clickthrough-prototypes-to-support-participatory-design/

Here are a few tools that I use that are not nearly as expensive or have the learning curve of Axure (I think it's over kill for any kind of agile project IMO). I use balsamiq for quick sketch wireframes or even paper prototypes. There create some quick click models either in HTML, or there are a few great free/cheap tools for creating these that I love as well. Connect-a-sketch is free. Invision is amazing and is a small monthly subscription but is far easier and quicker than Axure. It's my #1 choice.

Good luck! Keep fighting the good fight!

  • 1) yes. 2) yes 2) YES! (Good answer!) – DA01 Mar 12 '14 at 17:25

Have you tried prototyping? Sometimes seeing and trying is easier than reading that 17 column 100 page doc, as you mentioned.

Styles and colours, on the other hand, because it's part of branding can definitely be documented in a quick-reference guide. From experience as a front end developer, this is something that's useful to have on hand.

Also, it's best to kickstart the communication with a kick-off meeting to walk the team through all the elements. This will ensure everything is clear and they know they can still contact you if they have questions.

Edits based on comments: Consider the "exploded view" idea by showcasing the same entire layout in different states.

Layer 1 - No interactions

Layer 2-4 - Rollovers that don't interfere with eachother

Layer n - Whatever the tertiary, quarternary, etc. interactions are.

I also overlay different cursors on top of the interactions so you can see what the cursor needs to be and what type of interaction it is.

You can easily frame this in your Fireworks/Photoshop Layers.

  • Based on my experience with an equally defensive development team that I've had to work with. – Pdxd Mar 12 '14 at 14:01
  • :) Yeah, I've tried prototyping. No, they can not and will not derive meaning from comps or live anything. Being very stubborn. They want precise specs on every facet of every element. The team meeting ship has sailed unfortunately. Yeah, I've been a dev too. I'm simply amazed that they are being so silly about this. Trying to play the political game and get the what they want. – Rich Price Mar 12 '14 at 14:31
  • Developers like knowing everything for MVP on a very precise level. Looks like there isn't much alternative to the dictionary-sized guide other than an exploded view of each mockup page. Likewise, if they are real sticklers, you have a page reference for each thing. The doc was heavily relied upon by the dev team I worked with as well. – Pdxd Mar 12 '14 at 15:01
  • The other thing to keep in mind is that politics will only go so far. If it starts effecting ROI and target deadlines, you have leverage to push back as everyone will be under the gun at that point. – Pdxd Mar 12 '14 at 15:02
  • Cool. Thanks for chatting this through. I was just brainstorming an exploded view. Say, have you seen any such views lately? Curious if I could borrow some tips from any that have been done... off to Google images. Amazingly nice source for UX deliverables examples these days. – Rich Price Mar 12 '14 at 15:03

The only two things I've found that work are:

  1. Development team has Front End Devs (FEDs) who are open to maintaining open comunication with the UX team to do iterative work via discussion as needed (Agile really helps here). UX sends over minimal documentation and discuss. FEDs begin building it out and loop in UX as questions arise and/or feedback is needed. This is the best way to do good product design, as now you are leveraging the collective expertise of UX and FEDs and you often end up with a solution much bigger and better than either team would have come up with on their own.

  2. UX develops either final presentation layer code or at least prototypes in JS/HTML/CSS. This is essentially the same as #1, except that the FEDs are now on the UX team.

Alas, many companies don't do either, and tend to use the "annotated screen shots and spreadsheet with 17 columns per element" and even then things tend to fall apart.

Tools like Axure are a mixed blessing. They can work great with the right team, they can get in the way with the wrong team. The biggest challenge with Axure type tools is that while they can create interactions, they tend to be interactions confined to the capabilities of the Axure tool and the person using it. So you can end up with apps that just fell like Axure. Sometimes this is better than nothing.

Another argument for proper prototyping in the native environment: No matter how much thinking you do, no matter how much documentation you do, there will always be edge cases in the interactions that don't make themselves apparent until you are actually clicking through the code.


All that you need is a good design handoff tool.

Design handoff takes place when requirements have been met and prototypes have been tested. The design is handed off to developers to start coding. It’s like a relay race, designers are about to finish their work and pass the baton to developers.

As designers and developers are trying to complete completely two different stages of product building. They don’t understand each other very well. Normally, designers don’t have too much perception about coding. At the same time, developers don’t have too much knowledge about the design process.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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