Kevin Fox is a user-experience designer who worked on the mail and calendar apps that that little company down in Mountain View puts out, before leaving to join FriendFeed last year. In a lengthy interview with Google Blogoscoped published earlier this month, he made the following remark:

[D]esign is really a collaborative process and even when there’s a single UI designer or experience designer on the project, a big part of their job is synthesizing the ideas and desires of the rest of the team.

Fox is exactly right. In fact, I’d say that the process of identifying, understanding, organizing, editing, and synthesizing what an interactive development team comes up with is where experienced UX designers add the most value.

The question is, how can a firm help user-experience specialists to fully inhabit that crucial role? And how does he or she deliver on that?

Unfortunately, it’s still common for the user-experience specialist’s role to be confined to the beginning of the development process. He or she works with a client or other stakeholder to understand their needs and desires, and then translates that understanding into an impressive number of documents–user flows, wireframes, etc.–that the rest of the team is meant to follow. It’s the well-known top-down approach, and like an architect designing a new building, the UXD is supposed to have accounted for every detail. Unlike an architect, however, who continues to be involved (and at a very deep level) throughout the building process, the user-experience designer isn’t typically allowed much of a role once his or her documentation is handed to the next person in the development chain.

What can be done differently

Over the last decade I’ve started to develop an alternate approach. It’s not for every organization or every user-experience specialist, but it has led to some great successes even when implemented only partially. It’s easiest to describe as a series of steps or instructions I’d give to a UX designer or information architect who’s looking to really harness the power of the principles we value at Hex15, particularly improvisation and iterative design.

1. You organize. As part of the project kickoff, or immediately thereafter, you (the user-experience specialist) assemble the project team and get a brainstorming session going. There’s whiteboards, colored pens, sticky notes, squeeze toys, free food, recording equipment, and anything else that gets people’s minds loose. You’re not doing UXD at this point: you’re facilitating, interrogating, coaching. The goal here is to get every idea out on paper, on camera, on tape.
2. You observe. If you can get 5-to-10 customers in front of you to do something–anything–that’s relevant to your product, you’ve just improved your chances of coming up with a successful design by roughly an order of magnitude. Figuring out what those users should be asked to do to grant you those magnificent insights is the tricky part, of course, but an insightful user-study provides the biggest bang for your user-experience buck, period.
3. You sketch. Take the output of that brainstorm and combine it with the expertise, experience, and knowledge you’ve developed over several years of doing this kind of thing (almost 10 in my case). What’s important here is to let it all stew for a couple days before you put pen to paper. It’s also important not to think systematically yet. Make a first stab at one or more key parts of the project: a registration form, or the video-upload tool, or a search results page: whatever seems important and/or interesting. Do one version, let it sit for a day or two, then do another from scratch. Compare the two; see what makes sense, and what falls away. Repeat. And then stop for a while.
4. You discuss. Now you take whatever you’ve come up with (in rough form) to the various team members and (if you’re feeling cocky) the client–not all at once, but individually. The idea here is to get different folks’ perspectives on the filtering and editing and synthesizing process you’ve done, as shown in your sketches. This is an informal process, and could go through several iterations of its own before you come up with something suitable for a group presentation.
5. You document. But not like crazy. Create the right amount of documentation to show the team (first) and the client (soon thereafter). What’s the right amount? Maybe it’s the sketches, maybe it’s a comic-strip or a set of flowcharts, maybe it’s a Flash prototype–it really depends on the job at hand. I like what can be achieved by layering several kinds of media to tell a story, so I often combine them. Because that’s what you’re doing at this point: telling a story. Because you want the whole team to agree on the approach you’ve arrived at by synthesizing your ideas with theirs with the latest usability research and the user studies you did. (You did do some user studies, right?)
6. You deliver. Hand over your documents with as much or as little annotation as necessary to get the next group working. It doesn’t have to be perfectly documented–why spend 3 weeks creating a set of wireframes that will take only 3 days to turn into code? That’s just backwards. Produce enough to keep the visual designers, copy writers, and developers on your team moving forward for a week or so.
7. You follow-up. Provide only enough for those other folks to get working because you don’t want to get too far ahead of them. The feedback they’ll provide as they work will be useful in informing the next round of detail you give them. And it’ll help you understand for future projects how they (not just they, but the other people in those roles too) think about what they do, meaning you have an even better idea of what they need.

Repeat any or all of these steps as necessary – particularly the last few. In certain development methodologies, you deliver a chunk of code that works and almost immediately start hacking away at it to make it better. Whether you call that refactoring or kaizen, you do as much of it as the schedule–and the rest of team–allow you to. Because it works.

What about your portfolio?

Sure, it won’t be easy to find a binder that’ll hold both the giant sticky notes and the little cocktail-napkin sketches, or the evidence of refactoring that got a process and an experience just right.

Really, though, the things that stand out in your work history are the things that have succeeded. I’d rather point to a sheaf of pencil sketches documenting the thinking behind a registration process that was responsible for a 30% increase in sign-ups than any number of meticulously crafted wireframes that didn’t move the needle at all. Wouldn’t you?