How do I organize a medium-scale product design files with Figma

7 min readMar 19, 2023

身為一個產品設計師，當產品成長到一個階段後，伴隨著大大小小的迭代，常常會發生「在茫茫專案海中找不到最新畫面為何，因此拿到舊版畫面/元件」的問題，並且 PM 或其他團隊有時想從 Figma 上看畫面或拿圖時，也會因為很難找到所需功能跟畫面，而需要一直問設計師的狀況。

因此，為了想解決這些問題，決定建構出一個產品、功能、到專案 Handoff 檔都分類邏輯清晰，易讀易整理的架構。不僅加強設計迭代的效率，也減低團隊溝通成本。花了一段時間與團隊設計師、PM 一起討論後，終於完成 Figma 設計檔架構整理：

一、Figma Configuration

Product & Main Feature

我們針對不同的產品(Mobile App,Web)分別成立一個 Team，Team 裡面的 project group 則是依據產品裡的主要功能去分。因為產品的迭代大多都是依照功能以及 User Flow去迭代，而非單純美化某一頁，常常一個功能就會牽涉到不同的頁面，為了設計與未來回來找資料方便，會使用「主要功能」而不是「頁面名稱」去分類。

舉個例子：例如訊息功能除了訊息頁外，還會牽涉到公司頁、帳戶頁、個人檔案頁、設定頁的迭代。

Specs

基本上幾乎每個專案的 Handoff 檔案都會有 UI Spec，去紀錄設計上有哪些狀態、變化邏輯與規則限制。基本上 SPEC 是累加的，做迭代時以前講過的 SPEC 就不會再特地講一次，只會講這次新增與修改的規則。但久而久之，在需要迭代一個很久沒迭代的功能而需要對照目前的 SPEC 時, 就會很容易迷失在一片專案海，不確定哪個 SPEC 有被迭代過了，哪些還在沿用。

因此我們參考了許多其他產品的設計架構，另外開了一個 Spec File ，將各項功能的最新畫面與SPEC ，以及重要的 User Flow 收集在此，方便未來設計時回對拿取，也方便 PM 在思考 Product Roadmap 時，有個地方可以去一覽所有最新功能畫面。

將各項功能的最新畫面與 SPEC ，以及重要的 User Flow 收集在此（source of truth)

另外，這份 SPEC 同時也會包含「功能的特定元件」，我們稱為 Parts 或 Elements。Parts(Elements) 通常都是由 Global 的 Component 變化而來，只是通常用途特定，並且常常緊密的牽涉到 flow 和狀態變化。這些元件通常是設計師在進行專案時，為了設計快速而將畫面中的某個特定部分 or 特定用途的按鈕，製作成 Figma components，製作 Parts (Elements)目的不外乎是為了讓設計變更快、更好維護。如果母元件有修改，Parts (Elements) 也會更新，並同步到所有的畫面與 User Flow 上，不用逐一修改。

Design Library

我們的產品因為還屬於中型產品，每個主要功能還沒有發展成非常龐大（像是 yahoo, Google, Meta 等就屬於大型結構），因此在 Design Library 的連結檔案上，暫時先採取簡單的組織架構，也就是每個主要功能，都連結到一個主要的 Design Library。

示意圖來源：https://zeroheight.com/blog/how-to-organize-your-figma-files-for-your-design-system/

Summary

Teams 會依據「產品線」來分類.
Projects 會依據「Feature」或「Feature Group」來分類.
Specs 會跟畫面、Flow 等一起整理進一個單獨檔案中，裡面的東西都是最新的、正確的。
Design Library 會是一個單獨檔案，分別存在於不同的 Team 中。

二、Hand off Configuration

為了讓工程師與 PM 能夠透過 silent read 就能弄懂 90% 專案的細節，降低來回溝通的時間成本，以及在 present 時大家都能夠清楚易懂，因此不管是設計檔還是 Hand off 檔，我都會盡量用從上到下，從左到右的排列方式（配合閱讀習慣），並依順序放置以下內容架構：

Overview section: 包含專案背景內容與細節，跟對應的文件連結。
Components/Parts state & spec: 比較重要的 component 的變化狀態與規則。
Page state & spec: 依據畫面名稱分類，可以一覽這次的專案新增或迭代了哪些畫面，以下這些畫面的關鍵狀態、UI SPEC
User Flow: 每個 User Story 都會對應到相關 User Flow, 每個 Flow 前面都會有個 Cover 去簡述這個 Flow 的 User story 和其他細節。

三、Project Configuration & Iteration

通常在某一個大 Feature 內的專案都會以 User flow 或 Epic 取名，每個專案都會包含以下內容：

Cover: 方便後續找專案時，能清楚知道現在這個專案是什麼，裡面的功能流程迭代到哪裡了，以及一些文件連結。
Project & Iteration: : 每個迭代放一頁，若為比較大規模的迭代，那會需要考慮是否要另開一個專案來做。
Project Component: 放在這專案裡的 Components & Parts(Elements), 再定期整理到 Design Library(較通用的元件）或 SPECS(較綁定特定功能的元件）
Archive: 目前用不到的 Idea 或被暫時淘汰掉的舊設計，先留著以免往後還有需求要拿回來用。