如何進行設計交付？做自己看得懂的檢核表、不要害怕看網頁原始碼…

身為 UI/UX 設計師，「設計交付」一直是工作上的大課題，如何讓工程師更有效率地開發、讓產品更貼近設計稿落地，都是在設計交付這個環節中實現。

我目前待的團隊人數並不多，主要的產品開發團隊即我（UI/UX）、前端工程師、後端工程師以及該專業領域的老闆。因此在產品開發過程中，彼此之間的合作頻率算是蠻緊密。

這一篇文章是想記錄目前在一人設計團隊下，我是如何進行設計交付和品質控管，以及從中學到了什麼？

從會議中一起認識產品

因為目前團隊規模較小，為進行 brainstorming ，老闆會希望團隊中的不同角色在產品開發前期，就一起加入會議。我認為這對設計師與工程師來說是相當好的開始，透過各階段的會議推進，漸漸釐清產品需求，到進行 wireframe 前，團隊的每個人大多對產品的目的、預期效益以及主要功能都已經有初步的認識。

每一次的腦力激盪✨

與工程師密切保持溝通

在 Wireframe 規劃時，先無論可行性，我會將目前產品心目中理想的功能都先列出來。重要的是，與工程師保持溝通，定期詢問工程師：「這個功能我想實現XXX的效果，可行嗎？」、「這部分能幫我判定不同的身份並顯示不同的畫面嗎？」…等等。

如此一來，我能根據工程端的回饋適時調整功能規格，若有必要再與工程師和老闆一起討論並找出可能的替代方案或妥協方案，也能確保團隊在理解目標和限制性下仍保持共識。

找出範例以及可參考的實際畫面

在設計時腦子常常迸出不同點子，如果在靜態設計稿無法呈現，或是時程導致無法在 Prototype 實現時，我會提供工程師以下3種參考來源：

1. Codepen：我會上 codepen 找尋是否已有其他人做出來的畫面，好處是工程師也可以一併看到原始碼，同時如果我想微調修改也能自己開新的 Pen
2. 套件：當你想實現的功能或互動剛好有套件可以輔助，那真的很幸運！不過不是每個套件網站都可以相容，提供時也請工程師確認一下
3. 別人做的：對，就是拿已經上線網站給工程師看，「這個網站做的不錯齁，要不要也來挑戰看看？」

有具體的內容或畫面都比文字傳達或比手畫腳來得好，所以交付前可以檢查看看有哪些互動功能也可以靠以上這些參考來源來減輕負擔。

做一份交付檢核表，只有自己看得懂也行

一開始總是被工程師追著問各種小細節：「如果文字超過這個容器的寬度，是要加高還是加上…符號？」、「圖表預設要幾個資料？」、「如果這個用戶沒登入，還看得到會員畫面嗎？」還有「這個財務指標是怎麼算出來的？」每每被追問都會焦躁不安XD

也因為遇到這些問題發現會讓當下的我手足無措，於是我把每個被追問過、我進一步想到的問題都整理成一個檢核表，其實表格目前蠻陽春（哈

不過是夠我在進行交付前好好 check 一下自己還沒有遺漏的細節:

網路上也有設計師分享檢核表，這裡也貼上來

從網頁原始碼 F12 調整

功能或頁面已完成 70% 時，工程師會跟我對一次，這階段其實還有不少地方可以調整，可能是與設計稿有落差、或是資料放上後發現不如預期需要做調整。

在這個階段產品的樣貌大多都定型了，若要在針對視覺細節優化，比起改設計稿，我更傾向直接 F12 開啟網頁原始碼來調整，調整好後直接跟工程師討論「我想要長這樣子，這是我剛剛有調整的數據（遞」。

所幸在大學時候蠻常接觸 HTML 和 CSS，相當年專題我還是組內負責寫互動網頁的呢！！對於基本的標籤語法都還算熟用。

結語

以上就是當設計師悟出來的一些交付心得，交付做得好，中間來回的溝通就能更少、更有效率。對於這塊也還在學習中，希望往後會有更多好玩的專案！