現在基於scenario的設計已經被廣泛的應用到了各種產品設計中。大家發現，很多時候一個短小精悍的小故事往往比一大段枯燥的介紹更來的實在和有趣。但是在我的工作過程中，實在是見過不少非常糟糕的scenario，下面就是一個典型的例子：
Joe在Fortune 500公司上班。他的工作常常需要他查詢客戶的Snarfbladt資料。他發現Bladtblaster 2000能夠讓他在bladtblaster的網站上更快的獲得Snarfbladt的信息。這讓Joe非常高興。
這個scenario有什麼問題？簡單來說，全部。它其實算不上是一個scenario，而只是一個單薄又毫無營養的“廣告”，用來告訴某人：“OK，那裡有個客戶需要Snarfbladt的資料，所以別砍掉這個功能。”除開這個，這個scenario就沒什麼其他作用了。不幸的是，我見過的大部分scenario都跟上面這個例子差不多。
基於功能的設計 和 基於任務的設計
為了進一步了解問題的所在，我這裡先先簡單回顧下基於情景設計的歷史（scenario-based design）。在早期的軟件設計中，大部分公司的軟件都很給力。因此，同行之間經常會有“功能競賽”，比誰的軟件能做的事情更多，比誰的軟件附加功能更多。在那段時間，基於附加功能的設計（feature-based design）誕生並占了主導位置 — 哪家軟件公司的產品的feature列表越長，哪家公司就貌似越NB。
這個東西的弊端就在於，用戶的根本目的不是去使用這些功能，而是通過這些功能去完成不同的任務。所以，這些豐富的功能一開始貌似非常吸引人，但不久，用戶就發現其中很多的功能對於他們完成主要目標沒有任何幫助。因此，基於用戶任務的設計（task-based design）誕生了，用來幫助用戶更加快捷方便的完成他們的任務。
基於情景的設計
盡管基於任務的設計在一段時間內看上去挺不錯的，設計師們還是越來越感覺到了它的局限性，問題出在哪裡呢？因為在設計用戶體驗的過程中，“目標用戶群”這個概念越來越重要，然而基於任務的設計完全就沒有考慮這一塊！另外，基於任務的設計往往導致“設計師設計他們自己喜歡，而不是用戶喜愛的東西”。
好的設計需要在設計時候有一個清晰的思路：“這個產品是為誰設計的？”，“這個產品需要為這些人做什麼事，解決什麼問題？”。隨後，基於情景的設計（scenario-based design）才漸漸被引入進來。前文說了這麼久的scenario，到底什麼才是scenario呢？
一個情景（scenario）描述的是目標用戶怎樣在特定的環境裡完成特定的任務。
或者更簡潔一點：
情景 = 用戶 + 任務 + 環境
因此，scenario-based 和 task-based的最大區別是牽著專注於產品的用戶和使用環境。好的設計必須同時具備易用性和高的用戶滿意度。設計scenario瞄准的是用戶滿意度這一塊，而基於任務的設計大部分時間只能讓產品可用和易用而已。
因此，一套經過深思熟慮的scenario將對你的產品帶來極大幫助。如果你在設計過程中弄出來的新東西沒法跟你的scenario對上號，那你很可能是做錯了。
Scenario 分析
讓我們再回到文章開頭的scenario — 它到底有什麼問題？我們來逐字逐句的分析下。
Joe在Fortune 500公司上班。可以說這是用一種最沒意義的方式帶出用戶和他所處的工作環境。你從這句話中了解不到任何關於joe的具體信息，目標用戶並沒有被准確定義 — 他可以是任意人，處於任意地點，做任意事情。
他的工作常常需要他查詢客戶的Snarfbladt資料。還好，至少用戶目標被定義了。
他發現Bladtblaster 2000能夠讓他在bladtblaster的網站上更快的獲得Snarfbladt的信息。這就是那條“為什麼Joe需要這個功能”的廣告了。但是難道就沒有任何其他解決問題的方法了嗎？只此一條路？如果有其他途徑，你需要把他們放到scenario中，然後通過scenario說明Joe為什麼不選擇它們。
這讓Joe非常高興。這是一個典型的在寫Scenario時很容易犯的先入為主的錯誤，下面會詳細說說。
“這讓Joe非常高興”這句有什麼問題呢？
也許會顯得有點太鑽牛角尖了，但是用一個“高興”的用戶來為一個scenario結尾是一個大錯誤！為什麼？參考下Everett的“基於情景設計的原則”：
如果寫scenario的意義在於證明某個/某些功能是成功的，那顯然你並不是在做基於情景的設計（scenario-based design），你是在做基於功能的設計（feature-based design）！
使用scenario的目的不是為了“取悅”Joe，否則你直接給他他想要的功能不就得了。Scenario的目的是找出Joe為什麼高興，系統中的那一部分取悅了他。這一部分重要的信息必須要包含在scenario裡，遺憾的是它並沒有。總的來說，舉的這個例子，它名義上是基於情景的設計，實質上又回到了基於功能的設計的老路上。
改進後的新Scenario
Joe在一家大型公司的貨運部門工作，平均每天要負責200個包裹的簽收和發送工作。為了保持一個積極的工作態度，他經常加班，做一些額外的工作。
在做包裹的發送工作的時候，Joe常常需要查詢客戶的Snarfbladt資料。他發現Bladtblaster 2000能夠讓他在原理辦公室電腦的地方從bladtblaster的網站上輕松獲得Snarfbladt的信息。無論如何，他可以在簽收和發送貨物的時候使用它，只需要單手操作 — 大部分情況下都可以在3次點擊下完事。
可以看到，新的scenario更加豐滿。它並沒有告訴你“Joe很開心”，而是詳細的繪制了Joe的個人和工作情況。在此基礎之上，我們可以更加自信的捕捉那些會讓Joe高興和挫敗的部分，從而發展出新的，更加豐富客觀的Scenario。
本文編譯自唐卓，原文地址。