Reality isn't Reality TV

A couple of days ago, I wrote a post on thisTangent about teamwork and Learning from Reality TV's Top Chef. There's something that Richard Blaise said in that episode that I've been thinking about:

"Tough lesson to learn on Top Chef, you know, is that the goal is to bend each challenge to your strength, not to totally change your style to the challenge."

I think that Richard is spot on -- for reality TV. And I have to say I'm surprised that many contestants, and not just on Top Chef, don't seem to know that. A lot seem to operate at the two extremes -- either trying to be perfect for the challenge itself, as if they have no style of their own, or ignoring parts of the challenge to suit their own style. Quite a few contestants have been sent home for one or the other of these offenses.

But, reality isn't reality TV, and this advice doesn't work so well when thinking about user interface challenges. Too often, we see the sin of user interface designs that are bent to the strength or knowledge of the designer, not the needs of the challenge. Windows UI foisted on the web. Web UI stuck in a Macintosh application. Computer UI foisted on phones and cars and remote controls. Unlike reality shows, UI designs last a lot longer than the end of the episode and you and your customers will be living with your mistakes for a long time.

Interviews are the closest that most UI designers will come to being on a reality show. I remember when I interviewed at Microsoft, one of the questions that I got was the "universal remote control" question. It's a classic question and, for all I know, there are still people at Microsoft asking it. And, just like on Top Chef, you've got 30 minutes to "wow" the judge and whatever you come up will be tossed. But I hate questions like this -- the candidates jump to conclusions and try to impress the judges by naming lots of potential features, rather than digging in and thinking about what challenge really means.

For the record, the closest I came to asking the "remote control" question when I was at Microsoft was the "better coke machine" question. In short: improve the coke machine -- tell me what you will do to make it better, how it will be better, and who will be better served by it. Notice the what, how, and who, which allows the candidate to define and focus on a smaller set of improvements, without thinking they need to come up with as many ideas as possible to impress me. I'm not interested in tricking the candidate -- I want to learn how they think and how they go about the design process.

If I were trying to paraphrase Richard, I would say that a UI designer needs to bend their strength to the challenge, not the other way around. If you're not sure what the challenge actually is, you need to figure it out. Usually, figuring out the challenge is the biggest task (and the most neglected task, too). And if the challenge requires an expertise that you don't have, learn it, rather than trying to redefine the challenge.