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 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.

share|improve this question
add comment

3 Answers 3

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!

share|improve this answer
    
1) yes. 2) yes 2) YES! (Good answer!) –  DA01 Mar 12 at 17:25
add comment

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.

share|improve this answer
    
Based on my experience with an equally defensive development team that I've had to work with. –  Pdxd Mar 12 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. –  Richard Price Mar 12 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 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 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. –  Richard Price Mar 12 at 15:03
show 1 more comment

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.

share|improve this answer
add comment

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.