起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識一名優秀交互設計師要思考的四類問題
對于交互設計師來說，除了專注于設計的規劃與執行外，我們更應該騰出一部分時間與精力去思考、去探索交互設計中的關鍵問題與關鍵環節，從認知層面提升自己。
做設計不是接到需求就埋頭苦干，也不是產品說一我不說二，而是一個先思考再動手、邊動手邊思考的過程。
在這個過程中，有些思考如果不夠全面或者深入，就有可能導致做出來的設計有漏洞，既影響產品質量，也對自己的專業進階無益。
為了能打磨好每一次設計，我整理了一些問題來幫助自己思考，各位交互設計師也可以試著在工作中用以自問。這些問題如果能找到答案，那就離優秀的設計產出也不遠了。
十八個問題，分了四組，不見得全面，但也能貫穿設計始終。
一、需求
1. 為什么要做這個需求，需求背景是什么？
要搞明白用戶在怎樣的活動場景下遇到了問題，然后產生了需求。這是從根本上去了解一個需求，也是最后驗證產品功能的地方。
2. 誰提出來的，是否是原始需求？
工作中設計師收到的需求有時候是二三手需求，經過多節點傳遞后，信息就容易失真。如果無法直接觸達用戶，最好能聯系到提出第一手需求的人。
3. 用戶有沒有未表達出來的需求？
用戶有時候只是描述困惑和問題，而不會專業地描述他們的需求。即使有描述也可能只是在表達表面層的問題，優秀的設計師需要能夠透過表面看到實質問題。
二、用戶場景
1. 這個功能用戶是怎么使用的，流程是怎樣？用戶平時怎么理解它，具體的場景是怎樣？
對于這個問題的挖掘其實非常重要。我們做產品做設計，其實就是幫助用戶解決在某個場景下活動中出現的問題。能夠清楚地知道用戶使用產品的習慣、方式和流程，了解他們對于產品的理解（用戶心理模型），能非常好地幫助我們在設計中有的放矢，而不至于去設計“我們覺得用戶會怎樣使用”的產品。
2. 什么人會用這個功能？
很多產品大大小小功能非常多，整個產品面向的用戶有100個的話，其中某些小功能可能面向受眾只有10個，而這10個人還和其他的用戶畫像可能并不完全一樣。那么做某些功能設計的時候需要重新思考，這10個人的用戶畫像特點是什么。
e.g： 一個主要面向HR用戶的人事管理系統，其中的某些功能公司的高層管理也會用，比如查看公司的組織架構。高管使用時的訴求和一般的HRBP是不一樣的。那么就這個功能，我們也需要再去了解一下這些高管用戶。
3. 有沒有找合適的用戶測試過，用戶調研中有沒有什么新的發現，用戶對于這個功能有什么未被滿足的期望？
如果不能接觸到最初產生問題提出需求的用戶，可以找身邊和目標用戶畫像重疊度較高的同事/朋友幫忙做非正式用研，一方面可以多了解他們在使用中的問題，另一方面可能會有新的發現和收獲。
4. 使用頻次、重要程度怎樣？
一個功能或控件在使用頻次和重要程度上的定位，會影響到它在產品/頁面中的位置、視覺突出程度、設計研發成本等。
5. 對產品中其他功能是否有影響？
有些功能并不是完全獨立存在，很可能不管是操作上還是數據上都和其他（頁面的）某些功能有牽連，那在做這個功能設計的時候，也要考慮設計出來會不會對與之有關聯的功能使用有影響。
e.g. 比如微信里，用戶把聯系人A、B和C分組為“家人”，然后發一條朋友圈對“家人”可見。那么如果用戶一段時間后在“家人”的標簽里加入了D，那么D還能看到之前那條朋友圈消息嗎？
6. 競品是怎么解決的，如果找不到競品，那么具有類似功能的產品是怎么解決的？
做設計也會偶爾沒有思路，或者陷入某個點出不來，再或者做出來后大家總覺得不滿意，這種時候都可以找優秀的競品看看。如果沒有直接競品，也可以就某個功能找有此功能的產品看。
三、控件
1. 是否能用現有控件完成？如果新增控件的話，必要性大嗎？有沒有其他地方會復用？
管理設計資源非常重要，一般成型的設計規范和控件資源盡量復用，避免沒有節制地添加新的控件和規范，不然容易影響到開發成本以及后期的控件維護。
2. 這個控件在操作時的各種狀態以及引起的各種變化是不是都想過了，通順嗎，全面嗎？
作圖的時候我們常常只做一些關鍵頁面來評審和討論，評審通過后繼續細化的時候才發現有些控件的變化狀態以及引起的頁面變化沒有考慮到，甚至會對已經通過評審的一些功能有很大影響。所以建議大家有自己的交互自查表（我也在嘗試整理，整理好后會分享出來），可以對照著檢查控件的每種情況、每種變化等都是否考慮全面，在頁面上能否跑得通。
e.g. 設計一個列表要考慮到空數據的展示、數據排列規則、新增和刪除數據的樣式、超出一屏的情況等等。
3. 自己想當然增/刪/改的部分，實際場景中會有可用之處嗎？
完成一個需求的時候，可能會根據自己的一些想法，額外增/刪/改點現有的功能，不是不可以，只是也要考慮一下，這種設計師自發的改動，放在實際場景中，是否真的適用，如果是的話那當然好，但如果不是就可能白費力氣了。
4. 會不會引起誤操作，會的話怎么避免？
控件的大小、位置、間距、顏色設計不得當的話都可能會引起用戶的誤解或者操作不便，從而導致誤操作，盡量從設計層面來避免。
四、檢查
1. 設計完成后
有沒有找合適的用戶測試過？
有時候自己做的設計怎么看怎么OK，即使是很有經驗的設計師，有時候一個功能做久了就不容易跳出來發現問題。做完后找身邊的同事/朋友幫忙看一看，說不定他們第一眼看出的問題和疑惑能給你新的啟發。
2. 這樣是不是就夠了？
很多需求我們可以用常規的方式去解決，最后得到的也很可能是一個中規中矩的方案，說不上不好，但也說不上多好。這時候可以再想想有沒有體驗更好、操作更便捷的方案，而設計師的進階有時候就是從這里的“多想想”開始的。
3. 自己有沒有先演示試用一下，看看實際效果能否跑得通？
做完設計稿不自己驗證一下就直接給開發是不太負責的。其實現在軟件聯動很方便，像Sketch上做完圖，可以直接導入Principle或者手機里點擊查看效果。確保能點擊的地方點擊后效果無誤等再交付給開發，也能避免后期返工。當然，如果是非常小的改動或者設計，自己確信可以腦補運行效果無誤也OK.
4. 設計文檔寫清楚了嗎，有沒有一些細小的改動需要特殊強調一下以免開發注意不到而遺漏？
設計圖搞定后，就要補充完交互文檔，這里會涉及更多的細節問題，交互邏輯說明甚至視覺標注等都要再三檢查是否做到了完整和通順。另外，如果有一些在原頁面/功能上的細小改動，建議可以用自己的方式強調一下，以免開發注意不到給漏掉。
e.g. 已經上線的某個頁面上只需要修改某個標題文字，開發很可能注意不到，我一般會在旁邊加個顏色反差大的箭頭以及文字說明指示一下。
5. 和開發溝通過嗎，開發可實現嗎？實現起來超出預計成本嗎？
有時候因為產品形態的不同，一些我們覺得想當然的效果，在開發看來并不是那么容易實現。比如我們在APP上司空見慣的一些效果，在H5頁面上實現起來就不一定容易，有時甚至會因為一些技術限制實現不了。所以在做完設計后可以讓開發提前review一下（尤其一些新設計的、不常見的交互方式）。當然，這個問題建議設計做完最后再想，以免前期給自己設限太多，影響設計發揮。
面對這些問題，就像“吾日三省吾身”一樣，常問自己常反思，既能提出問題又能解決問題，才能有助于進益。
不過這些問題挨個兒自問一遍其實也比較花時間，建議可以用在比較復雜或者棘手的需求上。而且也不一定要每次全過一遍，根據實際情況，酌情增刪就好。
作者：Vicol， 微信公眾號：略設小計
本文由 @Vicol 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 unsplash，基于 CC0 協議
- 目前還沒評論，等你發揮！
