The Two.

下面这幅漫画，来自我在排练室发现的一管万能胶水的包装。

仔细看有几个亮点：

• 那个小朋友喊“妈呀”的时候，吓得尿了一地。
• 小朋友赞叹“不可思议的胶水！”时，似乎脚还踩在尿里。

我大胆的猜测是，设计这幅漫画的设计师被客户搞得极为不爽于是非常有爱地埋了亮点。

所以，不要惹毛设计师！

Devil is on the Space Bar, too.

[Placeholder]

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!

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.