The Two.

Last week I was on trip in Redmond. We stayed in Fairfield Inn, a really nice hotel.

Everything was great, except I had some problem with the bath faucet. (Later, I found out one of my colleagues had same problem.)

The faucet looked like this:

(I should have taken a picture…)

It was very clear that the red dot stood for “Warm Water” and the blue one for “Cold Water”.

So, how do I get warm water?

I tried below operation but I failed. It didn’t move.

(This is so-called “User’s Model” *)

And I tried in the direction out of this page. I failed again.

I was very confused. Then I accidentially found it works like this:

(And this is so-called “Design Model” **)

It’s a very good sample that the design is to make it look better but less workable. And the user’s model cannot map to design model very well.

I would think to myself – DON’T HAVE THIS FAUCET IN YOUR SOFTWARE!

*,** – Please refer to the book “The Design Of Everyday Things”, which I was just re-reading on my flight.

I believe it’s a very common scene that 2 (or unfortunately more) program managers argue in a feature design meeting.

It’s more likely to happen in an early stage of feature design when everyone is not clear about how to implement the functionality. The discussion should be focus on setting the goals, target users, and the scenarios.

According to my experience, the arguements are often initiated by introducing unkown factors of the how: “If we can have Scotty SDK to beam my cup to the tea room… If Scotty SDK is not public to 3rd party, we’ll have to…” But what’s more important is how user’s needs get met in the scenario: “I want to get a cup of tea without going to the tea room in person as I’m on a conf call.” The scenario may go well by asking a Star Trek fan developer to do you a favor.

So the motto can be “No developers in this room” when having a feature discussion on early stage. Focus on how to meet user needs but not how to implement everything.

Of course I mean don’t think like coding the feature on the meeting, but we surely should involve the developers!

Spec is the tool for program managers to communicate with others – developers, test engineers, peer PMs, the remote team located on Mars, etc.

A spec is often started from a “Page-one” stage. On this stage, you’re answering some questions to yourself:

• What’s this feature?
• Why we bother to implement it?
• How to measure that we succefully done it?
• How the users will be using it?

I’m not experienced enough to make it a big topic but I want to share a tip which sometimes makes my spec look better:

When I look at my page-one spec over and over again, I would imagine that the spec is telling a story to a stranger. If the stranger gets the points, the spec is good. If not, the spec fails.

If it doesn’t feel real enough, I would try to explain to some guys not from a same team in the way I spec’ed. If they can understand, the spec works.

So this is my first Spec 101: Page one for strangers.

A very valuable learning from today’s Engineering conference is that when co-designing with your customers, don’t simply ask the stupid question of “what do you want us to design our software?” But observe their footprints of how they’re doing with their current pieces.

The words from the customers may inspire you for further innovation but the footprints are telling the truth where you can address the real issues.

I’d like to start the very first blog post with the mysterious button which bugged me for a while.

I saw this “DHB” button in the elevator of the hotel beside my office.

I was curious and asked my friends around but nobody knows what it means. (We’re in BEIJING and we speak Chinese…)

So I took a picture with my iPhone, and forgot about it later.

1 month ago, I went to the hotel for my wedding again, and the button showed up again. This time I asked the girl behind the reception desk and she told me this button is for emergency.

“OK, so nobody hits it?” I said.

“No.”

I believe nobody hits it but I don’t think it’s for alert.

So I googled it and found out yes it stands for “Door Hold Button”..

Then my points are:

1. In China, people hit the “Open” button to hold the door

2. Chinese people really don’t know what “DHB” means

3. The DHB button is really placed very well among other buttons that it looks neat

4. Nobody hits it

So the lesson learnt is – Don’t put any DHB button in your software.