Best type of UI specifications for UI design?

Question

I've had some problems handing over specifications that were wireframe designs + explanation of elements, to UI designers/artists.

What tended to happen was that the first few screens created were indeed free interpretations of the loose wireframe spec, but as we got closer to the project mid-end, the designs tended to mirror the wireframe designs (which never were intended as actual layouts), leading to increasing amounts of iterations for each new screen.

This despite being very clear up front of the need of not only art but also design.

Recently, I was suggested that doing a wireframe in the first place might be the wrong approach. I was told I should create a hierarchy of elements for each screen and let the designer work from that.

My question is: Which type of specification is best in order to give the designer the best possible help creating a good UI with a great user experience?

Are there any sample documents out there that I could use as basis for my revised spec?

EDIT:

Clarification, this question is primarily about specifications for a contracted freelancer. Like DA01 says, it's best to work together from the start and keep iterating. However, in the case when you contract someone for the UI design, who might be on the other side of the world even, the rules tend to be quite different.

Answer 1

What is your role? Information architect? Business analyst?

Based on what you've said, I think one or more of the followings are happening:

1. You are extremely talented at producing optimal layouts and workflows, so the designers always end up reverting back to your design.

2. Your specification (which you said contains "wireframes + explanation of elements") does not contain sufficient use-case documents and high-level information for your designers to do their own workflow and task analysis.

3. Your designers do not have strong expertise in workflow and task analysis.

4. Other project management issues. (not enough time, lack of review, etc)

Whatever the culprit, the answer isn't to withhold the wireframes that you've created to the designers. You've created those wireframes, because it helped YOU work through problems. Those wireframes will be equally valuable to the designers. The challenge is, to create an environment for the designers that would enable them to do their own analysis. (see above 4 bullets)

After all, you are asking them to do more than just pure visual and interaction design.

---

Edit:

If it is a fixed price contract project, there is a lot of incentive for the designer to minimize the time he spends on your project by re-using what you give him as much as possible, especially on things like analysis that don't always yield tangible assets to show to client.

So you need to specifically ask for wireframes/workflows as separate deliverable. Doing this will also let you assess whether the designer has this particular skill-set. And by agreeing on wireframes/workflows that both of you can be happy with before moving onto visual design phase, you can avoid the problem of the designer reverting back to your design.

(However if your designer is passing on opportunity to make more money, then problem #3 is a good possibility too)

Answer 2

leading to increasing amounts of iterations

I think that's the best way. Iterate, iterate, iterate.

To make the process smoother, try to get the client/business, UX, UI design, IX design and UI development all working in parallel (bonus if you can get back-end dev on the same page as well).

When the entire team is working in parallel, it streamlines the process immensely vs. the waterfall-ish model of wireframes getting tossed to UI design which then gets tossed to UI dev which then gets tossed to the back end. That latter process leaves a lot of unknowns until the very end due to things being decided that affect other team members without their feedback and inevitably everyone is scrambling near the end to make adjustments that were missed early on.

In the end, what is 'best' is completely dependent on the particular team structures and business processes you have at your disposal. It's going to vary from project to project. I do think the more you can get people working in parallel, though, the smoother, in general, things will be.

Are there any sample documents out there that I could use as basis for my revised spec?

Related to the above, another challenge is that documentation during the design phase rarely streamlines the project timeline. The argument for iteration is that everyone is actually focused on the user experience being improved, and not focused on having to produce and maintain burdensome documentation.

Documentation is important, of course, but keep it as lean as you possibly can. A lot of specification communication can likely happen verbally. Have frequent meetings with the key teams listed above. Knock out revisions in code rather than in specification documents and things typically go much more smoothly.*

* with the huge caveat being that yes, I also completely realize that in some organizations...typically the bigger ones...all of what I said above may not be a pragmatic solution. Many organizations are still mired in waterfall/non-iterative development and throw additional hurdles into the mix such as outsourced development. In those situations, all I can offer is a huge 'good luck!' ;)

Answer 3

Sketching For Better Mobile Experiences could be very helpful for you.

In short, there are some stages while sketching:

1. Divergent sketching – brainstorming, the result are loose sketches
2. Convergent sketching – combining ideas, polishing the best one, detailed sketch as the result, could be used as spec and implemented as prototype
3. Creating UI flows, could be used as spec and implemented as prototype

Detailed steps of a typical sketching session could be found in the article. So sketch is good spec tool, just make it detailed enough.

Answer 4

This is dependent on the skill sets of those involved. It might be worth looking into Lean UX. Currently there's no one definition of it with even the recent book O'reilly book coming across as very sketch (http://shop.oreilly.com/product/0636920021827.do) but, in a nut shell, it is about ensuring that all team members are involved and have visibility of idea generation and that you are not reliant upon deliverables in order to communicate an idea. Detail specifications are very time consuming and, as you are experiencing, are difficult to maintain for long iterations or rapid quick iterations.

Daily short meetings each day in the morning (as used in Agile) are a good way to ensure communication, as is working in a war room (an idea that predates Lean UX by at least ten years) and using white boards as the origin and living place for some of the outputs of the process. I used a mixture of a spreadsheet with page status, a sitemap on a white board and a HTML wireframe for a project for Boots in the UK in 2000. The designs where attached to the HTML pages with a link and the content strategist could put copy in situ on the wireframes - the developers then used all this to create a final version of the site, although there where less heavy interactions back then compared to sites today.

All this depends on the nature and location of the team members. In short if the specification is failing, see what you can take out of it and see where you can turn paper communications into face to face (or 'high bandwidth' as I've heard it called) communications.