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

編輯導語：產品驗收，對于產品經理而言應該都不陌生，它是產品上線前的一個關鍵的步驟，那么產品驗收該如何做呢？作者結合自己的經驗，總結了產品驗收的全過程，希望對你有所幫助。

產品驗收，是產品發布上線前不可缺少的一個環節。但是，如何驗收呢？

產品驗收時會面臨各種挑戰，比如：

• 設計稿還原度低，需要反復與前端校對
• 交互細節不到位，前端實現與設計師預期落差大
• 小需求容易被忽略
• 驗收問題多，溝通成本高
• …

問題多多，困難重重，但是在設計階段或是驗收階段能否盡量避免或優化的呢？從需求到設計，從設計到研發，從研發到驗收，在這幾個環節中間，設計師可以做什么呢？

根據以往驗收的經驗，我會在【設計階段】【驗收階段】做一些優化，以及后面的復盤中總結相關經驗，來減少一些不必要的錯誤。

一、設計階段

設計階段是設計的主戰場之一，不僅挑戰設計師的設計能力，還有需求理解分析，最終所有的努力成為一紙設計呈現。在設計師披荊斬棘，終于產出設計稿后，設計師最希望的是一稿過，并且最終實現設計稿 100% 還原。但是，我們都知道，這真的只有夢里有。

設計交互說明補充和與前端提前溝通一些交互，可以提前避免一些預知錯誤并減少后期溝通成本，提高效率。

1. 設計交互說明

設計時，并不僅僅只是交付視覺稿，還需要一些設計交互輔助說明。這樣做可以減少后期溝通成本，也防止自己忘記。特別是項目周期長的，可能設計時，清楚是怎么樣的交互，等驗收時，可能都忘記這個需求了，這也會導致驗收時，會遺漏需求。

對交互的書面描述，也是幫助設計師更加深入的思考。有時，只是在腦海里過一遍，往往會有所遺漏。同時，要保持交互說明的簡潔，不要長篇大論，可以用更少文字描述的，就不要用長文?？梢杂脠D片或圖案表達的，就盡量不使用文字。因為，人都是對視覺更加敏感，也更容易記住，文字過多，可能干脆都跳過。

設計交互說明中，要包含但不限于以下說明：

組件交互說明：

• 基礎組件：輸入框，下拉框，日期選擇器，按鈕等等
• 定制組件：根據產品需求特別定制的，比如下拉框下拉列表要展示 【名稱】【ID】【創建時間】【創建人】
• 其他：比如狀態，需要枚舉，需要寫清楚對應可操作的 Action。
• …

操作類交互說明：

• 比如點擊某個 Action 觸發什么頁面，頁面形式是什么。是彈窗，還是抽屜，還是新頁面打開，當前頁還是新開頁面等
• 點擊或懸浮，UI 上是否有變化
• 不可操作的情況枚舉

頁面布局說明：建議在設計規范中一次性約定：

• 字號和字色：標題、主文字、輔助文字、不可點擊
• 默認排序
• 空頁面展示
• 分頁器規則
• 不同顯示器的適配
• 文字溢出的處理
• 瀏覽器標簽頁約定：比如是展示一級菜單名稱，還是二級+三級名稱，還是只展示產品名等等

異常：

• 異常情況枚舉
• 報錯的展示 UI，包含原因和解決方案
• 404、403 等異常頁面的異常

其他：

• 特殊情況說明

交互設計說明的假設前提是，前端同學不清楚交互規則。很多時候設計師會假設，前端一定知道這個組件或頁面是如何交互。但是現實往往不是這樣，這不是誰對誰錯的問題，而是大家站的角度不同，處理事情的方式當然也有所差異，再加上人本身的復雜性。

所以，在與前端同學培養好默契前，建議寫好交互說明，避免開發或驗收中反復確認反復修改。

定義好整體的設計規范，會幫助前端更加清楚一些交互的規則。但是在前期與前端剛合作時，設計師要寫清楚交互細節，因為開發也需要時間熟悉規范。當然約定好規范，也是減少雙方在一些交互方式上 Argue 的時間。

對于一些定制類比較特殊的組件，建議讓前端同學沉淀成組件，保證整體設計的統一性，減少后期維護成本。

2. 提前溝通

復雜的交互，建議提前與前端溝通，確認好交互細節，避免開發時，前端錯誤理解或無法實現，這時不只是在設計稿上要標記，最好是找前端面對面溝通?；旧蠌碗s的交互，開發的時間也不會太短，提前溝通能幫助前端預估好開發時間，也能避坑，順便建立好關系。

開發有時只是大概 Review 一下設計稿，等到真正開發時，才會評估難易和時間，所以比較復雜的交互有可能會被忽略或錯估。

設計評審時，對于復雜交互或復雜業務邏輯，要充分與開發確認，盡量減少后期設計調整或更改。

二、驗收階段

一般會由 PD/PM 牽頭，邀請設計師、測試一同參與產品驗收。若是小團隊，可能就是產品和設計兩個人。驗收前后的準備，可以以團隊形式進行，提高效率。

驗收時，可分驗收前、驗收中、驗收后來看。在不同的時間，做一些準備工作，也能讓驗收過程變得高效和愉快。

1. 驗收前準備

（1）與開發確認可驗收范圍

開發過程中，可能會因為一些原因，有些需求會被延遲或暫不開發，所以與開發確認驗收范圍是必要的。

（2）需求清單

羅列需要驗收的需求清單，重點需求或交互點可標記。清單可按產品模塊來劃分或項目，清單上可包含以下：

• 模塊或項目名稱
• 前端負責人，后端負責人
• 需求名稱

（3）測試用例

設計師比較少會寫測試用例，為了避免重要需求點驗收遺漏，可以有些針對性的梳理。測試用例不需要太復雜，符合設計師的需求就好，測試用例梳理過程是比較費時間，所以建議只對復雜的一些業務場景。

示例：

（4）時間規劃

時間規劃也是讓驗收能夠順利完成的關鍵點之一，雖然工作最終能完成，但是沒有 Deadline 的項目，會無限期推遲，不利于整體項目推進。而且時間要連續進行，專心找 Bug，專心修 Bug。

• 設計驗收時間
• 開發修復時間
• 再次驗證時間
• 最后：設置最后截止時間

（5）需要開發配合的一些準備

• 測試賬號：一些需求的驗證，可能需要多賬號來驗證，提前準備好測試賬號是有必要的。
• 權限：如果涉及賬號權限，可以提前讓開發開通或授權
• 驗收環境的準備，如果是約定預發環境驗收，要讓開發同學提前部署

（6）其他

約定提 Issue 的存放位置，比如云效和 GitHub 都有提缺陷的功能。同時要約定缺陷的等級，優先級【緊急】【高】【中】【低】設定標準是什么，什么樣的缺陷這次驗收是一定要修復的。

驗收通過的標準是什么，是優先級高以上都修復完成就通過，還是優先級中以上。不管最后約定的規則是什么，都需要同步給開發同學。

2. 驗收中

驗收時，對問題的描述同樣很重要。對問題清楚的描述，能幫助開發更好理解問題所在，減少彼此溝通的時間。對于比較難描述的問題，可以錄屏來記錄問題，然后當面和開發聊這個問題。

提 issue 時，有幾點建議：

• 標題清晰，寫清楚主要原因，例【模塊名稱】創建XX頁面，提交顯示成功，但是列表無數據
• 觸發條件或路徑描述清晰，寫清楚上下文，幫助開發了解問題發生過程
• 文字加上截圖，圖文并茂
• 不想只寫問題，要把修改建議一起附上
• UI 問題，直接在截圖上圈出有問題地方，并寫上正確值，減少前端來回看設計稿的時間，或許你一眼就看出間距有問題，但是對于前端來說，這始終是一個盲區。大家關注點不一樣，不需要在這僵持
• 同一個頁面的問題，比如同個創建表單的一些界面 問題，可以把問題提在一個 issue 里面，可以方便前端同時改了。如果當中有高優化級的，可以單獨提一個。

驗證問題的時間最好可以隔一天。開發改好了，就會更改狀態，但是大部分前端不會在當時就發布，所以如果當下去驗證，基本上還是一樣的。除非開發自己和你說，他已經發布了。

3. 驗收后

驗收完成后，需要對驗收有個總結，產出驗收報告。驗收報告，包括驗收的基本情況，驗收的維度，驗收需求范圍，各模塊或各項目 issue 情況等等

（1）基本情況

• 驗收時間
• 驗收人
• 驗收環境
• issue 地址
• 驗收范圍
• 測試賬號

（2）驗收維度

（3）驗收需求清單

按各模塊或項目，列清楚當前驗收的情況。

（4）驗收結果

對現有問題做一個結論，當前共發現 XX 個問題，其中：

• A 模塊：51 個
• B 模塊：36 個
• C 模塊：23 個

截止 2022074 18:00:00, 當前修復情況：

• 待修復：19 個
• 已修復：109 個
• 暫不修復：7 個

三、復盤總結

坦白講，我不是個喜歡做復盤的人，但是我基本上都是強迫自己做，因為腦袋知道這是件有益的事。

對驗收發現問題的總結，也能幫助我在下一次設計中，知道哪些地方需要多和開發們確認。哪些類型的交互需要考慮的更加仔細，盡可能提早發現問題，避免到驗收才發現交互不合理，要臨時調整。

最后的話

產品驗收，始終會是產品的一個挑戰。但這就像每個生命都需要成長一樣，總是在磕碰中，砥礪前行。

本文由@箴鹽設計 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議