2017-3-29 周周
網易UEDC – 何巖：本文是剛入行的交互設計師結合整個實際項目實踐，嘗試探討交互設計師和產品經理、其他上下游同事之間的“共生”關系，希望幫助設計新人找到與上下游配合的一點靈感。
（工作原因，文中配圖較模糊，請見諒）
產品經理才是最懂產品的人嗎？在項目初期，大家對產品的概念都很模糊，即使是產品經理也是通過來自各方的需求、數據和競品分析等來大致搭起框架。這個框架是否合理，框架衍生的功能流程限定在什么范圍，這些問題即使是最有經驗的產品經理也不敢保證。
交互設計師雖然是產品經理的下游，也應盡早參與策略層（Strategy）的討論，如果你的領導了解交互設計的重要性并且邀請你參加項目前期的務虛會議，你就應該珍惜機會，會前做好競品分析等準備工作，會上以交互崗位的專業(yè)視角提出建議； 如果你不夠幸運，不能參與到產品戰(zhàn)略決策，只是承接上游下達的交互任務的話，那么也不要只是淪為畫線框圖的工具，要發(fā)揮主觀能動性積極溝通，最終讓方案變得更好。
需要注意的是，我們的建議不要僅僅只局限在功能流程實現(xiàn)（Structure）和頁面結構（Skeleton）等方面，也要積極參與功能范圍（Scope）和產品愿景（Strategy）等方面的討論。
案例：項目前期產品經理往往會先畫一些草圖來幫助說明問題，這是一種很好的溝通方式，草圖能顯示對產品的理解和將來產品的發(fā)展方式。“網易帳號管家”作為一款多帳號管理工具，涉及安全檢測及操作引導、帳號保護加固、產品保護等功能，為了盤活產品還要在未來加入一定的運營內容。但產品經理前期的草稿只是將帳號功能簡單排列，這時候就要我們通過各種方法來表達自己對于產品的理解并給出建議。前期的定位非常關鍵，一旦架構錯誤，之后的交互工作很難開展。
總結：
產品經理不需要一個和他爭吵的交互設計師而是需要一個幫助他解決問題的人。很多文章都介紹產品經理和交互設計師的“相愛想殺”，其實，就像培根（Francis Bacon）說的：“人們創(chuàng)造了事實上并不存在的對立，并且他們也給這些對立強加上十分確定的新的名稱”。
不同產品經理的工作方式難免不同，開始合作的時候需要一些時間磨合，應該在磨合中一起找到解決問題的方法而不是互相抱怨甚至影響工作。其實如果大家目的一致并且足夠信任對方的專業(yè)能力的話，爭吵便會很少發(fā)生。
案例：有些產品經理喜歡畫流程草圖而不是以打磨PRD邏輯為主，這種工作方法可能在一些沒有專門交互設計師崗位的公司出現(xiàn)，但在設立專門交互設計師崗位的公司，產品經理可以專心的把PRD完善好。PRD是整個產品的權威依據，交互視覺開發(fā)和測試都要根據PRD行事。如果產品經理醉心于畫稿子，一方面會影響和限制交互設計師的思維，另一方面也會減少完善PRD的時間和精力，就會導致更應該關心的東西有所欠缺。
總結：
一個現(xiàn)實的情況是，PRD經常隨著交互稿的細節(jié)深入而不斷完善。雖然交互設計師“夢想著”PRD中有嚴謹完備的邏輯流程圖，但交互設計師都遇到過“一句話需求”，類似“我們需要加一個掃碼登錄功能”、“這個功能參照某某競品”等等。當產品經理的頭腦中沒有完整概念的時候，交互設計師是選擇要求產品經理回去想好再說，還是根據產品經理的“只言片語”、自身經驗和分析資料先動起手來呢？
案例：下面的文字是產品經理給出的同一帳號綁定不同設備時的“踢號”規(guī)則。其實，這段文字是經過思考的，已經比“一句話需求”好很多了，根據這段規(guī)則是可以進行交互工作的。但是根據經驗發(fā)現(xiàn)過程中恐怕還有很多細節(jié)需要考慮，這就需要設計師將需求轉化為解決方案的過程中將各個功能細節(jié)表述清楚了。
總結：
實際工作中我們會發(fā)現(xiàn)，并不是所有的功能敲定都會召開全員評審大會，有些結構簡單的功能和模塊只會和相關人員敲定，這時候如何使得方案不被部分人的意見左右而是符合產品整體風格和氣脈就顯得非常關鍵。
設計師不應該做“老好人”，滿足相關人員的需求而產出“這樣就好”的方案，也不應該攻擊或直接否定他人的創(chuàng)意，我們需要一定的溝通技巧，善用每個職能的優(yōu)勢，一版一版的優(yōu)化方案，在這個過程中不要忘記積極的給出建議。
案例：“網易帳號管家”中的“發(fā)現(xiàn)”模塊是重運營的部分，考慮到其中“幫助中心”的內容稍顯“枯燥”而且運營方式有限，設計師經過調研向運營同事建議加入頂部圖片輪播，這樣可以方便后續(xù)運營同事“揮灑”創(chuàng)意。同樣， 為了幫助運營搜集用戶反饋，底部加入了“問題反饋”、詳情頁底部加入了答案是否解決了問題的功能。運營同事經過思考也覺得這些功能有必要，便欣然采納了建議。
總結：
“沒事”，是指由于某些原因導致交互工作不能馬上進行的時候或是項目過程中特別是中后期交互工作沒那么緊張的時候?！罢沂隆?，是指在“沒事”的時候尋找一些項目的風險點或是其他可能幫助項目順利進行的工作。
風險點可能是前期由于時間等原因考慮的不夠細致的地方或是開發(fā)完成還沒有經過驗收的模塊和頁面或是一些極限情況的處理方式等?！皼]事找事”是一種主動尋找潛在問題和解決方法的工作態(tài)度，這種積極的工作態(tài)度是交互設計師體現(xiàn)職能價值和提升專業(yè)素養(yǎng)的關鍵。
案例：“網易帳號管家”項目分兩次迭代開發(fā)，在第二次迭代平穩(wěn)進行的時候，大部分交互設計工作已經完成了，這時候對已經完成的迭代一部分進行交互視覺回歸并產出文檔，就可以幫助測試同事和開發(fā)同事后續(xù)調整。
下圖是簡單的優(yōu)化點列表，問題的呈現(xiàn)形式不限，關鍵是要方便團隊中相關人員的理解和使用，如果真的幫到忙，同事也會給出積極反饋，這是團隊的良性循環(huán)。
總結：
提到敏捷開發(fā)往往想起小團隊，確實，隨著項目體量的龐大和參與人員的增多，“面對面”的溝通方式會變得困難，相信很多人都經歷過即使一個很小的Bug也要提工單走流程或者等產品經理提供需求文檔后才開工的“瀑布式”工作方式。
敏捷方法是方法論層面對工作方式和工作態(tài)度的探討，強調工作中“人”的作用而不是以“各種文檔”為準，強調同事之間的高度協(xié)作以及隨時準備應對變化的態(tài)度，這些是各種項目都必須思考的問題。
“ 網易帳號管家 ”項目組每天早上固定時間召開站會，全員面對面發(fā)現(xiàn)問題、解決問題、評估風險、把控進度。開發(fā)過程中各個職能同事坐在一起，關鍵問題的討論只需要召集相關人員“圍個圈兒”、“扭個頭”、“轉個身”就敲定了，之后發(fā)郵件周知大家。
這種看似“隨意”的解決問題的方式其實是一種扁平化的工作方式，強調“適應性”而非“預見性”，領導也坐在旁邊“召之即來”，所以節(jié)省了很多“等找某某商量一下再說”、“等領導看看再說”、“等審核批準了再做”的時間。
設計師往往帶點“潔癖”，為細節(jié)和綜合體驗操碎了心，但其實產品研發(fā)過程是否順暢、運轉模式是否健康甚至上線后成功或者失敗，這些是合力的結果，包括設計管理、開發(fā)管理等多方面因素共同決定了產品長成什么樣子。
所以，最后的經驗心得就是：設計師有時要被迫“放下”一些東西，不要讓自己“太累”。這也并不是教大家偷懶，而是要清楚給自己的職能定位。交互設計師溝通和處理問題的方式是靈活的， 這在上文有闡述，同時交互工作更應該是合作的，我們有自己的職業(yè)堅持，但也不要用“體驗”綁架一切。
無論是B端產品還是C端產品，好產品的成功是多方面因素的結果，設計師要有“百煉鋼”的堅持，也要懂“繞指柔”的智慧。
一個產品經理前輩說過，最好能在較大的公司孵化小產品中進行設計工作，經驗累積較快；其次是去創(chuàng)業(yè)公司單挑；最次是選擇去一個產品里做一顆螺絲釘，一直綁在某一個功能上。
這個結論正確與否姑且不論，但要真誠感謝交互團隊和業(yè)務團隊對一個新人設計師的信任，把這么重要的工作交給我，并且在工作中給予非常重要的幫助和指導。以上是整個項目走下來的一些感悟，寫完才感覺言辭稚嫩，希望大家一起思考討論，我們新人設計師共勉，今后工作中還要不斷錘煉。
藍藍設計( cqzjtgb.com )是一家專注而深入的界面設計公司，為期望卓越的國內外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務