一份設(shè)計(jì)文檔的結(jié)構(gòu)大概可以分成Background項(xiàng)目背景、Schedule排期、History版本歷史記錄、Information Architecture信息架構(gòu)分析（包括Site Map、Experience Map、Flow等）、Framework框架設(shè)計(jì)、Wireframe線框圖和Mockup視覺(jué)稿等。取決于實(shí)際項(xiàng)目的情況，部分內(nèi)容可以省略，也可以加入更多，比如Storyboard故事板，Prototype可交互原型等。

在過(guò)去，我一度沒(méi)有什么規(guī)范的設(shè)計(jì)文檔寫作習(xí)慣，用紙筆畫完Information Architecture和Wireframe后，就匆匆進(jìn)入了Mockup階段，最后的交付物也僅僅是Mockup。前期的時(shí)候覺(jué)得沒(méi)什么，后來(lái)就感覺(jué) 到了問(wèn)題，這樣很容易過(guò)早地陷入對(duì)視覺(jué)細(xì)節(jié)的糾纏，設(shè)計(jì)到一半忘了最初的設(shè)計(jì)目標(biāo)，有時(shí)花了很多精力糾結(jié)一個(gè)模塊交互or視覺(jué)設(shè)計(jì)的好壞，后來(lái)卻發(fā)現(xiàn)整個(gè)模塊都沒(méi)有存在意義，已經(jīng)背離了最初的業(yè)務(wù)目標(biāo)與設(shè)計(jì)目標(biāo)，根本不是用戶想要的東西；或者場(chǎng)景考慮不全面，設(shè)計(jì)完一個(gè)模塊后放到整體里充滿矛盾，結(jié)果需要花更多精力來(lái)進(jìn)行補(bǔ)救，導(dǎo)致進(jìn)度Delay或只能上線充滿問(wèn)題的版本等。

而良好的設(shè)計(jì)文檔寫作習(xí)慣，雖然會(huì)在一開始占據(jù)比較多的時(shí)間和精力，但卻能保證全程設(shè)計(jì)思路一直比較清晰，做設(shè)計(jì)的時(shí)候時(shí)刻思考用戶是誰(shuí)、目標(biāo)是什么、這樣設(shè)計(jì)是否能幫助達(dá)到目標(biāo)，向團(tuán)隊(duì)、向合作伙伴溝通傳達(dá)自己的設(shè)計(jì)方案時(shí)，也有更強(qiáng)的說(shuō)服力。

Background

這一部分的內(nèi)容在設(shè)計(jì)師和 PM、業(yè)務(wù)方充分溝通需求之后完成，我的習(xí)慣一般是分成這幾個(gè)模塊：產(chǎn)品描述，要設(shè)計(jì)的產(chǎn)品是什么，依托怎樣的平臺(tái)，在什么場(chǎng)景下發(fā)生；業(yè)務(wù)/產(chǎn)品現(xiàn)狀， 總結(jié)需求方現(xiàn)在面臨的主要問(wèn)題，有哪些體驗(yàn)不好的地方，關(guān)鍵痛點(diǎn)是什么；用戶目標(biāo)，用戶群有哪些類型，他們分別想解決什么問(wèn)題；訪問(wèn)流程，產(chǎn)品有哪些入 口，最終把用戶導(dǎo)向哪些地方。這些都需要和需求方確認(rèn)清楚，明白整個(gè)產(chǎn)品的來(lái)龍去脈，最終提煉出設(shè)計(jì)目標(biāo)：需要設(shè)計(jì)什么新的功能，需要優(yōu)化哪些已有的設(shè) 計(jì)，提高產(chǎn)品哪些使用環(huán)節(jié)的體驗(yàn)，引導(dǎo)用戶做出什么操作，最終達(dá)到怎樣的業(yè)務(wù)目標(biāo)。

Schedule

和需求方確認(rèn)各階段交付物的時(shí)間節(jié)點(diǎn)，制定完成設(shè)計(jì)的具體計(jì)劃，每個(gè)階段大概做哪些工作，什么時(shí)候內(nèi)部Review，什么時(shí)候和項(xiàng)目組Review等。確保設(shè)計(jì)以一個(gè)合理的節(jié)奏展開，可以以較高的質(zhì)量按時(shí)交付。

History

設(shè)計(jì)稿版本每發(fā)生一次比較大的迭代更新，都要記錄在版本歷史記錄里，相比一個(gè)個(gè)去翻以前的設(shè)計(jì)稿，版本歷史記錄可以清晰地展現(xiàn)設(shè)計(jì)稿的迭代歷程，有 哪些需求的變動(dòng)，有哪些設(shè)計(jì)時(shí)沒(méi)思考清楚需要修改的地方，Review時(shí)大家給出了哪些意見(jiàn)和建議等。有時(shí)版本需要回滾，可以更方便地追溯，而項(xiàng)目結(jié)束后 瀏覽這一部分，可以看到自己的設(shè)計(jì)在哪些方面一開始思考不足出現(xiàn)了各種問(wèn)題，是如何被發(fā)現(xiàn)、改進(jìn)和提升的，下一次設(shè)計(jì)的時(shí)候是否可以更早地思考到和回避 掉。

Information Architecture

根據(jù)具體項(xiàng)目性質(zhì)的不同，這一塊的分析工具也有較大的差異，具體的選擇和使用要按照實(shí)際場(chǎng)景來(lái)，而非機(jī)械進(jìn)行套用。

如果是設(shè)計(jì)一整套網(wǎng)站系統(tǒng)，Site Map必不可少，通過(guò)它將需要設(shè)計(jì)的內(nèi)容以全景圖的方式呈現(xiàn)出來(lái)，對(duì)整個(gè)網(wǎng)站的架構(gòu)可以構(gòu)建起一個(gè)初步的印象，像架構(gòu)層級(jí)過(guò)深、頁(yè)面內(nèi)容重復(fù)等問(wèn)題都可以 通過(guò)Site map發(fā)現(xiàn)，進(jìn)而提出是否可以減少頁(yè)面的信息層級(jí)、合并部分頁(yè)面等，從整體上優(yōu)化產(chǎn)品的使用體驗(yàn)，而非只見(jiàn)樹木不見(jiàn)森林。

Experience Map可以把產(chǎn)品在不同使用場(chǎng)景、流程下的體驗(yàn)問(wèn)題直觀地呈現(xiàn)出來(lái)，我們有時(shí)會(huì)得到一些用研結(jié)果反饋，但大量反饋建議直接列舉的話會(huì)很散亂，也不知道哪些 是真正的問(wèn)題，哪些只是個(gè)別用戶的吐槽，通過(guò)Experience Map可以整理出用戶使用產(chǎn)品大概有哪些場(chǎng)景和環(huán)節(jié)，各場(chǎng)景和環(huán)節(jié)下都遇到過(guò)什么樣的問(wèn)題，哪些問(wèn)題出現(xiàn)的頻率較高等，幫設(shè)計(jì)師更好地代入到用戶使用產(chǎn)品的實(shí)際體驗(yàn)過(guò)程中去，進(jìn)而思考各場(chǎng)景、環(huán)節(jié)下都可以進(jìn)行怎樣的設(shè)計(jì)目標(biāo)拆解與設(shè)計(jì)優(yōu)化、最終幫助完成產(chǎn)品的整體目標(biāo)。

Flow流程圖也是一個(gè)常用工具，可以總結(jié)出不同場(chǎng)景下用戶使用產(chǎn)品的流程和步驟是怎樣的，可能產(chǎn)生怎樣的分支需要在設(shè)計(jì)中考慮到，在哪些地方可能產(chǎn)生較大的流失，步驟是否可以合并優(yōu)化，能否抽象出通用的流程來(lái)構(gòu)建框架設(shè)計(jì)等。

Framework

Framework和Wireframe的區(qū)別主要在于前者更抽象、通用化，不需要太多的內(nèi)容細(xì)節(jié)，而后者更詳細(xì)、分場(chǎng)景、已經(jīng)有了刪格化和詳細(xì)的文案等，離Mockup甚至只差配色、圖標(biāo)、陰影細(xì)節(jié)等。

Framework開始構(gòu)建起產(chǎn)品的形，抽象出通用的布局原則，頁(yè)面上大概有哪些模塊，這些模塊之間的主次、優(yōu)先級(jí)關(guān)系是怎樣的，每個(gè)模塊要幫助用 戶完成怎樣的目標(biāo)。思考清楚了這些問(wèn)題，接下來(lái)的設(shè)計(jì)才會(huì)減少目標(biāo)偏離與方案返工出現(xiàn)的概率，能把握住界面的整體結(jié)構(gòu)、模塊關(guān)系呈現(xiàn)等，而不是陷入細(xì)節(jié)， 結(jié)果讓次要的東西喧賓奪主。

Wireframe

Wireframe在Framework的基礎(chǔ)上具化出了產(chǎn)品的完整骨架，在這一步需要仔細(xì)考慮到每一個(gè)可能的使用場(chǎng)景，包括極多極少、錯(cuò)誤等特殊情況都要包括在內(nèi)。

我一般習(xí)慣在Axure文檔里以建立很多頁(yè)面，每個(gè)頁(yè)面按照?qǐng)鼍斑M(jìn)行命名，再在頁(yè)面里畫Wireframe，具體到每一個(gè)模塊可能出現(xiàn)的一些特殊場(chǎng) 景等，則直接在頁(yè)面里以模塊的方式在主界面旁邊呈現(xiàn)，如果是比較簡(jiǎn)單的情況，也可用文字直接說(shuō)明。總之，每一個(gè)角落都要考慮得當(dāng)，不能有遺漏，因?yàn)樗浇?jīng) 驗(yàn)還比較稚嫩，一開始遺漏了較多內(nèi)容，也非常感謝合作伙伴和團(tuán)隊(duì)前輩們的及時(shí)指出。

Wireframe雖然不是Mockup，但在視覺(jué)效果呈現(xiàn)上卻馬虎不得。一開始我覺(jué)得不是視覺(jué)稿沒(méi)必要考慮那么多，在畫Wireframe時(shí)完全 沒(méi)考慮柵格之類，最終的視覺(jué)效果感覺(jué)也比較粗糙。后來(lái)被指出在Wireframe這一環(huán)，文案等內(nèi)容基本就確定了，如果不考慮視覺(jué)效果，可能在實(shí)際的視覺(jué) 稿產(chǎn)出后，會(huì)發(fā)生因?yàn)槲淖謨?nèi)容過(guò)多溢出，導(dǎo)致整個(gè)頁(yè)面結(jié)構(gòu)都要被迫調(diào)整之類的情況，最終增加了產(chǎn)品的設(shè)計(jì)成本。作為交互設(shè)計(jì)師，我們可能不用考慮太多配色、創(chuàng)建角色形象之類的視覺(jué)細(xì)節(jié)，但一定要懂基礎(chǔ)的UI設(shè)計(jì)規(guī)范，甚至在視覺(jué)要求不高（如很多B端產(chǎn)品）的時(shí)候，需要直接扮演視覺(jué)設(shè)計(jì)師的角色，這也是我們區(qū)別于“能畫線框圖的產(chǎn)品經(jīng)理”的重要價(jià)值。

還有文案，通俗來(lái)說(shuō)就是“說(shuō)人話”，各種導(dǎo)航標(biāo)簽、各種引導(dǎo)提示問(wèn)題、各種按鈕說(shuō)明等的文案也是交互設(shè)計(jì)師需要思考的，目前我在這方面做得還比較弱，文案有啰嗦、用戶不容易理解等問(wèn)題，正在努力看書寫作試圖彌補(bǔ)中，就不多談了。

Mockup

Mockup作為表現(xiàn)層的主要產(chǎn)出，在Wireframe的基礎(chǔ)上完成配色表現(xiàn)、圖標(biāo)繪制等視覺(jué)細(xì)節(jié)的呈現(xiàn)，為產(chǎn)品的骨架覆蓋上最終的皮膚。在 Wireframe已經(jīng)充分考慮到各種場(chǎng)景的情況下，Mockup不需要再面面俱到，而是選擇關(guān)鍵場(chǎng)景的界面進(jìn)行繪制表現(xiàn)即可，注意一些 Hover/Active之類的狀態(tài)表現(xiàn)，再就是標(biāo)注（在公司內(nèi)部神器的幫助下似乎已經(jīng)不用這一步了，怒贊，Sketch棒棒噠，前端都是專業(yè)的甚至還懂 點(diǎn)設(shè)計(jì)，不需要太多溝通就能高保真還原效果，感覺(jué)比以前幸福好多！）交付前端了。（想到自己以前畫大量精力畫不同場(chǎng)景的Mockup，很多只有一點(diǎn)細(xì)節(jié)的差異，而Wireframe就是一點(diǎn)紙筆草圖，感覺(jué)蠢爆了= =）

最后放一張自己的設(shè)計(jì)文檔結(jié)構(gòu)截圖吧，雖然Axure很多人黑，但我覺(jué)得在文檔結(jié)構(gòu)呈現(xiàn)這塊真的是最好用的。