截止2010年1月15日，使用google搜索“用戶體驗(yàn)設(shè)計(jì)”，返回1千3百萬(wàn)條結(jié)果。

“用戶體驗(yàn)設(shè)計(jì)”無(wú)疑是這兩年互聯(lián)網(wǎng)行業(yè)最炙手可熱的話題，而從我們成都UCD書友會(huì)火爆的現(xiàn)場(chǎng)來(lái)看，也的確如此。那么“用戶體驗(yàn)設(shè)計(jì)”為什么會(huì)如此火爆呢？這需要從互聯(lián)網(wǎng)的Web2.0革命說(shuō)起。
這場(chǎng)革命，代表了互聯(lián)網(wǎng)應(yīng)用關(guān)注焦點(diǎn)的變遷，從以內(nèi)容為王的門戶型網(wǎng)站時(shí)代，轉(zhuǎn)變?yōu)橐杂脩魹橹行牡幕ヂ?lián)網(wǎng)服務(wù)時(shí)代。以用戶為中心的互聯(lián)網(wǎng)服務(wù)，自然就需要以用戶為中心的設(shè)計(jì)。但是要做到真正的以用戶為中心的設(shè)計(jì)卻并不簡(jiǎn)單。

這是什么意思呢？我想用彩程的實(shí)際經(jīng)歷對(duì)這個(gè)問(wèn)題做出解釋。和很多其它軟件企業(yè)一樣，彩程也是從一些中小型的企業(yè)網(wǎng)站、電子商務(wù)網(wǎng)站開發(fā)業(yè)務(wù)啟程的。當(dāng)時(shí)我們開發(fā)一個(gè)電子商務(wù)類網(wǎng)站的流程是什么樣的呢？

首先會(huì)由超級(jí)打雜老妖出馬，跟客戶溝通，套出用戶的需求，然后由費(fèi)西或是老妖自己，三下五除二的搞一個(gè)首頁(yè)出來(lái)，拿去給用戶確認(rèn)，用戶如果點(diǎn)頭，那么ok，開始做首頁(yè)的html切圖，然后丟給程序員開始開發(fā)，同時(shí)，美工繼續(xù)孤軍深入，出各種特征內(nèi)頁(yè)，切html，交給程序員開發(fā)，如此循環(huán)往復(fù)。而一旦整個(gè)項(xiàng)目開始進(jìn)行，客戶就很少再參與其中了。
于是，這個(gè)項(xiàng)目持續(xù)運(yùn)行，直到某一天，程序員說(shuō)：“好了”，這樣，老妖滿懷希望的沖到客戶那里，很想聽到客戶對(duì)網(wǎng)站認(rèn)可，但實(shí)際的場(chǎng)景往往是：
客戶抱怨說(shuō)，這里我明明是想要個(gè)Flash廣告，但是卻只有一張圖片；這個(gè)訂單系統(tǒng)怎么不好用，為什么不參考淘寶來(lái)做呢？我還想要個(gè)會(huì)員系統(tǒng)，每個(gè)會(huì)員有自己的個(gè)人頁(yè)面。
這個(gè)時(shí)候，可憐的老妖只能作出兩種選擇，要么照單全收，ok，哪里有問(wèn)題我給你改哪里，要么就是耍死皮，但是后面一種情況一般不會(huì)出現(xiàn)，因?yàn)槔涎辉敢驗(yàn)榈米锟蛻舳鴣G掉奶粉錢。所以，這個(gè)原本大家都認(rèn)為很簡(jiǎn)單的網(wǎng)站項(xiàng)目就這樣被delay下去了。

這樣的情況出現(xiàn)的次數(shù)多了，讓公司首腦小s同學(xué)很不滿意，于是他開始召集大家思考，這是為什么呢？讓我們來(lái)看看之前我們的流程:

經(jīng)過(guò)對(duì)這個(gè)流程的幾個(gè)痛苦的日夜思索之后，我們發(fā)現(xiàn)了如下幾個(gè)凄慘的現(xiàn)實(shí)：
1. 用戶其實(shí)并不知道他到底需要什么，就算用戶知道，你也別想知道他究竟知道什么；
2. 美工都以為自己只是畫畫的，而無(wú)需去考慮整個(gè)產(chǎn)品的設(shè)計(jì)思想，包括用戶角色是什么，商業(yè)定位是什么，所以你說(shuō)你想要個(gè)新聞欄目，ok，我照著163畫一下就了事了；
3. 程序員都是腦殘，只關(guān)注用什么設(shè)計(jì)模式或是用什么框架，美工的設(shè)計(jì)圖對(duì)他們來(lái)說(shuō)不值一提，不就是一個(gè)for循環(huán)生成li標(biāo)簽而已嘛；
4. 客戶始終置身世外，他給錢了，只想你干好活，最后一手交錢一手交貨罷了，但最關(guān)鍵的是，“貨”這個(gè)東西，大家除了在最后一霎那能看到它的模樣，其它大部分時(shí)間它都異常神秘。

很多時(shí)候，最大的問(wèn)題往往在于我們不愿意去面對(duì)問(wèn)題。所以當(dāng)我們能把問(wèn)題找到，并敢于面對(duì)問(wèn)題的時(shí)候，解決辦法的出現(xiàn)就只是時(shí)間而已了。這個(gè)解決辦法，當(dāng)時(shí)我們認(rèn)為最優(yōu)的，就是強(qiáng)化設(shè)計(jì)，最后發(fā)現(xiàn)，其實(shí)就是引入了“用戶體驗(yàn)設(shè)計(jì)”。

從何入手呢？我們都知道，一般的軟件開發(fā)流程中，PM會(huì)根據(jù)用戶需求出產(chǎn)品需求分析報(bào)告，然后美工介入，出一些視覺(jué)界面，然后程序員根據(jù)有限的設(shè)計(jì)圖連蒙帶猜的進(jìn)行實(shí)際開發(fā)。但在這樣的模式下，產(chǎn)品會(huì)出現(xiàn)幾次偏離。

PM只有幾十頁(yè)的文檔，而這樣的文檔傳遞實(shí)際需求的效果極差，不能讓用戶確認(rèn)需求，于是出現(xiàn)整個(gè)流程中的第一次產(chǎn)品與需求的偏離。美工在做視覺(jué)設(shè)計(jì)的時(shí)候，就可能按照他自己的想法天馬行空，最后出現(xiàn)整個(gè)流程中的第二次產(chǎn)品與需求的偏離。程序員在拿到美工有限的設(shè)計(jì)圖后，大概想了想，覺(jué)得自己明白了，然后就開始寫代碼，但是由于沒(méi)有完整的產(chǎn)品模型到程序結(jié)構(gòu)的映射，最終導(dǎo)致第三次產(chǎn)品與需求的偏離。這樣帶來(lái)的致命后果就是：用戶明明想要個(gè)美女，但是最終實(shí)際交付的卻是個(gè)如花。

這樣的流程最大的問(wèn)題在于，缺少一個(gè)能夠聚焦各方的核心，幾十頁(yè)的文檔無(wú)法勝任，而原型卻可以。

我們認(rèn)為原型會(huì)很重要，于是我們首先引入了原型設(shè)計(jì)。在這個(gè)設(shè)計(jì)過(guò)程中，我們使用Axure作為輔助工具，它的好處在于，能讓任何一個(gè)PM很容易的上手，并能把需求書中幾十頁(yè)的文字落地為實(shí)際的界面。

在PM快速完成原型設(shè)計(jì)之后，PM會(huì)帶著原型去和客戶討論，客戶由于能有實(shí)際的使用感受，所以能夠很快的分辨出設(shè)計(jì)與他需求之間的偏差，然后PM根據(jù)用戶的反饋修正原型。

接著，美工上場(chǎng)了，注意，這個(gè)時(shí)候，美工不再是美工，他有了新的title—視覺(jué)設(shè)計(jì)師。有什么新的要求呢？他需要仔細(xì)的去評(píng)估原型，從設(shè)計(jì)師的角度出發(fā)，對(duì)原型提出意見。接著，才是用PS將界面畫出來(lái)，然后根據(jù)設(shè)計(jì)圖制作另外一份原型—高保真原型。

高保真原型和之前的原型—也就是低保真原型–的差別在于，低保真原型著重完成信息元素的組織以及概念模型的搭建，目標(biāo)定位在為產(chǎn)品搭框架，填充素材。但是高保真原型會(huì)完成對(duì)框架的裝修以及對(duì)素材的組織。這樣得到的高保真原型和實(shí)際交付的產(chǎn)物就幾乎是100%趨近的了。

然后，產(chǎn)品經(jīng)理會(huì)帶著這份珍貴的禮物再次走訪客戶，根據(jù)客戶的使用反饋?zhàn)鲎詈蟮脑驼{(diào)整，至此，整個(gè)原型設(shè)計(jì)階段結(jié)束。

接下來(lái)，根據(jù)高保真原型，我們給出了整個(gè)原型的HTML代碼，包括規(guī)范的CSS樣式表以及JS接口，都由我們的前端工程師定義并實(shí)現(xiàn)。

最后，我們交到產(chǎn)品實(shí)施人員手里的就有兩樣?xùn)|西，一是高保真原型，一是HTML框架代碼。我們希望高保真原型能真實(shí)反應(yīng)用戶需求，并且讓實(shí)施者知道開發(fā)出來(lái)的東西是一個(gè)什么樣子的。其次，通過(guò)提交高質(zhì)量的html代碼，減少普通程序員的工作量，因?yàn)椴豢煞裾J(rèn)的是，如今復(fù)雜的前端技術(shù)不是一個(gè)普通的java程序員能短時(shí)間掌握得了的。

所以，最后我們的第一版用戶體驗(yàn)設(shè)計(jì)流程就是這樣的：

這樣的流程解決了我們之前的哪些問(wèn)題呢？

首先，原型能夠成為客戶和項(xiàng)目經(jīng)理之間的溝通媒介，極大地降低溝通成本；其次，美工獲得了解放，從被動(dòng)畫圖，轉(zhuǎn)為通過(guò)原型真正的參與到了產(chǎn)品設(shè)計(jì)的流程中來(lái)；然后，程序員能通過(guò)原型知道自己要做出來(lái)的東西究竟是什么樣的；最后，再通過(guò)提交完整的前端代碼，把傳統(tǒng)程序員的前端短板一并解決了，這個(gè)流程就似乎已經(jīng)非常完美了。

那么實(shí)際情況呢？首先需要承認(rèn)的是，這確實(shí)是一個(gè)飛躍。我們自己的網(wǎng)站項(xiàng)目都得以順利的實(shí)現(xiàn)，不再有delay的情況，而客戶的反饋也非常良好。但是當(dāng)我們想以外包服務(wù)的方式將用戶體驗(yàn)服務(wù)提供給客戶的時(shí)候，就出現(xiàn)了問(wèn)題。
首先的問(wèn)題是，外包形式的用戶體驗(yàn)服務(wù)，我們的服務(wù)對(duì)象從最終用戶變成了外包服務(wù)購(gòu)買者，這使得和有效用戶進(jìn)行溝通的成本上升了，在需求調(diào)研的時(shí)候，感覺(jué)難以對(duì)最終用戶進(jìn)行定位。
其次是，我們發(fā)現(xiàn)低保真原型和高保真原型極有可能變成內(nèi)部的閉門造車活動(dòng)，拿出一個(gè)完善的原型往往持續(xù)很長(zhǎng)的時(shí)間，而客戶的產(chǎn)品經(jīng)理或者項(xiàng)目經(jīng)理沒(méi)有在設(shè)計(jì)途中參與進(jìn)來(lái)，所以當(dāng)拿出最終的高保真原型的時(shí)候，我們自己的設(shè)計(jì)師就變成了客戶的產(chǎn)品經(jīng)理。
最后的問(wèn)題是，我們交付給程序員的前端代碼太多，導(dǎo)致這樣的樸素的心理問(wèn)題出現(xiàn)：我是程序員，如果我拿到一份不是我寫的代碼，我就有很強(qiáng)的畏懼心理，不愿意去看。這樣，實(shí)際的開發(fā)過(guò)程中，有很多前端的問(wèn)題會(huì)壓到我們團(tuán)隊(duì)頭上，因?yàn)槿魏我粋€(gè)前端功能的開發(fā)，客戶的程序員都可以說(shuō)，前端代碼不是我寫的，我不會(huì)。

好吧，問(wèn)題當(dāng)然是不會(huì)結(jié)束，但我們還是選擇解決問(wèn)題。

關(guān)于難以對(duì)最終用戶進(jìn)行定位，我們?cè)谧鲂枨蠓治龅臅r(shí)候加入角色分析環(huán)節(jié)來(lái)幫助我們完成這個(gè)任務(wù)。在《設(shè)計(jì)溝通十器》這本書中，羅列了角色分析文檔所需的各個(gè)要素，我們選擇其中最重要的，用戶基本信息、動(dòng)機(jī)、場(chǎng)景、對(duì)應(yīng)需要實(shí)現(xiàn)的產(chǎn)品功能來(lái)完成角色分析文檔。這份文檔幫助我們建立起了最終的用戶模型，因此我們?cè)谧鲈驮O(shè)計(jì)時(shí)，就有了最終用戶的標(biāo)準(zhǔn)參照物。

其次，我們?cè)谠O(shè)計(jì)原型時(shí)，盡量和客戶一起設(shè)計(jì)，也即是用很高的迭代頻率和客戶交流，甚至?xí)r常駐點(diǎn)在客戶那里進(jìn)行設(shè)計(jì)，讓客戶隨時(shí)了解到我們的原型長(zhǎng)成什么樣了。

然后，在原型設(shè)計(jì)階段加入了可行性分析這一環(huán)節(jié)，提前將程序員拉入設(shè)計(jì)。和把客戶拉入設(shè)計(jì)一樣重要，需要程序員在早期就介入到對(duì)設(shè)計(jì)的評(píng)估，包括對(duì)后端數(shù)據(jù)以及前端邏輯實(shí)現(xiàn)難度的確認(rèn)。這個(gè)環(huán)節(jié)確保在后期開發(fā)的時(shí)候，程序員能有所準(zhǔn)備，杜絕了推卸責(zé)任的現(xiàn)象。

最后，我們拆分了前端代碼開發(fā)部分，將前端開發(fā)工作改為提供兩份文檔，一份是視覺(jué)規(guī)范文檔。這份文檔詳細(xì)的提供了視覺(jué)界面設(shè)計(jì)的規(guī)范，比如字體規(guī)范、是否自適應(yīng)寬度，各種配色組合等等。另外一份就是開發(fā)指南，包括在可行性評(píng)估中得出的有難度的前端部分的示例代碼，和相關(guān)的接口文檔。這兩份文檔主要在于鼓勵(lì)程序員真正介入前端開發(fā)。有問(wèn)題也不要緊，我們會(huì)按項(xiàng)目的實(shí)際情況，為客戶提供不同時(shí)間的現(xiàn)場(chǎng)技術(shù)支持。

這樣，就得到了目前我們使用的流程：

那么，這樣的流程實(shí)施的效果怎么樣呢？我們來(lái)實(shí)際看一個(gè)例子。這個(gè)例子是給四方科技的一款網(wǎng)絡(luò)優(yōu)化平臺(tái)提供用戶體驗(yàn)設(shè)計(jì)服務(wù)。

首先是對(duì)產(chǎn)品進(jìn)行商業(yè)目標(biāo)需求調(diào)研，在了解到這款產(chǎn)品的基本商業(yè)目標(biāo)定位后，我們便開始了用戶角色分析。我們首先把產(chǎn)品的最終用戶分為兩類，一類是管理層，他們最大的愿望是，一眼掌握自己企業(yè)的網(wǎng)絡(luò)使用情況，想知道自己為什么發(fā)封email都會(huì)這么慢。當(dāng)他們一眼發(fā)現(xiàn)自己企業(yè)網(wǎng)絡(luò)出現(xiàn)異常后，接著他們需要把優(yōu)化網(wǎng)絡(luò)的任務(wù)下派給一個(gè)下級(jí)，這個(gè)下級(jí)可能就是人事部經(jīng)理或一個(gè)網(wǎng)管。他們的最大愿望是，確保公司網(wǎng)絡(luò)的正常運(yùn)行，完成老板下達(dá)的任務(wù)。

角色分析

有了這樣一份角色分析文檔，接著我們的低保真原型設(shè)計(jì)就會(huì)圍繞角色的動(dòng)機(jī)和場(chǎng)景來(lái)進(jìn)行。下面我們來(lái)看看首頁(yè)設(shè)計(jì)：

可以從這個(gè)流量監(jiān)控的首頁(yè)看出，如果我是老板，很容易掌握的幾個(gè)信息是：今天公司網(wǎng)絡(luò)的整體流量情況，現(xiàn)在哪個(gè)員工的流量最高，是否正常。有了這幾個(gè)信息，我就大概知道我自己發(fā)郵件，之所以慢，是不是由于內(nèi)部網(wǎng)絡(luò)原因引起的。如果是，這時(shí)候我就會(huì)抄起電話打給人事部經(jīng)理或是網(wǎng)管，讓他給我解決問(wèn)題了。

人事部經(jīng)理得到這個(gè)任務(wù)后，就會(huì)通過(guò)平臺(tái)的流量實(shí)時(shí)監(jiān)控頁(yè)面，找出究竟是哪部分的流量出現(xiàn)了問(wèn)題。然后在上網(wǎng)控制頁(yè)面，修改對(duì)應(yīng)的網(wǎng)絡(luò)策略即可。

圍繞角色文檔的低保真設(shè)計(jì)之后，我們的視覺(jué)設(shè)計(jì)師會(huì)基于低保真原型出視覺(jué)設(shè)計(jì)圖，并將其作為素材制作高保真原型。最終的高保真原型就是這樣的：

高保真原型結(jié)束后，緊接著是兩份文檔的編寫，一是這樣的一份視覺(jué)規(guī)范文檔，我們看到這份文檔中包含了頁(yè)面布局定義、字體的字號(hào)以及顏色、所有控件的顏色定義等。

接下來(lái)是一份開發(fā)指南文檔，其中給出了一些復(fù)雜控件的前端代碼實(shí)現(xiàn)參考，供程序員在實(shí)際開發(fā)時(shí)使用。

最后，我們?cè)谟脩衄F(xiàn)場(chǎng)完成了4個(gè)工作日的現(xiàn)場(chǎng)技術(shù)支持服務(wù)，解決了一些html框架搭建，切圖等前端技術(shù)問(wèn)題。

這就是我們的用戶體驗(yàn)設(shè)計(jì)流程以及方法。它并不是完善的，甚至可能全盤錯(cuò)誤，比如在如何為用戶提供更好的前端開發(fā)的幫助方面，我們還在進(jìn)行各種嘗試。沒(méi)有不變的流程，只有不斷探索。

最后，我想回歸到“用戶體驗(yàn)設(shè)計(jì)”本身。用戶體驗(yàn)設(shè)計(jì)的出現(xiàn)，只是代表傳統(tǒng)軟件行業(yè)在互聯(lián)網(wǎng)時(shí)代開放、共享、自由的氛圍中的一種進(jìn)化需要，而它最終會(huì)和整個(gè)軟件產(chǎn)品的研發(fā)流程融為一體，成為無(wú)論是從需求分析、到界面設(shè)計(jì)再到開發(fā)到運(yùn)維的一部分，因?yàn)槲覀冸S時(shí)都需要將用戶置入服務(wù)的核心，用我們的愛來(lái)澆注產(chǎn)品本身。

原文：http://blog.mycolorway.com/2010/01/23/our-ued-flow-method/