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

前微軟項(xiàng)目經(jīng)理：怎樣設(shè)計(jì)一個(gè)像樣的方案

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

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

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

　　基于功能的設(shè)計(jì) 和 基于任務(wù)的設(shè)計(jì)

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

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

　　基于情景的設(shè)計(jì)

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

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

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

　　或者更簡(jiǎn)潔一點(diǎn)：

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

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

電腦資料

《前微軟項(xiàng)目經(jīng)理：怎樣設(shè)計(jì)一個(gè)像樣的方案》(http://m.lotusphilosophies.com)。

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

　　Scenario 分析

　　讓我們?cè)倩氐轿恼麻_頭的scenario — 它到底有什么問題?我們來逐字逐句的分析下。

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

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

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

　　這讓Joe非常高興。這是一個(gè)典型的在寫Scenario時(shí)很容易犯的先入為主的錯(cuò)誤，下面會(huì)詳細(xì)說說。

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

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

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

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

　　改進(jìn)后的新Scenario

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

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

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

　　本文編譯自唐卓，。

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