新人入職3個(gè)月，有幸參與到一個(gè)新項(xiàng)目，感覺既充滿機(jī)遇又面臨挑戰(zhàn)。在與項(xiàng)目一起成長(zhǎng)的時(shí)間里，踩了很多坑，趁此機(jī)會(huì)記錄下來，希望對(duì)跟我一樣的交互新人有所幫助。

1. 本來認(rèn)為綽綽有余的時(shí)間變得緊張

第一次接觸需求時(shí)，產(chǎn)品經(jīng)理給了我2周時(shí)間。當(dāng)時(shí)拍腦袋一想，2周時(shí)間綽綽有余啊，開心答應(yīng)了。但后來執(zhí)行時(shí)才發(fā)現(xiàn)：這兩周中還有另一個(gè)項(xiàng)目需要并行；新的環(huán)境和項(xiàng)目需要了解磨合；前期有些遺留問題需要跟進(jìn)……最后雖然按時(shí)完成了任務(wù)，但時(shí)間卻過得非常緊張。

【解決方法】將規(guī)劃時(shí)間并落實(shí)到書面

沒有計(jì)劃的時(shí)間永遠(yuǎn)不夠用，規(guī)劃時(shí)間并將其落實(shí)到書面可以時(shí)刻提醒自己提高效率。后幾期的工作中我開始規(guī)劃時(shí)間并覺得頗有成效。規(guī)劃時(shí)間可以從以下四步入手：

Setp 1：明確自己手里到底有哪些事情

工作之后，手里除了主任務(wù)還會(huì)有很多瑣碎的事情，比如開發(fā)跟進(jìn)、需求變更、臨時(shí)會(huì)議等等。所以不論事情大小，首先得一件不落地明確自己手里具體有幾件事情。

Setp 2：確定每件事情Deadline

標(biāo)記號(hào)每件事情的Deadline?？梢缘脑?，最好在客觀Deadline前提下，給自己定一個(gè)更早的時(shí)間節(jié)點(diǎn)。這樣一方面可以督促自己提高效率，另一方面可以減小風(fēng)險(xiǎn)，畢竟你永遠(yuǎn)不知道下一秒會(huì)冒出來什么事情來……

Setp 3：為所有事情排優(yōu)先級(jí)

排優(yōu)先級(jí)時(shí)可以根據(jù)自己的習(xí)慣，也可以采用常見的時(shí)間管理四象限法則（把工作按照重要和緊急兩個(gè)不同的程度進(jìn)行了劃分，基本上可以分為四個(gè)“象限”：既緊急又重要、重要但不緊急、緊急但不重要、既不緊急也不重要 ）。我一般按下圖安排自己工作的優(yōu)先級(jí)：

需要注意的是除了安排好的計(jì)劃，還會(huì)時(shí)不時(shí)出現(xiàn)一些影響規(guī)劃的臨時(shí)任務(wù)。這時(shí)則需要考量一下我是否有時(shí)間和精力來接下這個(gè)任務(wù)，如果不確定的話寧愿事先說明也不要答應(yīng)后臨時(shí)完成不了。

Setp 4：將時(shí)間規(guī)劃落實(shí)到書面

通過以上三步將時(shí)間規(guī)劃好之后，一定要書面記錄下來。記錄的方式有很多，可以寫個(gè)條紙條給自己看；但是最好的方法還是使用Google Canlendar、Excel等可以分享的工具，將時(shí)間規(guī)劃同步給導(dǎo)師、主管和團(tuán)隊(duì)，讓相關(guān)的人知曉計(jì)劃、進(jìn)度并進(jìn)行監(jiān)督，這樣也能很大程度的避免拖延癥和懶癌。

2. 沒有甄別偽需求，導(dǎo)致工作量浪費(fèi)

首先說一下產(chǎn)品的背景，我們產(chǎn)品的主要服務(wù)對(duì)象是移動(dòng)應(yīng)用的研發(fā)團(tuán)隊(duì)。如下圖所示，產(chǎn)品的形態(tài)是由SDK和Web后臺(tái)構(gòu)成的。

方式：

1. 將SDK集成到移動(dòng)應(yīng)用中；
2. SDK幫助App使用者執(zhí)行一些任務(wù)并獲取相關(guān)數(shù)據(jù)；
3. SDK將數(shù)據(jù)上報(bào)到Web；
4. Web對(duì)數(shù)據(jù)進(jìn)行管理或?qū)DK進(jìn)行控制。

當(dāng)時(shí)有一個(gè)需求場(chǎng)景是要在web端展示App版本列表，產(chǎn)品經(jīng)理提出要在web端增加一個(gè)手動(dòng)添加版本號(hào)的功能。 手動(dòng)添加版本有很多不可控因素，比如出錯(cuò)了需要?jiǎng)h除、添加的版本跟真實(shí)的版本不能一一匹配等。當(dāng)時(shí)心里有小人在打鼓說這個(gè)需求怪怪的會(huì)不會(huì)哪里有問題，但我還是硬著頭皮設(shè)計(jì)了一套手動(dòng)添加版本的流程。

拿著這份設(shè)計(jì)稿跟找了幾個(gè)設(shè)計(jì)老司機(jī)幫我過稿，在老司機(jī)們犀利的地追問下，讓我意識(shí)到我真正要解決的問題是：得到這個(gè)版本列表而不是去設(shè)計(jì)一套添加流程。

抱著新的目標(biāo)重新審視這個(gè)需求后發(fā)現(xiàn)，可以將規(guī)則設(shè)定為在SDK集成時(shí)自動(dòng)獲取版本并將版本上報(bào)到web，這樣既能夠保證業(yè)務(wù)需求，又可以避免用戶的額外操作和出錯(cuò)幾率。

【解決方法】明確需求本質(zhì)

以上的例子，歸根結(jié)底的需求應(yīng)該是“一個(gè)完整的版本列表”，而產(chǎn)品經(jīng)理提給我的需求“手動(dòng)添加版本功能”其實(shí)已經(jīng)是一種解決方案，且這個(gè)解決方案并不一定是最佳的，所以我們始終追問直到了解到需求根源為止。

總結(jié)來說：產(chǎn)品的本質(zhì)是發(fā)掘問題，設(shè)計(jì)的本質(zhì)是解決問題。

所以每次接到需求時(shí)有以下幾點(diǎn)需要注意：

1. 質(zhì)疑意識(shí)

設(shè)計(jì)師應(yīng)該需要有甄別需求真?zhèn)魏妥穯栃枨髞碓吹馁|(zhì)疑意識(shí)，通過對(duì)比競(jìng)品、跟產(chǎn)品經(jīng)理溝通、跟真實(shí)用戶溝通等方法可以幫助設(shè)計(jì)師做出判斷。一般來說，遇到以下幾種形態(tài)的需求時(shí)要特別留意：

（1）需求中只寫著“需要某功能”的時(shí)候

添加功能歸根到底是一種解決方案而不是需求。一般產(chǎn)品經(jīng)理會(huì)將真實(shí)需求和通過真實(shí)需求轉(zhuǎn)換出的解決方案一并提給設(shè)計(jì)師。但如果需求中只有功能點(diǎn)，而沒有為什么需要這些功能和期望這些功能幫助用戶解決什么問題時(shí)，就需要找產(chǎn)品經(jīng)理再三追問和確認(rèn)。

（2）需求來源于“產(chǎn)品經(jīng)理覺得”或“某個(gè)用戶覺得”的時(shí)候

這類需求很有可能是極少數(shù)人的需求。眾所周知的8/2定律在互聯(lián)網(wǎng)產(chǎn)品上體現(xiàn)在于：20%的功能滿足了80%的需求；80%的功能用于服務(wù)剩下20%的需求。所以當(dāng)需求的來源是個(gè)人時(shí)，尤其需要驗(yàn)證這是不是真實(shí)用戶群體的需求。

（3）需求寫著“參考競(jìng)品”的時(shí)候

經(jīng)常會(huì)陷入一個(gè)怪圈就是競(jìng)品做了我們也要做。但其實(shí)可能競(jìng)品與我們要解決的核心問題是不一樣的，或者競(jìng)品的使用場(chǎng)景是不一樣的。所以即使是這種看上去大家都在做的真需求也需要針對(duì)自己項(xiàng)目的情況追問一下我們?yōu)槭裁匆觥?/p>

2. 先解決問題再開始設(shè)計(jì)

確定了需求的真實(shí)性后，還應(yīng)該確認(rèn)當(dāng)前需求是不是通過設(shè)計(jì)功能或頁(yè)面就能最佳解決的。所以應(yīng)該首先以解決問題的態(tài)度看待需求，確認(rèn)需要通過設(shè)計(jì)解決后再進(jìn)入設(shè)計(jì)階段。

3.?每個(gè)方案都有利有弊，難以抉擇

在設(shè)計(jì)“設(shè)置”模塊時(shí)，很多地方涉及到編輯。有的場(chǎng)景編輯是高頻操作，有的場(chǎng)景是低頻操作；有的場(chǎng)景編輯是很簡(jiǎn)單一個(gè)按鈕，有的場(chǎng)景編輯包含大量表單。針對(duì)這些不同場(chǎng)景，操作項(xiàng)是始終存在還是Hover出現(xiàn)？編輯形式是在當(dāng)頁(yè)進(jìn)行還是新開頁(yè)面？操作按鈕是以文字鏈的形式展示還是icon形式等問題就迎面而來了。

【解決方法】全面考慮，擇優(yōu)確定

設(shè)計(jì)的過程也是一個(gè)平衡抉擇的過程。對(duì)于有經(jīng)驗(yàn)的設(shè)計(jì)師來說，平衡抉擇可以是在腦海中對(duì)過往經(jīng)歷的瞬間過濾，然后直接得到解決方案；而對(duì)于一個(gè)設(shè)計(jì)新人來講，則可以從以下幾點(diǎn)入手：

Setp 1：全面考慮

如果不能確定設(shè)計(jì)成什么形式那就都先在腦子里過一遍吧！這種全面的模式可以來自于自己日常的設(shè)計(jì)積累，也可以來自于書面的模式總結(jié)。比如在設(shè)計(jì)“編輯功能”時(shí)，《Web界面設(shè)計(jì)》一書中就已為我們歸納了編輯的6種常用模式：?jiǎn)巫佣涡袃?nèi)編輯、多字段行內(nèi)編輯、覆蓋層編輯、表格編輯、群組編輯，如下圖所示：

圖片來自《Web界面設(shè)計(jì)》

Setp 2：結(jié)合實(shí)際場(chǎng)景篩選方案

結(jié)合具體需求，把第一步中羅列出的方法進(jìn)行初步篩選。比如我在設(shè)計(jì)中的有一個(gè)場(chǎng)景是對(duì)列表中項(xiàng)進(jìn)行編輯，這樣的需求場(chǎng)景是行內(nèi)編輯和覆蓋層編輯（模態(tài)窗口）都可以解決的，而其它編輯方法并不適合。所以經(jīng)過初步篩選后剩下了行內(nèi)編輯和覆蓋層編輯兩種方案。

Setp 3：擇優(yōu)確定（QOC方法）

選擇方案時(shí)需要保證在主要目標(biāo)下，當(dāng)前方案優(yōu)點(diǎn)帶來的收益要大于缺點(diǎn)帶來的損失。沒有辦法明確判斷的時(shí)候，可以嘗試 “QOC（Questions, Options, and Criteria）”法。QOC方法可以幫助我們梳理方案的優(yōu)缺點(diǎn)，具體實(shí)踐方案是首先列出問題的備選解決方案和體驗(yàn)評(píng)判標(biāo)準(zhǔn)；然后將解決方案在評(píng)判標(biāo)準(zhǔn)上的表現(xiàn)進(jìn)行連線標(biāo)記；最后根據(jù)當(dāng)前場(chǎng)景中最注重的標(biāo)準(zhǔn)選擇表現(xiàn)最好的方案。如下圖：（綠線代表表現(xiàn)好，紅線表示表現(xiàn)欠佳）

例1. 設(shè)計(jì)按鈕怎么顯示時(shí)：在列表項(xiàng)中有多項(xiàng)操作的場(chǎng)景下，頁(yè)面簡(jiǎn)潔、易發(fā)現(xiàn)、不易誤操作是3個(gè)最重要的評(píng)價(jià)指標(biāo)，按鈕始終存在的方案雖然使得頁(yè)面不如hover出現(xiàn)按鈕那么簡(jiǎn)潔，但是卻更容易發(fā)現(xiàn)且不易誤操作。綜合評(píng)判下按鈕始終存在的設(shè)計(jì)方案表現(xiàn)更好，所以選用了按鈕始終存在的方案；

例2. 設(shè)計(jì)編輯操作采用什么形式時(shí)：在編輯對(duì)象是列表的場(chǎng)景下，行內(nèi)編輯既輕量又能在編輯過程中看到上下文，看似是更好的方案；但是整個(gè)平臺(tái)中編輯操作是一個(gè)復(fù)用性非常高的行為，我們需要為用戶在同一個(gè)平臺(tái)中執(zhí)行的相同操作時(shí)保持相同的預(yù)期。覆蓋層編輯就是一個(gè)具有很好擴(kuò)展性的形式。不論編輯內(nèi)容是簡(jiǎn)單還是復(fù)雜、不論使用場(chǎng)景是編輯成員屬性還是編輯文件，在覆蓋層上進(jìn)行編輯操作都能很好的滿足。所以最終選用了在覆蓋層上編輯的方案。

當(dāng)然，選擇最最優(yōu)方案時(shí)，讀書、競(jìng)品和經(jīng)驗(yàn)等等其它方法都可能幫助我們跳過以上三步，直接確定方案。需要特別留意的是在選擇當(dāng)前場(chǎng)景下最適合的方案時(shí)還應(yīng)該綜合考慮已有設(shè)計(jì)風(fēng)格的延續(xù)、其它場(chǎng)景下的統(tǒng)一性、未來的可擴(kuò)展性、資源耗費(fèi)（開發(fā)資源、運(yùn)營(yíng)資源等）等其它因素。

4. 交互稿沒有被預(yù)期的還原

有一期需求是在移動(dòng)端做圖片編輯功能。畫交互稿的時(shí)候考慮到當(dāng)前頁(yè)面的主要任務(wù)是編輯圖片，當(dāng)前場(chǎng)景下最大限度的展示圖片本身是最重要的。所以摒棄了下圖中如“1-常規(guī)結(jié)構(gòu)”所示的結(jié)構(gòu)而采用了“2-圖片區(qū)最大化”的設(shè)計(jì)：

當(dāng)這份交互稿進(jìn)入視覺流程后，視覺同學(xué)并不知道交互的考量，所以將視覺稿畫成了圖2.1的樣子。不可否認(rèn)，視覺稿的方案更符合用戶習(xí)慣，且操作信息更有層次；但這樣的設(shè)計(jì)卻不能最大化的滿足當(dāng)前的場(chǎng)景。最后，我跟視覺同學(xué)解釋了交互稿中的考量，視覺同學(xué)表示認(rèn)同并欣然修改了方案。但其實(shí)這三番五次的溝通跟修改卻浪費(fèi)了工作量，如果我能夠提前告知這些“特別的”設(shè)計(jì)，是可以避免以上情況的。

【解決方法】預(yù)估關(guān)注點(diǎn)，與下游溝通

交互后期主要是跟進(jìn)視覺和跟進(jìn)開發(fā)、測(cè)試的工作。每個(gè)環(huán)節(jié)的同學(xué)都有自己專業(yè)上對(duì)方案的考量，如果沒有特別的說明，他們會(huì)按照自己習(xí)慣的方式去執(zhí)行。我覺得涉及到以下點(diǎn)的設(shè)計(jì)最好跟下游的伙伴們事先溝通：

不合常規(guī)的方案

常規(guī)狀態(tài)下我們需要遵循平臺(tái)規(guī)范，最好使用常用組件等。但這些并不一定能最好的滿足所有設(shè)計(jì)，所以也常有設(shè)計(jì)方案是特別和原創(chuàng)的。當(dāng)設(shè)計(jì)中有這類方案時(shí)，一定要在交互評(píng)審會(huì)上跟所有同學(xué)強(qiáng)調(diào)并解釋出于什么考慮把設(shè)計(jì)方案做成這樣，讓大家都理解和接受。否則可能會(huì)出現(xiàn)下游同學(xué)按照自己理解漏掉交互考量的情況。

復(fù)雜的邏輯或流程

交互設(shè)計(jì)要做的事情并不只是線框，而是一套提供更好體驗(yàn)的邏輯或流程。這類邏輯或流程往往會(huì)受限于技術(shù)又或者因技術(shù)出現(xiàn)更多可能性。所以，當(dāng)設(shè)計(jì)中有這類方案時(shí)一定跟開發(fā)的同學(xué)事先溝通。描述自己期望的實(shí)現(xiàn)方案，讓他們做一些相關(guān)技術(shù)調(diào)研，根據(jù)調(diào)研結(jié)果來確定最終實(shí)現(xiàn)方法。

需要其它同學(xué)配合完成的交互部分

有些設(shè)計(jì)方案需要其它同學(xué)配合才能完成。比如頁(yè)面信息的優(yōu)先級(jí)，交互需要考慮在這個(gè)頁(yè)面上用戶體驗(yàn)的層級(jí)，視覺需要考慮其信息傳達(dá)的層級(jí)，這時(shí)就需要更多的提前溝通保證一致性。

將溝通工作前置既可以很大程度上提高工作效率、減小返工可能性，又可以保證交互稿的還原程度，何樂而不為呢？

5. 總結(jié)

任何工作都是一個(gè)熟能生巧的過程。走第一遍的時(shí)候多多少少會(huì)遇到一些問題，把這些問題記住，總結(jié)其中的規(guī)律就可以避免下次踩坑。這篇文章的作用，是給自己看的回顧，也是給其他人的避坑指南，希望有用。

作者：蔣蕊遙-Jerria，昵稱阿遙，網(wǎng)易UEDC交互小鮮肉一枚，現(xiàn)支持杭研測(cè)試項(xiàng)目。商業(yè)與體驗(yàn)就像美食與身材，要找到其中的平衡點(diǎn)–對(duì)我就是愛吃又想瘦！所以學(xué)習(xí)奮斗吧！

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。