産品驗收報告?編輯導語：産品驗收，對于産品經理而言應該都不陌生，它是産品上線前的一個關鍵的步驟，那麼産品驗收該如何做呢？作者結合自己的經驗，總結了産品驗收的全過程，希望對你有所幫助，現在小編就來說說關于産品驗收報告?下面内容希望能幫助到你，我們來一起看看吧!

産品驗收報告

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

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

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

設計稿還原度低，需要反複與前端校對

交互細節不到位，前端實現與設計師預期落差大

小需求容易被忽略

驗收問題多，溝通成本高

…

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

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

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

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

1. 設計交互說明

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

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

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

組件交互說明：

基礎組件：輸入框，下拉框，日期選擇器，按鈕等等

定制組件：根據産品需求特别定制的，比如下拉框下拉列表要展示 【名稱】【ID】【創建時間】【創建人】

其他：比如狀态，需要枚舉，需要寫清楚對應可操作的 Action。

…

操作類交互說明：

比如點擊某個 Action 觸發什麼頁面，頁面形式是什麼。是彈窗，還是抽屜，還是新頁面打開，當前頁還是新開頁面等

點擊或懸浮，UI 上是否有變化

不可操作的情況枚舉

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

字号和字色：标題、主文字、輔助文字、不可點擊

默認排序

空頁面展示

分頁器規則

不同顯示器的适配

文字溢出的處理

浏覽器标簽頁約定：比如是展示一級菜單名稱，還是二級 三級名稱，還是隻展示産品名等等

異常：

異常情況枚舉

報錯的展示 UI，包含原因和解決方案

404、403 等異常頁面的異常

其他：

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

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

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

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

2. 提前溝通

複雜的交互，建議提前與前端溝通，确認好交互細節，避免開發時，前端錯誤理解或無法實現，這時不隻是在設計稿上要标記，最好是找前端面對面溝通。基本上複雜的交互，開發的時間也不會太短，提前溝通能幫助前端預估好開發時間，也能避坑，順便建立好關系。

開發有時隻是大概 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 個問題，其中：

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

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

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

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

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

題圖來自Unsplash，基于CC0協議

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!