整合營銷服務(wù)商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
互文檔該怎么寫呢？這個問題不只是新手在問，在工作中要負責交互問題的產(chǎn)品經(jīng)理、設(shè)計師，都在糾結(jié)這個問題。本篇文章就從基本認識、工具選擇和制作過程這三部分內(nèi)容來為大家講解交互文檔要怎么寫，快來看看吧。
今天要分享的，是后臺和社群里幾乎每天都有人問的交互文檔該怎么寫的問題。不只是想要往交互設(shè)計師方向發(fā)展的新手，還有工作中要負責交互問題的產(chǎn)品經(jīng)理、設(shè)計師，都對它存在大量的疑問。
所以我們在今天這篇分享里完成一次深入的掃盲。
交互文檔，是一份用來解釋項目交互方式、內(nèi)容、規(guī)則的說明文檔，也叫 DRD ( Design Requirement Document )。
在過去的分享中，我們有解釋過，B端項目會包含大量的交互內(nèi)容，需要前期繪制交互原型來展示和確認交互方案。
如果是比較簡單的小型項目，或成熟產(chǎn)品的小迭代，那么這樣的連線圖確實就足以表達交互的意圖和方案了，寫太多注釋文字反而會畫蛇添足提高觀看者的認知成本。
但是，如果項目和展示的流程內(nèi)容，邏輯非常復(fù)雜，包含非常多的選項和狀態(tài)，那么單靠原型和連線是絕對不夠的，添加更多的圖文說明就變得非常有必要了。
同時在團隊協(xié)作場景中，就需要將這些內(nèi)容制作成一份規(guī)范的 “文檔”，用來進行統(tǒng)一的展示、備份、歸檔。
所以做交互光靠畫交互原型是不夠的，“文檔” 就成為必要的輸出成果。
在產(chǎn)品側(cè)（非開發(fā)），文檔就有好幾類：
BRD 和 MRD 是一個產(chǎn)品經(jīng)理行業(yè)內(nèi)部也在反復(fù)科普討論的東西，和我們沒多大關(guān)系可以暫時忽略。設(shè)計規(guī)范文檔 DGD 大家應(yīng)該也有概念，比較容易辨識，也不需要在這里強調(diào)。
而產(chǎn)品需求文檔 PRD，是和交互文檔最撞臉的文檔類型。它們的文檔規(guī)格、樣式幾乎一致，還包含大量界限模糊、相互交叉的內(nèi)容范疇，會對新手的理解造成很大的不便。
要理解產(chǎn)品文檔和交互文檔的核心差異，就得從他們各自的工作職能說起，產(chǎn)品經(jīng)理的主要產(chǎn)出是解釋產(chǎn)品要做的功能和邏輯，所有的原型和連線的目標都是為了解釋功能本身。
部分產(chǎn)品經(jīng)理會 “順帶” 在這個基礎(chǔ)上增加交互的元素，以及相關(guān)的說明。這恰恰是問題的關(guān)鍵所在，因為產(chǎn)品經(jīng)理制作產(chǎn)品原型的過程是可以覆蓋一部分交互信息的，所以很多設(shè)計師也天真的認為交互內(nèi)容是應(yīng)該由產(chǎn)品來出的。
這當中一定要關(guān)注里面的 “順帶”，因為一份有效的 PRD 主旨一定不是以交互為核心的，在面對需要大量圖例、連線、方案、解釋的交互問題下面，產(chǎn)品經(jīng)理往往選擇直接跳過，只把功能描述清楚，剩下的就交給交互設(shè)計師還是 UI 設(shè)計師來完成具體的交互方案。
所以，交互文檔就是在產(chǎn)品文檔的基礎(chǔ)上，進行交互內(nèi)容的補充，專注于解釋項目的交互內(nèi)容，讓設(shè)計師和前端開發(fā)可以更直觀得理解后續(xù)的工作內(nèi)容。
來自 UEDART 的付費文檔，案例地址：http://vip.uedart.com/interactive.html
交互文檔和產(chǎn)品文檔是相互獨立和補充的，當產(chǎn)品文檔無法完成對產(chǎn)品交互的有效解釋時，我們就應(yīng)該選擇輸出獨立的交互文檔，來提升項目協(xié)作的效率。
主流的交互文檔輸出有三種方式：
Axure 和墨刀是用來制作產(chǎn)品原型的軟件工具，也是目前在產(chǎn)品經(jīng)理、交互設(shè)計行業(yè)中應(yīng)用最廣泛的原型工具。
它的主要優(yōu)勢，在于可以比較方便的制作可交互的組件、連線、導(dǎo)出。
當然，光制作原型圖并不能叫交互文檔，它們還提供了比較全面的內(nèi)容標注、文本記錄、圖形繪制的功能。
這就可以讓我們完成原型繪制以后，結(jié)合頁面結(jié)構(gòu)的管理，添加交互文檔所需的其它信息，并最終輸出文件。
而在一些比較傳統(tǒng)的行業(yè)或外包領(lǐng)域，使用的記錄文檔往往要使用 Word 或 PPT（方便開會演示或要打印）。這就要在原型完成以后，導(dǎo)出原型圖例，并使用這些文檔軟件進行文字的記錄和連線。
受限于 Word、PPT 的布局限制（強行分頁），使用它們做交互文檔是非常難受的，并且這些文檔需要保存到本地，存在各種文檔版本管理的問題。
所以還有另一部分也希望使用普通文檔格式記錄，并滿足云端同步、備份、版本管理的團隊，就會使用 Wiki 類的工具來制作交互文檔。如語雀、飛書、Confluence、Notion 等工具。
如果只是一些比較小的項目迭代、一次性使用的交互文檔，使用前兩種方法都可以勝任。而真正大型、系統(tǒng)性的交互文檔，往往都使用團隊內(nèi)部的 Wiki 進行創(chuàng)建和管理。和設(shè)計稿不同，這些使用了內(nèi)部賬號或需要內(nèi)網(wǎng)訪問的文檔資料，是不會沒事發(fā)到網(wǎng)上來分享的，這也是在網(wǎng)上找不到完整交互文檔的主要原因。
和你們網(wǎng)上可以找到的大多數(shù)交互設(shè)計干貨不同，我即不推薦你們使用 Axure/墨刀 來畫原型，也不推薦用它們或普通文檔、Wiki 的形式來輸出交互文檔。因為：
—— 太低效了！
產(chǎn)品經(jīng)理和交互設(shè)計師的主要產(chǎn)出物就是文檔，自然可以耗費比較多的精力和時間去制作原型和編寫內(nèi)容。而 UI 設(shè)計師的主要工作肯定是最終的視覺界面和交付，所以用最復(fù)雜的方法去制作交互文檔，顯然是不合理的。
同時還要提一句，Axure/墨刀 等軟件用來制作一般的線框圖原型，效率實在是太低了。且絕大多數(shù)情況下的頁面跳轉(zhuǎn)、交互都是可以忽略不做的。而且隨頁面增加，它的左側(cè)導(dǎo)航層級、數(shù)量會非常龐大，導(dǎo)致查找和瀏覽的效率進一步降低。
我始終都建議直接使用你們正在用的云端 UI 設(shè)計軟件直接繪制產(chǎn)品、交互原型并輸出文檔，如即時設(shè)計或 Figma。原因包含：
比如下面這樣的原型案例，就可以通過一個簡單的鏈接快速分享出去，或者添加團隊成員自由查看。
在我過去長期的實踐體會中，這種方式是優(yōu)勢最明顯、效率最高、最易懂，也符合 UI 設(shè)計師工作需要的。如果項目中有其它因素要求，你們也可以選擇前面的方式輸出。
任何文檔的目標都是為了書面記錄和讓看的人更容易理解我們要表達的信息，不要被固定的方法局限住，要努力去探索適合團隊當前場景的方式。
前面把基本的信息聊完了，這里就來具體講講交互文檔應(yīng)該如何進行輸出。
當然，輸出交互文檔前需要先理解交互是什么，交互設(shè)計的具體設(shè)計內(nèi)容和步驟。交互文檔是對你已經(jīng)設(shè)計出來的方案的書面記錄，你不能在對交互一無所知的情況下強行編寫文檔。
交互文檔制作首先要確認文檔的記錄內(nèi)容和文檔結(jié)構(gòu)。
記錄內(nèi)容指的是你在該文檔準備放哪些交互內(nèi)容進去，并不是每次項目設(shè)計都要把項目所有頁面和流程交互都重做一遍。
比如一次中等規(guī)模的迭代，新增幾個通用的列表頁面，調(diào)整了一些細節(jié)字段，增加了一個功能流程。那么文檔重點記錄內(nèi)容肯定就是流程而不是所有頁面。畢竟通用的列表頁和細節(jié)更改，在產(chǎn)品需求評審階段就可以完整的解釋，而功能流程則不行。
如果是全新的項目，包含數(shù)十上百個頁面。把所有流程、頁面的交互內(nèi)容全部表現(xiàn)出來的工作量是頂不住的，在繪制原型的過程中，你就會發(fā)現(xiàn)有大量的重復(fù)頁面、流程和交互。所以制作文檔就要有目的性的對重復(fù)的內(nèi)容進行合并，以及只保留重要的頁面和流程。
具體該放什么要考慮項目的實際情況，需要設(shè)計師自己評估。除此以外，標準的交互文檔里面會包含背景介紹、編輯日志、文字圖例、業(yè)務(wù)流程、名詞解釋、頁面結(jié)構(gòu)等等。
這些 “文縐縐” 的細節(jié)，并不是必備的，你可以根據(jù)當前場景自己決定需要加哪些。比如項目、業(yè)務(wù)背景前面的產(chǎn)品需求已經(jīng)講清楚了，業(yè)務(wù)流程、名詞解釋團隊成員也都了如指掌的時候，那么這些頁面模塊就完全沒有放的必要。
并且，基于前面對放置內(nèi)容的考慮，結(jié)構(gòu)的順序并不一定要類似下方案例，完全按照產(chǎn)品的導(dǎo)航目錄來走。
所以，根據(jù)一個中等規(guī)模的迭代項目，我會制定一個這樣的一級文檔結(jié)構(gòu)：
每個1級文檔結(jié)構(gòu)對應(yīng) UI 軟件中的 Page 目錄，力求所需的 Page 數(shù)量越少越好，而不是像 Axure 的做法一樣密密麻麻的。
結(jié)構(gòu)可以根據(jù)復(fù)雜程度做進一步的細分，它像寫文章的大綱一樣，幫助我們提前規(guī)劃好后續(xù)完成文檔所需的內(nèi)容和工作量。
有了結(jié)構(gòu)，就要在對應(yīng)的 Page 中填充內(nèi)容了。其中一般的文字介紹、流程圖、思維導(dǎo)圖，只要正常輸入或?qū)?dǎo)出的圖例黏貼進來就可以。
而針對具體的交互內(nèi)容，流程解釋上，則重點處理連線和標注說明。比如下面是我自己在課程演示中的一個簡單的交互流程演示案例。
在 UI 軟件中，制作連線其實是很簡單的事情，只要畫出一個直線，再設(shè)置箭頭和尾部圖形、描邊色彩和粗細即可。
然后，將該線段的圖層放置在畫布之外，起點放置在觸發(fā)交互的區(qū)域之中，終點尖頭則緊貼目標畫布的邊緣（不用特意延伸進畫布內(nèi)）。如果使用水平、垂直的方式連接兩個畫布，那就可以雙擊進去添加錨點制作 90 度的折角。
連線的應(yīng)用是非常簡單的操作，不要舍近求遠通過插件或是其它的一些功能來實現(xiàn)。而除此之外，我在文檔中添加的解釋性文本主要有兩種，交互事件和交互規(guī)則。
交互事件代表了連線的兩個頁面是如何被觸發(fā)跳轉(zhuǎn)的，所以我會在線段中帖一個文字卡片，解釋觸發(fā)的條件和交互操作是什么。
然后，就是頁面或流程中的交互細則，包含兩個部分，數(shù)字標簽和對應(yīng)文字注釋。它們都是用 Auto layout 可以快速制作出來的組件，每次要做備注的時候，只要復(fù)制標簽到頁面上，設(shè)置對應(yīng)的數(shù)值，再將右側(cè)的文字卡片復(fù)制到頁面旁邊，再加上對應(yīng)的數(shù)字、內(nèi)容信息即可。
在設(shè)計軟件中，畫布的自由度極高，你想要怎么備注和添加內(nèi)容都沒關(guān)系，只要在內(nèi)容翔實的基礎(chǔ)上保證 —— 團隊成員能看懂，就是一份優(yōu)秀的交互文檔。多在繪制過程中和同事溝通，優(yōu)化展示的做法，可以避免很多會出現(xiàn)的問題，進一步加速我們的制作效率。
將文檔全部做完以后，最終就是關(guān)于交付和協(xié)作的問題了。
既然我們使用線上的 UI 軟件來完成交互文檔的制作，那么文件設(shè)置公開訪問權(quán)限，再分享鏈接自然是最簡單的辦法。
但每次項目分享個網(wǎng)頁鏈接，或者并行有好幾個項目，需要其它成員自己去收藏網(wǎng)址，也是挺麻煩的。所以盡量充分應(yīng)用軟件中的團隊協(xié)作功能，通過創(chuàng)建一個團隊，添加成員，讓他們自行查看當前文件目錄中的交互文檔。
查看過程中，團隊其它成員可以通過評論的功能對交互內(nèi)容進行糾錯、提問、建議，方便我們進行優(yōu)化改進。
通過這種簡單高效的文檔協(xié)作模式，我們可以非常快得完成整體交互內(nèi)容的定稿，并開始后續(xù)的工作。
再回到前面的話題，我們是 UI 設(shè)計師，不是全職交互設(shè)計。原型文檔輸出完了，下一步可是要做視覺界面的，所以交互文檔就可以不用管了嘛？
交互文檔的最佳狀態(tài)是 —— 應(yīng)用最終界面圖例解釋交互內(nèi)容。
也就是當我們把所有頁面內(nèi)容設(shè)計完成后，強烈建議將界面的展示和交互文檔進行整合。除了前端和產(chǎn)品可以看到最終的交互落地效果外（有時候最終設(shè)計和前面的交互不一致），還可以直接通過這個文檔查看界面數(shù)值標注，而不用往返于交互和設(shè)計文檔來回切換，這才能讓文檔作用最大化。
以上就是關(guān)于交互文檔的相關(guān)解釋，下一篇，我們會聚焦在和表單有關(guān)的交互干貨分享。
我們下篇再見。
作者：酸梅干超人；公眾號：超人的電話亭（ID：Superman_Call）
本文由 @超人的電話亭 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。
題圖來自Unsplash ，基于 CC0 協(xié)議。
該文觀點僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。
輯導(dǎo)語：作為交互設(shè)計師，離不開交互設(shè)計文檔，剛?cè)胄械男』锇榭赡軙诰W(wǎng)上找模板套用或者是自己摸索，這樣效率低下且容易走彎路。那么，如何完成一份完整的交互設(shè)計文檔呢？作者總結(jié)了以下幾點，教你手把手撰寫交互設(shè)計文檔。
作為交互設(shè)計師，我們平時工作最大的產(chǎn)出就是交互設(shè)計文檔，很多剛轉(zhuǎn)行的同學會在網(wǎng)上尋找模板直接套用或者自己慢慢摸索，而這篇文章會手把手教你怎樣完成一份完整的交互設(shè)計文檔。
為什么要寫交互設(shè)計文檔？交互設(shè)計文檔有什么用？
第一，交互設(shè)計師的交互設(shè)計文檔就好像UI設(shè)計師的PSD文件一樣用于保存記錄自己的設(shè)計思路，但交互設(shè)計師負責的任務(wù)不僅僅停留在頁面當中，還包括產(chǎn)品的需求分析、用戶畫像、競品分析、產(chǎn)品數(shù)據(jù)分析、用戶交互邏輯等等。
我們都可以寫在交互設(shè)計文檔中做記錄，為我們的交互設(shè)計提供依據(jù)（其實就是避免開發(fā)懟你、問你設(shè)計依據(jù)是啥，你就馬上把分析擺他臉上，避免尷尬）。
第二點是交互設(shè)計師作為產(chǎn)品的上游，一般開發(fā)流程是產(chǎn)品經(jīng)理負責收集需求給予交互設(shè)計師進行交互設(shè)計，撰寫交互設(shè)計文檔。
然后文檔評審?fù)ㄟ^后，UI同學負責UI設(shè)計，接著提供前端同學進行界面開發(fā)，后端同學則根據(jù)交互稿搭建框架和業(yè)務(wù)邏輯，開發(fā)完成后進行測試，反饋測試結(jié)果，如此循環(huán)。
因此交互設(shè)計師一般處于產(chǎn)品線的上游階段，撰寫一份標準和規(guī)范的交互設(shè)計文檔是非常重要的。
因為我們需要利用交互設(shè)計文檔去表達我們的設(shè)計思路，通過交互文檔我們可以讓UI同學知道頁面需要給用戶表達什么情緒，達到怎樣的目的，告訴前端同學頁面跳轉(zhuǎn)邏輯以及交互模塊怎么寫，幫助后端同學清晰搭建后臺框架與數(shù)據(jù)庫以及產(chǎn)品業(yè)務(wù)邏輯是怎么樣的，最后測試童鞋還會拿著你的交互稿進行單元測試，編寫測試用例。
所以只有我們先把文檔寫好了，才能避免后面產(chǎn)品開發(fā)出現(xiàn)問題。
第三點也是最重要的一點就是未來我們用于跳槽加薪面試作品。
內(nèi)行看門道，外行看熱鬧，如果你面試交互設(shè)計師的時候還是帶著一條長長的JPG或者是網(wǎng)上千篇一律排版的PDF作品集，在面試官眼中顯得不入行（或許你會遇到性格好的面試官，畢竟千人千面，面試特別看人）。
因為專業(yè)的交互設(shè)計師在平時工作中為了避免干擾UI同學設(shè)計，只會使用黑白灰做交互稿，也很少做成一條長長的PNG或JPG，我們可以適當包裝作品集，但是如果過度了會讓人覺得不落地，或許只停留在剛?cè)胄须A段。
所以在技術(shù)面試，我們可以拿著我們的交互設(shè)計文檔跟面試官敘述產(chǎn)品從需求層面怎樣思考完成交互設(shè)計的，解決了用戶什么痛點，最后取得了什么樣的成果，得到了怎樣的數(shù)據(jù)，我相信成功幾率會大很多（PS：用交互設(shè)計文檔進行面試前請注意把公司機密信息做脫敏處理，避免發(fā)生糾紛）。
交互文檔包含什么內(nèi)容？以及怎樣撰寫交互文檔？
一般來講，一個基礎(chǔ)、規(guī)范的交互設(shè)計文檔應(yīng)該包含文檔封面、更新文檔、設(shè)計說明文檔、業(yè)務(wù)流程圖、交互原型、垃圾桶等模塊，當然了，這些模塊也不是永恒不變的，有些是必須要，有些是選擇性添加的，至于這些模塊有什么功能和怎樣進行撰寫，這篇文章會逐一分享給大家~
（說明：作者比較習慣使用Axure軟件撰寫交互設(shè)計文檔，你們可以根據(jù)自身愛好或者公司規(guī)定進行選擇（例如sketch、figma、PS等等都是可以的）。
這里要引用一句話：軟件僅僅是工具，并不能限制我們的思維，好的工具能讓我們走得更快但不能使我們走得更遠——沃·茲基碩德。
文檔封面就相當于一本書的封面一樣，用于記錄產(chǎn)品名稱、版本號、日期以及文檔負責人（這樣開發(fā)童鞋就能精準找到你進行撕X），只要能展示以上信息，其他信息（例如產(chǎn)品經(jīng)理是誰等）可以自行添加。
以前我都習慣把更新日志放到產(chǎn)品文檔后面，但是隨著工作時間變久，我發(fā)現(xiàn)開發(fā)童鞋在SVN上打開設(shè)計文檔后第一時間就是查看更新日志，所以后來把這一頁提了上來（是的，設(shè)計文檔也是需要跟產(chǎn)品一樣不斷優(yōu)化迭代的）。
更新日志主要用于記錄產(chǎn)品迭代修改的內(nèi)容，讓開發(fā)同學快速了解這次迭代修改了什么內(nèi)容，他需要做哪些工作。
我的更新日志特別簡單，就只有日期、變更內(nèi)容、所在頁面以及備注四個字段，這里唯一注意的是，日期必須是最新修改的內(nèi)容放在上面，以前的日期在下面，很多同學每次迭代的時候會在下面列進行內(nèi)容添加，這樣開發(fā)同學每次都必須滾到最下面查看信息，大哥，你是交互設(shè)計師，專業(yè)一點好嗎。
產(chǎn)品項目背景是一個項目的核心關(guān)鍵，告訴所有的團隊成員我們要做一個什么樣的產(chǎn)品，需要創(chuàng)造什么樣的價值，就好比我們寫作文時的中心句，時刻提醒著我們要不忘初心，為團隊成員開發(fā)項目指明方向。
前段時間有個同學來問我，他們本來是剛開始是做校園教育系統(tǒng)的，但是隨著產(chǎn)品慢慢迭代，功能逐漸強大了，最近老板希望在系統(tǒng)中加上財務(wù)功能，本來用戶學習成本就高，如果再加上去會不會適得其反？
雖然我不知道那位同學的老板產(chǎn)品戰(zhàn)略是啥，背后是怎樣思考的，但是在我看來這樣的行為就不能是不忘初心，這頂多能算不忘出薪吧（拒絕諧音梗從我做起）。
好了，至于里面產(chǎn)品背景、產(chǎn)品目標以及定位的內(nèi)容應(yīng)該如何撰寫？對，我抄的。一般情況下，這些內(nèi)容我們都能夠在項目立項文檔或者在招投標書上就能找到，我們不用親自寫（但可以加以設(shè)計），再不行也能找到產(chǎn)品經(jīng)理去了解。
或者你會說，小公司既沒有立項、也沒有招投標書，產(chǎn)品經(jīng)理也是你，那該怎么辦？那么你就得發(fā)揮出自己當年高考的作文水平，積極了解清楚產(chǎn)品背景定位，努力完成這一部分，因為信息的傳遞是有消耗性的，只有我們作為產(chǎn)品的上游做好了，才能為團隊成員后面的努力提供方向。
產(chǎn)品需求列表用于記錄產(chǎn)品需要做哪些【功能點】，這些功能點我們一般能在產(chǎn)品經(jīng)理或者項目經(jīng)理上獲得，我們收集需求后需要對其按照重要程度P0、P1、P2等級進行分類。
我分類的原則是KANO法則（不知道的同學可以百度），P0等級是非做不可的需求，例如像微信的聊天，淘寶的支付功能等，P1是錦上添花的需求，時間緊迫的話可以下次再做的，例如微信的語音、視頻聊天等。
排到最后Pn就是一些不必要可做可不做，就算做了也沒太大影響的功能，就可以與領(lǐng)導(dǎo)層商討是否確認要做（例如炸屎，你們現(xiàn)在還有人炸屎嗎？什么？炸屎你都不知道？那當我沒說）。
所謂知己知彼百戰(zhàn)不殆，通過用戶畫像我們可以快速了解產(chǎn)品目標用戶群體特征，分析目標用戶群體的期望、需求、動機等，再根據(jù)用戶場景去進行設(shè)計。
有了用戶畫像的支撐，能避免我們在設(shè)計過程中出現(xiàn)一些不必要的因素，例如我們目標用戶是中老年人的話，那么按鈕、字體就應(yīng)該適當?shù)姆糯蟆⑴虐婧唵蚊髁耍槍η嗌倌昃涂梢云珎€性化風格設(shè)計。
當然，如果是小公司的話可能沒有那么多的資源去做用戶的調(diào)研，在這里分享一下我當年在創(chuàng)業(yè)公司經(jīng)常使用的一種快速獲取用戶畫像的方法，既快速又特別專業(yè)。
這里需要借助一個網(wǎng)站：艾瑞數(shù)據(jù)（https://index.iresearch.com.cn），打開后選擇自己產(chǎn)品的類型（例如學習教育類），網(wǎng)站會把該類型的產(chǎn)品按照用戶數(shù)量從高到低展示給你，然后我們選擇一個差不多的競品點擊去查看他們的用戶特征，最后Ctrl C+Ctrl V到我們的文檔中，完成。
競品分析相信大家都特別熟悉，我之前的文章也教過大家怎么進行詳細的競品分析，這里就不細講了，雖然在交互文檔中競品分析可做可不做，但是在產(chǎn)品初期階段我們。
如果認真做競品分析的話能夠快速了解產(chǎn)品業(yè)務(wù)、熟悉用戶的使用習慣，同時當我們在做交互原型的時候能提供快速借（cao）鑒（xi），因此有條件的同學還是建議盡量做一下。
數(shù)據(jù)分析時交互設(shè)計師必不可少的一項技能，也是驗證設(shè)計成果的重要因素。如果缺少了數(shù)據(jù)分析而單憑個人主觀因素的話，我們難以說明設(shè)計效果的好壞，畢竟現(xiàn)實中會出現(xiàn)各種意想不到的情況。
所謂“無對比，不分析”，一般數(shù)據(jù)分析都是通過數(shù)值進行對比，去查看數(shù)據(jù)相對是上升、下降、還是持平，是否跟當初設(shè)計預(yù)期的一樣，對于初期的產(chǎn)品會更關(guān)注產(chǎn)品的一些DAU(日活數(shù))、GMV（成交總額）、以及支付人數(shù)等，因為這些數(shù)據(jù)的增減是直接影響到整個產(chǎn)品的存活，如果產(chǎn)品的DAU不斷下降的話，那你就要馬上查找原因，及時調(diào)整，避免惡性循環(huán)。
一般情況下，像日活數(shù)那些簡單的數(shù)據(jù)可以直接問后臺同學就能獲得，而用戶某些環(huán)節(jié)的存活率、轉(zhuǎn)化率等就需要利用【數(shù)據(jù)埋點】，市場上也有很多第三方做數(shù)據(jù)埋點的，例如神策數(shù)據(jù)、Growing IO等，這里就不展開說了，但是面試的時候你能說出這些就會顯得很專業(yè)。
信息架構(gòu)屬于用戶體驗的結(jié)構(gòu)層，就像產(chǎn)品的骨架一樣，而信息架構(gòu)設(shè)計就是對產(chǎn)品信息進行構(gòu)架、歸類的設(shè)計，信息架構(gòu)能夠防止我們對產(chǎn)品功能點遺漏，同時也可以通過產(chǎn)品大體的信息架構(gòu)觀察出產(chǎn)品設(shè)計是否合理。
一般來說（干貨來了），產(chǎn)品架構(gòu)分支可以分為度和層，而好產(chǎn)品的信息架構(gòu)在廣度和層度都是恰到好處，下面我舉兩個反例大家就懂了。
產(chǎn)品架構(gòu)的廣度太廣（不懂的看下圖）：信息架構(gòu)的廣度太廣意味著頁面的承載信息量特別的多，沒有側(cè)重點，這樣用戶點進頁面后會思考很久而不知所措，最經(jīng)典的就是某某寶和某同城，新用戶進入到首頁真的模棱兩可。
繪制業(yè)務(wù)流程圖的目的就是：梳理并分析優(yōu)化業(yè)務(wù)流程。我知道很多同學做UI設(shè)計師的時候可以完全不管業(yè)務(wù)，直接做設(shè)計，但是作為交互設(shè)計師了解產(chǎn)品業(yè)務(wù)是非常重要的，因為不了解業(yè)務(wù)你就無法完成交互設(shè)計，優(yōu)化業(yè)務(wù)場景。
舉個例子：在教育考試系統(tǒng)中一般流程是：教育局出通知→學生報名考試→老師審核→報名通過→老師編排學生考試名單→學生開始考試對號入座→教育局公布成績→學生查詢成績→考試結(jié)束，看這一些列的流程。
因為關(guān)聯(lián)特別多，如果對業(yè)務(wù)不熟悉的話設(shè)計起來會非常的不便，如果前期因為業(yè)務(wù)流程不熟悉而設(shè)計出錯誤的交互稿的話，后面就會特別麻煩。
那么如何去繪制完整的業(yè)務(wù)流程：
如果你的產(chǎn)品經(jīng)理比較專業(yè)的話，可能會直接給你一個現(xiàn)成的業(yè)務(wù)流程圖，那樣就能省事很多。
要是沒有產(chǎn)品經(jīng)理的話，最直接的就是問用戶，這里介紹我最常用的方法就是“一聽二問三確認”。
一聽：先聽客戶代表或者業(yè)務(wù)方的介紹。聽得過程中，不打斷對方，以最簡單的方式勾出主體脈絡(luò)，即基本要素中的角色、活動、協(xié)作關(guān)系梳理出即可。
二問：完成上一步后，就可以進行提問了。主要是沿著流程進行發(fā)問，重點放在分支、產(chǎn)物關(guān)系上。看看是否存在分支的情況，各協(xié)作之間是否有交付物。一邊問，一邊修正。
三確認：最后一步就是自己講一遍流程，和客戶代表或者業(yè)務(wù)專家進行最后的確認。
幾乎可以說，上面所有的東西都是為了完成交互原型做鋪墊的，我相信對大家來講交互原型都非常熟悉，但是給大家分享幾個經(jīng)常犯錯的點。
【1】頁面盡量只采用黑白灰配色，避免干擾UI同學設(shè)計。這是大家經(jīng)常犯錯的一個點，畢竟很多同學以前是UI出身，做交互稿時也順便配配色，這樣會非常影響UI同學設(shè)計的（不在其位不謀其政，你做UI的時候也不希望有人在旁邊指指點點吧）。
所以我們做交互稿時只采用黑白灰就夠了，灰度大小就代表信息的重要程度，簡潔規(guī)范即可。
【2】頁面的跳轉(zhuǎn)用連線表示其實就很方便了，真正厲害的人不會到處炫技。有些同學在交互稿上各種跳轉(zhuǎn)、動態(tài)面板、中繼器等花里胡哨一大堆，這樣開發(fā)同學看起來特別的難受，所以很多時候用連線的方式表示往往是最簡單明了的。
【3】如果涉及到多端設(shè)計（IOS、Andriod、PC端）的話，除非產(chǎn)品非常龐大，不然就放在同一個設(shè)計文檔中，避免以后評審還要弄多個文件。
【4】創(chuàng)建一個適合自己的組件庫，在日常設(shè)計中，80%的控件是可以重復(fù)利用的，做一個合適的組件庫能節(jié)省大量時間。
做交互文檔時垃圾桶就相當于后悔藥，因為一些頁面如果刪掉保存后是不能還原了的，因此在改稿時如果一些暫時不需要的頁面可以丟到垃圾桶中，避免到最后用回以前的方案時重新再做浪費時間。
好啦，文章分享的內(nèi)容比較多，但是并不是每一部分都非做不可，文檔也并不是絕對的規(guī)范，每一家公司交互設(shè)計師的職責可能都不太相同，所以大家可以根據(jù)自身需求因地制宜。
曾經(jīng)有人說過，設(shè)計的本質(zhì)并不是把簡單的事情做復(fù)雜，而是把復(fù)雜的事情做簡單，所以我希望有一天你們能把交互設(shè)計文檔做到很簡單，而把產(chǎn)品做得非常好，然后跟我分享經(jīng)驗，這才是我寫文章的初心。
最后希望大家有所收獲，與大家共同進步，共勉~~
本文由 @北沐而川 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。
題圖來自Unsplash，基于CC0協(xié)議
大多數(shù)優(yōu)秀的企業(yè)網(wǎng)站建設(shè)中，他們的設(shè)計方案通常會包含了視覺部分、交互部分以及管理員使用部分這三大板塊的精雕細琢工作。而很多深圳很多企業(yè)負責人往往會只注重視覺設(shè)計部分，忽略了交互部分的定制。今天跟大家分享的這個陰陽臉交互設(shè)計，是在不少領(lǐng)域、不少高級品牌網(wǎng)站中能看到的。所謂陰陽臉交互，即用戶在一個屏幕內(nèi)會看到左右平均分布的兩塊內(nèi)容，隨著用戶自動拖拽內(nèi)容后，從左往右展開或從右往左展開視窗的寬度，從而讓一半顯示更全的交互邏輯設(shè)計。
陰陽臉網(wǎng)頁交互設(shè)計通常會用在藝術(shù)行業(yè)、科技行業(yè)、醫(yī)療行業(yè)等領(lǐng)域，它的特色就是神秘感、互動感，在某些不適合渲染這種氛圍的行業(yè)，就不能隨意使用這種交互，效果會適得其反。
為了更好地展示這個交互效果，我們找來了一個在線的深圳公司網(wǎng)站案例
訪問深圳網(wǎng)站建設(shè)官網(wǎng)，查看動態(tài)的交互效果
https://www.gloshine.com/
值得設(shè)計師們注意的是，陰陽臉網(wǎng)頁交互設(shè)計，需要注意它的承上啟下作用，要么作為官網(wǎng)Banner區(qū)域的全屏模塊內(nèi)容，要么作為下面兩個板塊之間的銜接模塊，這時需要注意虛實結(jié)合的節(jié)奏。而陰陽臉通常都是深色為主的，所以它的上面和下面，盡量不要都是深色區(qū)域，至少有一個是淺色的（或顏色對比度稍微大一些的），避免連續(xù)三個重色模塊，導(dǎo)致視覺無法呼吸。
在看另一個深圳網(wǎng)站建設(shè)案例，這是一個產(chǎn)品H5專題頁的形式
訪問深圳網(wǎng)站建設(shè)官網(wǎng)，查看動態(tài)的交互效果
http://www.coleder.com/products/ace-block/47.html
陰陽臉交互設(shè)計在網(wǎng)站建設(shè)中的運用
注意陰陽臉交互設(shè)計運用的上下環(huán)境搭配
好了， 以上就是今天跟大家分享的，通過陰陽臉交互設(shè)計讓深圳網(wǎng)站建設(shè)公司提出的設(shè)計方案與眾不同的好技巧。
*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
