設計師應該如何科學優雅的管理文件？

12-13

針對UI設計師來說，有沒有什麼科學命名和管理的好方法？
（主要針對項目作品相關的文件）

請從命名結構和文件夾結構安排兩個方面解釋。

我現在命名文件結構為：
主要描述_屬性1_屬性2_屬性3.擴展名.
屬性可以是日期、版本號一起其他為了直觀體現文件性質的關鍵詞。
不太認同在文件名前面加序號或大寫字母排序的方法，雖然說視覺看起來會很整齊，但感覺並不科學。

另外很好奇英語國家的文件命名方法，除了某些單詞使用縮寫，如management縮寫為mgmt，其他不能縮寫的怎麼辦？如果命名一個文件豈不特別長？

始終相信作為一名設計師，所有經由我手產出的東西，都必須是被我精心設計過的——不僅僅是最終的視覺稿或標註，而是在整個工作流程中，每一份文件都應該做好接收眾人審視的準備。讓自己的工作更有邏輯性，更高效，也讓拿到你文件的同事或者客戶一秒看懂你的文件結構找到他們需要的東西，易於修改和補充，並且露出「哇看起來好專業」的星星眼。

======================================================================
為新項目建立 6 個文件夾

如果是一個完整的新項目，我一定會一開始就設好這幾個文件夾，不過對於一些日常迭代的需求，則會做適當刪減。

docs ：放置需求文檔、多語言文案、產品數據、競品分析、郵件歸檔
spec ：交互文檔
mockup ：視覺源文件
output ：截圖、展示用的完整視覺稿、change log
measurement ：視覺標註
assets ：切圖

(@JJ Ying 在這個問題提到每個文件夾里都可以再有一個archive的子文件夾，用於存放舊版或不再需要的文件，這是個非常棒的建議)

======================================================================
再建立 4 種不同用途的源文件

標準文件名_for_me.sketch ：（給自己的工作台）

這是創作過程中的文件，我會按照主流程的順序，一個環節放在一個page；把自己需要用到的一切素材和靈感放在叫 Mood Board 的page里（個人覺得用工具不如全部拖進sketch里來的直觀）；那些實驗性的創作半成品則放在一個叫 EX 的page里，總之，這是給我自己看的文件，就像有些混亂的工作台，把所有需要的東西都放在觸手可及的位置。

標準文件名_measurement.sketch ：（視覺標註）

這是為開發者準備的文件，我會從設計稿中提取通用的組件做統一標註，再針對單獨頁面，分別從縱向布局、橫向布局和視覺樣式的三個維度來說明一個頁面。

標準文件名_mockup.sketch ：（正式視覺稿）

這是為所有人準備的文件，當需要和同事合作或向團隊展示進度時，我會從自己的sketch文件中把確定的界面整理到這裡，每個頁面按照版本號排列。

標準文件名_style_guide.sketch ：（Style Guide）

設計完成後，制定 Style Guide，不僅說明規則，也列舉出可以多次復用的組件，方便自己和團隊高效的完成後續的迭代，同時保持設計的一致性。

======================================================================

文件命名規則

說完文件夾結構，再來看看文件和文件內的命名規則 —— 沒辦法，我強迫嘛。

文件名

交互文檔：產品名_平台_產品版本號_ui_spec_文檔版本號/文檔修改日期.pdf/sketch

例：ae_android_4.0_ui_spec_20150101.pdf

視覺稿：產品名_平台_產品版本號_mockup_文檔版本號/文檔修改日期.pdf/sketch/jpg/png/psd.ai

例：ae_ios_4.0_mockup_v2.4.sketch

（如果不同平台的設計或不同版本的放在了一個源文件中則做適當刪減就好）

頁面名畫板名

頁面可以根據主流程或者版本號或者其他維度來區分。
畫板則最好遵守文件一樣的命名規則：流程/場景_操作/說明_狀態，這樣方便將畫板隨時導出，不必慌慌張張的批量改文件名。

圖層名

把每一個屏幕的內容按照功能分區，一個個 group 起來，排排坐，吃果果。注意同一組件在不同平台里可能叫法不一樣。比如 Web 端我們有 header、main content 和 footer，但是 iOS 里的 navigation bar 是在天上的，Android 里卻是指地上的那三個原生按鈕。

熟記好不同平台的結構，不然跟工程師 buddy 手舞足蹈說了半天才發現在說不一樣的東西。(當然也可以直接叫 top 和 bottom，這樣就比 header 和 nav_bar 都要簡短也不易混淆）

同時熟練地利用 sketch 里的 symbol 功能，要會聰明的偷懶。

DOs DON』Ts

使用小寫和下劃線（或減號，只要和你的工程師保持同步就好），不要出現空格和特殊字元
使用簡短的單詞描述功能/屬性而非樣式，比如「btn_pressed」而非「btn_blue」
用具體日期或者版本號做為後綴，不要隨意寫成「修改1」「修改2」「最新」「最新新」「最最新」

======================================================================

這個非常好的問題刺激我思考了一番自己的工作流程，開始寫起專欄，不就是自學個設計嘛，所有分享你都可以直接拿來實踐。

除了特別要求的項目，我沒有用什麼工具，都是人肉管理的說，包括目錄、版本和命名管理。總體是按照類型和功能模塊的緯度來區分所有文件，歷史版本等沒有作為主要的區分

總體結構：
+ Inspirations // 收集的一些靈感，有時候也會用專門的工具代替，比如 Pixa 之類的
+ Docs // 需求文檔
+ Assets // 切圖文件
+ Measurements // 標註文件
+ Output // 截圖或者效果圖
+ Showcase // 項目包裝
+ Source // 源文件
+ WWW // 靜態頁面的 HTML、CSS、JS 等
+ Archive // 存檔

一些規則：

每個目錄下面都有自己 Archive 文件夾，一些舊版本的或者不再需要的文件都丟裡面。
源文件一旦出現了兩個完全不同的版本，把不用的或者舊的那個丟進 Archive 文件夾方便以後翻找，然後主文件的命名會比較勤快，但是 Archive 裡面經常是「修改1.psd」、「Final2.psd」這樣的文件。
文件命名上我喜歡用減號而不是下劃線來連接，比如「home-edit-hover.png」覺得這樣操作在雙擊文件名的某個部分時候能單獨選中這段，方便修改。
感覺現在所有的文件瀏覽系統的按照日期、修改日期等排序的功能都挺全的，所以基本命名裡面都不涉及時間。

基本上類似我在 GitHub 上的一個樣例項目：JJYing/Lifenote-Web · GitHub

一些參考：

國外設計師 / 開發人員的命名習慣可以在 Google、GitHub 之類的地方搜索一下「naming convention」，比如下面這套規則：dkhamsing/ios-asset-names · GitHub
開發人員似乎比較喜歡駝峰式：駱駝命名法_百度百科

其他內容想到了再來補……

勞駕先把您桌面上那些亂七八糟一坨坨的文件刪刪乾淨再說

好了，到了上圖的時刻。。。

只有設計師才懂的圖，說多了都是淚
把這毛病改掉就很了不起了......

手機怒答。
作為一名視頻設計師，要來說兩句。
我一般會這麼命名:
_script 腳本文件
_layout 分鏡頭
_bin 倉庫
_shotfx 特效鏡頭
_editing 剪輯
_output 渲染輸出
_videoclips 視頻素材
_sound 聲音相關
_reference 參考素材

所有文件用Adobe的brige來管理

貼一下我自己的設計命名規範

文件夾 Folders

1. 用 Title Case 命名法

2. 以「文件類型 - 類別輔助說明」格式命名?例如：Glyph - Quick Actions?Glyph 表示文件類型是圖標?Quick Actions 是哪一功能區塊的圖標

3. dash 左右有空格

4. 根據實際情況使用名詞的單複數

5. 不要縮寫單詞

6. 不要在文件夾前面手動加序號，保持默認按照字母表順序排列

7. 根目錄下的文件夾每個內都建一個 Archive 文件夾以歸檔舊版本

8. 一級目錄內按照文件類型分類建立二級文目錄，不同類型的文件不要散放在同一文件夾內，但可以共用一級目錄內的 Archive 文件夾

9. UI/UX 項目根目錄：

- Assets（切圖）

- Documents（需求文檔、文案、競品分析、客戶現產品截圖等）

- Measurements（標註）

- Output（展示用的視覺稿圖片）

- Showcase（項目展示包裝）

- Source（視覺稿源文件）

- Wireframe（線框圖、交互稿）

10. 平面設計項目根目錄：

- Documents（需求文檔、文案、競品分析、客戶原品牌資產等）

- Mockups（mockup 的源文件）

- Output（展示用的視覺稿圖片、最終交付物）

- Showcase（項目展示包裝）

- Source（視覺稿源文件）

11. 素材和靈感圖片在源文件內單獨存 artboard 或 page

文件 Files

1. 用 CamelCase 命名法（每個詞都大寫首字母且沒有空格或連接符）

2. 以「文件性質-文件類型-輔助說明」格式命名?例如：Template-Glyph-NavigationBarAndToolbar?Template 表示文件性質是模板文件?Glyph 表示文件類型是圖標?NavigationBarAndToolbar 是哪一功能區塊的圖標

3. dash 前後不加空格

4. 根據實際情況使用名詞的單複數

5. 不要縮寫單詞

6. 只保留最新一版，更新後舊版本加上 yyyymmdd 格式的數字日期後歸入 Archive 文件夾

7. UI/UX 項目命名以「產品名-平台（-產品版本號-日期）」格式

頁面 Pages

用於版本控制，每一次更新將舊的存為「產品名稱+頁面類型+版本號或時間」的一個 page

畫板 Artboards

根據產品的類型可按照不同分類標準建畫板

1. 按功能模塊

2. 按用戶角色

3. 按使用流程

符號 Symbols

1. 確保 symbol 的粒度足夠小

2. 用全小寫英文字母

3. 給 symbols 里的 layers 恰當的命名，不要縮寫，以免 detach 之後混亂

4. 按照「功能模塊/控制項類型/屬性-狀態」格式，不帶空格的後斜杠分隔便於 Sketch 自動創建 symbols 文件夾目錄結構

5. 全局通用的控制項按照「控制項類型/屬性-狀態」格式

6. 不要過分詳細描述實際樣式，因為會改

7. 默認狀態不用寫屬性或狀態，正確範例：tab 和 tab-active ，錯誤範例：tab-active 和 tab-inactive

8. 確保會經常切換的 symbols 的文字圖層名稱相同，這樣 override 的文字可共用

9. text layer 放到 group 里的第一位，按兩下回車可直接展開 group 並激活到文字內容修改

10. 子 symbol 的排列符合邏輯順序，因為會在 overrides 處反映出來

11. 子 symbol 如果尺寸一樣大也是可以 override 的，碰到頻繁換 icon 和 glyph 的時候很好用

12. text 的大小和位置保持固定，resize 屬性選成 Resize Object 確保 resize 時能正確的 position 和 padding

圖層 Layers

1. 按照「功能模塊/控制項類型/屬性-狀態」格式，不帶空格的後斜杠分隔

2. 描述該圖層的類型而不是內容，比如「name」而不是「Daniel Barton」

3. 如果不同類型的元素歸入同一個文件夾，用「a+b」的形式命名

4. 圖層順序按照頁面內的布局順序和功能模塊排列

5. 根據實際情況使用名詞的單複數

6. 可以縮寫單詞，詳見英文單詞列表

7. 備註用圓括弧，如 large(default)

8. 乘號為避免不識別特殊符號用x代替，如120x120

9. 不同的 color scheme 不用在命名上有區分

切圖 Assets

1. 全小寫並用下劃線連接

2. 按照「模塊組件_控制項類型_功能_狀態@解析度.後綴」命名，如：tabbar_icon_home_default@2x.png

3. 貼邊切圖，不要給 margin 和 padding

4. 色值統一 RGB 或十六進位

5. 標註的間隔和組件的大小遵循偶數原則

字體 Fonts

1. 管理字體庫，團隊協作時共享字體池

2. Text boxes 盡量長度合適

3. 使用 character styles，那是文字的 symbols

Git 在手，天下我有。

實話告訴你，這基本不可能。

反正github又沒容量限制

還是關心會不會被改稿吧

文件的話就不知道怎麼說了，不過文字類和圖片類的話可以談談。
文字類的話，用到的是Loop群主開發的PKM2軟體，他的群號【個人知識管理(A) 19040160】，他本人熱衷於文字信息的管理，所以開發的軟體非常遵循管理的規律。如果有興趣可以加他的群跟各位文字管理的人交流。我就不多說了。

============================
然後圖片方面，因為本人是一名畫師，手中有大量的圖片資料需要管理，相對應的有自己個人化的管理方式。

題主說的那個命名方式：主要描述_屬性1_屬性2_屬性3.擴展名.
要用的是時候搜索相應的關鍵詞，其實用到的就是「庫」——沒錯，是win7新出來的「庫」功能。
（對於win7的「庫「，私以為還是不夠人性化，加標籤太麻煩。操作還是略繁瑣不夠簡潔）。關於這個庫，我想建議題主閱讀一下某篇文章，但是我一時之間找不到當年的那篇文章…………容我幾天想想找找看。。。

庫——也就是相當於給文件打標籤，圖片管理的話可以使用bridge。
這個我就不用多說了，直接查看 Juno_Ma 所寫的【Bridge——設計師Juno的終極圖像管理術】
站酷上的網址：http://www.zcool.com.cn/article/ZMTM3ODcy.html

在bridge裡面直接把題主的命名方式轉換為一個個相對應的標籤，具體看看那篇文章就懂。

其他的暫時沒想到怎樣說。等我把今天接到的單畫完再想著怎樣補充吧~~

養成另存為的習慣，按時間排序，勤建文件夾，勤刪

Spotlight + Tags，表示毫無壓力。

項目編號項目名稱
1、客供資料
2、效果圖
原始版本為V0，升級版v1 以此類推
2、2D
原始版本為V0，升級版v1 以此類推
3、3D
原始版本為V0，升級版v1 以此類推
......
4、Temp （可能需要調用的文件，結案即毀）
5、log 垃圾文件
PS:1、文件層次不宜建的太長，最好不要超過三層
2、文件名不宜包含時間、地點、人物等信息，時間長了東西多了自己也會搞不清

以上。每一個文件夾的誕生都是淚。

活用Creative Cloud的各種library功能，存儲所有素材和設計規範等。然後剩下的就是原始文件和輸出的pair按照版本存好。可以用git，也可以手工。

搜一下「慧豐文件箱」吧