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 協商達成一致意見。鞋帶要打多緊纔算好? 打好的鞋帶能拖在地上麼?
第五, 描述主流的用戶/軟件交互步驟。
