現(xiàn)在基于scenario的設計已經(jīng)被廣泛的應用到了各種產(chǎn)品設計中，

前微軟項目經(jīng)理：怎樣設計一個像樣的方案

。大家發(fā)現(xiàn)，很多時候一個短小精悍的小故事往往比一大段枯燥的介紹更來的實在和有趣。但是在我的工作過程中，實在是見過不少非常糟糕的scenario，下面就是一個典型的例子：

　　Joe在Fortune 500公司上班。他的工作常常需要他查詢客戶的Snarfbladt資料。他發(fā)現(xiàn)Bladtblaster 2000能夠讓他在bladtblaster的網(wǎng)站上更快的獲得Snarfbladt的信息。這讓Joe非常高興。

　　這個scenario有什么問題?簡單來說，全部。它其實算不上是一個scenario，而只是一個單薄又毫無營養(yǎng)的“廣告”，用來告訴某人：“OK，那里有個客戶需要Snarfbladt的資料，所以別砍掉這個功能。”除開這個，這個scenario就沒什么其他作用了。不幸的是，我見過的大部分scenario都跟上面這個例子差不多。

　　基于功能的設計 和 基于任務的設計

　　為了進一步了解問題的所在，我這里先先簡單回顧下基于情景設計的歷史(scenario-based design)。在早期的軟件設計中，大部分公司的軟件都很給力。因此，同行之間經(jīng)常會有“功能競賽”，比誰的軟件能做的事情更多，比誰的軟件附加功能更多。在那段時間，基于附加功能的設計(feature-based design)誕生并占了主導位置 — 哪家軟件公司的產(chǎn)品的feature列表越長，哪家公司就貌似越NB。

　　這個東西的弊端就在于，用戶的根本目的不是去使用這些功能，而是通過這些功能去完成不同的任務。所以，這些豐富的功能一開始貌似非常吸引人，但不久，用戶就發(fā)現(xiàn)其中很多的功能對于他們完成主要目標沒有任何幫助。因此，基于用戶任務的設計(task-based design)誕生了，用來幫助用戶更加快捷方便的完成他們的任務。

　　基于情景的設計

　　盡管基于任務的設計在一段時間內(nèi)看上去挺不錯的，設計師們還是越來越感覺到了它的局限性，問題出在哪里呢?因為在設計用戶體驗的過程中，“目標用戶群”這個概念越來越重要，然而基于任務的設計完全就沒有考慮這一塊!另外，基于任務的設計往往導致“設計師設計他們自己喜歡，而不是用戶喜愛的東西”。

　　好的設計需要在設計時候有一個清晰的思路：“這個產(chǎn)品是為誰設計的?”，“這個產(chǎn)品需要為這些人做什么事，解決什么問題?”。隨后，基于情景的設計(scenario-based design)才漸漸被引入進來。前文說了這么久的scenario，到底什么才是scenario呢?

　　一個情景(scenario)描述的是目標用戶怎樣在特定的環(huán)境里完成特定的任務。

　　或者更簡潔一點：

　　情景 = 用戶 + 任務 + 環(huán)境

　　因此，scenario-based 和 task-based的最大區(qū)別是牽著專注于產(chǎn)品的用戶和使用環(huán)境。好的設計必須同時具備易用性和高的用戶滿意度。設計scenario瞄準的是用戶滿意度這一塊，而基于任務的設計大部分時間只能讓產(chǎn)品可用和易用而已，

電腦資料

《前微軟項目經(jīng)理：怎樣設計一個像樣的方案》(http://www.szmdbiao.com)。

　　因此，一套經(jīng)過深思熟慮的scenario將對你的產(chǎn)品帶來極大幫助。如果你在設計過程中弄出來的新東西沒法跟你的scenario對上號，那你很可能是做錯了。

　　Scenario 分析

　　讓我們再回到文章開頭的scenario — 它到底有什么問題?我們來逐字逐句的分析下。

　　Joe在Fortune 500公司上班。可以說這是用一種最沒意義的方式帶出用戶和他所處的工作環(huán)境。你從這句話中了解不到任何關于joe的具體信息，目標用戶并沒有被準確定義 — 他可以是任意人，處于任意地點，做任意事情。

　　他的工作常常需要他查詢客戶的Snarfbladt資料。還好，至少用戶目標被定義了。

　　他發(fā)現(xiàn)Bladtblaster 2000能夠讓他在bladtblaster的網(wǎng)站上更快的獲得Snarfbladt的信息。這就是那條“為什么Joe需要這個功能”的廣告了。但是難道就沒有任何其他解決問題的方法了嗎?只此一條路?如果有其他途徑，你需要把他們放到scenario中，然后通過scenario說明Joe為什么不選擇它們。

　　這讓Joe非常高興。這是一個典型的在寫Scenario時很容易犯的先入為主的錯誤，下面會詳細說說。

　　“這讓Joe非常高興”這句有什么問題呢?

　　也許會顯得有點太鉆牛角尖了，但是用一個“高興”的用戶來為一個scenario結(jié)尾是一個大錯誤!為什么?參考下Everett的“基于情景設計的原則”：

　　如果寫scenario的意義在于證明某個/某些功能是成功的，那顯然你并不是在做基于情景的設計(scenario-based design)，你是在做基于功能的設計(feature-based design)!

　　使用scenario的目的不是為了“取悅”Joe，否則你直接給他他想要的功能不就得了。Scenario的目的是找出Joe為什么高興，系統(tǒng)中的那一部分取悅了他。這一部分重要的信息必須要包含在scenario里，遺憾的是它并沒有�？偟膩碚f，舉的這個例子，它名義上是基于情景的設計，實質(zhì)上又回到了基于功能的設計的老路上。

　　改進后的新Scenario

　　Joe在一家大型公司的貨運部門工作，平均每天要負責200個包裹的簽收和發(fā)送工作。為了保持一個積極的工作態(tài)度，他經(jīng)常加班，做一些額外的工作。

　　在做包裹的發(fā)送工作的時候，Joe常常需要查詢客戶的Snarfbladt資料。他發(fā)現(xiàn)Bladtblaster 2000能夠讓他在原理辦公室電腦的地方從bladtblaster的網(wǎng)站上輕松獲得Snarfbladt的信息。無論如何，他可以在簽收和發(fā)送貨物的時候使用它，只需要單手操作 — 大部分情況下都可以在3次點擊下完事。

　　可以看到，新的scenario更加豐滿。它并沒有告訴你“Joe很開心”，而是詳細的繪制了Joe的個人和工作情況。在此基礎之上，我們可以更加自信的捕捉那些會讓Joe高興和挫敗的部分，從而發(fā)展出新的，更加豐富客觀的Scenario。

　　本文編譯自唐卓，。

　　譯文出處：，轉(zhuǎn)載請注明出外鏈接。