設計師如何在團隊合作中獲得更多話語權？

 　　之前@5key 說了設計師該向產品經理學習的四個方面，今天聊聊如何在合作中掌握主動權。想改變被動現狀，一套好的流程方法非常重要，這份破開產品經理一言堂的干貨，從設計前期准備、開始設計到設計後期，每一階段都有細致入微的過程演示，同學們收好咯。

　　設計師、產品經理，兩個完全不同的角色，但有著一樣的目的：利用自己的專業不斷的改進產品，讓用戶更好的接受產品從而達到商業利益上的成功。

　　我從正面的角度講述了產品經理的優勢以及設計師應該從他們身上學到什麼。但事實上並非每個產品經理都是優秀的或者說是難合作的(設計師也一樣)，他們往往會因為各種原因而拋棄設計師的創意、想法。是的，這讓每位設計師都很不爽，就目前的觀察來看大致有這麼幾種情況：

　　產品經理一言堂

　　很多環境中產品經理是離商業最近的人，他們要背商業指標，而通常情況下設計師並不背。於是大家更多的把設計師當做“資源方”，認為設計師更多關心的是設計，而且這些設計只是拍拍腦袋想出來的。

　　如果設計方案正好和產品經理想象的一樣，恭喜你，產品經理會當著所有人好好的把你誇一通;如果不一樣，不好意思，他們會通過自己的優勢來證明你的錯誤。作為一個在大多數團隊擁有產品話語權的人，你的設計方案很可能就會被斃或者被改得支離破碎。

　　產品經理干預設計、甚至直接設計

　　設計師相對於產品經理來說算是一個較新的崗位，很多創業型公司一開始是並沒有設計師的。產品功能和頁面設計都是由產品經理一個人完成，所以你會看到一批全能型產品經理。隨著業務的擴大，公司也希望找到更為專業的設計師來幫助完善產品。

　　原本完整的產品“控制權”被重新分配，而產品經理由於工作慣性依舊會保持對產品設計的關注。在工作中他們有時會“忍不住”直接畫出交互稿，設計師要麼在其基礎上做“刷油漆”的工作;要麼新的設計方案會被他們各種挑戰。

　　人人都是用戶，產品經理也不例外

　　之前有本書叫做「人人都是產品經理」，在互聯網公司中它一定可以換成「人人都是用戶」。

　　絕大部分設計師所設計的產品都是大眾消費類產品，所以團隊中的每個人都可以代表用戶，而這個權利在產品經理這裡可能會被放大。這幾乎是每個設計師都會遇到的問題。

　　如果你的設計方案沒有滿足產品經理的預期，那麼他一定會戴上用戶的“帽子”並通過產品經理的“特權”企圖將你的設計方案扼殺在搖籃中。

　　產品經理設計的老板

　　在我看來這也許是設計師最悲哀的一件事情了。除了前面會遇到的問題，設計師還將面臨一個更大的問題 – 學習與成長。

　　有很多公司喜歡招聘從 BAT 出來的設計師，覺得他們非常的專業，這其實與他們所處的團隊有很大的關系。BAT 這類大型互聯網公司的設計團隊少則幾十人，多則幾百人。在如此龐大的專業團隊中設計師有機會學習到更多的專業知識，也有機會參與更為全局、系統的設計工作中。這自然也有機會讓設計師獲得更大的提升。而在絕大部分隸屬於產品團隊的設計師他們的成長是非常有限的，很多時候甚至只是一個畫圖的工具。

　　現實很殘酷，設計師不好當。其實即使在 BAT 設計團隊也並非所有設計師能夠在與產品經理的合作中獲得認可。但想要改變現狀也並非完全沒有辦法，一套好的工作流程、方法尤為重要。

　　簡單畫了張圖，列舉了一個項目完整的基礎設計流程：

　　設計前期准備：

　　01. 需求分析：

　　上期我們提到，這是設計師的起點。通過對商業需求的分析，我們需要將其轉化成設計需求並建立兩者間的聯系。確保設計方案是朝著解決商業需求進行的。

　　同步對象：產品經理、設計團隊

　　02. 競品分析：

　　我現在將競品分析分解成了商業競品和設計競品兩種。商業競品幫助設計師搞清同類產品的產品背景和設計師思路，設計競品幫助設計師將每種功能設計的方式爛熟於心，除了輔助設計還能在於產品經理的 PK 中提供支撐。

　　同步對象：全員(代指產品經理、開發工程師、運營人員、設計師等最小項目單位)

　　03. 用戶研究：

　　這是一個非常容易被忽略的環節。忽略的原因其實不是不知道，而是大家覺得沒有時間進行完整的用戶研究。

　　用戶研究在很多大的設計團隊都有專人負責，用戶研究員會負責訪談課題、用戶招募以及最後結論的分析。可惜除了大的設計團隊，很少公司會專門配備這樣一個角色來幫助完善產品。但這不代表我們不需要或者不能做用戶研究。前面我們提到過，互聯網時代人人都是用戶，所以你身邊的朋友、同事都可以作為你的研究對象。制定一些核心的訪談話題對他們進行一些調研，你一定能得到不少的信息輔助設計，讓你的設計更具有說服力。產品經理再以己代全的時候你可以拿出研究報告來告訴他你為什麼會這樣考慮。

　　同步對象：全員

　　開始設計：

　　00. 設計規范：

　　現在越來越多的團隊開始建立屬於自己的設計規范，這是基於系統平台(Web、App)、業務、用戶習慣建立的一套設計標准。有了這個才能讓我們的設計有根可循，讓設計更具有全局性和系統性。這個話題找機會單獨寫一篇，今天先不展開。

　　同步對象：全員

　　01. 交互設計：

　　基於前面的分析和研究，我們可以根據需求開始交互設計的工作了。其中有兩個重要的點上期也有講到過，UserFlow 和 SiteMap。確保在現有的商業需求和設計需求下完整的完成整個項目的設計。

　　同步對象：設計團隊

　　02. 用戶測試：

　　在完成交互稿設計後，一定要進行一輪用戶測試。有資源的可以邀請用戶測試，沒有資源也可以邀請同事進行測試。測試的目的一方面是是幫助自己找出設計方案中潛在的問題，同時也可以通過測試驗證設計方案的可行性。當遇到產品經理以自己為用戶對方案提出質疑的時候，你的測試報告和用研報告就可以牌上用場了。

　　同步對象：設計團隊

　　03. 交互評審：

　　通過用戶測試並對交互進行迭代後就要進行交互評審了。這是非常重要的一個環節，建議邀請所有項目成員(如果Boss 參加更好)參加。在評審會上你可以基於前期分析研究的結論闡述自己的設計方案，並將用戶測試反饋同步給大家。讓更多的項目相關方了解你的工作過程和設計思路。如果與產品經理在方案上出現較大分歧，其他角色也有機會參與到討論中，給予合理的建議。這對避免產品經理一言堂有很大的幫助。

　　交互評審的另一個關鍵作用就是讓技術方也盡早參與方案討論，避免由於技術限制導致設計方案的反復修改。

　　同步對象：全員

　　04. 視覺設計：

　　在確認交互設計方案並確認可行性後，視覺設計師可以介入進行設計。有了前面的共識，視覺部分的工作會相對簡單很多。不會再由於過多的交互方案改動導致視覺設計師時間的浪費。

　　同步對象：設計團隊。

　　05. 視覺評審：

　　如果可以在這個環節之前還可以再進行一次用戶測試，通過視覺對信息層次的處理和行動的引導用戶對於信息的理解將有一個新的認識。可以在開始之前准備好可能會被產品經理挑戰的問題進行著重的詢問。在評審的時候針對性的進行闡述。

　　同步對象：全員

　　設計後期：

　　01. 數據跟蹤：

　　在進入開發後，設計師需要進行對項目中核心功能、爭議點進行數據打點，確保項目上線後能夠能夠通過數據進行項目結果分析。

　　項目上線後提取相關數據進行分析，看看此次的設計是否達到了商業期望或設計期望。同時將可以需要關注和改進的點形成報告同步給大家。

　　同步對象：全員

　　02. 用戶反饋：

　　項目上線後(真實環境)可以再次邀請用戶進行用戶測試。可以著重就當初設計方案的爭議點進行訪談，看看用戶在真實使用中的感受如何。

　　如果這是一款 app，強烈建議要對當前版本在 AppStore 和 GooglePlay 的用戶打分和評價進行整理分析。如果有必要，你還可以借助 http://appbot.co 之類的工具幫助完成分析的工作。

　　同步對象：設計團隊

　　03. 項目總結：

　　等待用戶測試和數據反饋趨於穩定，我們需要花點時間進行項目結果分析。將整體結果和存在的問題進行歸納總結，在與大家溝通之前我們還需要針對現有的情況制定改進的方案。在總結分析的同時將自己下一步的改進策略同步給大家。

　　同步對象：全員

　　這是一個項目設計過程中一個完整的基礎設計流程。當然按照這套流程完成的項目並不代表就一定能得到好的結果(還有很多復雜的因素會影響結)，但設計的策略和方向不會有太大的問題。最重要的是讓項目所有相關人員了解你在使用科學的方法進行合理的設計。