新人設計師如何參與一個具體項目

數十萬互聯網從業者的共同關注！

作者： 胡振明

來源：網易UEDC（ID：NetEase_UEDC）

編輯：Verna

筆者從設計概念、設計實施、產品上線參與項目的完整過程，項目歷程3個月。該項目是由團隊內部自發的一款「為設計師提供成就體系展示平台」的全新產品。該產品類型偏信息展示，設計上更注重交互創新性，項目團隊是通過 「借用」其他部門視覺和開發的方式臨時組建。在這種情況下，怎麼做到設計師主導設計並推動產品上線呢？希望通過這次設計經驗分享能夠給大家帶來幫助。

一、方案階段，如何做好設計？

設計過程中的各種考量和取捨都是不可見的，並且設計師最終交付的產出物也沒有標準答案，但是只有在設計過程中嚴格把關才能得到更好的結果。

1.設計實施前，多問「為什麼」

多問「為什麼」是指從項目的利益相關者收集信息。通過信息的收集，明確設計原因及產品目標，梳理出核心方向及策略點，提高工作效率。

在本項目中，需求多為老闆提出，經產品經理轉述給交互設計師。多問「為什麼」就是從老闆和產品經理「轉述」的需求中挖掘出用戶真正的需求並找到與業務目標契合的平衡點。

?為什麼要做這個功能？（業務目的）

?產品期望得到怎樣的成果？（業務目標）

?誰來使用這個功能？（目標用戶）

?他們為什麼要使用這個功能？（用戶需求、體驗目標）

?如何讓他們都來使用這個功能？

?……

（對信息的收集後，可通過以下幾個角度對用戶需求梳理、分解找出設計關鍵點）

在這一過程中，可以直接找最終決策人——老闆了解設計原因，但老闆給的信息較為模糊。最好提出幾個可行的方向策略，請老闆做出判斷和抉擇。你需要做的是通過「這個體驗不行啊」、「不需要展示這個信息」、「用戶應該可以分享這個頁面」等回答，挖掘出老闆真正想表達的東西。

2.設計過程中，考慮所有可能方案

在設計評審時，我們可以只拿出一種設計方案。但是在評審之前需要把能想到的方案都仔細考慮一遍。如果只做一個方案交差，一方面可能會錯過更優的方案，另一方面，在評審時被問到「這裡為什麼不設計成那樣」時，很可能會措手不及。反之，如果事先把所有可能的方案都考慮到了，就可以從容應答，把之前已經思考過的其他方案中存在的問題一一列舉出來。

3.方案評審時，將設計思考過程可視化展示

對於0到1的產品，下游的同事並不了解產品背景，對設計方向及方案權衡過程可能會存在疑問，如何在方案評審中讓大家更容易理解你的設計，可視化展示設計的思考過程就顯得尤為重要。

利用工具將思維視覺化是一個很好的表達方式，例如：將產品要解決的問題以及設計分析推導過程，通過思維導圖、線框圖、流程圖或者其他的手段可視化表達出來，不僅利於大家一目了然地理解和討論，同時增加設計方案的說服力。

（例如：在視頻拍攝方案構思時，為便於大家理解方案，通過場景定義關鍵、通過一句話場景描述語+意向圖的形式，將方案視覺化呈現）

二、項目跟進，如何保障設計效果實現？

項目跟進是設計師重要工作之一，設計能力再強，設計方案再好，如果沒有後續良好的執行，也終究不過是廢紙一張。

1.溝通及解決問題

儘管在設計階段，我們已經儘可能地考慮了所有的交互狀態，但在開發時，仍然有可能疏漏，所以技術人員在開發時遇到關於設計方面問題，需要設計師輔助解決。

在實際項目過程中，我曾犯過一些低級錯誤，為了節省時間，將問題的截圖標出，然後直接丟給視覺開發人員，導致反覆修改的現象。所以對問題的規範化描述是不能省略的，通過操作、結果、期望三個方面對問題進行描述，即什麼樣的操作，會導致什麼結果，最終可以滿足什麼樣的期望。

（對溝通過程中的問題進行記錄、對於不能按設計方案的內容，與開發溝通後、調研，尋求其他解決方案。將調研的產品截圖或者鏈接一起記錄下來）

若遇到因為技術限制或設計效果無法達預期情況，這時候要找問題的關鍵和邊界，為什麼不能解決？限制是什麼？有沒有可替代的方案？尋求正確的對策。並將溝通結果、記錄、形成規範化的文檔沉澱。

2、及時設計走查

產品上線前，需要對測試環境下的產品Demo進行交互走查。因本產品動效及交互細節較多，在此緊將常見幾類走查的問題總結如下：

交互動作：操作及其反饋，交互控制項的各種狀態、極端、極限和出錯的情況，默認值是否正確，懸停的狀態，文案等等，這些小細節在開發階段可能被疏忽。

動效時間：顯示時間、持續時間和消失時間的驗收；一般動效包括卡片的展開、收縮、切換；氣泡或toast提示等，例如：卡片切換的時間是0.5s還是1s，這0.5s的差異對用戶的心理會帶來完全不同的體驗；

兼容性問題：不同機型來驗收實際的顯示和操作效果，確定文案是否折行、按鈕排布是否適合點擊等。若有硬體問題導致原定的設計效果無法在當前設備上較好呈現，還需要調整優化原有的設計方案，從實際出發來達到預期的體驗。

網路許可權：不同的網路是否可訪問，不可訪問顯示狀態等；

三、設計走查後，如何推動開發解決走查問題？

推動開發解決走查過程中出現問題的能力是考量交互設計師能力的重要標準之一。

1.通過以下3種方式推動開發解決走查過程中發現的問題

直接郵件提交方式

郵件是一種比較快速又正式的方式，內容較多時可附上對應的附件（走查文檔）。

在管理系統提交方式

直接在管理平台提交問題@相關人員與解決問題期限，便於交互設計師管理、跟蹤自己bug的解決情況，同時也便於開發人員認領屬於各自的bug。

線下找開發溝通方式

這是最快、最直接的一種解決方式。

但需要注意的是，一是提前與開發約好時間；二是準備好問題清單，最好是將「問題清單」列印出來，防止溝通時遺漏。

當面溝通效果雖好，但是人力成本相對較大，無論是精力還是體力，面對面溝通更適合於功能的微調、頁面小改動等小問題統一解決，對於一些大問題以上兩種方式更適合。

2.寫好驗收的報告

寫好走查問題，提高文檔的可讀、易讀性，有利於減少反覆溝通次數，提高設計優化的效率。

問題描述簡潔準確：

問題描述力求精簡、明了、盡量使用公司內部一致的描述方式（可使用操作、結果、期望三個方面對問題進行描述），以及附上對應問題頁面截圖作為補充。

問題梳理清晰並標註優先順序

可以遵循分類-提取-標註優先順序的原則，將問題按照bug、吐槽、建議等標準進行分類，分辨哪些是需要馬上修改的，哪些是值得關注的。通過問題分類對優先順序進行劃分，分清楚輕重緩急，便於開發人員合理安排工作進度。

給出問題解決方案或預期效果

對於「是與否」的問題，只需指出問題點即可，如:交互操作「是hover而非點擊」。對於關於用戶體驗「good or better」的問題，因此需要給出相應的解決方案和預期效果。

（可參考上圖標註有功能頁面、問題描述與預期、優先順序及處理人信息的等較為規範走查表）

四、產品上線，需要做什麼準備？

一般到這環節，交互設計的工作才算完成。但因此項目屬內部自發項目，職位角色並未劃分那麼清晰，筆者也有幸承擔了產品上線的工作。項目產品面向的是公司內部成員，因此跟普通產品上線流程並不太一樣，在這裡主要講兩點：

1.上線前，物料準備

其中比較重要的是產品上線相關的工單申請，走審批流程等，工單主要包括：

新產品上線申請

域名申請

伺服器申請

對於域名，建議考慮簡單易識別，為避免重複最好多準備幾個，域名申請一般時間比較長，因此需要提前做好準備，以免耽誤上線進程。另外，工單與工單填寫項之間會有串聯關係，因此需要向運維人員提前了解需要申請的工單項以及注意事項，如果牽扯到技術項要配合開發與運維人員一起填寫。

2.上線後，項目交接

通過郵件或者會議的形式交付給項目的發起人驗收，並提些官網宣傳以及後續的發展方向的建議等。

五、總結

由於是新項目，無論是設計還是開發，大部分都是摸石頭過河，沒有現成的資源可用，都需要重新開始。在需求階段，要對用戶需求及業務目標有更透徹與深入的理解；在設計階段，要探索多種方案的可能性、在業務目標與用戶體驗目標找到一個平衡點，優中選優；在項目跟進過程中，與視覺一起把控細節與精度，推進開發保證體驗效果，通過不斷溝通、協調解決項目中遇到各種問題，使得產品最終向著更好、更優秀的方式發展。最深的感受是對於設計師而言，設計功能的上線才算實現價值，在這一過程，除了對自身執行力嚴格要求，還需要關注產品體驗敏感度，努力提升產品思維，培養整體設計的全局觀。

本文由網易UEDC（ID：NetEase_UEDC）原創發布，授權互聯網早讀課轉載。內容僅代表作者獨立觀點，不代表早讀課立場。如需轉載，請聯繫原作者。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！