作為交互新人入職3個月，感覺既充滿機遇又面臨挑戰(zhàn)。在與項目一起成長的時間里，踩了很多坑，趁此機會記錄下來，希望對跟我一樣的交互新人有所幫助。第一次接觸需求時，產(chǎn)品經(jīng)理給了我2周時間。當(dāng)時拍腦袋一想，2周時間綽綽有余啊，開心答應(yīng)了。但后來執(zhí)行時才發(fā)現(xiàn)：這兩周中還有另一個項目需要并行；新的環(huán)境和項目需要了解磨合；前期有些遺留問題需要跟進……最后雖然按時完成了任務(wù)，但時間卻過得非常緊張。沒有計劃的時間永遠(yuǎn)不夠用，規(guī)劃時間并將其落實到書面可以時刻提醒自己提高效率。后幾期的工作中我開始規(guī)劃時間并覺得頗有成效。規(guī)劃時間可以從以下四步入手：· Setp 1：明確自己手里到底有哪些事情
工作之后，手里除了主任務(wù)還會有很多瑣碎的事情，比如開發(fā)跟進、需求變更、臨時會議等等。所以不論事情大小，首先得一件不落地明確自己手里具體有幾件事情。· Setp 2：確定每件事情Deadline
標(biāo)記號每件事情的Deadline。可以的話，最好在客觀Deadline前提下，給自己定一個更早的時間節(jié)點。這樣一方面可以督促自己提高效率，另一方面可以減小風(fēng)險，畢竟你永遠(yuǎn)不知道下一秒會冒出來什么事情來……· Setp 3：為所有事情排優(yōu)先級
排優(yōu)先級時可以根據(jù)自己的習(xí)慣，也可以采用常見的時間管理四象限法則（把工作按照重要和緊急兩個不同的程度進行了劃分，基本上可以分為四個“象限”：既緊急又重要、重要但不緊急、緊急但不重要、既不緊急也不重要 ）。需要注意的是除了安排好的計劃，還會時不時出現(xiàn)一些影響規(guī)劃的臨時任務(wù)。這時則需要考量一下我是否有時間和精力來接下這個任務(wù)，如果不確定的話寧愿事先說明也不要答應(yīng)后臨時完成不了。首先說一下產(chǎn)品的背景，我們產(chǎn)品的主要服務(wù)對象是移動應(yīng)用的研發(fā)團隊。產(chǎn)品的形態(tài)是由SDK和Web后臺構(gòu)成的。 當(dāng)時有一個需求場景是要在web端展示App版本列表，產(chǎn)品經(jīng)理提出要在web端增加一個手動添加版本號的功能。手動添加版本有很多不可控因素，比如出錯了需要刪除、添加的版本跟真實的版本不能一一匹配等。當(dāng)時心里有小人在打鼓說這個需求怪怪的會不會哪里有問題，但我還是硬著頭皮設(shè)計了一套手動添加版本的流程。
拿著這份設(shè)計稿跟找了幾個設(shè)計老司機幫我過稿，在老司機們犀利的地追問下，讓我意識到我真正要解決的問題是：得到這個版本列表而不是去設(shè)計一套添加流程。抱著新的目標(biāo)重新審視這個需求后發(fā)現(xiàn)，可以將規(guī)則設(shè)定為在SDK集成時自動獲取版本并將版本上報到web，這樣既能夠保證業(yè)務(wù)需求，又可以避免用戶的額外操作和出錯幾率。以上的例子，歸根結(jié)底的需求應(yīng)該是“一個完整的版本列表”，而產(chǎn)品經(jīng)理提給我的需求“手動添加版本功能”其實已經(jīng)是一種解決方案，且這個解決方案并不一定是最佳的，所以我們始終追問直到了解到需求根源為止。總結(jié)來說：產(chǎn)品的本質(zhì)是發(fā)掘問題，設(shè)計的本質(zhì)是解決問題。所以設(shè)計師應(yīng)該需要有甄別需求真?zhèn)魏妥穯栃枨髞碓吹馁|(zhì)疑意識，通過對比競品、跟產(chǎn)品經(jīng)理溝通、跟真實用戶溝通等方法可以幫助設(shè)計師做出判斷。一般來說，遇到以下幾種形態(tài)的需求時要特別留意：
（1）需求中只寫著“需要某功能”的時候
添加功能歸根到底是一種解決方案而不是需求。一般產(chǎn)品經(jīng)理會將真實需求和通過真實需求轉(zhuǎn)換出的解決方案一并提給設(shè)計師。但如果需求中只有功能點，而沒有為什么需要這些功能和期望這些功能幫助用戶解決什么問題時，就需要找產(chǎn)品經(jīng)理再三追問和確認(rèn)。
（2）需求來源于“產(chǎn)品經(jīng)理覺得”或“某個用戶覺得”的時候
這類需求很有可能是極少數(shù)人的需求。眾所周知的8/2定律在互聯(lián)網(wǎng)產(chǎn)品上體現(xiàn)在于：20%的功能滿足了80%的需求；80%的功能用于服務(wù)剩下20%的需求。所以當(dāng)需求的來源是個人時，尤其需要驗證這是不是真實用戶群體的需求。
（3）需求寫著“參考競品”的時候
經(jīng)常會陷入一個怪圈就是競品做了我們也要做。但其實可能競品與我們要解決的核心問題是不一樣的，或者競品的使用場景是不一樣的。所以即使是這種看上去大家都在做的真需求也需要針對自己項目的情況追問一下我們?yōu)槭裁匆觥?/section>（4）先解決問題再開始設(shè)計
確定了需求的真實性后，還應(yīng)該確認(rèn)當(dāng)前需求是不是通過設(shè)計功能或頁面就能最佳解決的。所以應(yīng)該首先以解決問題的態(tài)度看待需求，確認(rèn)需要通過設(shè)計解決后再進入設(shè)計階段。在設(shè)計“設(shè)置”模塊時，很多地方涉及到編輯。有的場景編輯是高頻操作，有的場景是低頻操作；有的場景編輯是很簡單一個按鈕，有的場景編輯包含大量表單。針對這些不同場景，操作項是始終存在還是Hover出現(xiàn)？編輯形式是在當(dāng)頁進行還是新開頁面？操作按鈕是以文字鏈的形式展示還是icon形式……等等問題就迎面而來了。 設(shè)計的過程也是一個平衡抉擇的過程。對于有經(jīng)驗的設(shè)計師來說，平衡抉擇可以是在腦海中對過往經(jīng)歷的瞬間過濾，然后直接得到解決方案；而對于一個設(shè)計新人來講，則可以從以下幾點入手：Setp 1：全面考慮
如果不能確定設(shè)計成什么形式那就都先在腦子里過一遍吧！這種全面的模式可以來自于自己日常的設(shè)計積累，也可以來自于書面的模式總結(jié)。比如在設(shè)計“編輯功能”時，《Web界面設(shè)計》一書中就已為我們歸納了編輯的6種常用模式：單子段行內(nèi)編輯、多字段行內(nèi)編輯、覆蓋層編輯、表格編輯、群組編輯，如下圖所示：Setp 2：結(jié)合實際場景篩選方案
結(jié)合具體需求，把第一步中羅列出的方法進行初步篩選。比如我在設(shè)計中的有一個場景是對列表中項進行編輯，這樣的需求場景是行內(nèi)編輯和覆蓋層編輯（模態(tài)窗口）都可以解決的，而其它編輯方法并不適合。所以經(jīng)過初步篩選后剩下了行內(nèi)編輯和覆蓋層編輯兩種方案。Setp 3：擇優(yōu)確定（QOC方法）
選擇方案時需要保證在主要目標(biāo)下，當(dāng)前方案優(yōu)點帶來的收益要大于缺點帶來的損失。沒有辦法明確判斷的時候，可以嘗試 “QOC（Questions, Options, and Criteria）”法。QOC方法可以幫助我們梳理方案的優(yōu)缺點，具體實踐方案是首先列出問題的備選解決方案和體驗評判標(biāo)準(zhǔn)；然后將解決方案在評判標(biāo)準(zhǔn)上的表現(xiàn)進行連線標(biāo)記；最后根據(jù)當(dāng)前場景中最注重的標(biāo)準(zhǔn)選擇表現(xiàn)最好的方案。
當(dāng)然，選擇最最優(yōu)方案時，讀書、競品和經(jīng)驗等等其它方法都可能幫助我們跳過以上三步，直接確定方案。需要特別留意的是在選擇當(dāng)前場景下最適合的方案時還應(yīng)該綜合考慮已有設(shè)計風(fēng)格的延續(xù)、其它場景下的統(tǒng)一性、未來的可擴展性、資源耗費（開發(fā)資源、運營資源等）等其它因素。任何工作都是一個熟能生巧的過程。走第一遍的時候多多少少會遇到一些問題，把這些問題記住，總結(jié)其中的規(guī)律就可以避免下次踩坑。這篇文章的作用，是給自己看的回顧，也是給其他人的避坑指南，希望有用。
作為一個交互新人，向交互老司機學(xué)習(xí)是進階路上必不可少的一步。接下來的兩周內(nèi)，我們邀請到了交互設(shè)計領(lǐng)域的大牛與大家進行線上分享，希望能對你有所啟發(fā)。
