DIV CSS 佈局教程網

 DIV+CSS佈局教程網 >> 網頁腳本 >> WEB網站前端 >> 關於網頁技巧 >> 用戶體驗設計案例:產品策略、技術、運營和界面設計
用戶體驗設計案例:產品策略、技術、運營和界面設計
編輯:關於網頁技巧     

 隨著互聯網產品的不斷發展,越來越多的人意識到了用戶體驗的重要性,越來越多的公司成立了UED相關的部門,並且職位劃分已相當細致。但是UED中職能的劃分,卻大部分僅對接界面的層面。事實上,一個互聯網產品從策略的產生到最終上線,其中的每一個環節都可能影響最終的體驗。總結起來,筆者認為共有4個重要的因素會對最終體驗產生明顯的影響。它們是:產品策略、用戶界面、技術和運營。

  下面分別來說說這4個因素。在說明每一個因素的同時,會舉2個跟該因素有關的例子,一個是互聯網上的例子,另一個是日常生活中相似的例子。所有涉及到的案例,僅僅在我所能看到的層面(這意味著,我所描述的問題,在我看不到的層面上,可能是合理的做法,或者是有苦衷的),為了說明問題而設置,並僅代表我的個人觀點。

一、產品策略(對應職位:產品經理)

  策略是產品的靈魂。產品策略除了決定產品的具體功能外,還對體驗有重大的影響。不好的策略可能會傷害用戶體驗。

Web上的例子:騰訊拍拍的收貨提醒

  我曾在騰訊的拍拍上買過一件商品,在該商品發貨的當天,我登錄QQ,看到了這樣一個提醒:

  是在提醒我,賣家發貨了。因為這件商品是從廣州發出,一般的快遞公司到北京需要3天左右的時間,於是我沒理會這個提醒。

  但是,悲劇的是,發貨的第2天,我再次登錄QQ的時候,依然看到了這個提醒。同樣的提示貌似每天登錄都會看到,這其實已經對用戶產生了騷擾。但問題在於,我不是不想確認收貨,而是,我的貨還在路上,我根本沒有辦法“確認收貨”。於是我想,萬一我要是不小心用了中國郵政平郵,路上走20天,難道我要連續20天看到同樣的提示嗎…?又或者,我的貨物不幸遇到了什麼百年不遇的山洪、地震一類的,在路上多耽擱了幾天。這時本來我已經很郁悶了,卻還要天天面對這個煩人的提醒。並且這個界面上沒有明顯的“消息設置”入口,我並不知道能否關掉該提示,以及如何關掉。

  這顯然是由於產品策略而造成的體驗問題。

解決辦法:

  那麼,這個收貨提醒功能,應該如何設計呢?也許每個人都有不同的想法,我想了一個簡單的方法:

  首先,計算出從發貨地點到收貨地點的距離。然後,需要獲得一般的快遞公司送貨的速度,包括一般情況下可能產生的延時范圍(例如發達地區和偏遠地區的差異)。然後,大致計算出貨物在路上要走的時間。當賣家確認發貨後,開始計時,過了這個時間以後,再向買家彈出提示。如果可以跟快遞公司合作,取到快遞公司的物流數據,在買家簽收後再彈,會更加靠譜。並且在提示框內放置明顯的設置選項,允許用戶屏蔽該信息。如果彈出的信息對於產品整體策略來說很重要,不希望用戶輕易屏蔽,則可以考慮將屏蔽選項藏得深一些。

生活中的例子:中國大陸的交通信號燈

  “紅燈停,綠燈行。”這是我們在很小的時候就已經熟悉的規則。但是這句話是對於行人來說的,如果是機動車司機,其實規則並非完全如此。在《中華人民共和國道路交通安全法實施條例》中,第三十八條和第五十一條闡述了機動車轉彎時相關的規則,與本例有關的內容,總結如下:

1、要轉彎,需先占道。向左轉彎需先進入最左側車道,向右亦然。

2、綠燈時,可以左轉,也可以右轉。

3、紅燈時,只能右轉。

  但是這些策略與行人要遵守的規則會有一些沖突。如圖:

  首先,對於1號行人來說,在他行進方向為綠燈的時候,他首先要躲避從A車道右轉的a1,然後,前進過程中,又需躲避從B車道左轉的b1。如果A,B兩車道均有大量機動車排隊轉彎,理論上講1號行人在不闖紅燈、不與機動車搶行的前提下,永遠都無法成功走到路的對面。

  其次,我們看2號行人,這裡更加悲劇。當他馬上就要成功的時候,遇到了從C車道右轉的c1。但是,由於C車道旁邊的2個車道上的機動車正在等待紅燈,所以,它們會阻擋2號行人的視線(扇形部分是他的可視區域)。以至於,對於2號行人來說,C車道上究竟有沒有車輛要通行、有幾輛,以及下一輛車距離斑馬線有多遠,他根本就看不到!這意味著,他每次走到此處,都要冒著生命危險試探著跨越C車道。

  還有更悲慘的事情在後面。

  我們看3號行人。當他到達斑馬線的後半段的時候,隨時可能有機動車b1從B車道向左轉彎。而對於此時的3號行人來說,車將從他背後駛來!他或許完全無法預期,下一秒將發生什麼!

  雖然我們注意到,在《條例》中提到,以上情況下機動車轉彎時,必須是在“不妨礙直行車輛、行人通行”的基礎上進行。但是這個策略本身,很難操作和把握。出了問題也不容易界定責任。所以筆者認為,我們的交通信號燈系統的整體策略,是嚴重影響用戶體驗的(司機和行人都是用戶)。

解決辦法:

  因為存在上述問題,所以,有人發明了帶有箭頭的信號燈:

  這樣,我們按照行進方向,將不同車道的信號分開表示。如上例中,當水平方向有行人通行時,使用紅燈禁止水平方向A、B兩車道機動車轉彎,而保持水平方向其他車道暢通。同時禁止C車道機動車轉彎。這樣,行人就可以安全的通過斑馬線了。同樣,當允許轉彎時,使用紅燈禁止行人穿越。如此便可以保證雙方的安全和通暢。

二、用戶界面(對應職位:交互設計師、UI設計師、視覺設計師等)

  影響用戶體驗的第二個重要因素,是用戶界面。在這個層面上,流程、控件、交互、排版、視覺等諸多因素都有可能影響到最終的體驗。我們只選擇其中一個小的點來舉例。

Web上的例子:掌上百度Android客戶端

  「掌上百度」是百度較早推出的移動客戶端軟件之一。它將百度的幾個主要產品(如搜索、貼吧、新聞等)做到一個app中。能夠讓用戶在移動終端上使用百度的主要功能。

  但是個人認為,這個版本的掌上百度應用,僅僅是這幾個產品的簡單整合,在設計時並沒有充分考慮移動平台的特點。實際上該客戶端的使用體驗,並不比使用移動浏覽器直接訪問移動版網站好很多。我們僅提取1個簡單的點來說明該問題,請看截圖:

  這是該應用內置的一個常用網站列表。我們從UI上可以看出,該列表從文字大小、間距、排版等方面來看,依然在沿用傳統web的風格。但是,在傳統web上,我們多數情況下使用鼠標來進行操作。鼠標是一種比較精確的指向設備,這樣的排版,鼠標足以精確點擊。但是在移動設備上,我們需要使用手指進行操作。事實上,筆者用尺量了一下這些鏈接的尺寸,在我的HTC G7的屏幕上,每個鏈接的尺寸只有大約4mm×2mm的面積。這個面積,即使是對於女孩子來說,都難以對其進行精確操作。如果是對於手指相對粗大一些的男性,或者考慮實際移動過程中可能產生的干擾(如晃動的車廂),使用體驗就更差了,必須很小心才能夠點擊到想要的鏈接。

解決辦法:

  事實上,對於現行的Android和ios這類用手指操作的系統來說,列表或許應該考慮設計得寬大一些。比如百度知道的app:

  相對來講,每一級列表都比較寬大,可以在移動設備上比較容易的進行操作。

生活中的例子:電梯上的開關門按鈕

  我們平時乘坐電梯的時候,經常要操作電梯上的各種按鈕。主要的需求有2種,一種是進入電梯後選擇自己要去的樓層;另一種,是開門和關門(關門較多)。

  大部分電梯的操作界面上,開關門按鈕都是用圖形表示的,類似下面:

  但是,大部分電梯上的這兩個按鈕,使用了相同的圖形元素,只是方向不同。加上具體的箭頭樣式、兩個按鈕的排列方向並沒有行業標准,以至於這兩個按鈕長什麼樣,完全由電梯生產廠商決定。在實際操作過程中,我們並不能夠馬上分辨出這兩個按鈕的功能(左側是開門,右側是關門)。筆者每次進入一個陌生的寫字樓的電梯,想按關門鍵,都要遲疑一下。這不是一種好的體驗。

解決辦法:

  事實上,圖形並不一樣比文字更加直觀。兩個按鈕的識別性較差,可能是因為他們外觀太過相似。如果考慮換成漢字,或許會簡單明了得多,操作時幾乎不需要思考:

  (當然,這樣做的缺點是,降低了通用性,外國人看不懂了。所以這並不是最終的解決方案,還需繼續推敲。)

三、技術(對應職位:各種工程師)

  技術是實現產品的工具,也是產品正常運行的基礎。如果技術方面出了問題,同樣會對最終的體驗產生不良影響。這個因素中具體的表現也很多,如前端頁面對各種浏覽器的兼容性,代碼運行效率,服務穩定性等。涉及的范圍非常廣,我同樣只挑選一個點來說明問題。

Web上的例子:北京市房地產交易管理網

  在這個網站上,可以查詢到北京市所有新建商品房的相關信息,包括面積、銷售狀態、最高價格等。

  但是,該網站只在IE浏覽器中可以勉強正常使用(頁面排版部分亂掉暫且不計),如果使用Firefox、Chrome等浏覽器,不僅一些頁面的排版會亂掉,還會出現查詢信息無法顯示的情況。如圖所示:

  圖中兩個浏覽器打開的是同一個頁面。左側是IE的結果,右側是Firefox的結果。我們看到,在左側圖片的右下方,是很多花花綠綠的表格。而右側圖片,同樣位置則是一片空白。按照一般的思路,查詢出來的數據,應該是後端程序生成的,理論上不應該受不同浏覽器兼容性的影響。後來在查看該頁面的HTML代碼過程中,發現了這樣一行久違的代碼:

<script language=vbscript>

  我明白了。原來這個網站的編寫者,使用VBScript這種陳舊的技術將後端生成的數據填充到頁面中。但現行的大部分浏覽器只支持通用的Javascript,不支持VBScript。結果是,在非IE浏覽器上面,這些VBScript腳本無法運行,導致內容在前端看不見。這已經嚴重影響了用戶體驗。

解決辦法:

  使用更加先進,更加通用的技術來構建網站。

生活中的例子:北京某寫字樓的電梯

  筆者之前工作過的公司,在北京市的一棟神奇的寫字樓中。這棟寫字樓的電梯時常會出問題,我認為是技術問題,並且嚴重影響用戶體驗。比如:

  1、停在某一層關不上門

  這個時候大家只好走出電梯,換另外一部,或者走樓梯。

  2、有人下了電梯後提示超重

  注意,是下電梯後,提示超重。這個就很恐怖,想象一下如果是晚上,你上了電梯,你按了1層,發現電梯裡面還有一個人,他按了13層。然後到了13層以後,他下去了,這時候電梯提示超重… 好吧,會不會是有別的東西進來了…?太恐怖了…

  3、電梯正常運行,但是樓層提示卡住了…

  這種情況也很恐怖,就是,你能夠感覺到,電梯在運行,但是顯示樓層的數字停下不動了,比如,一直顯示停在20層… 結果開門後,你發現,是4層…

  4、自由落體
  這是最恐怖的一種情況,而且可能會威脅到乘梯人的人身安全。就是,電梯不受控制了,從高層掉下。但是幸好電梯會有一套備用的裝置,當速度達到一定程度後,備用裝置會啟動,防止電梯直接掉到地面去… 雖然該寫字樓有記載的電梯自由落體只有3、4次,但是,那真的是比做過山車還恐怖啊…

解決辦法:

  換一部技術上更有保障的電梯吧…

四、運營(對應職位:運營經理、客服、一部分manager等)

  一個好的產品,在擁有了好的策略、好的界面和先進的技術支撐以後,還需要配合靠譜的運營手段,才能夠真正使其擁有好的體驗。

Web上的例子:百度的域名

  一個網站該使用什麼樣的域名,我認為應該算作運營范疇。百度的名字取自辛棄疾的那首著名的《青玉案·元夕》,其中的“眾裡尋他千百度”在中國可謂家喻戶曉。所以用baidu.com作為域名,中國人很容易就可以記得住,是個好域名的典范。

  但是,百度旗下的一些產品,也曾使用過一些筆者認為不是很合適的域名。例如:

  樂酷天商城(rakuten.cn)

  這是百度與日本的樂天集團合作的商城網站,面向的是中國用戶。這個網站的產品策略和用戶界面都沒有什麼大的問題。但是唯獨,rakuten這種拼法,是日文的拼法。我想對於中國人來說,很難記得住,這也會損害用戶體驗。

  阿拉伯語版百度知道(zhidao.baidu.com.eg)

  這個應該是百度為了進軍國際市場而推出的產品,將「百度知道」這個在中國做的比較成功的產品搬到國外。我們不討論其產品策略和用戶界面,但是,zhidao這6個英文字母,對於埃及人(.eg是埃及的國家域名)來說,或許真的是不知所雲。我想他們的感覺可能跟我們面對rakuten時是一樣的。

  泰語版hao123(th.hao123.com)

  hao123網址之家也是中國的一個運營奇跡,作為網址導航站,它有很明確的目標用戶群,所以在國內很成功。但是,它的泰語版,並沒有注冊新的域名,而是在原域名的基礎上添加了一個二級域名。但是對於泰國人來說,hao這3個字母是否容易記住,同樣值得商榷。

解決辦法:

  筆者認為,域名的選擇需要考慮到產品特征、目標用戶群、地域文化等等因素。

  樂酷天商城,完全可以使用 lekutian.com 作為主域名(目前該域名也在樂酷天手中,但是會轉向rakuten.cn),這樣對於中國人來說更容易記憶。

  而那些國際化的產品,則應該考慮使用當地的表達方式,重新命名。而不是簡單音譯。就像是,Facebook可以譯作“臉譜”,但不能譯成“非死不可”。

生活中的例子:大學中的飯卡

  讀書的時候,食堂是我們最常去的地方之一。目前國內幾乎所有大學的食堂都是采用電子化管理,我們去吃飯,不需付現金或飯票,而是要刷卡。飯卡極大的提升了食堂付款的速度,也更加安全衛生,飯卡的開發者們也不斷的增加和改進各種策略和技術,使得大家在使用的過程中體驗更好。但是,僅有一個好的產品還不行,運營層面也會產生一些問題。

  北京某著名高校的飯卡有這樣一個策略:如果在一個自然日內,同一張飯卡累計消費超過一定的額度(如30元),則需要輸入密碼才能夠進行交易。這是一種很好的安全機制(在產品策略層面是很好的),它可以防止飯卡遺失或被盜後由於掛失不及時而產生大量的消費,使得持卡人的損失降到最低。

  但是這樣好的策略,在該校卻由於運營的問題而嚴重影響使用體驗。

  首先,新生入學辦理飯卡的時候,並沒有被告知存在這樣一個策略。亦沒有隨卡配備任何說明性的資料。

  其次,辦理飯卡時,密碼是隨機生成的(可能是為了提升辦卡效率,也可能是技術問題),由工作人員口頭告知持卡人,這導致了密碼本身對於持卡人來說不易於記憶,甚至有的人根本沒聽清楚工作人員在說什麼。而且修改密碼的程序很繁瑣。

  這兩個問題導致了,很多學生在首次遇到消費超額問題的時候,會不知所措。售貨員要求輸入密碼,但是持卡人根本不知道什麼是密碼。有的人雖然記得辦卡的時候工作人員告知過密碼,但是具體密碼是什麼,早就忘了。以至於支付流程受到阻礙,體驗嚴重下降,甚至很多時候由於實在想不起密碼而餓肚子。

解決辦法:

  這個案例的解決辦法很簡單,只要隨新卡配備一些說明資料即可,哪怕只是一張紙。

總結

  1、所謂「用戶體驗」是一個整體的感知過程,研發序列中的每一個環節都可能對其產生影響,所以它不應該僅由設計部門來考慮,更不應該僅局限在界面層面上。

  2、在某一個環節產生的問題,有些可以在其他環節上進行彌補(例如使用帶有箭頭的信號燈來彌補交通規則的不完善),有些則不行。

  3、如果真的想把體驗做好,應該存在一個類似「用戶體驗設計師」或者「用戶體驗經理」的職位,他應該至少是leader級別,跟其他環節的leader們有同等的話語權。他應該像產品經理一樣,在整個研發流水線范圍內針對用戶體驗進行總體的設計和協調工作。

XML學習教程| jQuery入門知識| AJAX入門| Dreamweaver教程| Fireworks入門知識| SEO技巧| SEO優化集錦|
Copyright © DIV+CSS佈局教程網 All Rights Reserved