首先我認為沒辦法完全量化設計師的績效，就像你沒辦法按代碼量或者加班量來衡量一個程序員的績效一樣。作為一種專業性的支持角色，衡量設計師的績效當然要看兩個方面：支持的好不好、支持的過程是否專業。那具體用什么標準去評判呢？

1，首先看他是如何對待問題的

如果只是產品經理或運營提需求他就直接做，那我們認為這是對待問題不夠認真。我們內部有一個處理產品需求的原則，在開始一項設計之前設計師需要評估的是：

1）拋開這個問題的表面，它背后的本質是什么？

2）我做的這個能為用戶和產品帶來什么價值？

3）這個問題的解決方案應該以什么指標來衡量（數據或調研反饋）？

4）做這個問題牽扯到的設計資源和工作量有哪些？

只有當經過這樣一輪Review，我們才能相信設計師能夠合理的對待他遇到的問題和思考如何去開展設計。當然除了對問題的對待方式外，我們還會看設計師主動挖掘問題的能力。比如設計師是否會經常走查產品流程，主動將用戶體驗上的問題或設計細節整理出來，在內部和外部討論并爭取資源改進等。

2，看他是如何思考解決方案的

很初級的設計師往往面對需求會憑借自己的大概感覺去思考，最多逛逛網站或玩玩其他產品，挑出一個自己滿意的進行改進和模仿，但是我們更看重的是”系統性有深度的思考過程”。

比如我們最近去做某App的GooglePlay商店截圖改版，會把直接的競品和相同類別下比較優秀的產品都打印出來橫向對比，然后去觀察這些產品商店截圖的兩方面：他們是如何敘述產品特點的？他們用什么樣的形似來敘述這些特點？通過觀察，我們會發現很多他們設計方式中的優點和缺點，還會找到讓我們靈感一線的創意，又或者能摸清楚這個新領域設計的規律等。一邊調研，一邊討論并記錄下來，才逐漸清晰出我們的設計方法。

再舉一個做視覺風格的例子，我們最近為歐美的年輕人做一款 App的視覺風格，先是把現在美國年輕人流行的App的市場狀況了解清楚，然后去觀察他們的設計趨勢，再之后是感受美國年輕人的流行音樂和時尚文化，甚至之前有的團隊還會出國去實地考察和訪談。后來我們開始動工做風格的時候就選擇了從他們喜歡的歌手和潮流符號的角度出發，做出了很多反饋不錯的方案。

我們并不是鼓吹要把設計過程都搞得這么復雜，或者有的人可能認為這是過渡的設計包裝。我們認為設計師的目標不僅僅是把任務做完，而是平衡所有條件和資源去把面對的問題真正搞懂和搞定，在這個目標下去把設計做的有深度和創新。所以我們衡量設計師能力最重要的手段，就是去考察他的工作思路和工作方法。

3，看他的設計溝通和跟進

設計師不能前期包裝做的很漂亮，但是作品出來之后就不管了，所以我們也要看設計師在后期執行層面做所做的努力。他是如何去說服需求方的？他是如何去協調資源保證設計落地的？他是如何與研發溝通確保實現效果的？這一點說起來含糊，但是實際卻可以有幾個考察點：

1）設計師在溝通的時候能否就事論事，平衡情緒，保持客觀；

2）設計師在溝通和推進的過程中是否能夠有條理有依據去闡述自己的想法；

3）設計師能否換位思考，靈活的轉換自己的角色去協助團隊的其他成員；

4）還有我認為非常基礎，但現在確很少有設計師具備的。就是設計上線是否有主動總結結果，觀察數據表現或用戶反饋去找到設計的問題并開展下一輪優化；

4，最后是看設計師的學習能力

如果一個設計師只是在運用相同的方法解決類似的問題，那頂多他的工作算是在復制粘貼，最后領個苦勞錢，但是一個設計師如果能不斷的突破自我獲得提升也是一個很好地加分項。這方面通常會有兩個角度去觀察：

1）解決了比之前更棘手的問題

比如說本來只是一個做界面適配的初級設計師，卻在承擔視覺風格定義這樣的大活下獨立扛下來了。即使你以嚴格的標準衡量他的處理過程發現還不夠成熟，但是他卻突破了自身的能力超出預期，這也算是一個很好的績效點。

2）通過思考或實踐學會了新技能和方法

這里的設計方法包含的比較廣闊，比如說一個設計師因為項目需要自學了動效設計，而且還做的不錯，又或者一個設計師因為接觸新領域（比如VR）了解到很多的相關領域的知識等，又或者跟進了一個用戶調研學到了很多用研方法等。通過這些學習他的能力廣度獲得了提升，那么他在團隊中發揮的價值潛力也相應的提高了。

講完了衡量標準，最后講講衡量的方法

這個問題問的是"如何量化UI/UE設計師的績效"，那題主一定是希望能找到一種非常簡單快速干脆的評估方法吧，但這是不可能的！對待設計師的工作不可能通過很簡單的指標就能下定論，你不能期望年終的收到一個漂亮的PPT，或者平時看看周報就能知道設計師是否做的好。

1）所以作為管理者，最靠譜的方法就是跟這設計師"一起設計"。平時觀察他們的設計過程，多問情況，多參與甚至多幫助，然后在這個過程中去你再去思考前面的標準來判斷設計師是做的是低于預期、符合預期還是超出預期；

2）直接看設計結果，通過觀察這個產品最后變成的樣子，加上管理者自身豐富的經驗就能大概明白背后設計師付出了怎樣的努力；

3）通過合作方的反饋，你能知道這個設計師平時的設計細節和溝通方法。當然這個的難點主要是你如何獲得真實的反饋；

4）通過設計師之間的互相review和評價能夠獲得跨領域的狀況，尤其是你是視覺對方卻是交互的情況下，參考一些更資深但無利益相關人士的意見變得尤為重要；

作者：馬力

總體來說沒有一勞永逸的辦法，不要指望通過簡單的數字和公式來衡量用戶體驗研究和設計團隊的產出。管理本來就沒法這么簡單，不然就不需要 Manager 的職位了，你想偷懶就肯定出問題。好的做法是讓最接近UE/UI團隊的的、最懂行的人來做出評價，可以融入一些用戶滿意度、縱向和橫向的可用性指標對比等等，但是不要完全依賴看似量化的指標。好多公司非常想要量化的績效指標，就是因為外行來評定內行、看熱鬧的評看門道的（沒有貶義，陳述事實）。
在績效評價上，IBM 的做法是由直接 Report 的經理來根據年初的目標（PBC）和年底執行的結果來做出評價，這些評價中有的還會在更高一級的管理層里討論，然后和員工1對1的直接溝通，給出最終評定。這個無論對于開發團隊還是UE/UI 都是一樣，我覺得這是個靠譜的辦法。具體不在這細說了。
海底撈的經驗里有一個很有意思，服務員們很有很大的授權，可以給客人贈送菜品甚至買單，有人就問了，怎么考核？通過什么流程、什么指標來防止這些服務員濫用權力？海底撈的回答是，一線的管理者們本身就曾是經驗豐富的服務員，他們很容易發現問題，這比一個看似安心的指標、流程更可靠。