中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

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

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

沒有計劃的時間永遠(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í)慣，也可以采用常見的時間管理四象限法則（把工作按照重要和緊急兩個不同的程度進行了劃分，基本上可以分為四個“象限”：既緊急又重要、重要但不緊急、緊急但不重要、既不緊急也不重要 ）。我一般按下圖安排自己工作的優(yōu)先級：

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

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

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

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

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

方式：

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

當(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ù)需求，又可以避免用戶的額外操作和出錯幾率。

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

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

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

所以每次接到需求時有以下幾點需要注意：

1. 質(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)槭裁匆觥?/p>

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

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

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

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

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

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

Setp 1：全面考慮

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

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

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)最好的方案。如下圖：（綠線代表表現(xiàn)好，紅線表示表現(xiàn)欠佳）

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

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

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

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

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

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

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

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

不合常規(guī)的方案

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

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

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

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

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

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

5. 總結(jié)

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

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

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