1. 討論：下面的老板犯了什么錯誤?
只看用戶的表面語言或行動還是不夠的。我們還要找到用戶語言行動背后的動機!
(圖像來源: http://www.weibo.com/funnyshoelace)
2. 是否要文檔
有人說，我們敏捷的團隊，就喜歡直接的面對面的交流，不喜歡搞文檔什么的，多好！
其實大多數情況下，留下文字說明是很有好處的，相對於后來的浪費和返工，當初花的時間真的是太值了。看下面的例子:
自習課時，教務主任匆匆走進來，告訴班長“幫我找兩個人，我要班花”，同時兩手在胸前做了一個抱花的動作，就走了。班長就組織全班投票評選起班花來，鬧了一節課，搞了一些大數據，終於統一了意見，選出了班里最漂亮的兩個MM。於是倆MM很羞澀的去找主任，主任說：“怎么是你們？男生都哪兒去了？好吧，跟我去后勤，我要搬花……”
可見，面對面直接的交流當然很敏捷, 但是還是要留下文檔, 以明確用戶的需求。
3. ATM操作界面的用戶
團隊要設計一個銀行自動櫃員機 (ATM) 的操作界面, 這個櫃員機擺在銀行營業廳的外面。你覺得會有多少種用戶來使用你的操作界面?
（提示：多於5種用戶類型）
4. 練習：
你想寫一個游戲，你知道游戲用戶有哪些種類么?
參考答案：有些公司根據玩家游戲生命周期特點來划分玩家類型：
- 重度發燒友 (hard core) 玩家根據游戲安排日程
- 中度發燒玩家根據日常生活計划安排游戲時間
- 休閑玩家只在剛好有空的時候，才考慮以游戲作為消遣
這些定義很實用，因為它使我們明確了玩家對游戲的期待是什么。對於休閑的用戶，你的游戲就不宜要求用戶在開始游戲之前必須完成詳細的注冊或練習階段。
5. 別做過頭
場景驅動 (scenario driven) 的設計做過了頭會是什么情況？一天，大家在討論“吳小石頭上貨”這一場景時，二柱叫到：“停，別忙了，我有了場景！”他從桌子底下抽出一個模型，上面擺着用紙糊起來的房子、院子等，中間有幾個人形的木頭疙瘩，他指着其中一個木頭疙瘩說，“這就是吳小石頭，我們問他怎么做就行了！”
在你的項目中有做過頭的情況么?
5. Spec 寫作練習
怎么才能寫好Spec？其實也不難，就是要把一件事情描述清楚，下面是一個練習：
如果你要給一個外星人描述怎么系鞋帶, 寫一個 “系鞋帶“ 的spec （用英語）, 你怎么寫?
第一, 我們要定義好相關的概念
—what is “shoe”, “shoe laces”, “tied shoe laces”, and “untied shoe laces” 鞋, 鞋帶, 系鞋帶, 解鞋帶都是什么概念
—Benefit of this feature “tie your shoe laces”。 系好鞋帶的好處是什么
—The goal of the feature? 系鞋帶的目標是什么?
—What does “success” look like? 什么叫系好了?
—Unambiguous steps to achieve from “untied” to “tied” 明確的步驟來演示系鞋帶的過程
第二, 規范好一些假設 （assumptions）, 例如, 鞋帶是已經穿好在鞋上的么? 什么樣的鞋屬於我們要處理的?
第三, 避免一些誤解， 下面這個從技術上也是 ”鞋帶綁緊了“, 但它是 “系好了”么? 打了死結算成功么? 要打多少個蝴蝶結才算好?
第四, 厘清一些邊界條件, 下面的情況屬於好的系鞋帶狀態呢, 還是不好的狀態呢？ 這需要PM/Dev/Test 協商達成一致意見。鞋帶要打多緊才算好? 打好的鞋帶能拖在地上么?
第五, 描述主流的用戶/軟件交互步驟。
