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?


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.

  • In order to understand this better it would be useful to define some terms. By art you mean visual design (fonts, colours, spacing and a degree of layout) and by design you mean interaction design (deciding which interaction methods are used at each step and how they respond to the user)? Does that mean you're doing more of an information architect role? That is defining the front end navigation and flow structure and overall functionality? I'll attempt to answer with those assumptions. Jun 29, 2013 at 13:30
  • @StewartDean Art would be font, colours, graphical decorations, small degree of spacing and layout, whereas the design would be grouping elements, general layout, behaviour etc, including usability considerations.
    – Nuoji
    Jun 29, 2013 at 19:46

4 Answers 4


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.


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)

  • Actually, I'm game designer and lead programmer. I'm pretty sure that (1) isn't the case, as I've deliberately tried to do as little visual design as possible. If (2) is the case, then I'm sure I should have at least gotten some questions about it, so 3 and/or 4 seem the likely main reason for my issues. I'd like to work on (2) - but how can I determine the right level of detail?
    – Nuoji
    Jun 29, 2013 at 20:04
  • @Nuoji Do you and the designers work for the same company? Or are you contracting this out to designers who are working with fixed budget?
    – Jung Lee
    Jun 29, 2013 at 20:39
  • Contracted to a freelancer working with a fixed budget (which, incidentally, was the way they wanted it - while I was quite ready to pay an hourly rate. I've also been willing to compensate for extra work that wasn't clearly communicated in the spec. So I'm not sure it's a clear-cut money issue)
    – Nuoji
    Jun 29, 2013 at 22:27
  • Sorry, ran out of space here, so I edited my post!
    – Jung Lee
    Jun 29, 2013 at 23:12

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!' ;)

  • Iterations are simpler with in-house competence, but that's not really the problem. The main issue is unnecessary iterations due to misunderstanding of what the UI documentation actually cover. If the are understood to be a layout guide, then we're going to have at least a few discussions back and forth for every screen because the initial pitch will conform too closely to the docs! Not to mention the room for usability improvements may appear limited to the designer.
    – Nuoji
    Jun 29, 2013 at 19:55
  • @Nuoji my opinion is that the UI designers should be influencing the UX design as much as the converse. Are the UI folks on board with the project from day one, or are they not brought it until the wireframes are finished? If the latter, that might be one area that can be improved.
    – DA01
    Jun 29, 2013 at 22:08
  • You have to realize that we need to outsource everything related to the UI. This means we can't contract someone unless we have some sort of specification they can estimate the work from - and the more detailed the spec - the better. Just finding a good freelancer to work with in the first place is an enormously time-consuming business, and extremely few competent people would want to waste time with you unless you come prepared. In a big company, with people employed full time, it's quite a different thing and very different rules apply.
    – Nuoji
    Jun 29, 2013 at 22:35
  • @Nuoji ahh! Outsourcing! Yes, that throws a monkey wrench into nearly every process. Unfortunately, with outsourcing, the solution is often copious amounts of documentation. The catch is that creating all that documentation eats up time and money too. So it may be cheaper in the long run to hire the freelancer on an hourly basis to 'consult' during the initial wireframing stage, at which point they would have an understanding of how you got there without the need for creating all the documentation to explain it.
    – DA01
    Jun 29, 2013 at 22:43
  • 1
    @Nuoji having been in both the UX and UI position in this situation, I can appreciate the problem you're facing. Wireframes are great, and in my opinion are required if you want to communicate to a UI designer. Your ordered list of the most important UI elements would also be helpful, as would a discussion about the wireframes when kicking off with the UI designer. It can be hard from a UI designer's perspective to know what is expected to live on from the wireframes and what is open to interpretation. Communication and early/often reviews with the UI designer are important. Jun 30, 2013 at 7:47

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.

  • How does that relate to my question? Our issue is that the design ends up adhering too close to the layout of our visual spec, even when the design clearly suffers from it, and despite us saying that the layout of the visual example needs improvement.
    – Nuoji
    Jun 29, 2013 at 13:11
  • @Nuoji, sorry I've misintepreted your question. I've just pointed that high fidelity sketch is itself a good specification and following formal steps as described in the article gives predictible good result. Now I've understand you probably meant visual design, i.e. elements' styling. Jun 29, 2013 at 14:58

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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