【入門文章】產品從0到1 新人設計師要如何參與一個具體項目

筆者從設計概念、設計實施、產品上線參與項目的完整過程，項目歷程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.上線后，項目交接

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

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