*全文3000字左右，約花費您6-10分鐘左右讀完。
在設計實踐中，我認為很難用正確和錯誤來簡單評價設計方案。當然一定有很傻的，錯誤的方案，但是多數方案是游離在完美解決和剛剛能夠解決體驗目標之間的“差不多正確”方案。給出最合適的設計方案的首要決定因素在于需求溝通。美國通用汽車公司管理顧問查爾斯·吉德林說過：把難題清清楚楚地寫出來，便已經解決了一半。在我看來，只有把需求溝通清楚，才能基本保證最終設計方案的質量。
怎樣澄清設計需求，這一套方法并非我原創，而是在前司的WW老師和LV老師指導下，結合工作中踩過的坑慢慢領悟的。還不算全然掌握，只是做一個階段性總結與反思。接下來進入正題。
“
總的來說，設計需求需要搞清楚三樣東西：數據，邏輯，競品。
”
1- 數據：最原始的需求來源
設計不同于藝術，在我理解設計應當是通過創新和優化的方法解決現實的問題。問題就是我們日常面對的需求，數據可以理解為需求的原始來源。這里數據不局限于以數字呈現的數據，還包括原始用戶的語言描述，截屏記錄等。提出需求的人一般并不是傻子，但他們不站在交互體驗立場，提出來的需求不一定能解決真正的體驗問題。需求來源的原始數據是什么樣的，數據反映出的用戶場景和行為是怎樣，該場景下用戶的真實需求是什么，需求的影響面和優先級有多高，這是每一個設計師在溝通需求的時候最先要考慮的一個問題。
從設計思維角度來說，設計師必須考慮真實場景，從真實的用戶那里發現需要實現的體驗目標。傳統發現體驗目標的方法包括訪談，觀察等等，這些依然有效。舉一個例子，我有一次收到的一個需求是：將某個特定篩選浮層上的按鈕控件變矮一些。這個需求的體驗目標是什么？為什么要將按鈕變矮？影響到視覺一致性和可點擊區域問題怎么解決？向我提出需求的那位仁兄也說不清楚，只說這是某總提出的一個必須要修掉的問題。為確認需求的原始數據，我就直接找到某總，當面問他這個浮層上出現了什么問題。他對我說他使用這個浮層的時候，總有一行按鈕在屏幕外，這種展示很傻很不合理。問詢后我得出的結論是，用戶的原始需求是看不到最下面一行的按鈕，而并不是認為按鈕過高。按鈕樣式有整體一致性，也有可點擊區域的問題，因為一個浮層的顯示問題而創造一個新的樣式并不合理。而根據原始需求，設計上只需要調整這個特定浮層高度，或將浮層改為模態頁面即可解決。
互聯網產品擁有巨大而詳實的線上數據，通過不同的數據分析方法，可以窺探出用戶的行為、偏好、習慣甚至思維方式。針對各種各樣的產品有各種各樣的數據來源與分析方法，各個公司也有不同的取數規定，我并不算特別了解，因此不在此贅述。只是基于我有限的與數據打交道的經驗看來，設計對數據的理解不能僅限于線上數據及常規分析。設計解決的不是“這里數據不對我來試幾種方案fix一下”的工作，這種探針一樣的設計方法多半是抱著碰運氣的心態，靠直覺嘗試解決問題，并不是真正在做設計工作。數據真正體現的是用戶的場景和行為。在觀察日常數據的同時，需要結合訪談和觀察等用戶研究建立該產品對應的場景與用戶角色模型，梳理用戶的體驗流程。場景會越來越細，越來越具體；用戶角色也會隨著對日常數據的觀察分析及對真實用戶的洞察越來越具象。只有清楚了真實場景下用戶的體驗流程和痛點爽點，才能有的放矢，結合有效的設計方法做出能實現體驗目標的設計。
2- 邏輯：解決問題的思路
雖然被冠以“用戶體驗設計”設計者的名號，但交互設計師很多情況下處理并不是純粹感性的體驗，而是復雜的邏輯問題。流程圖是和線框圖并列的交互設計師兩大法寶。一個需求的交互邏輯是怎樣的，很大程度上決定了這個需求的體驗目標能不能被優雅而有效地實現。
但是梳理需求邏輯本身就是一件復雜的事情。一層一層撥開看，一個常見需求對應的邏輯包括業務邏輯，產品邏輯，技術邏輯，用戶行為邏輯，交互邏輯，視覺邏輯。交互設計師需要理解前四層邏輯，才能梳理出適合的交互邏輯。
理解前4層邏輯的復雜之處往往在于，跟你溝通的人并不理解其它層次的邏輯，他往往只能理解自己崗位下所需要的邏輯，以及由此得出的“他想要的交互邏輯”。這有時候會很可怕，往往會出現產品經理對你大吼大叫“我就要這個設計”，或者技術對你微微一笑“這個設計做不出來”。如果此時設計師也陷入情緒化，或者對需求層次理解的不清晰，往往機會是半天的雞同鴨講，然后出現一個折中的蠢方案。
為避免陷入這樣的僵局，交互設計師必須要清楚地知道自己此時在處理的需求邏輯是哪一個層面的，以及怎樣獲取正確的前四層邏輯。就業務邏輯來說，設計師不能只埋頭于設計，需要有一定的業務背景知識。這種知識不管是和業務交流需求的時候獲知的也好，還是從產品經理哪里挖出來的，或者結交幾個業務的小伙伴平時嘮嗑嘮出來的，甚至是讓領導安排去一線觀察得來的，總之必須能夠支持自己理解完整的業務邏輯。技術邏輯也類似，不過有時間精力的小伙伴還可以通過慕課網、w3school等等平臺自學一些技術知識以備撕逼之需。用戶行為邏輯可以通過數據和用戶研究建立。比較困難的是產品邏輯，這一層邏輯是關于產品目標，很容易和交互邏輯混淆。因此在這個層面更重要的是和產品經理本人的溝通，需要明確什么是他關心的產品目標，這個產品目標里的商業目標、用戶目標分別是什么，而體驗目標是在什么程度上實現商業目標與用戶目標的平衡，從而最合適地實現產品目標。在這個過程中，不宜過早地進入細節，這樣容易演變為“我就要這個交互方式”的爭論。此時需要確認產品邏輯后再結合業務邏輯、技術邏輯和用戶行為邏輯，梳理出合適的交互邏輯。
3- 競品：解決方案的參照物
競品不是拿來抄的。這是我想表達的第一句話。如果需求是“我就要抄這個競品”，那么設計時需要格外當心。當我們不了解競品的數據和邏輯的前提下，盲目照搬競品，那么設計完成之后應該做的就是燒香拜佛，祈禱這個競品的設計在我們的產品上也奏效。競品面對的場景、用戶和自己團隊的產品往往不會完全相同，并且競品也不能保證他的設計就一定是好的，照抄是很蠢的行為。
競品是可以用來抄的。這句話似乎與上一句矛盾，但這里需要強調的是，抄競品并不是照抄形式，而是“抄”解決問題的思路。交互設計本身就是解決交互問題，實現體驗目標的，就像思想不會專屬于任何一個人，交互思路也不專屬于任何一個產品。只要設計思路可以最好地解決當前問題，并非不能“抄”過來。抄形式容易陷入產品品牌特征不明顯，格調變LOW的囧境；而“抄”思路，通過一個更優的套路來解決當前問題，甚至優化競品的套路來實現整個行業解決方案的進化，并非是一件壞事。
因此，需求溝通的時候如果有可以參照的競品，將會更容易理解需求對應的設計思路。使用競品進行溝通時，往往需要注意競品的使用場景和用戶角色是否和自己的產品相對應。如果沒有對競品的細致研究和精心挑選，很容易陷入“當我覺得有用的時候就說競品也是這么做的，當我覺得沒用的時候就說競品做得不好”這層境地。競品長期使用或有數據支持或廣受業界承認的做法可以作為設計支撐，競品偶爾呈現或在測試之中的方案往往只能作為“靈感來源”，并不適合作為參考。總體來說，Best practice是否best并不好判斷，因此需求溝通時更需要注重的還是數據和邏輯的支撐。
此外還有一點，就是初步溝通完成后，在進行設計時如果有參考競品，最好是能夠保留競品的完整截圖或者錄屏。即便是放在文件夾或者單獨一頁備用集合里也可以，當后期設計方案發生爭執的時候，也好說明當初需求澄清時的邏輯以及設計時的思路。
以上就是我對設計需求澄清時基本思路的理解。經驗粗淺，也許總結得有失偏頗，這里只當是給各位同行一些思路，也許能提供一些幫助。
