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