【文章內(nèi)容簡(jiǎn)介】 內(nèi)容比較多，再辟章節(jié)專講吧。）詳細(xì)程度不同的用戶建模結(jié)果：即興人物角色、定性人物角色、定量人物角色數(shù)據(jù)翔實(shí)的用戶研究結(jié)果對(duì)軟件產(chǎn)品的設(shè)計(jì)是非常有用的。但是，越翔實(shí)的數(shù)據(jù)，其獲取成本也越大。悶頭研究用戶直到研究的“很透”，這種做法不僅耗時(shí)費(fèi)力，并且長(zhǎng)時(shí)間的用戶研究結(jié)果不落實(shí)到產(chǎn)品設(shè)計(jì)中就無(wú)法驗(yàn)證用戶研究結(jié)果的有效性，即使用戶研究結(jié)果有效，也很可能因?yàn)檠芯恐芷谳^長(zhǎng)而耽誤市場(chǎng)戰(zhàn)機(jī)。在項(xiàng)目初期花太多的時(shí)間在用戶研究工作上，這種做法是與敏捷思想背道而馳的，我們應(yīng)杜絕這種勞民傷財(cái)?shù)淖龇?。在用戶研究的初期，我們可以先拍著腦袋想一個(gè)人物角色雛形（拍腦袋這事，老外專家們也干，并非只是中國(guó)特色。Don Norman將拍腦袋得到的人物角色稱作AdHoc Personas），我們可以送它個(gè)美稱“即興人物角色”。即興人物角色可以通過(guò)頭腦風(fēng)暴來(lái)生成，所以，它的建模時(shí)間很短；但是，這樣的用戶模型并沒有真實(shí)用戶數(shù)據(jù)的支持。如果說(shuō)即興人物角色有何可信之處的話，那就是：拍腦袋的過(guò)程實(shí)際上是對(duì)各位的“腦袋”里的已有經(jīng)驗(yàn)進(jìn)行深度挖掘的過(guò)程。拍腦袋的人越有經(jīng)驗(yàn)，即興人物角色就越可信。從這個(gè)角度講，專家拍腦袋還是比一般人強(qiáng)的。拍腦袋時(shí)，我們可以考慮以下問題：誰(shuí)將使用系統(tǒng)？ 這些用戶屬于哪類人群？ 他們想達(dá)到什么目的？ 他們需要系統(tǒng)為此提供什么東西？ 系統(tǒng)應(yīng)對(duì)怎樣提供他們所需的東西？ 他們與系統(tǒng)有什么關(guān)系，其具體表現(xiàn)特征是什么？ 什么因素決定了他們使用系統(tǒng)的方式？（對(duì)現(xiàn)有系統(tǒng)：） 系統(tǒng)的什么功能不要用或不太有效？ 怎樣才能使系統(tǒng)更有效地支持使用？我認(rèn)為，即興人物角色作為用戶模型有點(diǎn)弱，但作為用戶研究的起點(diǎn)——假設(shè)框架是非常有用的。在下一小節(jié)“定量用戶研究案例”中，我們將會(huì)結(jié)合案例詳細(xì)講解人物角色的生成過(guò)程。定量用戶研究案例：手持終端設(shè)備用戶體驗(yàn)創(chuàng)新功能研究（待補(bǔ)充）目標(biāo)建模星期日, 09月 13th, 2009 上一章我們對(duì)用戶建模的輸出成果“人物角色”做了詳盡的介紹。由于用戶目標(biāo)在整個(gè)敏捷用戶體驗(yàn)設(shè)計(jì)過(guò)程中非常關(guān)鍵，是用戶研究和任務(wù)分析的承接點(diǎn)，所以，我們?cè)诖藛伪僬鹿?jié)重點(diǎn)講解“目標(biāo)”?！坝脩裟繕?biāo)列表”不僅是用戶建模的兩個(gè)重要輸出成果之一，它也是后繼任務(wù)分析的起點(diǎn)。簡(jiǎn)單地列出“用戶目標(biāo)”還是遠(yuǎn)遠(yuǎn)不夠的，我們必須對(duì)“目標(biāo)”進(jìn)行歸類、梳理、增刪、優(yōu)化后，才能有效地駕馭它。因此，我們需要對(duì)目標(biāo)進(jìn)行建模。用戶的目標(biāo)可以分為兩大類：1）業(yè)務(wù)目標(biāo)；2）個(gè)人目標(biāo)。用戶在工作中所使用的軟件產(chǎn)品，我們需要考慮的主要是“業(yè)務(wù)目標(biāo)”；而個(gè)人消費(fèi)類軟件（電子）產(chǎn)品，則更多地需要考慮“個(gè)人目標(biāo)”。例如企業(yè)的銷售人員所用的CRM（客戶管理系統(tǒng)），“用戶”的目標(biāo)主要是業(yè)務(wù)目標(biāo)，即“管理客戶”；而B2C網(wǎng)站的用戶，其用戶目標(biāo)就是“購(gòu)買到自己喜歡的商品”。也就是說(shuō)，辦公類軟件產(chǎn)品主要考慮用戶的業(yè)務(wù)目標(biāo)而不會(huì)考慮用戶個(gè)人的喜好；個(gè)人消費(fèi)類軟件產(chǎn)品則正好相反：主要考慮個(gè)人喜好。（此時(shí)的UCD思想好像有點(diǎn)BCD的傾向了，即Boss Centered Design以老板為中心的設(shè)計(jì)。不過(guò)這里的Boss不是軟件生產(chǎn)商的Boss，而是購(gòu)買軟件的Boss，所以更確切地說(shuō)是“以客戶為中心的設(shè)計(jì)”。客戶和用戶的差別在于：客戶可能希望購(gòu)買的軟件能提高他們企業(yè)的整體辦公效率，而用戶則更期望在工作之余忙里偷閑地上網(wǎng)泡MM @_@）目標(biāo)的5個(gè)層次關(guān)于目標(biāo)，Alistair Cockburn在《Writing Effective Use Case》中有過(guò)充分的論述，我在此提及的目標(biāo)模型，完全忠于Cockburn原著。用戶的目標(biāo)有的很具體（輸入用戶名和密碼），而有的則很泛（讓我的生活多姿多彩）。在抽象和具體之間，我們把用戶的目標(biāo)劃分成了不同的層次：云彩層、風(fēng)箏層、海平面層、游魚層、蛤貝層。這些隱喻只是為了與不同詳細(xì)程度的用戶目標(biāo)之間進(jìn)行映射，使我們更好的理解不同層次的目標(biāo)。有的用戶目標(biāo)比較抽象，像飄在空中的風(fēng)箏；有的用戶目標(biāo)則更加虛無(wú)縹緲，想飄在天上的云彩；有的用戶目標(biāo)則和低級(jí)。在確定地勢(shì)高低的時(shí)候，我們是以海平面作為基準(zhǔn)確定不同地方的海拔高度的。那么，我們要衡量用戶的目標(biāo)到底是具體還是抽象，也需要確定出“海平面”級(jí)的用戶目標(biāo)。海平面層次的目標(biāo)，我們稱之為“用戶目標(biāo)”（user goal）。它是用戶使用系統(tǒng)的目標(biāo)，相當(dāng)于業(yè)務(wù)分析中的“基本業(yè)務(wù)過(guò)程”?；緲I(yè)務(wù)過(guò)程的衡量標(biāo)準(zhǔn)是：一人一時(shí)一地點(diǎn)，完成一件有最小業(yè)務(wù)價(jià)值的事情。云彩層和風(fēng)箏層的目標(biāo)，統(tǒng)稱為“概要目標(biāo)層”（summarylevel goal）。它們的主要作用是：顯示用戶目標(biāo)的上下文背景 顯示相關(guān)目標(biāo)的生命周期順序 為底層次目標(biāo)提供一個(gè)目錄列表刻意區(qū)分云彩層和風(fēng)箏層在實(shí)際的操作中并沒多大用處，一般就統(tǒng)稱為“概要目標(biāo)層”。不過(guò)，不同的概要目標(biāo)層之間也的確有高低之分，故保留“云彩層”和“風(fēng)箏層”這兩種提法。概要層的目標(biāo)通常需要幾個(gè)小時(shí)、幾天、幾星期、幾個(gè)月、甚至幾年才能達(dá)到。概要目標(biāo)層的用例通常是用來(lái)描述業(yè)務(wù)的用例，而用戶目標(biāo)層的用例通常是用來(lái)描述軟件系統(tǒng)的用例。子功能目標(biāo)層（subfunctionlevel goal）的目標(biāo)是指那些在實(shí)現(xiàn)用戶目標(biāo)時(shí)可能會(huì)被用到的目標(biāo)。每個(gè)子功能目標(biāo)單獨(dú)存在時(shí)都是沒有業(yè)務(wù)價(jià)值的?！坝昔~層”目標(biāo)通常對(duì)應(yīng)于用戶在執(zhí)行任務(wù)（為了達(dá)到“用戶級(jí)目標(biāo)”）時(shí)所采取的每一個(gè)步驟。在分解任務(wù)/編寫用例時(shí)，我們只要分解到“游魚層”（即“步驟”）即可，更低層次的目標(biāo)（哈貝層）在任務(wù)分解階段就沒有必要關(guān)注了，我們?cè)谠敿?xì)的界面設(shè)計(jì)時(shí)再作考慮。關(guān)于“目標(biāo)模型”，我們需要注意以下兩點(diǎn)：我們最應(yīng)該關(guān)注的就是“海平面”，因?yàn)樗恰澳繕?biāo)模型”的基準(zhǔn)我們還應(yīng)該找出概要層次的目標(biāo)，以便為其他用例提供上下文背景如何找出各層目標(biāo)？“用戶級(jí)目標(biāo)”（即“海平面”層）的衡量標(biāo)準(zhǔn)是：一人一時(shí)一地點(diǎn)，完成一件有最小業(yè)務(wù)價(jià)值的事情?？刹鸱譃槿缦氯龡l：由一個(gè)人、在一個(gè)地方、一次性完成（約2~20分鐘）用戶一完成操作，就可以很高興地離開用戶在完成該目標(biāo)后，就可以向老板提出加薪（有業(yè)務(wù)價(jià)值）要想找到較高層次的目標(biāo)，我們需要不停地YY（哈哈，是很不雅的“意淫”的拼音首字母），不停地問自己“why”：用戶真正想要的是什么？ 如果不是，用戶真正想要的是什么？ 用戶為什么要做這件事？找較高層次的目標(biāo)，我們需要“求本溯源”，找出用戶最本質(zhì)的“目標(biāo)”，因此我們需要不停地YY（why？why？）。相反，如果我們想要找出較低層次的目標(biāo)，我們則更關(guān)心“用戶目標(biāo)”是如何由一個(gè)個(gè)更小的目標(biāo)支撐實(shí)現(xiàn)的。此時(shí)，我們需要不停地問自己“how”，當(dāng)我們沖自己“嚎”一陣之后，我們就會(huì)弄清楚那些用戶級(jí)目標(biāo)是如何一步步地實(shí)現(xiàn)的。通過(guò)考察步驟（子目標(biāo)）的數(shù)量，我們就可以判定出對(duì)“用戶級(jí)別的目標(biāo)”的分解是否合理（通常合理的步驟為：3~8步）。幾乎多于11步的步驟都可以被裁短。一般對(duì)于一個(gè)需要通過(guò)10個(gè)步驟以上才能完成的“用戶目標(biāo)”來(lái)說(shuō)，人們都會(huì)覺得難以容忍。如果對(duì)“用戶級(jí)目標(biāo)”的分解多余10個(gè)步驟（子目標(biāo)），那么很可能是涉及到了用戶界面細(xì)節(jié)。此時(shí)我們可采取的措施有：刪除界面細(xì)節(jié)信息 提升目標(biāo)層次，多YY（多問“為什么”） 將某些交互步驟合并盡管以上對(duì)各層次目標(biāo)的度量都有很大的主觀性，但是，依照以上標(biāo)準(zhǔn)，人們卻能很快地對(duì)目標(biāo)層次達(dá)成共識(shí)。這樣看來(lái)，找出用戶目標(biāo)還是有章可循的，并且是可信的。小結(jié)：目標(biāo)上承“用戶”，下接“任務(wù)”用戶模型=用戶目標(biāo)集+用戶特征集。目標(biāo)是用戶模型的重要組成部分，更是用戶執(zhí)行“任務(wù)”的理由。目標(biāo)是終極狀態(tài)，任務(wù)是達(dá)到該終極狀態(tài)所需的中間過(guò)程。什么是任務(wù)建模？星期日, 09月 13th, 2009 任務(wù)與目標(biāo)的關(guān)系、任務(wù)與工具的關(guān)系“目標(biāo)”是用戶執(zhí)行“任務(wù)”的理由，“任務(wù)”是為了達(dá)到用戶“目標(biāo)”所需執(zhí)行的動(dòng)作。目標(biāo)是穩(wěn)定的，任務(wù)是會(huì)隨著技術(shù)的發(fā)展而改變的。例如：我們的目標(biāo)是“保持口腔衛(wèi)生、口氣清新”；我們的任務(wù)在清朝老佛爺?shù)臅r(shí)候可能是鹽水漱口+牙簽剔牙，到了現(xiàn)在，我們的任務(wù)就變成了刷牙、嚼口香糖等?！肮ぞ摺辈粌H為“任務(wù)”的執(zhí)行提供技術(shù)支持，也會(huì)改變?nèi)藗儗?duì)“任務(wù)”的思考方式，新工具的發(fā)明能促進(jìn)新任務(wù)的形成。人們對(duì)工具的使用往往超出設(shè)計(jì)者的預(yù)期。例如：我們?cè)谝巴馑逘I(yíng)的時(shí)候，會(huì)把鏟子當(dāng)錘子來(lái)釘釘子；當(dāng)手邊沒有小刀時(shí)，我們常常會(huì)用圓珠筆筆尖劃開包裝上的密封膠帶，甚至我們會(huì)覺得筆尖比小刀更好使，因?yàn)閳A珠筆筆尖長(zhǎng)度有限，我們不會(huì)因?yàn)橛昧^(guò)猛而劃傷包裝內(nèi)的物品。此時(shí)，我們完全沒有意識(shí)到圓珠筆這一“工具”其設(shè)計(jì)本意是用來(lái)寫字的，并且我可以在此毫不負(fù)責(zé)地?cái)嘌裕翰徽撃奈粓A珠筆的設(shè)計(jì)者，他都不會(huì)考慮讓圓珠筆來(lái)劃開包裝膠帶的！再舉個(gè)網(wǎng)站的例子：據(jù)我所知，有部分用戶會(huì)利用“豆瓣”來(lái)找chinapub上的圖書，其原因就是chinapub首頁(yè)的載入速度太慢，他會(huì)在他鐘愛的、頁(yè)面載入飛快的豆瓣網(wǎng)上搜索他想要找的圖書，然后直接點(diǎn)擊轉(zhuǎn)向chinapub上該書的鏈接。軟件設(shè)計(jì)中的任務(wù)建模我們?cè)诖艘接懙娜蝿?wù)建模，是為了最終的軟件設(shè)計(jì)而展開的。我們要設(shè)計(jì)開發(fā)的軟件產(chǎn)品，它本質(zhì)上是“工具”，是為了支持用戶完成任務(wù)而向用戶提供的一種信息化工具。在設(shè)計(jì)軟件（工具）前，我們先要理解用戶的目標(biāo)，然后理解他們所需完成的任務(wù)。用戶建模和目標(biāo)建模已經(jīng)確定了“目標(biāo)”并將其模型化，現(xiàn)在要做的就是明確、細(xì)化用戶所需執(zhí)行的“任務(wù)”，這樣，我們才能有的放矢地為用戶提供相應(yīng)的軟件“工具”來(lái)支持用戶任務(wù)的執(zhí)行。讓我們從敏捷軟件開發(fā)生命周期的角度來(lái)審視一下“任務(wù)”所處的位置吧。我們知道，用戶故事是設(shè)計(jì)的最小單元，它承載了最基本的設(shè)計(jì)套路：設(shè)計(jì)規(guī)劃224。技術(shù)實(shí)現(xiàn)224。測(cè)試評(píng)估。通過(guò)迭代、增量我們可以最終將一個(gè)個(gè)用戶故事實(shí)現(xiàn)為最終的軟件產(chǎn)品。搞定了最基本的用戶故事，我們就有信心最終搞定軟件產(chǎn)品了。我們此刻要討論的是“任務(wù)建模”，那么我們就來(lái)看看“任務(wù)”與用戶故事的關(guān)系吧。用戶故事由3部分組成：用戶（user）、任務(wù)（task）以及用戶執(zhí)行該任務(wù)所要達(dá)到的目標(biāo)（goal）。通常的格式如下：作為[某種類型的用戶]我想[執(zhí)行某某任務(wù)]這樣，我就能[達(dá)成某某目標(biāo)]看來(lái)，任務(wù)是用戶故事的重要組成部分，要想搞定設(shè)計(jì)的最小單元——用戶故事，我們必須搞定其中的“任務(wù)”。任務(wù)建模，就是將業(yè)務(wù)逐漸分解為“海平面”級(jí)的任務(wù)，然后再用“用例”的形式詳細(xì)描述“海平面”級(jí)任務(wù)的人機(jī)交互過(guò)程，并最終由軟件開發(fā)人員從用例中提取軟件設(shè)計(jì)的最小單元——“用戶故事”。任務(wù)Task、用例UseCase、用戶故事UserStory、場(chǎng)景Scenario星期日, 09月 13th, 2009 與任務(wù)類似的概念有：用例、用戶故事、場(chǎng)景等。在本小節(jié)，我們會(huì)對(duì)其作詳細(xì)的澄清。任務(wù)Task任務(wù)，來(lái)自“目標(biāo)導(dǎo)向的活動(dòng)模型”，即：目標(biāo)任務(wù)工具，它所描述的是人們?yōu)榱说竭_(dá)某種目標(biāo)而采取的行動(dòng)。用戶所采取的行動(dòng)有大有小、有粗有細(xì)，其粒度是與“目標(biāo)”的層次相對(duì)應(yīng)的。設(shè)計(jì)軟件時(shí)，我們需要考慮海平面及更高的任務(wù)目標(biāo)。任務(wù)是對(duì)用戶為了達(dá)到某種目標(biāo)所采取的行動(dòng)的統(tǒng)稱，它既可以是海平面級(jí)的任務(wù)，也可以是風(fēng)箏層、云彩層的任務(wù)。海平面級(jí)的任務(wù)是最小粒度的任務(wù)，游魚層、蛤貝層的用戶“行動(dòng)”一般對(duì)應(yīng)執(zhí)行任務(wù)時(shí)所采取的“步驟”，它們都沒有業(yè)務(wù)價(jià)值。因此，我們可以講任務(wù)定義為“有業(yè)務(wù)價(jià)值的”用戶行動(dòng)。由于海平面級(jí)的任務(wù)有著最小的業(yè)務(wù)價(jià)值，所以，我們以后提到“任務(wù)”一詞時(shí)通常都特指“海平面級(jí)的任務(wù)”，對(duì)應(yīng)“用戶級(jí)別的目標(biāo)”。用例UseCase“用例是代表系統(tǒng)中各涉眾之間就系統(tǒng)的行為所達(dá)成的契約。用例描述了在不同條件下，系統(tǒng)對(duì)某一涉眾的請(qǐng)求所做出的響應(yīng)。提出請(qǐng)求的涉眾被稱為主執(zhí)行者（primary actor）。主執(zhí)行者通過(guò)發(fā)起與系統(tǒng)的一次交互來(lái)實(shí)現(xiàn)某個(gè)目標(biāo)。系統(tǒng)對(duì)任一執(zhí)行者所做出的響應(yīng)，要保證所有涉眾的利益不受侵犯。根據(jù)執(zhí)行者做出的請(qǐng)求和請(qǐng)求涉及的條件，系統(tǒng)將執(zhí)行不同的行為序列，每一行為序列稱之為一個(gè)場(chǎng)景（Scenario）。一個(gè)用例是多個(gè)不同場(chǎng)景的集合?！币陨鲜茿listair Cockburn在《編寫有效用例》中對(duì)“用例”的一段描述。在我看來(lái)，用例更像是一種文學(xué)體裁，一種與小說(shuō)、詩(shī)歌、散文等并列的文學(xué)體裁。用例這種體裁很適合用來(lái)描述業(yè)務(wù)過(guò)程、軟件需求以及人機(jī)交互過(guò)程。也就是說(shuō)，我們寫用例的目的，就是要對(duì)業(yè)務(wù)過(guò)程、軟件需求、人機(jī)交互過(guò)程等進(jìn)行詳細(xì)準(zhǔn)確的描述，以便讓涉眾就軟件系統(tǒng)的行為達(dá)成一致。而用例，正是能清晰地記錄涉眾所達(dá)成的一致意見的最佳表達(dá)形式，所以，用例不僅僅是一種“契約”，它也正是記錄涉眾就系統(tǒng)行為所達(dá)成的一致意見的“最佳體裁”。正如任務(wù)會(huì)有不同的層級(jí)（云彩層、風(fēng)箏層、海平面層），用例也可以描述不同層次的內(nèi)容。因?yàn)橛美皇且环N“體裁”，所以它的內(nèi)容可以非常廣泛：業(yè)務(wù)過(guò)程、軟件需求、人機(jī)交互過(guò)程。我們?cè)凇叭蝿?wù)建模”階段，主要用用例來(lái)描述人機(jī)交互過(guò)程，并且，多數(shù)情況下是用來(lái)描述“用戶目標(biāo)級(jí)”的任務(wù)的。用例也會(huì)包含這兩種情況：1）只描述用戶執(zhí)行任務(wù)的步驟；2）既描述用戶執(zhí)行任務(wù)的步驟又描述系統(tǒng)的反饋，此時(shí)的用例反映整體的人機(jī)交互過(guò)程。在此給出用例的模板，供大家參考。用戶故事UserStory在介紹“敏捷軟件開發(fā)生命周期：產(chǎn)品–版本計(jì)劃–迭代–用戶故事”時(shí)，我們已經(jīng)對(duì)“用戶故事”有過(guò)介紹：用戶故事是最基本的設(shè)計(jì)單元。用戶故事就是以用戶的語(yǔ)言對(duì)產(chǎn)品功能（feature）所作的描述。關(guān)于用戶故事，應(yīng)注意以下幾點(diǎn)：每個(gè)用戶故事，只描述一個(gè)功能（feature）用戶故事，用的是用戶的語(yǔ)言