台北通 App / GDS
上一次寫了一篇如何開始建立設計規範文件是在 2017 年剛踏入 UI 這個圈圈裡的時候，今年因緣際會下進入了北市府資訊局 UX Team，專門處理台北通 App 的介面設計及參與部分功能的流程規劃，這個 Team 其實蠻特別的，他不屬於公務員體系，我們的母公司與市府簽約，派駐一個團隊在資訊局裡做台北通 App 的案子，不過實際上還接手了很多不是台北通的專案，例如：Taipei Government Digital Service（後面會再提到這個專案簡介）。
團隊使用工具：Adobe XD 。一直以來都是用 Sketch 的我對於轉換到 XD 最困難的部分應該就是旁邊工具列表很多都還蠻不方便的，還有 Symbol 的設定…很難詳細一一說明，要實際去使用後才能體會不方便的感受 ╮(╯_╰)╭
年初剛入職的時候，與新同事拿他們正在使用的設計原檔，發現台北通 App 沒有 UI Kits，其實沒有 Kits 真的不會怎麼樣，畢竟每家公司的開發團隊習慣不同，但每張頁面相同元件的間距、字體大小、顏色、Icon 尺寸都不一致，正式機上的畫面在設計檔案裡掉了很多頁（不知道他們開發是怎麼做出 App 的==）、找不到原檔畫面…等，在抓這些細節裡令我感到最驚悚的事，莫過於看到了很多小數點，這對開發來講是很麻煩的，也會造成自己在之後設計排版上的負擔。
龜毛的我看到這些稿真的是無法開工，由於台北通 App 已經上架一年了，基本功能與配置都差不多定案，於是我直接決定先把他們的 UI Kits 先做起來。主管對於處理這件事情蠻開放的，也贊成趕快建立起一個設計規範，讓同事們可以快速因應上頭長官丟下來的改動、順便讓我熟悉所有線上的功能及畫面。
花了約一週的時間，不斷在測試機和正式機上補畫面、抓蟲蟲，終於做好了一份稍稍完整的 UI Kits，讓同事在做專案的時候可以有個依循、也可以一起同步更新 UI Kits 的內容。
與 17 年的文章不同的地方，大概是自己已經比較知道哪些元件需要被抓出來做規範、哪些細節需要被定義，照著自己的基礎觀念去建立 Kits 其實是可以很快做完的。
台北通這個專案的開發流程本身其實洞蠻大的，這邊就不方便詳細描述，主要想講的是長官丟下來的願望又大又深，主打「滾動式修正」（我的註釋：每小時都在打自己的臉），所以在設計和開發團隊這邊需要快速不停的做修正。自從建立好 UI Kits 之後，同事都可以很迅速的產出需求畫面，修改也很方便（除了硬要無視 Kits 的各式大量特殊要求之外）。
最後想說的是，UI Kits 真的不是必要，設計環境還是須依照公司開發流程及成熟度決定，但有 UI Kits 絕對會使你的工作效率大幅上升。
Taipei Government Digital Service
GDS 原意可解釋為 Government Design System，參考英國、新加坡…的 GDS 網站，政府設計系統為他們國家的各個官方網站做了一個系統化的設計模組，我覺得這個概念很棒，可以讓人民瞭解到這個網站的直屬系統是官方所建立。
瀏覽了一下北市府入口網站、各局處網站或其他縣市的官方網站，對於台灣常常被數落的「中華民國美學」來講，建立一個完整的 GDS 絕對是一個超棒的改變。
此專案北市府這邊也與 悠識 Usersper 合作開工作坊，從上到下先讓各局處的相關人員來上課，瞭解基礎使用者介面設計和使用者經驗的概念、練習找出問題並提出解決辦法之後，再進行到落地實行建立。
北市府的其中一個 A 團隊接手了此專案的設計及規劃，台北通團隊負責聯繫、支援及監督此案的進行時程。
在專案初期，原本想投入做 GDS 的我，參考各國 GDS 網站內容，也先建立了一個應該算蠻完整的網頁系統元件檔案，後來因為整個人被抓去做台北通因應 Covid-19 的緊急 App 案件，這份檔案就丟給 A 團隊做未來他們規劃元件庫時的參考。
在這個團隊短短的半年裡做了兩款設計規範，一直以來都喜歡處理 App 的我覺得這個經驗很難得，GDS 的部分就算最後他們沒有參考製作也沒關係，至少自己知道有了這個獨立製作的能力，當做網站的練習也不錯 ( ◜◡‾)
2021/09
