產品設計的過程很長，如果設計的時候疏漏一些內容，會導致需求反覆和研發資源的浪費，本文主要列舉了各個產品階段需要自查的部分，檢查當前設計是否存在未考慮到的問題。
一、需求分析階段
判斷需求真偽
- 是誰在什麼樣的場景而下產生的什麼訴求，希望用什麼方法解決什麼問題；
- 是否需要進一步調研相關用戶\\需求提出方，是否需要數據佐證；
- 是否符合當前核心業務場景、是否符合用戶畫像和用戶故事；
- 是否存在類似競品，是否完成競品分析；
- 當前方案是否是同類場景下的共性訴求。
量化收益
- 對核心用戶的影響程度，儘可能量化；
- 對核心業務的貢獻程度，儘可能量化。
判斷可行性
- 當前技術是否可以支持；
- 當前業務是否可以支持。
風險評估
（1）功能風險
- ①是否存在關聯功能的改造點
- ②是否完整梳理當前規劃內容下線後的影響點
- ③是否已預估業務高峰數據爆發量級，及其處理措施
- ④是否已計劃好功能上線後的驗證方法
（2）外部風險
- ①是否引發諸如騷擾、欺詐等安全隱患
- ②是否存在負面輿情風險
- ③是否存在法律及合規風險
排定優先級
參考維度：用戶覆蓋度、使用頻率、對核心場景的影響、對核心用戶的影響、實際收益的高低、對KPI的影響、實現難度的高低、產品成長時機。
二、信息架構設計階段
定義
面向用戶，組織合理的信息及展現層級使其正確傳達給用戶的過程，從客戶端功能佈局到界面字段排版均需要。
檢查點
- 設計時是否結合了用戶畫像、用戶習慣、業務場景等因素；
- 架構層次是否清晰，是否足夠扁平，是否容易能使用戶理解；
- 所有信息均需要進行重要級評定，以決定在界面和功能中的重要程度；
- 信息分類是否合理，一定要“高內聚，低耦合”；
- 架構拓展性是否足夠大，後續對信息模塊進行增刪改查時，是否容易施行。
三、流程設計階段
（1）流程設計是否結合了用戶畫像、用戶習慣、業務場景、競品等因素？
（2）主幹流程是否最簡化，是否覆蓋了足夠多的場景？
（3）是否有特殊流程（分支流程、逆向流程）？
（4）是否有異常流程？
（5）是否歸納出所有的操作節點、數據交互點：
- 操作節點是否足夠精簡易理解？
- 是否考慮了操作節點的容錯性（二次確認、撤銷操作）？
- 數據交互點是否依賴其他系統？
（6）特殊、異常流程是否需要增加切換流程的引導，避免流程斷頭？
（7）相關流程的用戶體驗路徑是否一致？
（8）繪製是否美觀規範：
- ①各圖形形狀/字號統一:，重點內容可特殊標識，關鍵節點增加註釋說明
- ②流程均以開始框開始，以結束框結束，避免斷頭風險
- ③流程圖從左到右、從上到下排列
- ④流程線儘量不要交叉
（9）流程完成後是否進行了場景驗證，是否符合用戶預期？
四、交互設計階段
細節交互
（1）頁面流
- ①頁面跳轉的描述說明是否完整，是否需要頁面流轉圖輔助說明？
- ②頁面內容是否完整，是否符合信息架構設計，是否存在缺失？
- ③頁面是否存在空值狀態？
- ④頁面加載狀態展示的loading圖是否友好，是否可打斷加載狀態？
- ⑤頁面加載狀態是否可操作部分原生控件（移動端）？
- ⑥頁面的逆向操作是否有完整的路徑，返回是否會造成死循環？
- ⑦頁面的跳轉是否需要轉場動效？
- ⑧是否添加全局特效的交互操作，iOS右滑返回？
- ⑨移動端單頁面中的功能是否有冗餘，單頁面主功能僅限一個？
- ⑩後端web頁儘量在一個頁面中展示更多相關信息，單頁面可完成多次相關操作。
（2）文案
- ①是否易理解，是否有歧義，是否有錯別字？
- ②句式、用詞是否準確一致？
- ③文案是否與產品調性一致？
（3）數據展示
- 展示數據是否使用的是服務器數據，或使用的是本地緩存數據？
- 展示數據是否是初次加載讀取的靜態數據，或實時、定時展示的動態數據？
- 是否規劃數據為空時的展示效果，是否增加用戶引導？
- 是否規劃數據字數超長展示效果，是否有超長限制？
- 對過期的緩存數據是否需要告知用戶刷新（活動過期）？
- 是否規劃數據極限值的展示效果？
- 是否規劃了數值的特定展示格式？
- 是否存在敏感數據，敏感數據如何展示？
- 是否對特殊內容進行過濾、標記（敏感、違禁的詞語）？
- 前置場景的不同是否對當前展示數據產生影響，不同場景是否需要展示不同數據？
- 移動端從後臺喚醒應用時，是否需要刷新當前頁面數據？
（4）數據表單
- 數據按什麼規則排序？
- 數據是根據什麼搜索規則篩選出？
- 數據展示是否分頁，單頁展示數據量是否有限制？
（5）控件
- 控件是否符合用戶認知？
- 全局控件樣式是否具有一致性？
- 全局控件交互行為是否具有一致性？
- 控件的不可用狀態如何展示？
- 是否周全地考慮了所有操作成功的反饋？
- 是否周全地考慮了所有操作失敗的反饋？
- 操作過程中是否允許取消？
- 是否設計了必要且合理的動效？
- 待操作按鈕在當前界面中是否明確？
- 待操作按鈕是否易操作？
- 控件觸發的提示類型是否恰當（小紅點、Toast、彈窗）？
- 控件觸發的功能過程中是否可以隨時取消（下載新版本、上傳文件）？
（6）文字輸入
- 輸入文字前是否有默認值，是否有輸入提示？
- 輸入焦點丟失和存在時是否有展示內容的差異？
- 輸入文字是否存在極限長度或最低長度？
- 輸入文字是否可存在特殊字符，若用戶輸入如何處理？
- 輸入文字是否存在對敏感詞（密碼、存款金額等）、違禁詞的禁用或過濾展示？
- 輸入文字後是否需要一鍵清空操作？
- 輸如文字後是否顯示輔助結果（輔助詞），輔助詞的搜索規則？
- 輸入文字後遇到流程打斷的情況是否保留輸入記錄（斷網、關閉頁面等）？
- 是否針對輸入的內容指定鍵盤類型，數字鍵盤，英文鍵盤（移動端）？
- 是否說明了鍵盤喚起後需要頁面的滾動來避免輸入框的遮擋（移動端）？
（7）圖片輸入
- ①是否強制要求上傳圖片的必須參數（尺寸、格式等）
- ②是否設置了不符合尺寸的提示，圖片過大或過小，格式錯誤等
- ③是否提供上傳完成圖片的預覽
- ④是否提供了再次編輯操作，引導是否明顯
- ⑤上傳失敗的情況是否給予用戶提示，引導再次上傳
- ⑥上傳完成後遇到流程打斷的情況是否保留已上傳的記錄（斷網、關閉頁面等）
特殊因素
（1）帳號角色
- ①是否存在不同登錄狀態下展示內容或操作有不同（登錄、未登錄、帳號異常狀態）？
- ②是否存在不同用戶狀態下展示內容或操作有不同（非會員，不同等級的會員，特殊付費會員等）？
- ③是否考慮多賬號切換，切換時，本地緩存數據是否需要同步清空？
- ④是否允許多終端同時登錄同一帳號，若允許，操作同一數據時是否產生衝突？
（2）網絡狀況
- ①WiFi網絡；
- ②移動網絡（4G）；
- ③連接超時，多久為超時？
- ④無網絡顯示什麼內容？是否給予用戶友好引導檢查網絡或重試按鈕？
- ⑤網絡變化從WiFi到4G網絡環境時，是否需要提示？
（3）服務器問題
服務器出問題返回數據失敗時，是否給予用戶友好提示或重試按鈕？
（4）舊版本兼容
是否存在高低版本兼容問題（瀏覽器頁面緩存、APP舊版本）？
（5）硬件設備
- 橫豎屏是否有橫屏展示的需要，如不需要需要鎖定豎屏？
- 分辨率高低情況下是否會有適配問題，是否備註清楚？
- SD卡 Android手機，沒有SD卡、SD卡儲存已滿、儲存位置等情況是否考慮並備註？
- 硬件不同，手機物理按鍵的不同衍生不同操作？
- 系統版本的不同是否同步支持，iOS、Android、Windows及其不同版本
（6）硬件權限
- 定位提示是否打開定位？
- 相機提示是否打開相機？
- 閃光燈提示是否調用閃光燈？
- 藍牙 示是否打開藍牙？
- 設備數據是否需要調用？步數、心率等，主要在iOS設備中。
（7）閱讀模式
- 夜間\\日間模式，是否考慮光線較暗的場景？
- 編輯模式下出現意外情況，是否提示保存或自動保存已填信息？
- 無痕模式，不記錄用戶所有操作信息（實際是否記錄根據數據需求來看）？
- 無圖模式，節約用戶流量，加快頁面加載速度。
輔助功能
（1）數據埋點
- 是否存在用戶漏斗埋點需求？
- 是否存在運營數據報表需求？
- 是否定義功能可用性標準？
（2）通知機制
- 操作交互是否需要觸發推送消息，推送內容是什麼，推送時間節點是什麼？
- 是否確定當前通知的類型（短信、推送、微信消息）？
- 是否確定當前通知的失效策略？
五、文檔撰寫
- 乾淨整潔，注意排版細節；
- 多層級格式標記一致；
- 同層級字體大小一致；
- 說明的圖片是否易理解，是否可快速定位位置？
六、上線準備
- 客戶端版本更新是否需要做新的應用商店圖、新的歡迎頁、新的功能引導頁、新的功能描述文案、升級版本文案？
- 功能埋點列表是否確認及提出？
- 版本上線計劃是否確定，是否及時同步給運營或其他相關部門人員，及佈置相關工作？
- 數據統計需求是否確認及提出？
- 若需求內容較大，是否在上線前做好業務人員培訓？
題圖來自 Pexels，基於 CC0 協議
分享到:
閱讀更多 人人都是產品經理 的文章
