<- 回專案列表

Design System 重新設計

平台

角色

Lead Designer

執行時間

2022Q2 ~ 2023Q1

負責項目

設計執行

協作流程優化

由於產品的許多基礎功能及設計建置於產品早期,隨著團隊擴大及商業目標的改變,既有的設計系統逐漸不符需求,設計與工程端的協作也開始產生歧義。但也如同許多資源有限的新創團隊,大部分的時間與人力多投注在新功能上,在維護上的資源相對捉襟見軸,以致於待解決的開發問題逐漸累積。

在擔任 Design Lead 的期間,我持續將建置 Design System 的重要性提出討論,並獲得資源啟動專案。

專案摘要

  1. 專案目標

我們的團隊想要為日本的求職者重新設計目前的 Indeed 工作搜尋體驗,同時也想要重新整理產品系統架構增加未來產品擴展彈性。

02 | 角色與產出

在這個專案中,我和產品經理和四位工程師密切合作。我負責整個 UX 和 UI 設計流程與產出,從定義問題到交付最終視覺設計成果給工程師。

03 | 專案挑戰

這個專案當時有不少技術上的限制,需要與其他產品團隊溝通協調,我們同時需要處理許多任務優先級確保我們能在時間內上線第一版 MVP 。

04 | 專案成果與影響

我們最終在六個月內上線了 MVP 版本,這次改版大幅度提升了我們產品的主要指標,尤其是提升了 12% 的整體收益。同時我們也從使用者身上收到了許多了正面的反饋。

有待優化的
開發體驗

本來沒有 Design System 嗎?

舊有的 Design System 雖然也包含各種樣式表及元件,但由於與工程端的協作出現斷層,以至於看似相同的設計,在產品上卻有百百種實作差異。

設計上也缺乏清楚一致的設計邏輯說明,設計師憑各自的理解延伸設計,也導致體驗逐漸不一致和開發的低效。

明明應該是同一個元件,但產品上有好幾種不同的樣式和行為,想要整理但是沒有資源。

我以為這是既有元件,但實際上在工程端卻沒有被共用,需要反覆確認。

我需要在既有元件上擴充規則,好用在新的專案上,但我不知道當初的設計邏輯是什麼?

設計師

工程師

這個之前沒有被元件化,改起來又複雜,時程的關係重刻比較快。

元件沒有既定的設計規則,容易因為開發習慣不同有差異,維護起來越來越困難。

我要怎麼更清楚知道有哪些能複用的功能,可以讓我初步評估開發成本呢?

我了解不重做輪子的重要性,但如果元件化要額外花時間的話,可能排不進這個專案裡...

PM

▲ 原本的 Design Guideline,缺少更完整的應用說明,容易在使用時產生歧義

▲ 各團隊在不同時期開發的產品卡片,大致相似卻又充滿了不一致的細節

▲ 缺乏清晰的設計規則,僅隨每次需求逐漸疊加,變得龐雜而難以維護

關鍵目標

目標一:打好地基

持續而有機的運作流程

Design System 和打造產品一樣,不是一個交付完就結束的專案,比起一次到位,如何創造一個可以持續運作、並持續優化的流程,是這個任務的重要目標。

實際上也因人力非常有限—僅有我與一位前端工程師負責啟動專案,且彼此都有其他任務同時進行,一次翻新所有的設計與功能並不務實。因此目標放在如何小步快速的上線、持續調整和團隊的協作與搜集回饋,嘗試出更適合公司團隊的運作方式。

目標二:產生影響

增加團隊導入並提升效率,擴大影響力

Design System 最主要的目標就是提升效率、改善開發體驗,因此讓各個開發團隊有感 Design System 好用並採納,自然是重要的目標之一。

除了基礎建設外,我們也優先選擇具有高商業價值的元件進行重構,期待讓相關 stakeholder 更直觀感受到差異,進而提升獲得更得更多資源的可能。

▲ 搜集大家在開發時遭遇的問題

設計原則

Hahow 當時的公司規模大約一百多人,其中包含約 5-6 個專案開發團隊。和其他大型設計系統影響動輒數千上萬人相比,生搬硬套相同做法顯然不合理。因此在研究過各式各樣的設計系統後,理解到最重要的不是怎麼做設計系統才「對」,而是找到適合團隊的做法,才是最好的方法

原則一

設計系統是為了增加效率,而不是徒增工作

由於使用設計系統勢必會帶來新的規範和流程,有時難免會產生額外的工作,因此必須考慮「這件事真的能夠長遠地帶來好處嗎?」,而不是為了建立規則而建立;或是單純統一了樣式,實際上對使用者體驗卻沒有更大的幫助。

原則二

設計系統也應隨著產品商業目標而迭代

設計系統的目的是透過一致性加速產品開發、順暢使用體驗。然而作為網路新創產品,經常會探索新的商業可能,一旦發現設計系統之於新產品帶來的不是效率,而是更多創新的限制,就需要考慮在新產品使用設計系統的必要性,或是調整設計系統的應用方式。

規劃執行

如同產品設計流程,發掘問題、收斂、

▲ 搜集大家在開發時遭遇的問題

設計產出

建立設計 <-> 工程更一致的樣式規則

導入 Token 工具

我們參考 Material Design 的命名規則,重新收斂並整理既有的樣式命名,同時考慮團隊規模,在複雜度上稍微做了簡化。

並導入工具於設計流程中,由設計團隊依照樣式的使用目的命名,

流程:

新增樣式 -> 導出 json 檔給工程師 ->