應當避免一個產品變成產品經理自己的設計、或者某個領導拍腦袋的想法。作為產品團隊的一員，交互設計師有責任和義務進行需求調研，拿到第一手需求資料，而不是接受莫名而來的需求列表。

這個比喻有點形象，當需求經過多人之手，傳遞到設計手里經常都變了味道，貌似所有接觸過需求列表的人都喜歡改兩筆，尤其是初成長的產品團隊。

很多設計師都是坐辦公室里完成界面設計的。閱讀本文后，倒是希望大家能去看看你們的產品市場，用戶的使用場景，用戶的需要，用戶使用產品的想法，以及用戶的期望。

收拾下，申請外勤出差吧~不去看看真正的市場，你可能發現不到，團隊內有時候糾結的那些問題，對用戶實在太微不足道了。

在之前的文章《可用性測試：讓交互設計變被動為主動的利器》講過，設計師的的強大后盾是用戶，考慮他們的立場、思維和體驗，你的設計一定不會差。

設計師，你理解需求了嗎

我遇到的一個例子：

產品團隊糾結“用戶列表”功能界面是不是該新增一個按鈕叫做“用戶分組”。

為什么需要分組呢？

因為作為一個人員管理的工具，產品經理認為對于有相同屬性的人員是應該歸類為一個組，這樣，調閱一組名單可通過組名來選取。

很多同事也會認為，這個新需求就是在界面上加一個新增分組按鈕。如果用戶勾選了列表里的一批用戶名單，點擊新增分組，輸入分組名稱，分組就完成了。

好像這就是日常~

直到有一天，跑過現場的同事收集到了情報：

分組功能很多用戶不知道，也沒用過。他們只是按名字和電話搜索用戶而已。

會議上：

• “我們是不是要培訓，要教育用戶？”
• “是不是設計的不好用??？”
• “加個引導吧”

好了好了，別跑遠了。可能起初的需求就有點拍腦袋的意思，這個需求用戶并不覺得重要。

為避免上述情況，設計師最好領一下任務，任務做完，你就升級了~拒絕不合理需求，做有意義的設計。

產品需求到設計需求的轉化

產品需求大多是紙面的文字，excel表，word文檔，里面列出了產品需要的功能。我很好奇有多少人對產品需求提出過質疑，貌似每一個都超級重要。

這里我的經驗是，產品需求與設計需求是相關聯的，相輔相成，但并不等同。產品需求給了產品想要的功能模塊定義，優先級大多與研發周期掛鉤，優先級越高，說明越要最優先實現。

設計需求由主導產品的交互設計師確定，作為設計師的你需要進行需求轉化，依據重要性，使用頻次，層級關系等把產品需求轉化為可視化界面。這些可能不是產品經理直接能給你的，你也很難自己一個人搞定，準確無誤。

不要看到需求就一上來畫線框稿，先來需求轉化。

舉個例子：

產品需求是：用戶列表、業務1、業務2、結果分析四大模塊；每個里面還有細節的功能點，這說明產品經理構想出了產品大致的輪廓架構。

交互設計師需要理解相關概念，其次，問問為什么？

產品經理可能會說“這是第一版，后續還要考慮XX功能，,當前XX功能不考慮，如果某個地方用的好，我們可能考慮…”

我相信你問了，產品回答可能會有點模糊，尤其是少競品、從無到有、又要體現功能特色的產品。正式上線前，新生產品的功能塊、使用頻次、重要性、優先級等等產品經理自己可能也是模糊的，尤其是新手產品對產品的預期更不明確。

指望產品經理回答所有問題，他的壓力很大的。設計師們，我們的存在是解決問題的。

對于不明確的需求，我們可以找用戶。

別怕費時間，因為真的很有意義。

洞察需求方法一：通過“重要性-滿意度”調查得出設計重點

這個階段，設計師可以讓產品經理安排幾個用戶，進行簡單的測試。前期調研，哪怕人數少，也好過前期不做，后期找一堆人改。

把需求列表里幾個主要功能名稱，拿去給用戶看看。

1.可以做一個功能-重要性-滿意度列表，每一項進行打分。

重要度高，滿意度低的功能點，應該是設計的重點。

可以設定重要性、滿意度打分范圍均是0-10分，綜合分數表明機會所在，產品的機會就是用戶痛點，也就是對用戶很重要，但是用戶非常不滿意的功能項。比如，業務2，重要性得分：9，滿意度3，那么綜合得分：9+max（9-3,0）=15。之所以有max存在，是因為重要性比滿意度權重更高。如：

• 重要性10，滿意度0；（用戶覺得非常重要，但是非常不滿意）
• 重要性0，滿意度10；（用戶覺得不重要，但是非常滿意）

以上兩個，你覺得哪個是你的設計重點？

這里避免一個誤區，是直接相加。因為重要性的權重更高，重要的功能是設計的重點。對不重要的功能做過多的設計其實是沒抓住核心。

重要性-滿意度打分是常見的用戶調研的方法之一。具體分值指標，可以在調查表中設計并調整。

• 不重要，很滿意：屬于過度滿足，考慮減法或隱藏，別喧賓奪主（衍生或非核心功能的情況）；
• 很重要，不滿意：屬于用戶痛點，集中在痛點區域的一系列需求，都是設計要點。

大的功能模塊剛剛得出重要性優先級別排列，接下來，我們需要對每一項需求進行進一步拆分。如果這個事情是產品經理做了，那么設計師需要好好理解大功能下的小功能模塊是如何切入進去的。

洞察需求方法二：核心功能的細分，繪制“Job Map”

對核心任務的理解，可以設置幾個關鍵點串聯：

Plan：計劃——Execute：執行——Moniter：監控——Conclude：結束確認

來個栗子：德國博士Bosch，一個做電動工具的公司，把電動鋸產品的核心功能——鋸木頭功能，做了Job Map。

采用當面訪談、用戶調查、電話訪談、集中研討等多種方法，依據細分步驟，搜集用戶在每一步期望達到的效果（outcome）。每一個outcome，都是一個顧客需求。

收集并明確了需求，才可以定義設計指標，找出讓用戶提高工作效率的方法，或者設計出更便捷的流程。

總結

現在，明確產品的需求來源（1頁PPT）及需求內容（2頁PPT），來源大致是5W（調研的時間when、地點where、誰who、調研了什么what、為什么why），再做上面列出的需求洞察方法：重要性-滿意度分析痛點、或畫出Job Map。你就能夠明確需求，排除需求干擾項，推動你的產品設計思路。

搜集和篩選需求不止這兩種方法，以上兩種方法是我在工作實戰中的經驗總結，你可以利用這兩種方法的步驟，明確你的設計重點。

要明確你的設計重點，排查不合理需求。

可能，一些不合理需求并不是真的很不合理，只是不分析，它的重要性與層次會誤導很多人，這個把控就在你了，產品或交互設計師。

當然，只有洞察需求還是不夠的，我們還沒轉化完成。

對于每一個設計內容，都需要一個可衡量的指標，確定之后再考慮出圖流程與步驟。

后續我會再發一些經驗帖，上述僅是我個人偏好的方法匯總，當然方法不止這些，大家可以選取喜歡的方法進行需求采集與分析。感謝大家的關注。

本文由 @葛達尼尼 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議