Kevin Cheng  

Getting Your Design Past the 36th Chamber of Engineers

November 19th, 2005 by Kevin Cheng :: see related comic

A couple of weeks ago, Jared Spool talked about screening for the right participants. One of the responses to the article mentioned that for some of us, the difficulty came even earlier in the process: convincing internal teams that it was beneficial to get any user testing at all. I don’t imagine Robby Slaughter is the only person in this situation, though I hope that by now, it’s become less and less of an issue. I thought it would be interesting to touch on one area of that which is getting your design to remain as intact as possible through the development process.

In software and web development I’ve found the best way to interact with both product managers and engineers has been to speak in their language. That is, integrate the UI process in such a way that the stakeholders can relate it to their own existing processes and documents.

I separate these into three primary deliverables/phases: the requirements, the specifications and the code review. I’m sure others can think of additional ways to effectively communicate their design and ensure its execution. These are the ones I’ve found have worked most consistently across almost any project.

### UI Requirements
The UI Requirements is the parallel to the Product Requirement Document (PRD). They’re created around the same time or very soon after. For the most part, this would be done by an interaction designer / information architect through wireframes. In many cases, describing what a product should do is difficult to do with words alone and it’s also difficult for the engineers to scope properly without consideration of the UI elements.

A requirement which states, “users must be able to view their archives” could be interpreted in many ways. A more detailed requirement with, “users can sort archives by date, title or rating” would be better but still can be implemented in many different ways - especially with the increasing popularity of rich interactions. Are we talking about dynamically sorted column headers? Creating a page for each of the sort criteria that the user can access? Graphs? These decisions are crucial to accurate scoping so they need to made early.

Creating a deck of wireframes which are closely tied with the requirements can help raise the issues of scope and feasibility nice and early. Engineers can look at the wireframes which might have annotations that reference specific areas of the requirements document (or vice versa) and then discuss the complexity with the designer so a compromise can be reached.

Typically, I put notes in each wireframe that point to specific section numbers in the product requirements. I’ve also found that putting unique identifiers on wireframes and then referencing them from the product requirements document has been immensely useful to the engineers as they can then refer to both concurrently as they develop. e.g., “users can sort archives by date, title or rating [WF112, WF113, WF114]”.

### UI Specifications
If there’s a visual designer in the team, this document would probably be prepared by that person. That’s assuming there is a team of designers rather than the one person show that’s rather common in smaller companies. The UI specifications is akin to the functional specifications engineers use. Most freelance designers and consultants are probably familiar with this - also referred to as a “style guide”.

The purpose of the document is the lay out detailed visual treatments. Some examples of things addressed by the UI specifications:
- When to use certain colours, fonts, sizes, borders, etc.
- What the controls and pages should look like
- Exact spacing of page elements
- When any given interaction piece should occur (if not already covered in the wireframes)

The specifications tend to be really specific to the point of being anal and this is quite deliberate - leave nothing to chance. It’s surprising how often I’ve assumed incorrectly that engineers will infer a patterns from my wireframes. I could blame the engineers for not seeing the obvious but perhaps it’s not obvious at all to anyone other than myself. The added benefit is that the specifications can be utilized by another designer in case the original designer is no longer on the team.

### The UI Code Review
Engineers have what they call code reviews (or code reads). In a code review, another engineer inspects a peer’s code as a sanity check and as an opportunity to give feedback. I have what I call a UI code review. It’s a bit of a misnomer because I don’t actually review the _code_ - just the UI.

Basically, I build enough of a relationship with the engineers such that a natural part of their process is to show off what they have thus far to me (once there’s anything on the front end to show). It’s pretty typical for a front end engineer to show peers when they have something visible working. All I’m asking is that I’m included in the “hey check this out” loop and I’ve never heard any complaints for such a request.

What this yields is a tight feedback loop as the UI is being developed so I can catch discrepancies early and often. Sometimes, it’s a misinterpretation of the requirements/specifications by the engineer and other times, I just wasn’t being as clear as I originally thought. Regardless, we see it happening well before beta or release crunch time, when issues like “that font is the wrong size” probably get pushed down and never fixed.

### Summary
The UI requirements tie in tightly with the product requirements and address development concerns early, the UI specifications plot out the detailed front end aspects and the UI code review is a QA process that ensures the requirements and specs are executed as intended. Through these three cornerstones, I’ve been able to mostly see a vision intact from start to finish. Of course, sometimes thing will inevitably get scoped out or modified due to unforeseen circumstances but that’s a problem not really unique to the interface so much as product development as a whole.

I hope this has been helpful for some of you. we have a wide range of readers in terms of skill set and experience so to some of you, this will seem like stating the obvious. If that’s the case, please do add your thoughts on how you go about maintaining your product vision and whether there are any similarities in your approaches.

Footnote: The title is in reference to a cult movie. If you know it, I salute you.

14 Responses to “Getting Your Design Past the 36th Chamber of Engineers”
Robby Slaughter wrote:

Whohoo, I’m famous!

What I probably should have really complained about when Mr. Spool was pontificating was that in my experience, most (software) product development teams lack *any process whatsoever*. The ideas described in both articles depend upon the explicit assumptions that (a) your team is fairly well organized and (b) within them, interface design is considered a material contribution, not just “making it look pretty”. In a decade of development, I’ve *almost never* seen one of these criteria, let alone both!

This problem is exacerbated by small groups (especially teams of one) or companies for whom software is not the core business. As an independent consultant, I’ve had more than one manager tell me that “software is black magic” and to “just make it work”. Incredulously, I have not been found success in responding to those statements using the logic of the usability practice.

Kevin, how do you mitigate your excellent advice above with the prevalance of what you’ve already mentioned—”manager centered design”? (

Jason wrote:

Why not just call it a UI review instead of a UI code review.

Glenda wrote:

Consider this shadowboxer saluted. ;)

Scott Berkun wrote:

I thought this summary was good - but it has the bittersweet scent of defensive design. That somehow if you make the right documents, or fill out the right forms things will go better. This can be true, but for every hour I have to spend making documents, I’d prefer to spend 45 minutes earning authority by talking to people. Maybe I can skip some docs altogether. In fact, I’d argue that the more documents a designer has to create, the less power in the organization they probably have.

If I’m depedent on programmers and marketers to bring my design into the product, I need influence chips. These docs might help me get involved in decisions, but there are other ways.

I mean, the goal isn’t to produce documents X, Y and Z - it’s to help the product through authority/influence over decisions. What if the marketing team agrees that all requirements must be approved by the UI designer? Or all code checkins? Would you need to produce as many documents if you were the approval path to all work? No way.

The more respect you have from marketers and programmers, the easier it is to influence them. The more value they see in your contributions, the less formal (and time consuming) the communication will be. So that’s the real goal: respect and influence.

So I’d start by saying to the requirements dude, on his terms: “Hey. I can help you make better requirements. Here’s why and how. How do I work with you to get the most value out of my skills?”. Same for programmers. They may have surprising things to tell you about how to influence them. If they don’t have any answers, wireframes and UI reviews are good defaults, but start with understanding and listening to the people you want to influence: they’re your users too.

Bob Baxley wrote:

One of the key benefits of UI specs and documentation — and the one that almost always gets overlooked — is that writing tends to enforce mental discipline and logical consistency.

When a design is communicated in conversation or even single page mocks, it is all too easy to avoid answering the hard questions or to ignore the weaknesses of the solution. As with so many other things, it is often the simple act of writing that illuminates problems and leads to more thoughtful, comprehensive, and appropriate solutions — solutions which in turn generates respect amongst our peers because they represent our best thinking.

Too often the arguments about design documentation focus on whether they are necessary communication artifacts when the real value is not how the specs help the rest of the team but rather how they help us as designers produce better work.

Writing is not the activity of recording what has already been thought through. Rather, writing * IS * the act of thinking things through.

Scott Berkun wrote:

(bows head at Master Baxley)

> Writing is not the activity of recording what
> has already been thought through. Rather,
> writing * IS * the act of thinking things
> through.

Sure, depending on who’s doing the writing :) I’m sure you’ve seen your share of “specs as intellectual black holes”. I see enough blogs and specs that clearly don’t contain any thinking - So writing *CAN* be the act of thinking things through, if the person doing it understands that’s part of the value.

I bet we agree on this: The value is the result, not the document. We don’t ship documents. If UI specs, wireframes or goose origami help, great. If “writing as design relfection exercise” helps you develop ideas, fantastic. But always focus on the results - which in the situations implied by this essay, involve dependence and influence on other people.

Bob Baxley wrote:

As always Master, the Truth finds its way to us through your Wisdom…

Agree that writing isn’t the ONLY way to think through this stuff but it is A way — a simple way and an accessible way. Assuming of course that the writer takes the exercise seriously.

Also agree that the spec is not the product anymore than the script is the movie. I’m sure you’ll agree however, that precious few great movies are made without scripts and it’s been my experience that great products rarely emerge from the chaos of conversation or the punctualism of single-page mocks.

Robby Slaughter wrote:

Woah. The Berkun-Baxely exchange is *so meta*.

Maybe I’m beating a dead horse here (and no, the article Mr. Spool referenced last time didn’t help), but I can’t even get people to *acknowledge* the value of process, much less debate it!

At this point in my career, I kind of think that all of the problems in designing products for other people relate to overfocusing on “what I want” and not enough on “what the user wants”. I spend a lot of time saying things like: “That’s an interesting idea, but until we actually study or talk to a real live user, we have no idea if its something they really want or could use.” This does not go over well.

Maybe what I’m asking is this: how do we get people to think about design with a even a sliver of objectivity? And, how mad am I making everbody by posing these pesky questions? ;-)

Scott Berkun wrote:

Robby: It gets back to authority and influence. If you don’t have authority over decisions, then you have to find ways to influence those that do.

You saying “how about talking to users” is the right thing to say - but if you’re in a world where they reject that sentiment, you have 4 choices: 1) earn more authority 2) become more influential/persuasive 3) accept your fate 4) leave.

For #2: Who is most receptive? How do you build that relationship and use their authority/influence to help you? It’s rarely easy or fun, but you have to build influence and authority over time and start with who’s receptive.

There’s a big list of tricks for gaining influence: showing video of users suffering at the hands of the last release, finding outside experts the team respects to come in and speak, hypnosis, martial arts, championing UCD on a small area (pilot) and making your case, ROI arguments, political power, persuasision, risk taking.. the list goes on. But the core of it is always authority and influence. If you have neither, the specs, wireframes, documents (and design talent) don’t matter. And the challenge here isn’t specific to design: consultants and experts of all kinds have the same challenge.

Paul Brown wrote:

“Look into my eyes, the eyes, don’t look around the eyes, the eyes … you’re under. Customers do not like whatever you tell them to like, no-one wants that feature and frankly, you’ve barely got any customers left anyway. Now, do some proper studies, read some books, read webcomics if you have to, but sort yourself out. Oh, yeah, and you owe me 20 quid. 3,2,1 … you’re back in the room.”

If only…

Moi wrote:

If it isn’t specified, it won’t get done, and if it isn’t written down it isn’t specified.

Quite simply, I don’t care how much “influence” you have, if I don’t remember it when I implement it then tough luck, I’ll do what I do happen to remember.

Ron Zeno wrote:

Paul Brown wrote:
“If only…”

If only what? If only that it could work and it was legal? If only that designers weren’t so incompetent that they wished for such powers?

Bob Salmon wrote:

UI designers c.f. developers reminds me of theoretical physicists c.f. experimental physicists. (Which is better? Answer: both of them.)

My dad did physics at college and told me about an experimenter who went back to the theorist who had asked him to do an experiment to test his theory -
E: This experiment would require more matter than there is in the Universe.
T: Well, can’t you make it out of lead or something?

Scott Sehlhorst wrote:

Could not agree more with your insight into speaking to others in their own language (or incorporating your work products into other people’s valuation-frameworks). Linked to you from my article here -

Leave a Reply

OK/Cancel is a comic strip collaboration co-written and co-illustrated by Kevin Cheng and Tom Chi. Our subject matter focuses on interfaces, good and bad and the people behind the industry of building interfaces - usability specialists, interaction designers, human-computer interaction (HCI) experts, industrial designers, etc. (Who Links Here) ?