幾乎所有的設計師同學在做方案評審時都經歷過撕逼大戰，有時東風壓倒西風，有時西風壓倒東風，無論如何，都令人身心懼疲。為什麼這樣子？專案組成員對設計的討論和挑戰，通常都是「自我參考」式的。無論是要做簡化去掉某功能還是要增加新功能，總會有人跳出來說這個功能對使用者（我）很重要，或者我覺得這個功能使用者根本不care，最後變成誰強勢誰就贏。當我們需要對一件事情提出意見時，習慣性的總是從自我經驗出發，主觀的下結論，這是一種追求效率決策的本能。我們總是擅於把毫無關係的兩件事情關聯起來，然後認為互為因果。但是這樣的聯絡可能是錯的，或者說可能被錯誤的套用。同樣的事情，在產出設計方案的時候也是時有發生，設計師從一個自我體驗式的方式去分析問題，在自我的糾結中，提出一個主觀的設計方案，俗稱“憋大招”。
設計師應該在漸進的洞見過程中掌握事實依據，以過程驅動設計方案演化，而不僅關注設計方案本身；設計師亦當是創意環境的塑造者，以一定的設計流程執行與團隊共建創新。設計需要以使用者心理、使用者行為相關的客觀事實為依據去執行，而非以一種自我體驗的方式進行論述。設計更多的是關於不斷地展望與想象不存在的體驗，設計師需要的是增強在現有配置下對未來多樣性的洞察力。
設計師應該做些什麼呢？在設計思維的流程定義上，都是大同小異，因為試圖體現的都是人類思維過程最普遍的發散收斂過程。以Design Council歸納的4D設計流程為例：包括Discover(發現)、Define（定義）、Develop（發展）、Deliver（執行）四個階 段。現存狀況是我們做的很多”設計”工作都是後面兩個D的執行，而在前兩個D的定義階段花了非常少的功夫。可以說這也是為了追求效率的一種下意識體現，把 功夫花在看似有確定性反饋的執行效果上。
然而後續有效的執行，一定是圍繞前期確定的一個明確的原則性的定義。這個定義需要不斷的被拿出來，作為執行方案確定與否的原則，並且來來回回基於執行的驗證反饋不斷被打磨更新，這就是動態的設計過程。
在設計過程中，有非常多的設計工作可以使用。比如說同理心地圖，使用者旅程圖和服務藍圖等。工具本身也是一種協同工具，讓專案組的成員可以基於共同的語言溝通－比如使用者，可以視覺化思考的過程，時時回溯，保證大家在一個明確的原則性上工作。在此環境中發散創新，找到創新。
設計過程中最忌諱的是拍腦袋，所有的設計應該都是基於事實依據來做出的判斷。事實依據很大程度上來源於使用者。很幸運的是閒魚一直很重視與使用者的互動，我們隨時從使用者反饋中知道產品的問題，並及時響應，進行修復，提升使用者體驗。
與使用者的互動不是簡單你問我答的過程，這樣不能建立一個高效，敏捷的解決問題的體系。為了更好的利用這些有價值的事實依據，更好的解決推進沉澱，閒魚找到了一套機制，幫助產品迅速迭代。
解決使用者體驗問題本質上是提升使用者體驗，除此之外，更高階的運用是利用問題來驗證設計，同時不斷在在問題中抽離出需求，最終設計師可以在使用者體驗問題中為產品找準目標，為設計找到方向。所以閒魚的這套機制專注於發現與解決問題，根治與利用問題。
閒魚發現問題的渠道主要有以下四個途徑：
-
紅草莓 紅草莓是閒魚內部長期回覆使用者反饋的機制，所有專案組成員輪流每天回覆使用者的問題，蒐集到的問題會流轉到對應的解決者。
-
微調研 微調研是每週會有跟使用者面對面交流的機會，拿著設計方案或是問題與使用者進行簡短溝通，獲得我們想要的訊息或是反饋。
-
社交媒體 （APP STORE/微博等）
-
自我發現
蒐集到問題後需要對問題進行分類，長期對問題的瀏覽發現，問題無外乎集中在以下幾個方面：使用者常用功能的反饋比如交易相關，不是必經的體驗流程比如設定，還有一類是視覺問題比如間距，字號，圖片變形等。因此我們把問題分為主體驗節點、其它體驗節點、設計規範三大類。為了更好地讓大家理解主體驗節點，我們又做了定義歸納。
問題分好類之後就需要組織相關人員一起來看這些問題，商量如何去推進。為了讓這個解決問題的過程變得高效以及常態化需要有“規矩”，可執行。因此我們確定了每週某個時間點開碰頭會，所有利益相關人要參與，比如介面的PD、開發、測試，最重要的是每次噴頭會下來需要對各個問題的解決時間有結論——能在哪個版本解決。
為了讓以上過程可被關注，設定了問題從發現到解決的幾個重要節點：
在討論過程中最容易引起分歧的是哪些問題該優先解決，不同角色對問題的認知是不同的，想要解決的迫切程度也不同，為了讓大家可以達成統一，我們設定了問題的重要程度分級，每個級別對應有具體描述，讓大家可以清晰定性問題。
當有了這一套可被執行的機制後，使用者體驗問題便可以輕鬆地運轉起來，每週或每個版本都會有一個完整的to do list告訴專案組成員有哪些體驗問題要解決。
問題發現後如果只是針對單個問題逐一擊破，我們會發現同型別的問題還是會接二連三出現，所以要想辦法找到這些問題出現的根本原因是哪裡，這樣才會讓問題越來越少，我們的解決問題的成本也會降低。通過問題不斷的積累，發現閒魚裡使用者反饋的大量問題都跟以下三點有關：
1. 狀態考慮不周全
通常設計中我們會忽略掉極限狀態的設計和異常狀態的設計，所以帶來使用者的反饋。通過整理發現上述兩種狀態多對應以下情況：
為了避免以後再出現同型別問題，整理了一個check list
2. 走查不到位
版本正式上線前，設計師都會對頁面的視覺進行走查，由於走查的過程沒有規範化的操作，很容易遺留一些盲區，導致版本帶著問題上線。為了避免走查不到位引起的問題，我們整理了走查清單，在走查過程中來使用。
3. 功能不全
由於閒魚是創新業務，很多功能都是從零開始嘗試，沒有任何參照，難免會有沒有思考到的場景，產品也是從雛形來時一步步迭代前進再完善。對於功能不全的問題，只能通過後續版本迭代的方式來完善功能，但不見得每個使用者的訴求都能滿足，我們可以把這些反饋進行分級處理，看哪些是急需解決，哪些是需要待驗證的。
當把體驗問題解決後，還需要去關注問題解決的效果如何，對業務，對使用者有沒有帶來實際價值。資料是驗證成果的有力證據。有些問題的解決可以帶來業務指標的提升，比如我們從使用者的反饋中發現了某個需求，當這個需求上線後帶來使用量的激增。有些問題的解決可以帶來問題的反饋逐漸減少。
對於結果的關注也可以形成一套機制，我們把它稱為使用者體驗量表。
體驗量表裡只記錄主體驗節點對應的頁面，每個頁面都會有對應的業務指標，這些是需要關注的常態資訊，是一個參考值，當我們對頁面做了新的功能或是問題的解決，會帶來資料的變化，同樣也會記錄下我們需要驗證的指標的變動，以驗證解決的效果。
閒魚使用這套機制已經有一年，整個過程中發現了145例問題，解決了106例。剩餘未解決的都是需要驗證或是不是閒魚重要使用者群體的訴求。
使用者體驗問題是設計師最常接觸到的外界資訊，以往他們都是碎片化的資訊，利用起來並不是很能體現本身的價值，當閒魚系統化運作這件事情後才發現背後的礦藏。不僅僅是提升了產品的使用者體驗，同時也提高了產品設計、開發的效率。大家不妨嘗試用用。