Composing a User eXperience framework made of findings, constraints, requirements, designs, personas, ... is one thing.

How do you communicate it at best with development team? How do you make your users present to developers mind?

2 Answers 2



I'll show you two extremeties, a bit exaggerated, but I'll hope you'll find some useful advices.

Stereotype 1:

If they're agile-maniac geeks, also in love with the latest fad (spring, scala, whatever), but no understanding of ordinary humans, it's likely that they won't do program design.

In this case, usually UX does program design, so a full platform-independent "spec" down to the last bolt, the last pixel, including complete flows, with all the alternative paths and a coherently maintained data-design.

Software is an engineering product. It's made to solve everyday problems to a community of human beings by the use of scientific advances.

This is what connects the office building you're living in, the bridge you crossed on the way to work, the watertap you opened to wash your teeth (and the pipe system beneath it), the vehicle you were using (unless you were walking), and the webapp / mobile app / whatever you're building right now.

These things were designed before constructed in the last 2100 years.

These kind of programmers need detailed screen-to-screen designs, based on scenarios, with all the alternative flows.

Format of a design document:

  • Flow diagram of screens, with main flow highlighted, entry points and preconditions clearly stated. It also acts as a table of contents for the documnent.
  • All the possible states of the screen, one after the other, in the order of the main flow.

Make sure you make no mistakes: if you draw something one pixel off, they'll implement it one pixel off.

If you have a knowledge of information architecture, it's not a bad idea to provide class diagrams. Some UXers even provide flowcharts of the algorithms.

Don't provide additional fluff: just bring what needs to be typed in to the computer. They hate to read long documents, it doesn't matter that it's full of diagrams. Yet anything you miss out likely won't be typed in...

Stereotype 2:

If they have a great understanding that programming is not about their latest tech, and that there are humans who don't care about their tech stuff, but have a real problem instead, which they happen to solve with the aid of computers, then usually, design patterns and anti-patterns is enough, sometimes with scenarios.

These kind of people want creative freedom, and want to understand what they're doing, want to be a part of the design process. They need creative direction, perhaps usability correction, but you always need to provide the reason on why you ask to do things in certain ways.

For these, I usually let them do what they come up with first, perhaps talk about the feature on paper, without finished lines or proper documents, as I don't want to force them really on either direction, they hate that.

Then when they feel they're finished with the first implementation, I come back, check what they did, and tell them if something is problematic from a usability perspective. I collect recurring problems in the form of "rules of thumb" or "antipatterns" (never using their mistakes as examples!) so that the dev team can clear these up next time on their own.

For them, your role is twofold:

  • you're the primary person to act as a 'stupid user': they might ask you to test the system, and you'll have to tell them which are the parts a most idiotic user won't understand.
  • you're the usability architect, in knowledge on how human psychology works, like, what is needed to make an intuitive interface.

The reason is always important. No matter what you say, always say this way: "I want you to do this, because / we know of our users that / on our user testing it was shown that / studies have shown / we expect our users to".

For them, I collect design pattern libraries: a design pattern is about a certain problem and recommendations (without actual widgets) on how to solve them. Let them browse it, and assemble the application on their own. Check the finished results of course, but let them do the groundwork based on the personas, perhaps the scenarios.

(Yes, do show them your personas, and tell a little short scenario for each new feature! If change requests are backed up by real user strugglings, that's great!)

If you can't tell why it's important to do something this way, either do research, and come back with results, or at least show a design alternative and ask for their opinion. This comes handy in terms of visual design and layout. "I think this layout looks less cluttered, what do you say?" Visual design is an art, you can't have always exact reasonings, and that's totally fine as long as it looks great :)

Some of these programmers will be familiar with UX, as they read about it as a hobby. In fact, most of the really top-notch guys I've worked with are really aware of usability issues and they've read a few HCI books.

For both:

No matter which kind of programmers you're working with, as they know the system they develop inside-out, it's likely that they won't see when something is ambigous or technical. Simply when they see a form they've built, they ultimately see its backend code as well. If there's an error, they know (or think to know) what the underlying problem is, and it's really hard to act like you're not aware of the backside. You can't help it...

Also, programmers can remember lots of things: simply it's needed for their job. If you're working with a senior developer, it's likely that he has better short-term memory than an average person, simply because (s)he needs to remember multiple levels of context while working. I'm not saying that they do remember what they ate for breakfast, but if they don't remember what they were trying to achieve in the middle of the code, there'll be problems.

And one more things: the two styles don't match. Some devs like the former, some the latter, but neither method works with both of them.

  • Thanks a lot for this detailed answer. Coming from and working in an agile environment, the stereotype 2 is more likely to have my voice. Could you detail a little more about those design pattern libraries? Commented Aug 29, 2012 at 19:03
  • Good answer! Stereotype 2 is what I would prefer to work with, but stereotype 1 is what I often come across. One extra tip: be patient with your developers. They have the same goal as you: making the product a succes. Only from a different viewpoint maybe.
    – GWv
    Commented May 23, 2014 at 8:46

Involve them in the process.

If they care about it, then the information will be relevant to them in their own way. If they don't care for it, then it doesn't matter how the information is presented to them - they'll just want the specs to build to the requirements.

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.