Design Quality Control — 怎麼導入設計品質控管到團隊流程中

W
Aug 23, 2021

完整的設計流程,設計師必須從頭跟到尾

設計師花這麼多時間從前期來來回回的需求確認到好不容易產出設計稿,交付最理想的介面給工程師。但最後上線的版本未必真的能完全符合設計師當初預想的,因此,更積極深入的去了解開發狀態,就是為了讓心血可以更接近理想的樣子被使用者使用。 設計出不良產品,除了無法滿足功能需求之外,更難以確保可靠度與壽命等品質目標。

尤其越大膽的設計越需要頻繁溝通

換個角度去解釋,當平面設計師產出完稿交付給印刷廠後,是不是也會去印刷廠跟師傅看色、確保印刷成品呢?這件事不只是設計師的責任感,也是在降低失誤。

什麼是DQC (Design Quality Control),為什麼是QC而不是QA?

一開始其實我也搞不懂為什麼會稱作DQC而非DQA,畢竟公司有QA的角色阿,到底QA/QC差在哪?所以自己試圖找了一些資料,或許對或許錯,不過讓我更了解兩者之間的差異了,也發現原來公司QA的角色定位好像不太一樣啊🤔

首先,先解釋QA&QC的英文差異,QA=Quality Assurance品質保障、QC=Quality Control品質管理。

QA偏向預防性測試會在開發的過程中同步進行,他需要去確保開發團隊是否有依照先前制訂的方式、流程與規範去執行,來保證產品品質不會有誤差。因此,產品開發規範的制定與落實,屬於品質保證的範疇。其中包含了像是程式碼中的命名慣例、排版原則,或像版本控制系統的使用規範,大到軟體需求規格書的寫法、設計書的內容、測試案例…等等。

QC則是事後補救,會在開發完去檢查是否正確,會透過各種型態的測試,來找出待測產品中所涵蓋的問題,並且搭配瑕疵追蹤機制,監看、管理瑕疵被找出來以及被修正、被檢驗的情況。

雖然QA和QC的工作是有所差異的,但最終目的都是希望產品滿足所規範的品質要求拉。簡單瞭解QA&QC的差異後,其實我做的是涵蓋DQA&DQC,會先訂出設計規範與排版原則等guideline&system使用規範,也在開發後檢查設計被落實的狀態,但比較著重於後者事後補救與檢驗。

為什麼要有DQC?DQC的必要性,為什麼QA以外還要被Q一次

1.在設計的過程中難免還是會有難以被發現的盲點,我們只能不斷對齊想法來減少失誤

在設計的過程中會盡可能去考慮到元件可能出現的狀況,但還是會有被遺漏的盲點,或是架構限制等原因讓設計稿無法被落實。有可能是對產品不夠瞭解,資料架構不熟悉、設計債技術債等迭代過程沒有文件存留、不確定會怎麼被實作等等,總之就是事情跟設計師原本想的不一樣,導致於有突發狀況。

2.整個體驗真實的被落實出來,才能算是告一段落

設計的部分除了介面的細節之外,其實也包含了互動的動畫效果,在最急忙的開發流程中,設計師不一定可以做出精美的prototype,所以可能導致工程師跟你想的不一樣,或是被工程師遺忘的細節,而設計師一定是團隊中視覺敏感度最高的角色,被開發出來的畫面沒有讓設計師看過的狀態下難以被保證真的符合設計稿跟設計師的初衷。

3.QA很難確保視覺被落實的狀況

很多公司有QA的角色,但QA的工作範疇主要還是對於產品的功能面做測試與驗證,以及QA沒有受過專業設計的訓練,很多時候很難去區分測試站與設計稿的視覺差異,即便是由其他設計師代理這個工作都難以確保能夠被完整執行,最好的辦法就是讓產出者設計師本人自己去管控。(自己的鍋自己扛的概念)

DQC是最容易被犧牲的環節,身為設計師應該站出來捍衛整體體驗

團隊內有各種不同角色,每個角色會在意的地方不一樣,設計師如果沒有話語權無法站出來捍衛整個使用體驗的話,就無法展現設計師的存在價值,當然,在各種開發情境之下都有必須要被犧牲的東西,可以暫時的退一步,讓UI issue在下次的迭代被優化,但不能一直都不把關品質。

設計品質可能乍聽之下很沒必要,團隊其他角色都可能去challenge設計師,但試著去說服,跟不同角色溝通傳達品質控管的重要性,我想也是設計師的工作內容之一,幾個px差距或是差一點的文字大小粗細顏色(?)、可能有點糊的圖片icon(?)、有點卡的動畫效果(?)其實一點一滴的累積起來都是扣分的體驗。

BUT!也不是要追求1px都不差的完美介面,更著重的是設計師對於自己的產品有沒有責任感,整體的使用體驗是不是有達到預想的狀態。

設計品質控管一定是耗時耗力的,在原本開發流程中加一個過程怎麼能不多花時間呢?不管是設計師或是工程師可能都會有痛苦的地方,但這麼做都是為了產品可以更好的呈現。

原本的工作就很多了,多了一個流程更崩潰的我們

DQC也會複雜到需要追蹤管理,用Notion追蹤管理Design Issue

最後,身為腦容量有限的Designer,每次DQC完都一片混亂,有些issue難以被處理,有些issue要延遲處理等待下個迭代等等,怎麼追蹤跟管理很重要。單靠自己的記憶絕對不可靠,要QC的裝置太多了,每次的記錄追蹤管理都是要確保每個裝置都有被測過。

以我遇到的專案來說,要QC的範圍包含Web&App,其中網頁又有手機版&桌機版,裝置也有Chrome&Safari,App也有iOS&Android。因此我整理了一份表格,列來列去最後發現網上大大有整理好的template可以用😍結合我自身專案的狀態調整了list。

也分享給團隊內的PM&RD&QA讓大家可以方便追蹤UI issue

--

--