從打造最佳的用戶體驗設(shè)計到產(chǎn)品開發(fā)

今天產(chǎn)品設(shè)計碰到的問題就是許多專業(yè)人士(如視覺設(shè)計師、項目管理、營銷人員等),都已習慣將項目草圖、使用者訪問,和交叉測試拿來說事,掛羊頭賣狗肉稱自己是用戶體驗專家。但,用戶體驗設(shè)計并不是一種技術(shù),也不是一種工作。不是會畫幾張草圖、去問使用者幾個問題、或是做多版本交叉測試就行。
用戶體驗其實是一種管理和運用使用者互動數(shù)據(jù)的思維;用戶體驗設(shè)計是一種利用通過與團隊合作、與使用者交流來改進產(chǎn)品設(shè)計的管理流程。這項的工作不是純粹在設(shè)計,而是去根據(jù)產(chǎn)品的開發(fā)階段和成熟度去挑選合適的模式去采集數(shù)據(jù),并引導其他團隊成員去為改進產(chǎn)品造就最大的效益。
雖然,很多設(shè)計師都說自己很懂用戶體驗,因而常常在設(shè)計師完成設(shè)計一界面后,就丟到其他項目去,完全忽視了產(chǎn)品真正的設(shè)計處理使用者數(shù)據(jù)的核心價值。
然而,用戶體驗設(shè)計真正有那么復雜嗎?其實不必然。用戶體驗設(shè)計真正的重點在于通過實作來了解個別產(chǎn)業(yè)的使用者特性和產(chǎn)品需求,才能量身訂做合適的產(chǎn)品的開發(fā)流程。
說穿了,就是利其器、善其事。
首先,讓我們看看當下的用戶體驗設(shè)計問題有那些?
使用者中心(User-centered)就是跟使用者接觸
字面上看去是沒有錯,但是問題在于很多團隊的執(zhí)行使用者訪問和使用者測試的方法。
跟使用者接觸是必然的,但是戴上有色眼鏡就會有色差。重點不是在跟使用者接觸,而是…你跟使用者接觸時,都問了些什么問題?大部分的團隊都會拿東西給使用者試用,這是非常致命的錯誤!
當你把一個殘破的原型塞給使用者用,使用者能夠給你的回饋就已經(jīng)局限于這原型的邏輯性問題。而當你連解決方案、甚至使用者面臨的問題都還不清楚的時候,叫使用者去挑出互動的邏輯性問題,對你的設(shè)計是沒有太大的幫助。
這時你應(yīng)該思考的問題應(yīng)該是:
1)使用者面臨的問題是什么?為什么這問題很難解決?
2)使用者是誰?他們在使用產(chǎn)品上有什么限制?(例:如果對象是幼兒園孩童,你基本不可能叫他們在電腦前面坐超過十分鐘。請定義你的使用者群,英文稱為User Persona。)
3)使用者目前怎么解決問題?用那些產(chǎn)品?(例:紙筆?筆電?云端平臺?)
4)使用者在使用現(xiàn)有的產(chǎn)品遭遇到了什么樣的困難?
5)最重要的是:使用者目前的喜好和厭惡,到底是工作本身的特性,還是現(xiàn)有產(chǎn)品設(shè)計的特性?
理清這五點,是幾乎所有人都必經(jīng)知道的基本要點。
打個比方,如果今天你要設(shè)計一套分數(shù)加減的教學軟件,而你觀察一學童用以下方式學習解題:
1 / 3 + 1 / 2
=(1 x 2)/(3 x 2)+(1 x 3)/(2 x 3)
= 2/(3 x 2)+ 3/(2 x 3)
= 2 / 6 + 3 / 6
=(2 + 3)/ 6
= 5 / 6
看到這樣的解題方式,你可能會想到用互動式設(shè)計讓學生可以輕易地輸入解題的下一步,對不對?
但事實上,這種"互動式"設(shè)計并不是"分數(shù)加減"的特性,而是"紙筆運算"的特性。如果搬到了產(chǎn)品應(yīng)用上,這種互動式式設(shè)計不但浪費很多瀏覽空間,還增加了操作的困難度。反觀,如果用拖曳式界面去幫助學生了解分數(shù)占一圓圈的比例,和加減后的比例改變,可能會更適合學生學習。畢竟,圓圈比例的視覺變化比互動的公式更符合分數(shù)加減更易懂。(純舉例,若你今天做的是評量系統(tǒng)需要使用公式,那當然另當別論。)
在了解使用者面臨的工作之特性、以及現(xiàn)有解決方案的特性,你應(yīng)該進行所謂的環(huán)境探勘(Contextual Inquiry),讓使用者在現(xiàn)有的環(huán)境中不受干擾地工作。直到數(shù)據(jù)采集完前,你都不應(yīng)該對使用者提問。你應(yīng)專注觀察使用者的工作方式和行為、情緒,以準備在實驗結(jié)束后后提問。你甚至可以采用口述協(xié)定(Think-aloud Protocl),要求使用者在實驗過程中必須口述自己的一舉一動,幫助你了解他們的思考過程。
情境分析聽起來很容易,但是在每種產(chǎn)業(yè)、每種工作環(huán)境,都有許多值得注意、分析的慣性行為,必須通過不斷累積經(jīng)驗才能夠熟練。
所以,切忌在尚未深入分析問題和解決方案的情況下就先拿出原型去引導使用者。在了解使用者面臨的問題以前,設(shè)計什么原型都言之過早。
什么時候該做線框圖,原型設(shè)計和開發(fā)?
上面其實已經(jīng)依稀提到,很多團隊最大的錯誤就是在不了解情況的時候一開始就動手做原型、畫草圖,以至影響使用者行為而無法確切分析使用者碰到的問題何在。
所以到底應(yīng)該什么時候畫草圖、什么時候做原型?又什么時候開始開發(fā)第一個版本呢?
其實這不是什么太高深的學問:
1,探索期:如果你還在探索使用者的行為與工作環(huán)境,那請先什么都不要做。先觀察、先聆聽、先分析,而且越少干預使用者越好!你此時的目標只是要搞清楚情況以避免重蹈覆轍。
2,構(gòu)思期:等到了解問題癥結(jié)后,請針對使用者面臨的工作之特性(而不是過去的產(chǎn)品之特性)來設(shè)計你的解決方案的概念。此時,你可以畫畫草圖。請記得,草圖的意思就是簡單的構(gòu)架圖,作畫請在十張以內(nèi),以簡單扼要為原則去傳達產(chǎn)品的概念。請不要洋洋畫出三四十張草圖去解釋細部的互動過程!花這么多時間畫圖是在浪費時間和團隊資源。
你此時的目標就是要為產(chǎn)品找一個大方向。
3,規(guī)劃期:既然草圖要在十張以內(nèi),這意味著當草圖已經(jīng)修改到概念能夠被使用者接受后,在用畫圖的方式去解釋細部的互動功能很浪費時間,此時請改用原型設(shè)計。原型簡單來說就是一種虛擬的展示品,用來假性地展現(xiàn)部分的互動功能和商業(yè)邏輯(Business Logic)。重點在于"假性"二字,所以請用簡單的內(nèi)容和交互設(shè)計去達到目的。在這階段,請不要浪費時間在解決什么使用者登入、數(shù)據(jù)庫構(gòu)架等技術(shù)性問題。原型設(shè)計只求快、準、狠!
你此時的目標是要了解產(chǎn)品各功能背后的邏輯可行性。
4,執(zhí)行期:設(shè)計的原型得到很多使用者的認同后,現(xiàn)在你面臨了一個問題:把這東西做出來到底要花多少時間?需要多少資源?是否能夠分段進行?或是平行分工?原型提煉出來的核心功能點就能為接下來的開發(fā)工期的大致做個估算。
此時,你可以開始和團隊商討如何去開始開發(fā),把產(chǎn)品的1.0版本做出來。原型最重要的定義就是為接下來所有配合制作開發(fā)的團隊其他成員做了一個明確的功能點定義開發(fā)。
例如我們平臺的流程:
原型(產(chǎn)品經(jīng)理):明確產(chǎn)品功能點開發(fā)需求,定義第一個版本核心業(yè)務(wù)流程開發(fā)。
設(shè)計(UI設(shè)計師):在產(chǎn)品經(jīng)理定義的原型之下將產(chǎn)品從視覺交互方面做更完善的用戶體驗設(shè)計。
前端(前端工程師):不管是PC端還是APP端都需要一個好的前端工程師去和后端開發(fā)做鏈條處理。
后端(后端工程師):整個產(chǎn)品的系統(tǒng)開發(fā),產(chǎn)品的使用邏輯的定義,以及功能點的使用操作實現(xiàn)。
測試(測試工程師):任何一款產(chǎn)品開發(fā)出來都不可能沒有Bug,需要測試工程師利用專業(yè)的技術(shù)來發(fā)掘。
最后就是激動人心的一刻,你的好友【產(chǎn)品1.0版本】已經(jīng)上線!
