為什麼設計師也要學會判斷優先級？

 　　今天的案例也是同學們日常工作中會遇到的問題，如何兼顧業務目標和用戶體驗?這裡邊涉及到的判斷優先級問題，其實大有學問。掌握這個思路，相當於半個產品經理，以後和產品的爭執會大大減少，來自阿裡交互專家@劉津legene ，特別推薦閱讀。

　　我的主管經常對我們說：產品經理最重要的能力就是判斷優先級，不然就不叫產品經理，而是需求經理。以前我聽了總是不以為然，覺得判斷優先級就是優先做緊急的和實現成本低的需求，毫無技術含量;而設計師需要從用戶的整體使用流程綜合考慮，給出一個理想而完整的方案。所以很長一段時間，我都覺得產品經理大多是在做救火的事情，而只有設計師才有條件和能力從用戶的角度全盤考慮，從根本上解決問題。

　　直到今年遇到這兩件事情，我才有了不一樣的認識。

　　不會判斷優先級的悲劇

　　年初時，主管發動了一場關於易用性方案的PK活動。一個產品經理拿出了彈層引導的方案(在每個頁面都有若干引導)，當時我簡直笑壞了，心想這不是在破衣服上打補丁嗎，完全是治標不治本的做法;我拿出了自己的方案：從深層次分析易用性不好的原因，重新梳理流程，給出了一個全新的方案，該方案從根本上改進了易用性問題，使用流程大幅縮減，信息結構簡明易懂。當時我講完我的方案，收獲了全場的掌聲。很多人表示開了眼界，從沒想過還可以這麼做，也見識了交互設計的專業性。

　　但最後主管選擇了彈層的方案。理由是我們承辦了一個活動，短期內將有非常大量的用戶迅速湧入，而目前產品的易用性存在很大問題，我們必須在最短時間內以最小代價解決。兩個方案擺在面前，怎麼判斷優先級，不是看哪個方案好就選哪個，而是要圍繞業務目標。

　　我當時覺得主管說的也對，於是過了一段時間，我選擇提出離開，因為在目前的業務環境中實在找不到自己的位置。當然最後我沒有離開，也許是因為不想向困難低頭，覺得自己還有很大提升空間，早晚有一天會克服困難。

　　最近一段時間，易用性的事情又重啟了。因為之前經過幾個月“打補丁”的改進方式，易用性還是沒有很明顯的起色，主管很不滿意，讓我也進入這個項目好好看看。我覺得機會終於來了，是時候把我當時的思路和方案重新拿出來了(由於時間已經過去大半年，業務方面發生了很多變化，於是我的方案也有所更新，但思路基本不變，還是從整體使用流程考慮，給出較完整的方案)。

　　review的時候主管說不想看這些看似正確卻抓不住重點的東西，要看具體改進了哪些點。幸好我早有准備列出了一個list，裡面羅列了和線上相比具體的改動點。主管一條一條的看，問我：你覺得哪條是最緊急的，是有關業務生死問題的?我愣了一下，回答：幾乎都不是。主管說你們要把所有改動的list列出來，根據業務目標排好優先級，不然你們短期是一定拿不到結果的。

　　當時我很不解，我一直覺得用戶體驗是一個完整的過程，不是一個個零散的點。怎麼能用改bug的方式去改進用戶體驗呢。以前好歹我也做過幾年的交互設計，也沒出現過什麼問題，為什麼在這裡就玩不轉呢。

　　問題出在哪裡

　　我仔細思考了之前做交互設計的經歷，發現忽略了這樣幾個客觀事實：一是產品經理在向設計師提需求之前，其實已經分解並排好優先級了;二是改版和日常迭代往往是分開的，很多日常迭代的需求可能和界面無關，產品經理自己消化掉了;三是對於現在在做的復雜平台型產品，功能邏輯的設計遠大於界面影響，所以必須從表層使用問題滲透到功能層面，易用性問題才有解(對比流暢而完整的設計方案，功能是相對獨立的)。由於我們這裡產品經理和交互設計師的分工並沒有那麼明確，當大家共同own易用性改進這件事情時，我還在按照以前交互設計師的思路做事情，而沒有根據業務節奏排列優先級sense的缺點也就暴露無疑了。

　　產品經理側重於從產品整體角度(包括業務目標、功能邏輯、技術資源、用戶體驗)去考慮問題，並排列優先級;而設計師側重於在既定優先級判斷基礎上從用戶角度考慮界面設計。太過考慮業務目標，難免忽視了用戶體驗;而太過於考慮用戶體驗，短期內又很難達成業務目標。怎樣保證在產品設計過程中最大限度的不影響體驗，又能按照業務要求拿結果呢?這裡面其實大有學問。

　　如何圍繞業務目標及用戶價值判斷優先級

　　一、高風險的大手術還是低風險的物理療法

　　由於我們的產品有比較復雜的歷史背景，所以易用性問題非常突出：功能設計復雜而冗余、信息結構冗余、操作流程復雜缺乏引導，所以我們首先要面臨一個選擇：是根據收集到的問題逐一改進，還是整體重構。之前就這個問題，我和產品經理發生了巨大的分歧，我強烈建議整體重構，因為用戶的問題其實都是建立在目前糟糕的設計上的，所以不能哪兒痛醫哪兒，而是要抓住問題根源，徹底根除;而產品經理的意見是先改容易改的以及可以快速見到成效的用戶問題，這樣才能拿到結果。

　　其實從產品整體視角來看，答案很明顯：老用戶已經養成較穩定的使用習慣，且目前正處在商業化進程中，一切不容有失;而新用戶主動使用的場景還不明顯。所以小步快跑的方式是最穩妥的。但是如果是站在設計師的角度來看，就比較容易迷失在其中。這也是我之前一直強調的“眼界”和“格局”，說出來容易，但真正做到其實很難。

　　二、迭代開發與增量開發

　　現在我們已經確定不做整體重構，而是定期、快速的產出，那麼分解需求的標准、形式應該是怎樣的呢?正巧上周公司有一個相關的培訓，我聽了後覺得收獲很大。當時老師舉了一個例子：如果你有五塊錢，你又不想一下子花出去，你是拆成五個一塊錢，還是撕成五瓣呢?如果是拆成五個一塊錢，那每張一塊錢都是可以立即花出去的，而撕成五瓣的話，每一瓣都無法使用了。這也是迭代開發的精髓，即把大塊的需求拆分成獨立的、可交付的若干完整需求，再開發上線。

　　用一幅圖來說明(圖片來源於網絡)：

　　△ 迭代開發

　　△ 增量開發

　　迭代開發中，每一次的交付物都是完整、用戶可用的。如同上圖的蒙娜麗莎像，雖然第一幅圖比較粗糙，但是用戶可以看到完整的輪廓，不影響對整體的理解，而且過程比較可控，可以隨時修改;而增量開發中，每一次的交付物雖然精細，但對用戶來說不可用，必須全部完成才能拼成一個完整的、用戶可用的產品，且風險不可控，一旦發現之前的存在問題，也很難回頭了。

　　而學過繪畫的人也都知道，畫畫是先從輪廓開始、逐步迭代、精細化的過程，而不是增量的過程，除非是畫過千百次這樣的畫，已經完全胸有成竹。但顯然這對我們這樣一個創新型、充滿各種不確定的產品來說不太合適。

　　三、MVP原則拆分需求

　　現在我們已經確定要以迭代開發而非增量開發的形式來拆分需求了，那麼具體該怎樣分解呢?

　　在培訓課堂上我們做了這樣一個練習：聽課人員分成兩個小組，每個小組的成員分別在貼紙上寫出自己每天早上從起床到出門需要做的所有事情，組長把所有的內容匯總，再分類展示，得到用戶故事地圖：

　　老師問大家，整個過程大概要多久?大家回答：一個小時左右。老師說：假設有一天你起晚了，並且這一天你要參加一個非常重要的會議，不能遲到。現在你只有五分鐘的時間出門，你會從其中選擇哪些?

　　大家一致選擇了上廁所、刷牙、洗臉、換衣服、關門、鎖門這幾項。雖然大部分事項被省略掉了，但其實並不影響大家出門。這也就是MVP的理念，即“最小化可行產品”，它無疑是簡陋的、粗糙的，但是它是完整的、基本流暢的、用戶可使用的產品。這樣，既可以在最短時間內有所產出，又保證了用戶體驗的連續性(不至於因為砍掉太多功能而根本無法使用);同時使用這種方法，可以讓項目所有成員都看到一個完整的用戶場景，可據此快速討論出優先級，避免“只見樹木、不見森林”的情況，節省了大量的時間。

　　對於一個老產品的快速迭代，通過這種方法也可以快速判斷出功能的優先級。然後我們可以重點看該功能對應的用戶反饋，歸納出問題的核心原因，得出解決方案，再通過業務價值、問題程度、預計效果、開發成本等因素綜合判斷具體的優先級。

　　最後總結一下心得：以前我會認為排優先級是產品經理考慮的事情，設計高質量的方案才是設計師的事情。就好比我用專業技能打造一個完美的工藝品，我不應該因為對方買不起就自降身價，偷工減料。而現在我會認為根據市場需要判斷該產出什麼樣的工藝品，如何把握制作節奏，如何更快市場化才是最考驗能力的事情。與所有設計師共勉!