周五Joy：…那天去理发November 30th 杨掌柜
暉哥台中@ Moninet 讲述一件理发趣事，且听他慢慢道来：
我每個禮拜都會到髮廳去保養頭髮…昨天也不例外。
叮咚！
進來的一位客人…
大約在60歲穿著胸前寫有-八卦山-的花襯衫..大大的耳朵，灰白的頭髮，臉色非常的紅..看來是喝了點酒..坐在我的右邊位子…我們相視一笑….
設計師溫柔親切地問…`
設計師：大哥!你要怎麼剪啊?
那位大哥不講話，拿出皮夾緩緩的遞給設計師說：我要剪跟他一樣…
設計師接過照片…我從鏡子裡看見設計師的眼睛瞪的大大的….
設計師：你真的?要剪跟他一樣?
大哥(肯定)點頭：對！
設計師：那頭髮要全部染黑喔。
大哥：沒問題啊!我明天要參加活動。
大哥：我還要穿跟他一樣的衣服呢！（說完自己不好意思大笑了幾聲）
設計助理向設計師（貼耳）細語：大概是去參加ＣＯＳＰＬＡＹ(模仿秀)吧？
設計師：嗯~有可能。
設計師：眉毛也要修的跟照片一樣嗎？
大哥：眉毛也要修？那好~~也順便。
接下來工程開始進行了。
老伯開始睡起覺來。
鏡子裡~~我看見老伯的頭髮開始出現了造型。
設計師及助理的臉色變得越來越凝重。
於是到了染髮的階段了。
染成黑色以後，看著鏡子裡的老伯，剎時我有一種似曾相識的感覺。
眉毛也快修好了。
我看見助理在老伯後面雙手合十膜拜。
設計師邊修邊唸著阿彌佗佛。
音樂放起了大悲咒。
～南～無～觀～世～音～菩～薩～:
我視線模糊。
開始眼淚盈眶~是的!我受感動了。
鏡子前的老伯~~~不就是！
南無救苦救難觀世音菩薩嘛！（男版）
設計師最後在老伯頭上放了一朵紅色小花。
設計師╱助理：好了！
老伯緩緩地張開眼睛。
老伯：嚇！…….Ｘ！！這係啥小頭(台語)！
設計師拿起照片：跟這張照片一樣啊？
老伯：這樣哪有像馬英九！
設計師：馬英九？你拿給我們的是這張照片耶？
老伯拿出皮夾~卻發現馬市長的照片還在皮夾裡。
到底老伯給的照片是？
老伯搶回照片一看。照片~~~~阿彌佗佛!!!!!!!*
老伯：阿彌脫啦庫咧！！哇~~~拿錯張啦！
設計師╱助理：我們以為你明天要去ＣＯＳＰＬＡＹ(模仿秀)。
老伯：我明天要去參加孫子的畢業典禮啦！
老伯：這下子我怎麼去啦。
我：你可以去參加南洋大海嘯招魂的典? 均C＝＿＝|||
老伯（啜泣）：s眉毛妳們也剪了＞＜嗚~
我：柳葉眉。＝ ＝ 比馬英九帥多了。。。。
最後以半價送出了這位大佛出髮廳….
开心的同时，也顺便想想，这位理发师哪里出了问题，应该怎么做，你是不是也曾犯过同样的错误了？
作者：油茶研究会§User eXperience STUDY
Related Articles:
iworm
2007-11-30 8:47
确认和合同是避免此事的方法之一吧。加强沟通
xorms
2007-11-30 9:27
在糗事百科上看过这个笑话～
在和用户确定需求的时候只是口头确定，没有落实到纸面或其他有凭据的媒体上……
兔子
2007-11-30 15:46
呵呵,满有意思的故事,这个故事告诉我们出去理发不要带如来的照片.”要相信用户”和”不要相信用户”在逻辑上相互矛盾,但我认为在UX体系里他们并不相互矛盾.
paul
2007-11-30 17:47
中途这个大叔根本就不看自己头一下 最后才出结果了才看。
中期评估没有做好，设计师也不中途评估下。
Azure
2007-11-30 23:13
同意paul的说法。他把我的台词说了..
marsocean
2007-12-01 1:10
感觉山少了一步。
第一步是客户把需求给设计师
第二步应该是设计师从自己这个角度理解一遍需求，和客户再确认一次，例如问他“那么我们就把头发染黑，盘一个发髻……”:) 这一步好像没有：）
没叶草
2007-12-01 16:26
从笑话中都能找出设计师的职责问题，杨梅同志太敬业了。:-)
Azure
2007-12-01 22:44
to marsocean
很明显需求是说了的。皮夹就是需求说明.只是意外的是…需求说明书的封面写的是如来哥哥，而到了第二页话锋一转，其实。。咱是忽悠您呢。我要变身马大叔。。
少的是中期检查吧，确切的说其实整个过程应该是迭代的。
william
2007-12-03 10:11
不错不错，蛮搞笑的
cindy
2007-12-03 14:17
设计师的工作不仅要接收需求，确认需求，还要更主动去理解客户提出需求的初衷（是去参加孙子的毕业典礼，还是cosplay？），思考对于这个需求的目标有没有更好的设计解决方案（有比老伯提供的照片更适合毕业典礼的造型，拿出来讨论），实现过程中也是需要分阶段的对进展进行确认。设计师应该更多参与到产品中去吧。
jameguilin
2007-12-12 10:47
都是跟用户扯上关系了,生活嘛,就是要笑笑!
这个让我乐了!
asun
2007-12-21 22:03
软件也好，设计师也好，当觉察到用户异常的操作行为时，除非操作可撤销，否则最好是要加以确认。因为用户总是会犯错误的。