中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

“用戶體驗設(shè)計”無疑是這兩年互聯(lián)網(wǎng)行業(yè)最炙手可熱的話題，而從我們成都UCD書友會火爆的現(xiàn)場來看，也的確如此。那么“用戶體驗設(shè)計”為什么會如此火爆呢？這需要從互聯(lián)網(wǎng)的Web2.0革命說起。

這場革命，代表了互聯(lián)網(wǎng)應(yīng)用關(guān)注焦點(diǎn)的變遷，從以內(nèi)容為王的門戶型網(wǎng)站時代，轉(zhuǎn)變?yōu)橐杂脩魹橹行牡幕ヂ?lián)網(wǎng)服務(wù)時代。以用戶為中心的互聯(lián)網(wǎng)服務(wù)，自然就需要以用戶為中心的設(shè)計。但是要做到真正的以用戶為中心的設(shè)計卻并不簡單。

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

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

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

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

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

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

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

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

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

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

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

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

然后，產(chǎn)品經(jīng)理會帶著這份珍貴的禮物再次走訪客戶，根據(jù)客戶的使用反饋做最后的原型調(diào)整，至此，整個原型設(shè)計階段結(jié)束。

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

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

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

這樣的流程解決了我們之前的哪些問題呢？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最后，我們在用戶現(xiàn)場完成了4個工作日的現(xiàn)場技術(shù)支持服務(wù)，解決了一些html框架搭建，切圖等前端技術(shù)問題。

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

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

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