和很多人一樣，我并不喜歡「整理」這件事情，我的桌子總會在一段時間后變得凌亂，電腦桌面也經常布滿各種類型的文件圖標。在具體的設計工作中，（仗著自己記憶力還行 + 有搜索功能在）也會表現得比較隨性，存放設計稿的文件目錄亂糟糟，疏于整理沉淀產品的設計規范，交付物的樣式經常變來變去等。
誠然，整理上的工作優先級不算高，經常需要給更重要的事情讓路，在項目組人員很長時間都不會發生變化時意義相對也不大（因為大家都足夠熟悉現在的工作模式）。但一旦出現項目變動人員交接搭檔變化的情況，忽視整理帶來的缺陷就會更容易暴露，也會給新的項目成員造成困擾，我還記得很久之前一次臨時交接工作中講解一些設計規范注意事項時的不耐煩心情，而對方的估計也一樣頭疼。（想起程序員最討厭的事是自己要寫注釋和別人的代碼沒注釋這個梗，其實設計師也有類似情況的 233）
文件夾的歸類與命名
我在前一家公司實習的時候，大家的設計稿一般存放在 Server 上，并且有些比較約定速成的歸類與命名方式（目前記得的有按版本分成 V1\V2\Archieve\Latest...，或者按時間分成 201X-XX，一組高保真設計稿按交互流程前綴上 01\02\03...），當時的老板會在組會上當場 Review 大家的設計文件存放方式是否規范（比如 .psd 和 .png 要放在不同的文件夾，不能混在一起），否則挨罰。不過我有一點一直做得不太佳，就是會慢慢把文件目錄搞得過細過深而疏于重新整理歸類（懶......），結果反而影響了查找東西的效率。
這樣的好處是別人（上級、項目組伙伴、其他設計師）看你的設計成果時能一目了然，迅速找到想要的東西，而不是迷失在混亂的版本管理與各種類型的文件海洋中，也相對不容易出現拿舊的設計稿開發完才發現不對的情況；你也可以更方便地瀏覽別人的設計稿、尋求思路借鑒。作為用戶體驗設計師，在公司內部和他人合作時，也要注意怎么帶給別人更好的體驗。
常用組件的整理沉淀
大公司的大型成熟產品線通常都有一份完整的設計規范，沉淀了各種常用的組件與使用原則，這樣的規范可以幫助新人設計師迅速熟悉和接手工作，將更多精力聚焦到對業務和用戶的理解與思考中去，而非糾結已經很成熟的組件設計上的細節。
但如果是做從 0 到 1 、偏偏還比較復雜不是一兩個內嵌頁面了事的產品設計，有必要時就需要自己動手豐衣足食了。起初做這樣的產品時，我對組件與規范的沉淀不以為意，也磕磕絆絆完成了第一期的上線，后來不斷增加新頁面新模塊的設計時，都是憑借自己的記憶從舊設計稿中找到可以復用的組件，但隨著時間推移記憶負荷與查找成本也有所上升。后來趁一個比較空閑的工作周里做了一下網站組件的統一梳理沉淀，并參考其他部門一些成熟的設計規范，寫了相應的使用場景與原則，進一步加深了自己對組件在交互設計中如何運用的理解，也希望讓自己之后設計工作里查詢復用、甚至項目變動需要交接給他人時變得更加方便。
交付物的規范化與實用性
剛來現公司實習不久時，寫過一篇設計文檔相關的文章：如何寫好一份設計文檔?。隨著時間推移，我發現自己的設計交付物雖然整體框架上還好，但細節上是有各種問題的，所以也在不斷地迭代優化。后來偶然接手了一個之前由天貓設計師負責的小項目，進而又通過內網發現天貓的設計師們有一套相對成熟的交互交付物規范，包括任務流程、用戶路徑、信息架構等，都有比較完整的模板，比自己摸索出來的交付物要成熟不少，注釋細節之類的信息很完整清晰。
但在實際工作中我發現，交付的規范、嚴謹、說明全面的交互文檔可能并不一定能起到很好的效果。比如前端未必有耐心去閱讀你那大段的文字，一個簡單的交互動效，用 Axure 直接模擬出一個可以交互的高保真效果演示給他人，比口干舌燥地描述上一大段效果要好得多；又比如常見的「左側標記數字，右側空白寫說明」的布局模式，在 PC 端的產品設計稿中（ App 端應該還好）右側經常會被人忽視（意識不到頁面還能橫向滾動一下），也提高了反復溝通確認的成本，所以我更傾向直接在設計稿上控件的旁邊直接標注，雖然會對美觀性產生一定影響。
《交互設計沉思錄》一書中就批評了 UX 經理把時間花在華而不實的文檔管理工作上的現象，指出文檔的時間維度體驗表現力偏弱，而可用原型會是一個更好的替代方案。在規范化交付物提升專業度的同時，也要注意觀察搜集他人實際的反饋效果，并進行調整改進，不要忽視了實用性。
