淺談設計品質控管(Design QA)
一起打造更好的產品體驗
今天想來和大家聊聊關於「設計品質控管」這件事，聊聊設計師可以在什麼地方出力，讓每次發佈的產品的體驗變得更好。
身為一個產品(UI/UX)設計師，我們花了許多時間定義問題、思考解決方案、探索設計想法，最後將我們設計解決方案付諸實現，成為一個個精美的介面，接著交付給工程師實作在產品中讓使用者使用。
不過一直以來，我總是能感覺到設計與工程開發之間存在著某種程度的缺口，交付設計之後，開發出來的成品往往不如我預期，或是一些當時設計沒設想周到的地方，工程端就用他們自己的方式自行製作出來了，導致雙方對於成品的想像有不小的落差。
所以，今天想來和大家聊聊關於「設計品質控管」這件事，聊聊設計師可以在什麼地方出力，讓每次發佈的產品的體驗變得更好。
什麼是設計品質控管 (Design QA)
品質保證 (Quality Assurance) 這個詞相信大家都不陌生。在軟體開發的世界中，也常常會有一個 QA 的角色，這個角色在開發流程中和工程師合作，確保他們開發的流程和功能符合產品的需求，且最終的產出是符合團隊期待的、並且在新功能在送到使用者手中前是經過完整測試，功能正常沒有瑕疵的。
隨著產品越趨成熟與複雜，每次發布的功能或新的流程可能會有非常多需要注意的細節。尤其當產品介面上有許多細部的互動和設計時，QA 人員會需要花許多的力氣去做確認與驗證。
而當 QA 人員對設計端或功能的背景沒有足夠的了解時，常常會無法對這些設計上的細節做驗證，導致最後工程師做出來的東西可能不符合設計師或 PM 的期待，最後需要花上更多一來一往的討論溝通，才能把成品調整到理想狀態。
所以，為了確保最終產品體驗是符合期待的(不管是看起來還是用起來)，這時候就需要設計師跳出來和 QA 一起做設計上的品質控管。
▍為什麼要做設計品質控管(Design QA)？ 這件事一定要由設計師來做嗎？
沒錯，做設計品質控管這件事的最佳人選當然就是設計師本人了。
原因其實很簡單：
因為所謂的「完成設計」並不是在你將美美的設計稿和規格交給工程師的那一刻就結束了。
而是當你的設計真正被落實在產品上，並且其不論外觀與運作方式都符合團隊的期待才算真正完成。而要達到這個樣成果，需要團隊的每一位成員從 PM、工程師、QA 等一起合作，但設計師的職責就是把關最後設計品質和整體產品體驗的部分。
也因為在許多公司中， QA 的工作範疇裡主要還是對於開發流程和功能性的層面做驗證，根據情況也會分為手動測試和自動測試等不同測試項目。
QA 人員雖然通常是最了解產品細節的人，他們的工作就是需要不斷的對產品做測試(包含用各種極端的暴力測試方法)，但是對於使用者端體驗上或是介面視覺上的細節，往往很難透過自動化測試來驗證，甚至 QA 工程師本人沒有受過專業的設計訓練，可能也難看出開發成品(Implementation)跟設計稿(Mockup)之間的的差異。
▍設計品質是什麼？在什麼階段要做 Design QA?
對我來說，設計的品質包括了視覺設計的細節、資訊呈現、互動的模式和整體流程的體驗是不是有被完整建造出來，基本上就是從設計師的角度，我們想用來解決問題的設計方案是否如預期般呈現，而不是體驗上有點東缺一塊西缺一塊。
每個團隊的開發流程都太不一樣，但「設計品質」的把關往往不在正規的開發流程中，設計師常常交付設計後就跑去忙別的事，有時候等到功能已經差不多開發完成，QA 測試完準備要發布時，設計師突然看到這功能長得有點歪掉，才會開始大聲呼喊：「欸～這裡有問題～不能上線！」但那時已經在開發流程的尾端，任何的改動都可能會增加開發資源的負擔，工程師們大概也會開始哀嚎：「靠～為什麼不早說～」。
所以我會建議，設計的 QA 最好在進入正式的 QA 流程前，當工程師開發到一個段落(可以積極點去了解他們的開發狀況)，可以邀請工程師們坐下來好好喝杯茶，請他們跟你對過一次設計細節和流程，至少把目前開發成品的外觀和基本的互動修整過一次。
雖然有些時候還是要帶入真實的資料才能看出介面上的差異，例如在資料很多時會不會跑版、資料很少時看起來會不會很空等等，但在正式 QA 前和工程師本地端做過一次這樣的一對一排練(walkthrough)，可以有效減少許多之後的問題跟提前找出必要的修改點。
▍試著讓想像空間縮小、減少溝通上的模糊地帶
每個人對於「想像」這件事永遠都不會有一模一樣的交集，設計師是想像力很強的生物，但其他人不見得是。在產品開發的世界裡，最好的合作方式還是讓其他合作夥伴不需要去「想像」你想要做什麼，最好讓他們看到你的設計成果就知道該怎麼做。
有時候設計師交付了幾張靜態的設計稿之後，工程師就要開始跳進去準備開發，但做到一半看著靜態的設計稿就開始會抓起頭深思：「這個按鈕點了下一頁要怎麼出來？要關閉這個彈窗是只能點擊關閉按鈕嗎？還是點擊彈窗外也可以關閉？這個選單裡面最多可以顯示幾個選項？這個動畫出現的秒數？設計稿裡面好像都沒有交代耶⋯」
好一點的工程師可能就會來一個一個問設計師這些問題，把答案理清楚之後再繼續開工，但趕時間的工程師大概就會使出平時磨練已久的「通靈之術」，把他認為「設計師應該是想這樣做吧。」的解法直接實作出來，想當然之後設計師如果看到成品暈倒在電腦桌上也不會太意外。
所以設計師的責任之一，其實就是要盡量減少這些溝通模糊地帶的發生。
我最近比較常使用的作法就是做一個可互動的原型給工程師，這樣可以確保我能夠完整展示我想要達到的效果。另外，一開始可以試著在設計階段就讓工程師或 QA 參與，除了確認技術上的限制之外，也能從不同的角度得到一些反饋。當然設計師對這些反饋也要懂的過濾、不要照單全收。一旦設計師和工程師及 QA 的互動更多、更密切之後，信任關係也會被建立起來，團隊溝通上也會變得更有效率。
▍設計師無法注意到每個細節，剩下的用合作默契來彌補
這一點雖然講起來有點不好意思，但真的是實話。
即便身為 UX 設計師，我們會盡力確保每一個設計細節、使用情境都被照顧到。但無可避免地有時候就是會漏掉一些少見的情況(edge cases)，這有時可能是歸因於設計師對於技術限制、現有產品的資料結構的不熟悉，因為不確定工程端會如何實作，所以可能設計時沒有想到需要處理某情特定的狀況。
介面設計跟平面設計最大的不同是它是「動態」的。根據資料結構、使用者的狀態或觸發條件的不同，資訊在介面上的呈現都會隨之變化，所以設計師能夠先盡可能想好各種可能的情境是對工程開發有絕對的的幫助的。
像諸如此類的提問是實作中絕對會發生，如果你能在工程師或 QA 問你這些問題之前已經想過一輪，並反映在設計的標註上，這絕對能減少許多一來一往的溝通成本，他們也會對你有更多的尊敬(吧)。
當然，平常也可以多跟工程師聊天培養默契，例如去了解產品上 Metadada 的來源是哪？什麼時候會有撈不到資料的狀況等等。
除了一般會設計的理想狀態外，在設計稿上也可以盡可能詳細描述在不同情境下畫面會如何變化，例如常見的像是空狀態、錯誤狀態、讀取狀態等等，以及在不同的裝置上需要考慮到 UI 畫面的適應性，這些都是能夠事先想好的，對於 QA 到時候要測試不同使用情境時也會很有幫助。
最後，文件或設計稿沒辦法講清楚的地方，就只能靠密切的溝通來彌補了。
「有任何不清楚的地方都可以問我哦！(aka 拜託不要自己通靈)」
這是我最常對工程師說的話，希望他們有什麼問題可以直接來找我討論，雖然有時可能無法馬上回答，但滿多時候當下最理想的解法就是和工程師一起討論出來的。
▍別讓 MVP 犧牲了產品體驗：設計師在意的是整體體驗，PM和工程師在意的是快速交付
PM 們最喜歡說的一句話大概就是：「我們這版先做 MVP ，剩下的之後再慢慢加。」MVP 最小可行產品，很多設計師聽到這個詞，會直覺是要出一個「最簡單、最不費工程資源」設計版本， 透過這個 MVP 先驗證想法，之後再持續優化。
這一切聽起來很合理，但要小心魔鬼藏在細節裡，常常 PM 想趕著上線功能，把一些互動或介面上的瑕疵(UI Bugs)排在次要優先級。
但身為設計師的我們，可不能為了 MVP 犧牲了該有產品體驗，MVP 可以很簡單，但不代表我們要犧牲設計品質，如果 MVP 已經被閹割到只剩下像是「半成品體驗」的時候，設計師應該跳出來爭取更多資源，至少要把「不是最理想、但我們認為是完整的體驗」交付出去，才算是 MVP 的標準，如果發布了一個不是很完整的體驗，相信這個 MVP 也無法為我們帶來我們期待的收穫。
設計的品質聽起來都是些非常小的細節，但也正是這些幾 pixels 的間距、字體的大小層級、轉場的動畫細節等等，我們正在一點一點去累積使用者對於產品的信任。
產品設計的本質就是在利用這一些的深思熟慮的安排，讓使用者有一個美好的產品體驗。如果最終的開發成品沒有把設計師所考慮過的細節打磨出來，不就等於有點浪費設計師之前所思考、設計過的這些成果呢了？
所以這也是為什麼，設計師必須是這個「設計品質控管」的發聲者，讓團隊成員知道我們在意的是什麼、為什麼這些設計細節很重要，他們會對產品帶來什麼影響、對使用者帶來什麼價值。
當然也可以理解的是，產品開發要權衡的事情很多，時間、資源、優先級等等，很多時候設計師可以對一時的「設計產出」妥協，但需要持續地去優化產品上設計的品質， 因為如果設計師對這件事漠不關心，大概整個團隊也不會有人關心了。
結論
聊了這麼多關於設計的品質控管，並不是要叫大家去追求所謂像素完美(Pixel Perfect)或是開發成果要和設計稿完全 1:1 ，更重要的是你對於你的設計的產品有沒有責任感(Ownership)，除了你的成品在設計軟體上看起來美美的以外，使用者真正用起來的體驗是不是符合你想帶給他們的，你的設計有沒有為他們帶來價值。
但不得不說，提高產品上的設計品質真的是非常花時間的事情，需要很多的心力和溝通，而且多數時候除了設計師以外的人比較難去感受這些設計上細微的差異。
我以前還是新手設計師時，一直以為把設計做好丟給工程師後，最後產品就會長得和我的設計稿一模一樣，後來發現完全不是這麼回事，好的設計品質和產品體驗需要設計師和其他夥伴伴們一同努力才能達到，可以想見市面上那些設計品質很高的產品，背後投注了多少人力與精神在上面，才能讓他們的產品不論看起來或用起來都是一場美好的體驗。
身為設計師的我們，還有很多可以做的事情，一點一點的讓設計品質及產品體驗變得更好！
以上就是簡單關於產品開發中「設計品質」分享，如果有任何想法或經驗談也歡迎留言一起交流！
原文出處：淺談設計品質控管(Design QA)
我是Simon，一名UX/產品設計師，目前正在東京討生活。
我喜歡分享、試著從小事開始創造價值，我的興趣很多、話也不少，如果有合作&交流機會或任何想聊的事情，都不用客氣透過我的 E-mail 或直接用Facebook 聯絡我，期待與你的相遇 :)
Simon的Medium：https://simon7972.medium.com/
用台鐵e訂通當例子，把App的價值一次說清楚
