團隊協作優化：如何使用 Notion 進行Design QA、追蹤管理 Issue
此篇文章會主要以工具 Notion 分享 Design QA 的實作方式 — 如何進行 Design QA、如何編寫 QA 內容和追蹤管理此階段，並淺談其他工具（例如：Google Doc、Dropbox paper、Jira、Trello、inVision、Figma）進行 QA 的心得，最後分享推動經驗，希望幫助設計師進行更順暢的 Design QA 階段。
文末附上提到的 Notion 應用參考網址，可以試玩看看，也歡迎複製、調整成適合團隊或自己喜歡的方式。
Design QA 常在不知不覺間成為一團混亂
身為設計師，在 Release 項目較多時，可能有過這個經驗……在設計階段結束後，期待著哪天工程師把測試連結傳來。過了一、兩週後，終於收到一串網址，打開測試網站開始與交叉比對與設計稿不同之處，在同時間也發現了許多在設計時沒有考慮到的問題……
花非常多時間建立 Issue，卻不確定哪些 Issue 已經修好
與工程師溝通了一小時後，看著測試站，這個問題剛剛好像有提過，但不太確定自己是不是通通都檢查過了；而且過幾天後回頭再看一次測試站，卻再也想不起來某些 Issue 是怎麼發現的？
工程師好像說過有些地方因為限制而無法修正的，但他講的是哪邊？為什麼好像重複討論著同樣的問題？
最初開了一份 QA 文件編列 Issue，但隨著問題越來越多，要找出還未修正的 Issue 開始變得有點困難。
無法掌握 Issue 狀態，不確定究竟 Design QA 進行到哪，也不確定之前發現的 Issue有沒有都修正了。
有進行 Design QA 更好的方式嗎？
在設計 Design QA 流程前，我們先試著釐清這個流程的特性。 Design QA 是一項需要團隊成員不斷來回溝通的協作工作，如果有一個平台容易管理、綜覽整個 Design QA 的工作狀態，會讓這個過程維持清晰流暢。
這個平台需要符合幾個特性：
【 共同協作 】：工程師和設計師都要能夠同協作，以便在認知有落差時，提供溝通與紀錄的平台，並且回報 Issue 的最新狀態。
【 問題描述 】：能讓設計師清楚地描述問題，像是發生的位置、發生在哪種裝置。若是容易附上圖片、上傳影片更佳。
【 進度追蹤 】： Issue 的修改分成多個階段，在修改量大的情況下，要能讓工程師快速知道需要修的問題有哪些，也要能幫助設計師了解有哪些已經修改完畢，可以檢查了。從管理角度是，可以綜覽所有的修改進度，掌握時程。
以下特性則是 Nice to have：
【 Issue 修改記錄 】：團隊成員可以在 Design QA 階段結束後，回頭審視整個工作流程，找出可以改善的空間。例如：有些 Issue 改到第三次才修好，是雙方溝通上的落差造成，還是技術上無法實現？或是有 30% 的 Issue 最後決定留到下個階段再改，是否是時間流程控管上可再改善？
在試過多種工具之後，我最後選擇了 Notion，以下以 Notion 做 Demo。
在 Design QA 開始之前
在開始撰寫 Design QA 文件之前，設計師有一些前期作業要準備。
- 【 列出頁面或功能的檢查順序 】：建立 QA 地圖與方向，減少在測試時不小心迷失方向。
- 【 盤點裝置檢查順序 】：裝置、瀏覽器、iOS / Android 繁多，要決定先從哪邊開始檢查。
- 【 列出設計重點的優先順序 】：針對特定頁面或功能， QA 重點要先看什麼？ 像是：UI 介面外觀、UI states、flow 或 動態。
- 【 開啟需要的連結與應用程式 】：測試站、設計稿（figma, zeplin or sketch）、圖片標註軟體通通都先開好，準備開始撰寫 Design QA 文件。
Design QA 文件的常見內容
描述 Issue 的內容
開 Issue 時，需要描述 Issue 的內容讓工程師了解，以 Web-based 產品為例，我常用的參考項目如下：
- 【 裝置 】：大致分為 Desktop / Pad / Mobile，有需要也可以分得更細，如：裝置型號、尺寸、Portrait、Landscape。
- 【 頁面或共用元件 】： 描述問題發生的位置，如：發生在 home，footer 或是 navigation。
- 【 問題類型 】：對問題進行分類，如：連結異常，間距調整，或是字體大小調整。
- 【 問題描述 】：描述 Issue 的內容。
- 【 圖片或影片說明 】：如果是 UI 外觀問題，附上測試站與設計稿的對照圖，並且標注出問題點或確切的調整數值，能讓工程師快速理解差異與修改；如果是 flow 操作或是動態問題，可用 UI flow 或影片幫助說明。
- 【 路徑 】：發現這個問題的路徑是什麼？有些 Issue 經過一連串的 flow 才會發現，讓工程師可以重現這個 Issue，也幫助自己在修好後能用同樣的路徑確認。
- 【 Issue 處理狀態 】：工程師可了解有哪些 Issue 待修，以及修完後如何更新進度。如：Issue 待修正、修完等待設計師檢查，或是設計已檢查無誤。
- 【 緊急程度 】：以問題的緊急程度排序，當列了 30 個 Issue， 在緊迫的時間下，工程師可以快速知道需要優先處理的有哪些。
- 【 階段 】：Design QA 有時候無法一口氣完成編列。可定義 1–2 天成為一個 QA 階段，請工程師先進行修正；在修的過程中，發現的新 Issue 歸為下個階段，設計師也可以針對未考量的地方補上設計或說明。
定義 Issue 狀態
處理 Issue 時，不只有待修正、已修正兩種狀態。可能還會有設計師需要再提供設計、需要雙方再討論的狀況，例如下圖：1 - 等待設計師提供資訊、0 - 需要討論。
另外，方便辨別舊 Issue 沒有修好，可增加其他狀態如： 1- Issue 待修正（R2），以及因時間限制無法立即修正： 4- 此 Sprint 無法解決的狀態。
哪些 Issue 等待修正，哪些 Issue 可以檢查了？
Notion 可將表格資料轉換成看板模式呈現，在看板模式下，工程師和設計師都可以快速檢視目前的修正進度，也可辨哪些 Issue 工程師已經修好，設計師可進行檢查了。
如果待修正的 Issue 較多，時間又急迫，可利用排序功能，對「緊急處理」欄位進行排序來找出優先順位較高的 Issue。
Issue 總覽
排序功能也可以用於掌握目前 Issue 的修復進度。只要對「Issue 處理狀態」進行排序，就可以一覽 Issue 所有狀態。
雖然在 Design QA 前期建置與調整流程需要花較多心力，但在後續遇到重複類似的 Issue 時，會因為前期已建置的規則而速度會加快許多，也可以感受到 Issue 有被一一消除的放鬆感。
建立容易管理的 Design QA 流程 — 設計師可專注評估體驗，工程師可批次處理 Issue，這種方式也非常利於遠端協作。
其他工具分享
以下分享幾個在寫 Issue 時常用的工具。由於開 Issue 需要大量截圖，而這些截圖幾乎不會被再次使用，我會優先選用的可以不用再另存新檔的圖片編輯工具。
【捕捉網頁擷圖 — FireShot 】：Chrome 擴充功能。整頁的截圖不需要先下載至本機再上傳。截圖完可直接複製、貼在文件內。省去下載步驟，讓編寫的動作跟上腦袋的腳步。
【顯示網頁使用的字型資訊 — WhatFont】：Chrome 擴充功能。查看網頁字體字型、大小與行高。
【 Shift + Command + 4 】：Mac 內建局部截圖的快捷鍵，存至剪貼簿，不需要再回到桌面刪除截圖。
【 Sketch 】：如果有截圖需要特別用標註輔助說明某個區塊的修改內容，Sketch 可以客製化想要的標註樣式，最棒的是可以將編輯完的截圖直接複製、貼上到文件上。
好工具幫助自己進入 Design QA 心流
幾個 Design QA 工具的使用心得
以下是我過往 Design QA 項目較大量時，各種工具的使用心得。
組織內沒有 Design QA 怎麼辦？如何將它導入到工作中？
將設計的考量傳達清楚
在討論日常中，試著讓跨部門的人能夠理解設計師對產品的考量，例如：
- 外觀上小幅度調整讓資訊更容易吸收。
- 測試站的操作盲點可能會中斷用戶完成任務。
不同部門看待產品的角度不同，讓團隊理解設計角度的考量，較容易凝聚共識，也有助於 Design QA 的推動。
關於如何減少與工程師的溝通落差和心態調整，在 Simon 文章 淺談設計品質控管(Design QA) 提到更完整的概念與經驗分享。
提前將 Design QA 安排在開發階段內，並與工程師討論可行的日期與次數
- 【 開發階段 】：找機會與工程師討論下次可行的預留時間，一起利用這段時間還技術債、一邊進行 Design QA。
- 【 規劃前期 】：在產品規劃前期，與 PM 溝通說明、預留與工程師進行 QA 的時間。
- 【 QA 階段 】：與 QA Team 討論，一起進行 QA session。
嘗試著把 Design QA 時間規劃進工作流程內；如果只爭取到半天或一天，也要保握每次可以優化產品體驗的機會；在進行數次小規模 QA 後，工作流程和跨團隊會慢慢習慣有 Design QA 階段。
Notion Design QA 應用
本文中的 Design QA Demo 已整理成 Notion template，歡迎大家取用。也非常歡迎跟我分享你的使用心得喔！
結語
我常常覺得產品開發是一場揉合了混合接力跑、短跑與馬拉松的瘋狂賽事。
在跑完設計階段棒次，短暫休息後，就要準備與工程師一起衝刺 Design QA，因此在 Design QA 階段時，團隊成員往往已經是身心俱疲。然而如果能在 Design QA 提升自己的續航力，逐步將問題修正，會讓自己在每次面對階段性終點線— 產品落實並上線 時，更加認同所參與的產品。
對自己設計的產品保持熱情，讓每次 release 成為產品體驗的推力
如果你正在摸索 Design QA 進行的方式，或有上述困擾，希望這篇文章能提供幫助與靈感。非常感謝觀看到最後的你，若有幫助、或是其他發現也歡迎與我分享 👏🏻👏🏻
