守護設計的最後一道防線 — Design QA

有一種悲傷，叫做開發完成後的設計長得跟設計稿中完全不一樣卻又不知道從何提起的悲傷。今天我們來聊聊如何療傷吧 🥲

在文章開始之前，我們先來看幾張迷因圖：

圖片轉自 ig @shutthestartup

圖片轉自 ig @shutthestartup

身為產品設計師的你，看到這些圖有沒有想起了一些崩潰的故事呢 😊？

在一項功能開發的過程中，產品設計師通常扮演的角色是功能進入開發前的探索及產出設計。而隨著設計進入開發過程，設計師的參與度就隨之下降，以至於往往開發完成後的設計常常和原設計稿差個一兩個缺角。而這些缺角累積起來後，就成為了大家最恐懼和頭痛的設計債務（Design Debts）。

以個人的經驗而言，通常完成開發後設計不如預期的原因大概分為這三個：

1. 設計師和工程師間的溝通不良
2. 設計稿品質不良（畢竟我們也不是神啊，偶爾就是會漏東西 ＱＱ）
3. 工程師開發過程漏掉資訊（工程師也不是神，不可能所有細節都看見）

而上述問題當然可以透過更緊密的合作、改善溝通或是定義更多規範（如 Design System）來改善。但對資源比較缺乏又要求快速產出的新創公司來說，與其將時間花在討論合作流程或改善交接流程，不如引進所謂 Design QA (或稱 Design Review)。

什麼是 Design QA?

Design QA 是個讓產品設計師能在某功能正式上線之前審查上線前最終樣貌的一個過程（通常建議為 24–48 小時）。這個最後的審查時間讓設計師能在功能上線前把一些設計或易用性相關的細節挑出來並由工程師修復，讓產品上線後的使用者體驗能夠更好。

當然，就像先前所提到的，產品上線前的設計品質也可以藉由更適當的協作或討論來確保產品品質。不過 Design QA 能更加確保產品上線前所有的設計疏漏都能夠被抓出來修正或紀錄，以降低設計債務出現的機率。而也當然，當產品開發流程逐漸成熟化後，Design QA 則可能就不再那麼重要。

不過，在流程變成一位「成熟的大人」以前，Design QA 所扮演的角色就很重要了，畢竟不管是設計師、PM、工程師、甚至是公司老闆都希望能開發出個讓你我都驕傲的作品。而Design QA 可能無法確保產品的最終樣貌很完美，但至少能將品質「往上」提升，並在過程中培養組織對於最終使用者體驗的同理心。

Design QA 和軟體開發流程的結合

大概說明完 Design QA 是什麼樣的怪物了，接著我們來看看 Design QA 如果被放入在軟體開發流程中會長什麼樣子：

我們所熟知的軟體開發流程，大概長這樣 （請原諒我稍微簡略一點⋯）：

導入 Design QA 後，大概會有三個選擇，我們來看看各選擇的優勢和劣勢：

1. 先 Design QA，再 Dev QA

⭕️ 優：基本上就是自己的設計自己負責品管，不太需透過 QA 工程師作為溝通橋樑。

❌ 劣：如果事情一多可能就成為 QA 工程師的絆腳石 ＋ 功能還沒正式進入 Dev QA，因此可能技術面上就有不少 Bug，無法好好體驗功能。

2. Design QA 和 Dev QA 同時進行

⭕️ 優：Design QA 不會成為上線前的絆腳石 + 有另外一個 QA 可以一起看確保沒有東西疏漏。
❌ 劣：QA 工程師可能會很不爽為何要跟你一起 QA（？）+ 且兩方同時一起測試的時候有很大的機率會看到類似的 Bug，導致開出來的票差不多（？）

3. 先 Dev QA，再 Design QA

⭕️ 優：設計師看見的產品已經移除一些基礎的 Bug，測試功能時可以看見更接近產品上線前的樣貌。
❌ 劣：QA 工程師對於設計稿的內容不會比設計師或前端工程師熟悉，因此有可能會來來回回問一些設計的問題。而 QA 工程師通常也習慣會依造設計稿做 QA，因此很容易和 Design QA 重工。

其實三者之間並沒有哪一個適用於所有公司⋯⋯ 所以其實很看公司流程和合作的 (QA) 工程師。

以個人經驗而言，我會推薦先 Design QA 再 Dev QA。最大的原因是我個人很常在開發的過程中和前端工程師直接討論開發細節並改變一些設計細節，而當事情多的時候也不一定有時間回去更新設計稿 🥲，導致 QA 工程師在測試時會看著設計稿感到困惑。當 Design QA 在 Dev QA 前進行時，設計師就能在 Design QA 階段幫助 QA 工程師將設計面的 Bug 通通抓出來，而 Dev QA 階段就可以花更多時間專注在工程面的問題。

Design QA 到底要抓什麼？

講完流程，接著快速說明一下 Design QA 大概在抓什麼樣的問題。其實也沒什麼好特別說明，大概的內容就是身為設計師的你會不爽哪些細節，其中大概可以分為：

1. 視覺上的問題（UI） — 顏色、字體、文字、按鈕大小等等
2. 功能上的問題（UX） — 按鈕點擊後有沒有反應、視窗展開的方向、等等
3. 其他的 Bug — 其他零零碎碎的問題

至於抓出來的 Bug 們該如何讓工程師開發呢？也大概分為三種方式

1. 開票：

其中第一個方法就是直接在 Scrum 版內開票，讓 Bug 可以集中在 Scrum 版內追蹤跟修復。

這邊也補充一下，若是直接開票，建議盡量使用貼近工程師的語言。例如間距（Spacing）可用 Margin、Padding 表示。

敝司使用的開票格式大概如下：

問題描述：
// 描述問題

預期的結果：
// 描述完美情況下的設計

實際的結果：
// 描述現況（通常會附上截圖）

（敝公司在 Jira 上的範例）

2. Figma 交付：

第二種方式（可與上方結合），則是將所有 UI/UX 上的問題都放在 Figma 中，讓工程師可以在設計檔中直接看見所有需要修復的 Bug。特別推薦個 Figma Community 上的模板 👉 點我查看。

Figma Community 上的 QA 模板

3. 直接溝通

最後的方法當然就是直接和工程師溝通（通常還是會跟上面兩個方法一起用啦⋯⋯），讓工程師可以直接了解你提出的問題。

結論

知名顧問公司麥肯錫的研究顯示出「當公司更專注的於提供更好的使用者體驗時，公司能在五年內提升 32 % 營收以及 56% 的顧客回頭率」（資料來源）。

雖然身為產品設計師的我們都知道提升設計和使用者體驗的重要性，不過在實際的公司環境中，為了縮短開發時程，設計和使用者體驗常常被犧牲。也因此，設計師們常常需要想盡辦法找到開發速度和使用者體驗之間的平衡點。

Design QA 算是許多方法中，個人認為對於在設計成熟度（Design Maturity）屬於初期/中期的公司，相對容易引進且不引起太多反彈的流程。你的公司也有引進 Design QA 嗎？或是公司中也有看見其他提升使用者體驗的方法嗎？歡迎一起分享讓我們可以互相學到更多守護設計的方法 🌞

特別感謝 Zoe 協助校正文章 ✨