最近做了一個項目，遇到一個經(jīng)典的用戶體驗案例，所以決定拿出來和大家分享一下。當然，因為涉及到項目保密的問題，所有素材都是我臨時重新制作的。由于只是用來說明問題，所以制作的比較隨意，難看了點，希望各位見諒。
這是一個h5套殼的手機APP設計，我所負責的部分是設計——我屬于設計外包，程序是客戶方自己實現(xiàn)的。當然，這個項目比較曲折，因為種種原因，到后期我并沒有繼續(xù)參與下去，然而，問題就是這么發(fā)生的。
關于那個引發(fā)慘案的切換按鈕，是一個極小的功能，小到我們平時都不會關注到，但是卻在主流程里的一個按鈕。這個按鈕只有兩種狀態(tài)，所以在設計上其實并不復雜。但是恰恰就是這么一個小小的按鈕，結(jié)果鬧出了大亂子。讓我們先來看看第一稿的樣子：
這個設計很土，但是功能性上，至少并沒有產(chǎn)生什么歧義。點擊按鈕，切換當前狀態(tài)，邏輯上非常容易理解。唯一的問題：丑！于是，調(diào)整了一個版本，提交了過去：
滑槽設計，設計中比較常見的方式，現(xiàn)實生活中也有原型，相對而言，比較容易理解。只是程序?qū)崿F(xiàn)上，為了圖效率，圖方便，效果打了很大的折扣。
這個版本提交完成以后，感覺這個項目太累，客戶對于用戶體驗這塊的干涉過多，卻又有很多問題。所以提交完了這個完整版本以后，果斷結(jié)單。后續(xù)的設計修改，移交給了客戶方的設計師——當然，費用上，也適當做了一些讓步，畢竟，這是由于我個人原因終止合作了——雖然提交了完整版本。
客戶設計師改的版本，我并沒太在意，想來是客戶希望這個按鈕能夠“高端大氣上檔次”，所以讓自己的設計改了個看起來復合時代潮流的扁平版本，但畢竟是個小功能，我也并沒有覺得問題有多大。但是，沒想到的事情發(fā)生了。
上線后沒幾天，當時對接我的pm突然找到我。堅稱我設計的這個界面結(jié)構有問題，要我找到問題改掉。我也納悶了，中規(guī)中矩的設計，怎么可能有問題。pm說是進入后的用戶完成主流程的概率太低，流失率很高。根據(jù)以前的經(jīng)驗，我判斷了下，應該是主流程里某幾個環(huán)節(jié)發(fā)生了問題。
于是，我說服了pm，讓程序在主流程的每個節(jié)點、每個功能按鈕里埋了采樣點，持續(xù)觀察了兩天，終于確定了問題——問題就出在了上面那個按鈕上。
拿著數(shù)據(jù)，找到了pm，告訴他，讓他們的設計師重新修改這個按鈕的設計，就能改善這個問題，看到了數(shù)據(jù)，pm將信將疑，讓設計又改了一稿。本以為事情到此告一段落了，但是沒過幾天，pm又來找我了，說問題沒改善，反而更嚴重了！于是我看了下他們修改的界面......
這個調(diào)整，簡直就是災難......pm表示無法和自己的老大交代了——畢竟，這個按鈕的設計是他們老大定的。于是拉著我去找了他們的老大。一翻解釋和交涉后，最后在客戶老大的深思熟慮下，又用回了第一稿（對于設計師而言，這個場景是不是很熟悉？）——當然，這次終于happy ending了，用戶的數(shù)據(jù)在新版本上線后，終于快速回升了——我不確定是否真的是因為這個按鈕方案的調(diào)整，但是我相信，應該是有很大關系的。
為什么這么一個很小的切換按鈕會出現(xiàn)這么大的問題？之前說了，這是一個很小的功能，但卻是主流程上的功能。但凡是功能按鈕，無一例外的是需要謹慎對待的——更何況是在主流程上的。
在任何功能性的頁面上，設計的核心是滿足功能的需求，美觀只能排第二位。功能的需求分幾方面：1、必須要為功能設計合適的UI；2、必須要讓用戶看到圖標后，對于圖標能夠無障礙理解，并正常使用。
第一個版本的設計雖然土鱉，但是至少不會出錯，用戶一看就知道，理解成本相對比較低。
第二個版本的設計似乎好看了一些，但是實用性上來說相對不高，并且實現(xiàn)成本上比較高。好在現(xiàn)實生活中，類似的滑槽設計比較多，所以理解成本相對也是比較低的。但是由于實現(xiàn)成本提升以后，為了妥協(xié)進度，去掉了滑動的動效，在某種程度上，其實是降低了用戶體驗的。
第三個版本，其實是第二個版本的一個簡化——應該說是所謂的“扁平化”，但是問題也由此出現(xiàn)了，“扁平化”之后，圖表意性被降低了，用戶看到這個按鈕的第一反應，是需要理解“這是個什么”？一旦理解成本提升了，那么歧義就會產(chǎn)生，就會干擾用戶的正常行為。所以，數(shù)據(jù)不好看，和這樣的調(diào)整脫不開關系。
至于第四個版本，原本是希望通過增加提示文字的方式提升“扁平化”以后帶來的圖表意性的缺失。但是事與愿違，問題反而擴大了：在這樣一個按鈕上，你無法分辨什么是當前狀態(tài)，什么是可切換的狀態(tài)。用戶理解成本再次提升，歧義變得更嚴重了。
所以，最終回到了第一稿，雖然丑，但是至少能夠說明問題。
總結(jié)了這次項目遇到的問題，以下幾點是值得思考的：
1、任何視覺設計方面的東西，都必須把實用與信息傳達放在第一位，美觀是其次考慮的問題；當然這不是說美觀不重要，而是在取舍的時候，這是一個衡量標準。
2、扁平化的確能夠去除不必要的視覺干擾，但是需要防止過度扁平后帶來的圖表意性的缺失；
3、設計的再好看，程序無法實現(xiàn)，依然是白搭。甚至由于不恰當?shù)耐讌f(xié)，會產(chǎn)生用戶體驗上的干擾。所以設計師的工作，并不是psd提交了就結(jié)束了。
4、沒有數(shù)據(jù)，就無法驗證設計的好壞。甚至出了問題，你也只能干瞪眼白挨鍋。所以，不重視數(shù)據(jù)的設計師，不是好運營；
5、這個項目并沒有做小規(guī)模的abtext，也正因為沒做abtext，所有調(diào)整，只能用正式版本做小白鼠，這種行為相當危險；
6、接外包的時候，最好有自己合作熟悉的程序員一起合作接整包。盡量避免接單包設計的單子，以免后續(xù)扯皮；
7、永遠準備好第一稿，萬一哪天第一稿復活了呢？
13450931319
微信登錄
QQ登錄
微博登錄
售前咨詢
