鴻影：一份設計文件的結構大概可以分成Background項目背景、Schedule排期、History版本歷史記錄、Information Architecture訊息架構分析（內含Site Map、Experience Map、Flow等）、Framework框架設計、Wireframe線框圖以及Mockup視覺稿等。取決於實際項目的情況，部份內容可以省略，也可以加入更多，譬如Storyboard故事板，Prototype可互動原型等。
在過去，我一度沒有什麼規範的設計文件寫作習氣，用紙筆劃完Information Architecture以及Wireframe後，就匆匆進入了Mockup階段，最後的交付物也僅僅是Mockup。前期的時候覺得沒什麼，後來就感覺到了問題，這樣很容易過早地陷入對視覺細節的糾纏，設計到一半忘了最初的設計目的，有時花了不少精力糾結一個模組互動or視覺設計的好壞，後來卻發現整個模組都沒有存在乎義，已經違背了最初的業務目的與設計目的，根本不是使用者想要的東西；或是場景斟酌不全面，設計完一個模組後放到總體裡充溢矛盾，結果需要花更多精力來進行補救，致使進度Delay或者只能上線充溢問題的版本等。
而優良的設計文件寫作習氣，儘管會在一開始佔領對比多的時間以及精力，但卻能保證全程設計思路一直對比清晰，做設計的時候時刻思考使用者是誰、目的是什麼、這樣設計是否能說明達到目的，向團隊、向合作伙伴溝通傳達自己的設計專案時，也有更強的說服力。
Background
這一部份的內容在設計師以及PM、業務方充沛溝通需求之後完成，我的習氣一般是分成這幾個模組：產品描寫，要設計的產品是什麼，依託怎麼樣的平台，在什麼場景下發生；業務/產品現狀，總結需求方現在面臨的主要問題，有哪些體驗不好之處，癥結痛點是什麼；使用者目的，使用者群有哪些類型，他們分別想解決什麼問題；走訪流程，產品有哪些入口，最終把使用者導向哪些處所。這些都需要以及需求方確認清楚，明白整個產品的前因後果，最終提煉出設計目的：需要設計什麼新的功能，需要改善哪些已有的設計，提高產品哪些使用環節的體驗，引誘使用者做出什麼動作，最終達到怎麼樣的業務目的。
Schedule
以及需求方確認各階段交付物的時間節點，制訂完成設計的具體規劃，每一個階段大概做哪些工作，何時內定Review，何時以及項目群組Review等。確保設計以一個合理的節奏開展，可以以較高的質量按時交付。
History
設計稿版本每發生一次對比大的迭代更新，都要記錄在版本歷史記錄裡，相比一個個去翻以前的設計稿，版本歷史記錄可以清晰地展示設計稿的迭代歷程，有哪些需求的變動，有哪些設計時沒思考清楚需要修改之處，Review時大家給出了哪些意見以及建議等。有時版本需要返回，可以更利便地追溯，而項目收場後閱讀這一部份，可以看到自己的設計在哪些方面一開始思考不足泛起了各種問題，是如何被發現、改良以及晉陞的，下一次設計的時候是否可以更早地思考到以及逃避掉。
Information Architecture
依據具體項目性質的不同，這一塊的分析工具也有較大的懸殊，具體的選取以及使用要按如實際場景來，而非機械進行套用。
假設是設計一整套網站系統，Site Map必不可少，通過它將需要設計的內容以全景圖的模式呈現出來，對整個網站的架構可以構建起一個初步的印象，像架構層級過深、頁面內容重複等問題均可以通過Site map發現，進而提出是否可以減少頁面的訊息層級、合併部份頁面等，從總體上改善產品的使用體驗，而非只見樹木不見森林。
Experience Map可以把產品在不同使用場景、流程下的體驗問題直觀地呈現出來，咱們有時會獲得一些用研結果反饋，但大量反饋建議直接列舉的話會很散亂，也不曉得哪些是真正的問題，哪些只是個別使用者的吐槽，通過Experience Map可以整頓出使用者使用產品大概有哪些場景以及環節，各場景以及環節下都遇到過什麼樣的問題，哪些問題泛起的頻率較高等，幫設計師更好地代入到使用者使用產品的實際體驗過程中去，進而思考各場景、環節下均可以進行怎麼樣的設計目的拆解與設計改善、最終說明完成產品的總體目的。
Flow流程圖也是一個常用工具，可以總結出不同場景下使用者使用產品的流程以及步驟是怎麼樣的，可能發生怎麼樣的分支需要在設計中斟酌到，在哪些處所可能發生較大的流失，步驟是否可以合併改善，能否抽像出通用的流程來構建框架設計等。
Framework
Framework以及Wireframe的區別主要在於前者更抽像、通用化，不需要太多的內容細節，而後者更詳細、分場景、已經有了刪格化以及詳細的案牘等，離Mockup甚至只差配色、圖示、暗影細節等。
Framework開始構建起產品的形，抽像出通用的配置原則，頁面上大概有哪些模組，這些模組之間的主次、優先順序關系是怎麼樣的，每一個模組要說明使用者完成怎麼樣的目的。思考清楚了這些問題，接下來的設計才會減少目的偏離與專案返工泛起的幾率，能把握住介面的總體結構、模組關系呈現等，而不是陷入細節，結果讓次要的東西喧賓奪主。
Wireframe
Wireframe在Framework的基礎上具化出了產品的完整骨架，在這一步需要細心斟酌到每個可能的使用場景，內含極多極少、過錯等特殊情況都要內含在內。
我一般習氣在Axure文件裡以樹立不少頁面，每一個頁面按照場景進行命名，再在頁面裡畫Wireframe，具體到每個模組可能泛起的一些特殊場景等，則直接在頁面裡以模組的模式在主介面旁邊呈現，假設是對比簡單的情況，也可用文字直接說明。總之，每個角落都要斟酌得當，不能有遺漏，因為水平經驗還對比稚嫩，一開始遺漏了較多內容，也很感謝合作伙伴以及團隊前輩們的及時指出。
Wireframe儘管不是Mockup，但在視覺效果呈現上卻馬糊不得。一開始我覺得不是視覺稿不必斟酌那麼多，在畫Wireframe時徹底沒斟酌柵格之類，最終的視覺效果感覺也對比粗拙。後來被指出在Wireframe這一環，案牘等內容基本就確定了，假設不斟酌視覺效果，可能在實際的視覺稿產出後，會發生因為文字內容過多溢出，致使整個頁面結構都要被迫調整之類的情況，最終增添了產品的設計成本。作為互動設計師，咱們可能不用斟酌太多配色、建立角色形象之類的視覺細節，但必定要懂基礎的UI設計規範，甚至在視覺請求不高（如不少B端產品）的時候，需要直接扮演視覺設計師的角色，這也是咱們區別於「能畫線框圖的產品經理」的主要價值。
還有案牘，通俗來講就是「說人話」，各種導航標籤、各種引誘提醒問題、各種按鈕說明等的案牘也是互動設計師需要思考的，目前我在這方面做得還對比弱，案牘有囉嗦、使用者不易理解等問題，正在努力看書寫作試圖填補中，就不多談了。
Mockup
Mockup作為表現層的主要產出，在Wireframe的基礎上完成配色表現、圖示繪製等視覺細節的呈現，為產品的骨架籠蓋上最終的皮膚。在Wireframe已經充沛斟酌到各種場景的情況下，Mockup不需要再四平八穩，而是選取癥結場景的介面進行繪製表現便可，注意一些Hover/Active之類的狀況表現，再就是標註（在公司內定神器的說明下似乎已經不用這一步了，怒贊，Sketch棒棒噠，前端都是專業的甚至還懂點設計，不需要太多溝通就能高保真復原效果，感覺比以前幸福好多！）交付前端了。（想到自己以前畫大量精力畫不同場景的Mockup，不少只有一點細節的懸殊，而Wireframe就是一點紙筆草圖，感覺蠢爆了= =）
最後放一張自己的設計文件結構截圖吧，儘管Axure不少人黑，但我覺得在文件結構呈現這塊真的是最佳用的。
------
原文位址：jianshu
作者：鴻影
轉摘請註明優設網譯文出處，謝謝各位小編。兩岸商貿,在家工作,網路創業,創業賺錢思惟,微商平台,賺人民幣
優設官方微信號：youshege 學設計，看這裡！夜夜好福利。
留言列表
