命名，是困擾很多 UI設計師的常見問題之一。從我們開始在軟件中設計内容時，就要對圖層、圖層文件夾進行命名，到對接開發的時候，還要對切圖進行命名，再到管理我們的版本，項目文件目錄，命名技巧都是不容我們忽視的團隊協作技能。

這類文章網上寫了不少，但很多同學去查看以後還是覺得無法在實際項目中應用。這是因為，隻學一些常用詞彙或命名格式，隻是聊勝于無，無法真正加快我們的效率。

尤其在今天，越來越多的互聯網團隊開始使用雲服務同步項目文件，如 Dropbox、Google Driver、Synology、堅果雲等等，這使得我們的項目文件還要暴露在所有團隊成員的公共視線之中，命名已經不是設計師一個人的事，重要性越發凸顯。

下面，我們來完整讨論讨論關于 UI 設計中文件命名的規範和要點。

一、文件的檢索方式

首先從文件的命名開始，前面提到的「适當」 一詞，就是因為對 UI 文件進行命名是沒有唯一标準的，如果隻靠對命名的死記硬背，依舊會在項目中遭遇諸多阻力。

要知道，之所以需要命名，它的目的是為了方便我們——檢索，讓我們可以更高效的查找到指定的文件。

在 Windows 中，由于某些曆史遺留問題，表現形式都在鼓勵使用層級邏輯來存放文件。最顯著的莫過于硬盤分區，C盤既然已經被默認分成了系統相關文件分區，那麼 D、E、F 盤自然就應該是劃分出遊戲、學習、電影的分類。

而 Mac 系統弱化了硬盤分區的概念，在 Finder 中更多突出了對文件進行标記，高效主動查找功能 Spotlight ，也就是暗示你文件存在什麼地方都無所謂。這是很多 PC 用戶剛剛切換到 Mac 不适應的原因之一。

2. 排序檢索

排序就是計算機文件排列的方法，無論是 PC 還是 Mac，在文件夾空白區域點擊右鍵，都可以看見排序方式的選項。有文件類型、名字首字母、創建日期、修改日期、大小等等。

在日常中我們使用這個排序功能最頻繁的原因，應該是文件沒有對齊網格，所以使用排序功能幫我們快速整理。

而在一個文件非常多的目錄中，我們就可以通過使用不同排序方式來快速找到我們想要的文件。

比如 Windows 經常會有「某.dll」引發錯誤的提示，我們要通過名字排序的方式在 win32文件夾下面找到這個字母開頭的文件區域，再向下一個字母縮小搜索範圍，然後很快就能清楚這個 .dll文件是否存在。或者，我們解壓了某個遊戲，它的根目錄文件特别多，于是我們就會使用類型進行排序快速找到 .exe 結尾的幾個啟動圖标。

3. 标簽檢索

在 Mac 中，标簽功能是被重點突出的，可以很方便的創建、分配标簽給文件。這樣，我們就多了一個維度來查找文件。

比如一個項目名為「超人的電話亭」的 Sketch 文件因為版本或者功能的原因，要分别存放到不同的文件夾内，沒有刻意使用層級系統進行分類，那麼如果有一天我需要找出并另外備份項目中所有的 Sketch 文件，那麼就可以在一開始打上「超人的電話亭」标簽，以後隻要選中這個标簽就可以立即篩選出這個項目的文件。

再到類似 Things、滴答、印象筆記、Bear、Eagle 等會包含大量目錄文件的應用，都會提供标簽這個檢索維度。

關于Eagle 的詳細介紹：《這款國人開發的Eagle，堪稱收集和管理素材靈感的最佳利器！》

這個功能在 Windows 資源管理器中是可以忽略的……

4. 主動檢索

主動檢索就是搜索，就是在輸入框中鍵入文字内容，直接根據名稱或者标簽、類型來查找你想要的文件。

這建立在我們對文件名稱已有一定了解的基礎上。例如想要快速找到之前切圖中的登錄按鈕，你可能就會直接輸入「登錄」或者「按鈕」這些關鍵信息。

而如果文件名本身沒有和内容有任何關聯，或者這種關聯是混亂的，那麼搜索自然無從談起。

5. 文件命名總結

項目的文件命名，說到底叫什麼、用什麼英文簡寫、大小寫和符号都是次要的，我們是要通過命名這個步驟，加快前面4種檢索行為的效率，而不是為命名而命名。

并且，在一個團隊中，大家使用的電腦系統不一定一緻，開發使用 PC，那麼你就不能強調文件中的标簽。而如果使用公共網盤，那麼不同網盤對排序的細節是有一定的區别的，都要經過測試再做決定。

二、文件的命名系統

在我給大家提供的思路中，隻以兩種檢索模式作為出發點，即層級和文字排序，因為我認為它們具有最廣泛的适用性。

并且，好的命名系統一定是緊密結合項目文件管理方法的，它能幫助我們有強迫性的對文件進行分類和删除冗餘的部分。即使任何一個人打開我們的項目，也能輕易找到目标，才是我們追求的方向。

1. 文件層級

項目開始時，要先規劃清楚，會出現哪些類型的文件，做出層級的劃分。

例如，在我過去的某個項目中，第一個版本文件包含的分類有 PRD文檔、Sketch原型文件、Sketch設計文件、其它設計文件、動畫源文件、參考圖片、應用素材、導出展示圖、導出交互動畫、設計說明、切圖等等。

那麼我們将他們分門别類，就可以得到下面這個樹狀圖：

那麼，我們就可以以此在名稱為 V1.0 文件夾下方創建各級子文件夾了，之後将對應的文件置入到指定層級文件夾中，就完成了我們初步的文件整理方式。

當然，不同項目性質和流程可能會有增減，最終确定的層級是需要自己整理的。即使一開始定義的不夠完整，那麼随着項目的深入，你可以直接在同級中插入新的文件夾即可。

而我們的命名系統，從這裡就開始了！

2. 文件夾命名

我習慣使用數字作為同一個目錄文件排序的方式，因為數字最容易被我們記憶，并且可以營造秩序感，減輕我們打開文件夾的焦躁。

上面是一般我會使用的文件夾命名方式，即使用—— NO._文件夾名稱。

因為默認排序方式「按名稱」會自動根據數字遞增，那麼文件的序列就能保持不變，使用幾天以後，這種數字序列就可以被我們有效的記憶。即使幾天後增加一個新的文件夾——「8_活動文件」，也不會影響到前面已經沉澱下來的習慣。

試想在你的手機上的微信啟動圖标，用的次數足夠多時，我們其實記憶的就是它是第幾行第幾列，而不是根據圖标樣式和應用名一個個看過去。同時，這樣劃分的文件夾，任何項目相關的人員都會很清楚應該如何查找自己需要的内容。

3. 畫布命名

在文件夾内的文件，是否一樣需要有效的序列，也要根據文件的具體屬性來确定。如素材圖，有沒有特意命名都不是太重要，因為它們沒有記憶和反複提取的必要，保存下來隻是做備份而已。

而界面展示圖，意義就不一樣了。多的有幾百個界面，少的也有二三十個，如果我們沒有任何命名和排序模式，那麼看起來會非常累，找一個指定的頁面也非常累。

所以該如何做出有效命名，就要從設計界面時的目标開始說起了。一般分為兩種情景，一種是比較大的工程，涉及到非常多的界面和模塊。另一種是以完整業務流程為準的設計項目，那麼它們的排序上就會有一定的差異，大緻如下方所示。

模塊_子模塊_類型_狀态，演示：

設置模塊_個人資料_頭像裁切

啟動模塊_注冊_驗證碼填寫_驗證失敗

流程名_流程步驟頁_狀态，演示：

發布流程_内容填寫_照片編輯

購買流程_提交付款_成功

基本的文件命名，都會根據層級從上到下通過下劃線分割。之所以需要這樣的層級劃分，是因為我們可以用來命名頁面的詞彙是有限的，如果一個應用中出現了很多都要稱呼為設置的下級頁面，那麼最好要清楚它的從屬關系，是哪個頁面跳轉進來的。

導出的界面圖片命名，實際上就是畫布的命名，以 Sketch 為例，設計還未導出的階段就要做出整理。Sketch 中有個關鍵功能是左上角的 Page 列表，我們可以通過創建不同的 Page 将整個 APP 的頁面進行分類。例如下面的案例：

我将整個 APP 劃分成了8個大模塊，每個模塊前面都增加了一個序号，并且這個序号對應我們的正常浏覽和權重的順序，之後再對每個畫布進行命名，這樣不會輕易搞混。

而在畫布的命名上，除了前面提到的下劃線層級以外，數字的排序依舊是要使用的。因為當我們導出了大量的頁面以後，查看的習慣就是放大一張一張向後切換，而這個向後切換的過程是需要有明确排序的，不能看了第一頁是購買成功，切換下一頁就是啟動頁。

所以我導出的頁面命名畫風是這樣的：

第一個數字是模塊序号，不僅快速表明所屬模塊，同時等于将所有頁面做出了分類。而在第二級開始對頁面做出命名，根據操作順序和權重，在頁面名字前面再增加一個序号。

比如社交模塊下的詳情頁，就可以這麼表達：1_2詳情頁。

但詳情頁不會隻有一個狀态，可能涉及到帶有評論的，不帶評論的。或者詳情頁下屬所有獨立的評論頁面。那麼我們就要再增加一個層級，正常情況導出去，文件的排序會受到文字首字母的幹擾，m>p>y，于是實際排列就會是這樣的：

1_2詳情頁沒評論

1_2詳情頁評論詳情

1_2詳情頁有評論

如果評論隻有一個狀态，但是包含下級頁面，那麼可能命名後實際的排序就會變成下面這種情況，下級頁面排到前面：

1_2詳情頁評論詳情

1_2詳情頁

所以，為了解決這些混亂， 我會在詳情頁後面和下一級标題前面都增加序号。比如：

1_2詳情頁1_1完整樣式

1_2詳情頁1_2沒有評論

1_2詳情頁2_1評論詳情頁默認

1_2詳情頁2_2評論詳情頁空白

1_2詳情頁3_1點贊列表

1_2詳情頁4_1轉發列表

命名最多隻需要保留4層即可，再長下去已經會很明顯的幹擾我們查看，并且中文實際應用起來是比英文高效的，因為英文字符占位大多不如中文精簡。

雖然這麼看起來命名似乎非常複雜，但隻要适應一下很快就能習慣并應用自如。因為這種命名的方法除了在導出後可以按順序查找，還會強迫我們思考頁面的關系，并會根據這種關系來排列 Page 中的 Artbord，我的習慣是獨立頁面橫向排列，不同的狀态就縱向排列。

而不具備這種規律的複雜設計文件，會出現什麼情況，借用上家公司拿到手的主要頁面源文件舉例（實際頁面數大概是這些的10倍）。雖然模塊有一定的分類，但是層級太碎片沒有邏輯，所以這些模塊的位置很難記憶，我們每次都要先花很多時間去定位到模塊位置，再浏覽頁面内容來找到想要的内容。

再加上其中每個模塊，實際上都有一個獨立的 Sketch 存放更完整的設計文件，那麼當每次我們要查找、修改、覆蓋對應的設計文件時，都需要消耗大量的精力。

産品、設計、前後端程序員都需要不定時查看源文件，如果為了這種缺乏體系的命名規則降低效率，長此以往，那造成的經濟損失遠超大家的想象。

畫布命名的規則，之所以要有邏輯和嚴謹，就是為了在任何情況下，我們都可以快速定位到源文件，對它們進行說明或者修改。無論是給自己、其他設計、其他同事查看我們的内容時，都可以很快摸清楚門路，不會像無頭蒼蠅一樣隻能挨個查看。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部