本篇是系列小結(jié)的第二篇，簡單總結(jié)一下自己對如何提高交互文檔質(zhì)量的一些思考。

希望自己在一年結(jié)束時留給自己感慨的不只是“我畫了幾百張交互稿”或者干巴巴的“完成了幾個上線項目”，也非常感謝網(wǎng)易saga前輩耐心的指點，還有“多總結(jié)、多思考”的建議。有感于這樣的建議，近期開始，將陸續(xù)把今年實際項目中遇到的一些經(jīng)驗教訓(xùn)，以及團(tuán)隊協(xié)作過程中遇到的問題和解決方案以文章的方式做一整理。

1 交互文檔的形式和內(nèi)容

交互文檔是交互設(shè)計師自己的“產(chǎn)品”，而相信每個選擇從事交互設(shè)計的同學(xué)，都有著一顆有情懷的心和做好經(jīng)手的每個產(chǎn)品的愿望。

那么，對展示我們自己交互崗位成果的產(chǎn)品，自然也要用設(shè)計一個產(chǎn)品的態(tài)度去精益求精。

整體呈現(xiàn)上自然不用說——一份整潔清晰、排版舒服的文檔總會更讓閱讀者心情愉悅，也更能感受到設(shè)計者的用心程度。而在此之外，無論在文檔結(jié)構(gòu)、內(nèi)容上還是形式上，都有不少值得注意的地方，可以幫助我們的交付物更好地通過Review，也更好地讓下游的UI、前端同學(xué)領(lǐng)會我們的意圖，增進(jìn)團(tuán)隊效率。

交互文檔的定義和形式都沒有太通行的定論，和團(tuán)隊的習(xí)慣有很大關(guān)系。一般而言，形成一份排版整齊的PDF文檔打印出來，對參與人數(shù)較多的評審過稿來說效果更好。但對全線采用Axure的團(tuán)隊來說，直接寫在Axure的HTML里也是一種不錯的形式。在實際項目中兩種方式都接觸過，也很難界定哪種更好。交互是一個承上啟下的中間設(shè)計環(huán)節(jié)，這決定了它的交付物只要做到表達(dá)清晰、有足夠的說服力，拘泥于形式?jīng)]有太大的意義。

本文中將以我實際在項目中的做法作為示例，并不代表這種就是最優(yōu)的做法，也歡迎同行提出更好的建議：）

在很多人的印象中，線框圖就是交互設(shè)計師的輸出物，線框圖也確實是交互文檔中篇幅最大的部分，但絕對不是最重要的部分。

在通過線框圖具體展示設(shè)計方案之前，目標(biāo)分析和全局性的流程方案是更為關(guān)鍵的一部分，也是實際項目中最花時間和精力的部分。

我的交互文檔一般由以下幾個部分構(gòu)成：

目標(biāo)分析、信息架構(gòu)設(shè)計、流程設(shè)計和線框圖這四部分中，需要注意哪些方面才能提高文檔的質(zhì)量？本篇將結(jié)合實際項目的一些小例子逐一地進(jìn)行總結(jié)。因為實際項目基本都是B端項目，因此本文的的大部分?jǐn)⑹龆际轻槍端項目進(jìn)行的。當(dāng)然，涉及具體方案的部分不方便以公司項目作為例子，會用個人的一些C端side projects里中原理相通的案例做示例。

而對最后一步——自查，會在后續(xù)更新的其他文章中對如何建立適合自己工作習(xí)慣和業(yè)務(wù)背景的自查表進(jìn)行總結(jié)。

2 目標(biāo)分析篇：底氣來自過程

把目標(biāo)分析寫進(jìn)交互文檔的最大作用就是讓方案有過程可查、有據(jù)可循，增強(qiáng)評審時的底氣。

對交互設(shè)計師自己來說，打開文檔時首先映入眼簾的是設(shè)計目標(biāo)和整體流程，有助于時刻提醒自己所有方案都是為設(shè)計目標(biāo)服務(wù)的，避免埋頭畫了幾十張線框圖后發(fā)現(xiàn)已經(jīng)離設(shè)計目標(biāo)十萬八千里了，這時候無論是想方設(shè)法勉強(qiáng)自圓其說、還是含淚返工，都是一件痛苦的事情。

對參與評審的產(chǎn)品方、客戶而言，首先看到扎實的目標(biāo)分析、完整的思考流程，可以在內(nèi)心對你的專業(yè)性、方案的推演過程產(chǎn)生不錯的印象分和信任感，基于對目標(biāo)分析的了解再去看具體方案的時候，言辭尖銳的challenge自然也會減少不少。畢竟，讓方案更具說服力、順利通過Review對設(shè)計師而言才是工作被認(rèn)可、帶著好心情下班的關(guān)鍵。

對下游具體與交互設(shè)計師合作的視覺、前端同學(xué)而言，相比直接拿到干巴巴的交互稿開始做視覺稿、寫頁面，看到交互設(shè)計的思考過程想必心里會更踏實，而不是一邊搬磚一邊心理犯嘀咕“這個bar為什么要這樣設(shè)計？會不會評審后又要改？現(xiàn)在做的是不是白做？“，同時，如果文檔里的思路足夠清晰，而你的視覺、前端同學(xué)的理解能力也不錯的話，”這里一定要這樣設(shè)計嗎？能不能……”之類的問題會減少很多，大大降低團(tuán)隊內(nèi)的溝通成本。

當(dāng)然，文檔作為交互設(shè)計師自己的“產(chǎn)品”，也有自己的產(chǎn)品目標(biāo)——溝通。所以，文檔的最終目標(biāo)是可讀、易讀，而不是展示自己搬了多少磚、有多少苦勞。所以，寫進(jìn)交互文檔用于評審或者協(xié)作的內(nèi)容應(yīng)該盡可能精簡。

2.1 產(chǎn)品目標(biāo)

產(chǎn)品層面的目標(biāo)其實說簡單很簡單。

無論做一個妙趣橫生的C端產(chǎn)品也好，還是一個崇尚高效的B端應(yīng)用也好，終極目的都是……賺錢。

所以，無論是言簡意賅地在交互文檔的開頭用最短的一句話寫明產(chǎn)品目標(biāo)時，還是完成任何方案的具體設(shè)計時，都要謹(jǐn)記自己的任何方案都是為利益服務(wù)的。

在交互文檔中，在開篇可以用一句精煉的話描述產(chǎn)品目標(biāo)。比如幫一個客戶公司設(shè)計辦公管理平臺APP時，顯然產(chǎn)品目標(biāo)就是提高客戶公司的辦公效率，讓客戶滿意服務(wù)，產(chǎn)生長期使用意愿，積累產(chǎn)品口碑和傳播量，吸引更多客戶與我方合作建立類似的平臺。

2.2 業(yè)務(wù)需求

一個業(yè)務(wù)需求是由業(yè)務(wù)目標(biāo)和業(yè)務(wù)目的構(gòu)成的有機(jī)整體。

• 業(yè)務(wù)目標(biāo)：做這個需求是想實現(xiàn)怎樣的目標(biāo)和成果？通?？蛻艋蛘弋a(chǎn)品方提供給交互設(shè)計師的也是這一層面的指標(biāo)。
• 業(yè)務(wù)目的：實現(xiàn)這樣的目標(biāo)后呢？真正動機(jī)是什么？最終是想要什么結(jié)果？并且，一個合理的業(yè)務(wù)需求是可以通過一定的信號和指標(biāo)衡量的。

但實際項目中，有時PM會提一些缺乏依據(jù)的衡量指標(biāo)（比如某流程執(zhí)行效率提高50%，50%從何而來？），甚至提出一些沒有衡量指標(biāo)的需求（原因通常是“因為競品做了XXX我們也要做“、”客戶覺得有這個功能更高大上“……）。這時盲目接收需求的話，痛苦和被問責(zé)的都是自己。所以一定要抱緊PM大腿不放直到刨根問底搞清楚為止。

這里我習(xí)慣用表格的形式，將業(yè)務(wù)需求和相應(yīng)衡量指標(biāo)的推導(dǎo)過程展示在交互文檔中，評審時一目了然。

2.3 用戶目標(biāo)

用戶目標(biāo)的分析中，有條件時可以通過問卷、訪談、現(xiàn)場觀察等方法獲取真實的用戶信息，因客戶企業(yè)的管理制度或時間所限、沒有相關(guān)條件時，也可以向團(tuán)隊內(nèi)熟悉客戶業(yè)務(wù)的產(chǎn)品同事求助，總之，這一步是基于真實用戶的反饋進(jìn)行還是基于設(shè)計師自己的臆想進(jìn)行，對后續(xù)設(shè)計流程順利與否的影響非常大。

用戶目標(biāo)部分應(yīng)該體現(xiàn)在交互文檔中的內(nèi)容主要有：目標(biāo)用戶的角色分析（用戶畫像）、用戶任務(wù)目標(biāo)和相應(yīng)的場景分析（故事板），以及由此得出的用戶需求和用戶體驗?zāi)繕?biāo)。

這一年中所做的項目都是以B端產(chǎn)品為主，而個人的side project則以C端產(chǎn)品為主，因此能很清晰地感覺到兩者之間在用戶目標(biāo)分析中的差別。

B端產(chǎn)品的角色多與工作角色或職責(zé)相對應(yīng)，而C端產(chǎn)品用戶的角色通常與家庭角色、態(tài)度、相關(guān)活動方法、興趣、選擇生活方式的能力等對應(yīng)，兩種產(chǎn)品在做角色和場景分析時方法有所不同。具體分析方法可以參見《B端產(chǎn)品的角色與場景分析：以會議申請功能的設(shè)計為例》，這里就不再展開了。

在交互文檔的篇幅有限的情況下，相比大段文字的場景描述，故事板是最適合在交互文檔中展示角色和場景的形式，而當(dāng)場景被質(zhì)疑時，再拿出具體的場景描述也不遲。

下圖就是開始構(gòu)思一個”發(fā)起在線投票“功能時的故事板。

同時，在獲取真實用戶信息的環(huán)節(jié)如果有拍照的話，在篇幅允許的情況下也可以放進(jìn)交互文檔，增強(qiáng)提案的說服力。

2.4 設(shè)計目標(biāo)（需求提煉）

對C端產(chǎn)品而言，這一步通常通過”創(chuàng)造動機(jī)、排除擔(dān)憂、解決障礙“的三大關(guān)鍵因素分解法提煉需求。而對B端產(chǎn)品，取代動機(jī)和擔(dān)憂的是履行工作職責(zé)的”剛需“，因此我在實際項目中多采用”信息需求“和”功能需求“的需求提煉方法。具體方法同樣參見《B端產(chǎn)品的角色與場景分析：以會議申請功能的設(shè)計為例》。

同樣的，表格也是我習(xí)慣采用的，在交互文檔中展現(xiàn)需求提煉過程的一種比較清晰的形式。

3 信息架構(gòu)：關(guān)注競品和真實用戶

緊密圍繞目標(biāo)和需求進(jìn)行方案設(shè)計的第一步，就是將目標(biāo)和需求轉(zhuǎn)化為全局性的信息架構(gòu)和流程。

3.1 信息架構(gòu)是什么

信息架構(gòu)是對頁面、信息和功能有組織的排列排序。合理的信息架構(gòu)在符合邏輯的同時，也會盡可能貼近用戶已有的使用習(xí)慣和思維方式，從而幫助用戶快速判斷和找到他們想要的功能。對B端產(chǎn)品而言可以大大降低產(chǎn)品的學(xué)習(xí)成本，對C端產(chǎn)品而言則可以帶給用戶更好的體驗、提高用戶的留存率。

在著手進(jìn)行信息架構(gòu)設(shè)計之初，我們總要面對目標(biāo)分析階段得到的大量的頁面、信息和功能名稱。對這一年里經(jīng)手的幾個B端項目來說，大體都是十余個模塊，每個模塊中至少有3~5個不等的小功能，每個功能對企業(yè)中不同職能、不同身份地位的角色而言可能又會細(xì)分成若干個場景，這樣分解得到的需求數(shù)量可能讓我們看到就頭大。

如果在目標(biāo)分析階段是按照場景通過“信息需求/功能需求”法進(jìn)行分解的，那么頁面和信息在頁面中的歸屬我們應(yīng)該是大概心里有數(shù)的，這種情況下信息架構(gòu)設(shè)計的下手會稍微容易那么一點。而如果是采用”創(chuàng)造動機(jī)、排除擔(dān)憂、解決障礙“三大關(guān)鍵因素分解得到的需求，則會顯得更加龐雜和無序。實際上，這也是我個人對小巧的C端應(yīng)用建議使用第二種方法，而對本身就復(fù)雜度非常高的B端應(yīng)用建議采用第一種更簡化的方法進(jìn)行分解的原因。

無論如何，海量的頁面、信息、功能元素是我們總要面對的，這時常用的兩種方法就是競品分析和卡片分類法。

3.2 競品分析

對大多數(shù)非首創(chuàng)性的C端應(yīng)用而言，或成功的或失敗的，或相似度高的或相似度低的，總是能搜到若干個和自己的項目類型類似的競品。這時候，選取3~5個競品，截一套完整的截屏、解析它們的信息架構(gòu)，無論從共性還是差異上都能找到很多值得學(xué)習(xí)的地方。

這里的學(xué)習(xí)不只是借鑒，選擇競品時也不一定要只選擇口碑最好的那幾個，有時偶爾找一個失敗的競品，學(xué)習(xí)到的教訓(xùn)可能更能幫助我們減少犯錯。對信息架構(gòu)而言，很多糟糕的競品都在”尊重用戶習(xí)慣“這點上犯了錯，為了體現(xiàn)差別而強(qiáng)行做出差別來，只會讓用戶用得別扭，結(jié)果就是大量用戶的流失。在做產(chǎn)品的版本迭代時，自家產(chǎn)品的歷史版本也是競品分析時不可缺少的樣本。

這里是一個對京東的京豆和淘寶的淘金幣兩個競品模塊進(jìn)行信息架構(gòu)分析的例子。

3.3 卡片分類

對B端產(chǎn)品而言，除了一些通用性高的企業(yè)辦公、ERP、金融服務(wù)類產(chǎn)品可能相對容易找競品，而對大多數(shù)企業(yè)應(yīng)用來說，各行各業(yè)都具有較強(qiáng)的業(yè)務(wù)壁壘，業(yè)務(wù)類型千差萬別，即使是相同的業(yè)務(wù)，不同企業(yè)的運作和管理模式不同，也可能導(dǎo)致產(chǎn)品需求差別非常大。例如建筑設(shè)計院的項目工時和圖紙歸檔系統(tǒng)、運營商的流量管理系統(tǒng)、通信行業(yè)的光纜巡檢系統(tǒng)等等，從名字上大家應(yīng)該就能大概明白為什么很難找到競品了。

這時，同時適用于C端和B端產(chǎn)品信息架構(gòu)分析的卡片分類法就是我們最好的伙伴。如果說競品分析只是借鑒，卡片分析法則是基于真實被試對象心智模型的直接分析手段。

卡片分類法是指將頁面、功能或信息元素的名稱寫在卡片上，讓用戶（沒有條件的話找非本項目組的同事也可以）按自己的理解將卡片分成幾組，并給每組起一個名字，如果初次歸類太小或者太小，可以讓用戶再進(jìn)一步擴(kuò)大或者縮小分組，最后對分類結(jié)果進(jìn)行整理，得到初步的信息架構(gòu)，同時也能幫我們發(fā)現(xiàn)一些頁面或元素命名不合適的問題。

卡片分類法應(yīng)該是信息架構(gòu)設(shè)計中最基礎(chǔ)的方法之一了，在此不再展開贅述。只想提的一點是，在B端應(yīng)用中要注意，卡片分類法要么分模塊進(jìn)行，要么應(yīng)該把一級模塊的名稱事先指定給用戶，否則面對多個模塊的功能混在一起時，用戶頭疼，測試結(jié)果也通常質(zhì)量很差、毫無參考價值。

這里就不再展示卡片分析過程的照片之類的了，沒有太大意義（當(dāng)然，如果朋友們在項目中有注意積累這種過程資料的話，評審時放進(jìn)交互文檔倒是很有用），就簡單看一下收集到所有用戶的分組結(jié)果后，對大量的信息該如何解讀和處理吧。

雖然有專業(yè)的統(tǒng)計學(xué)方法和軟件可以提供更全面的分析和數(shù)據(jù)，但這里只想講講在缺乏用研人員配備、需要快速得出有效的定性結(jié)論時，我所習(xí)慣的一種處理方法。不過，這種方法只適用于給定分組名稱（一級模塊名稱）的卡片分類測試，對B端產(chǎn)品的分析應(yīng)該說大多數(shù)情況下足夠了。

如果是不給定分組名稱、自由分組的測試，結(jié)果的處理難度會稍微大一點，一般在沒有統(tǒng)計學(xué)軟件支持的情況下，都是定性地看一下哪些分組比較趨同和固定，以及出現(xiàn)了哪些比較意外的結(jié)果。

嗯，沒錯，我還是喜歡表格：）

首先，第一列寫明是哪張卡片，第二列“設(shè)計分組”是指在初步設(shè)計中，根據(jù)設(shè)計師的心智模型設(shè)置的分組。第三列“用戶分組正確率”是指用戶分組與設(shè)計分組吻合的百分率。第四列“主要偏差分組”是指在不吻合的樣本中，卡片主要被分流去其他組中的哪一個了。第五列“其他偏差分組”則用于填寫除“主要偏差分組”外的其他分流去向。

以這種方法對所有卡片的分類結(jié)果進(jìn)行梳理后，我們就很容易對自己的方案和真實用戶心智模型之間的差距有一個大體感知了，通過“主要偏差分組”、輔以“其他偏差分組”，則可以針對產(chǎn)生這些分流的原因進(jìn)行思考，有條件時還可以進(jìn)行回訪。

3.4 交付物：樹狀圖

形成初步的樹狀圖后，下一步是對同級頁面/元素的重要性進(jìn)行分級，并初步確定其表現(xiàn)形式。

1. 分級：用數(shù)字1、2、3……標(biāo)明各頁面/元素的重要性順序，只有一個頁面/元素重要性最高時，可以在交互稿中考慮加大這一信息塊/控件的視覺比重，反之同理。
2. 表現(xiàn)形式：這個元素是一個頁面，一個Tab頁，一個”塊“（甚至可以細(xì)分成Banner、卡片、列表等更具體的形式），還是一個跳轉(zhuǎn)按鈕/鏈接？用各種腦圖軟件中的標(biāo)記工具，可以很方便將各種元素分門別類，不過放進(jìn)交互文檔時別忘了注明圖例，方便同事們看懂。當(dāng)然，如果只是對頁面做信息架構(gòu)的話這一步不適用。

這里不方便放公司產(chǎn)品的信息架構(gòu)，就放一個競品分析中的吧，道理是一樣的。

說到這里有個小建議，如果是對頁面、功能、信息元素同時做信息架構(gòu)（我個人也比較建議這種方式），為了防止整個樹狀圖太大造成閱讀困難，可以分模塊繪制多個樹狀圖，繪制和閱讀都更方便。

4 流程設(shè)計篇：接觸點，支線和異常

通過需求的提煉，整理得到諸多需要設(shè)計中體現(xiàn)的頁面、信息和功能后，信息架構(gòu)設(shè)計相當(dāng)于將這些元素組合成一張地圖，而流程設(shè)計則是將地圖上各個元素沿著不同的任務(wù)路徑連起來。

4.1 接觸點：流程設(shè)計的線索

流程設(shè)計就是對用戶使用產(chǎn)品的路徑進(jìn)行設(shè)計，是B端交互設(shè)計最有趣也最有挑戰(zhàn)的地方。如何將繁瑣、繞來繞去的流程打通成清晰簡潔的體驗路徑，甚至將原來冗長的流程縮短成只有一半，這是最能體現(xiàn)B端交互設(shè)計師能力和價值的地方。優(yōu)秀的流程設(shè)計能極大地提高用戶完成任務(wù)的效率，這對效率為先的B端產(chǎn)品而言尤為重要。

流程設(shè)計的線索是場景分析（2.2節(jié)）中涉及到的所有接觸點。

關(guān)于接觸點的類型，這里部分參考saga前輩介紹的分類方法。一種稱為”操作”（Do），用戶在執(zhí)行了某個操作后，改變了他所處的狀態(tài)，產(chǎn)生了接受新信息的機(jī)會。第二種稱為”看到”(See)，用戶接受了新信息，并產(chǎn)生了新的想法。

基本上我們所熟悉的所有接觸點都萬變不離其宗，接觸點之間連接的方式也通常符合Do-See-Do-See-Do…的模式。但也有例外的情況，更適合采用”連續(xù)Do”或者”連續(xù)See”的設(shè)計。

這里需要注意的是要周全地考慮流程的頭和尾，不要遺漏第一個和最后一個接觸點。此外，對一些需要跳轉(zhuǎn)至其他應(yīng)用的流程，例如跳轉(zhuǎn)至支付寶、微信支付的流程，最好將這部分流程也畫出（至少是用簡單的虛線框），不要因為不是自己APP內(nèi)的操作就棄之不理。否則會很容易遺漏接觸點。

4.2 支線流程和異常流程

流程設(shè)計中還需要考慮支線流程和異常流程，這些流程有一部分與業(yè)務(wù)相關(guān)性較大的，已經(jīng)在目標(biāo)分析階段就作為單獨的場景分析過了，而還有大量更加瑣碎的支線和異常流程需要交互設(shè)計師考慮，例如：

支線流程

1. 支付方式不同，例如銀行卡支付、余額支付、第三方支付平臺支付，以及銀行卡支付中綁卡和未綁卡的兩種情況下，流程有怎樣的不同？
2. 未登錄用戶、不同權(quán)限的用戶在同一接觸點的流程是否有區(qū)別？例如：流程入口隱藏、流程操作被禁止等。
3. 表單提交、照片或文件上傳的過程中是否允許用戶取消操作，取消后流程如何跳轉(zhuǎn)？
4. 對可編輯的表單頁面，是否區(qū)分了瀏覽模式和編輯模式？兩種模式下的流程是否有區(qū)別？
5. 業(yè)務(wù)、運營要求必須增加的接觸點，怎樣合理地設(shè)計流程將它融入主任務(wù)流程？

異常流程

1. 用戶網(wǎng)速緩慢、超時、甚至無網(wǎng)狀態(tài)時，流程上如何引導(dǎo)用戶正確地返回、自動保存已輸入信息或檢查網(wǎng)絡(luò)環(huán)境？
2. 服務(wù)器資源不足時，流程上如何引導(dǎo)用戶正確地返回、自動保存已輸入信息？
3. 頁面默認(rèn)/篩選后狀態(tài)下內(nèi)容為空或部分為空時，流程上如何引導(dǎo)用戶返回或嘗試其他選擇？
4. 用戶可能的誤操作導(dǎo)致?lián)p失時，如何設(shè)計防錯流程幫助用戶避免這樣的損失？

以上歸納部分參考了網(wǎng)易UEDC《如何建立交互設(shè)計自查表》這篇很棒的總結(jié)，并結(jié)合自己的項目經(jīng)驗進(jìn)行了補(bǔ)充和完善。

關(guān)于支線流程和異常流程的思考，即使經(jīng)驗再豐富的設(shè)計師，實際上在一個新接觸的項目中也不可能做到在流程設(shè)計階段就考慮得面面俱到。所以在方案基本完成后的自查階段還需要重新梳理、查漏補(bǔ)缺。

異常流程通常是很難做到窮舉的，數(shù)量也多得驚人。因此對異常流程而言，多數(shù)可以通過在交互稿繪制中注明toast和alert文案簡單地解決，不過如果需要引導(dǎo)用戶返回或者嘗試其他可行操作時，還是要在流程圖上加以說明。

而對支線流程，由于支線之所以成為支線，必然是有流程上的差異。因此支線流程在流程設(shè)計階段最好盡可能地考慮全面。

4.3 交付物：流程圖

考慮支線流程和異常流程后，合并掉共有的接觸點后，我們的流程圖就基本成型了。這里就簡單放一個概覽吧，一個小模塊的流程圖完成后大概就是這樣的。

5 線框圖篇：邏輯大于形式

線框圖是交互設(shè)計師主要的交付物，而文檔具體的表現(xiàn)形式和工具，則因團(tuán)隊和設(shè)計師個人的習(xí)慣而異。除了國內(nèi)互聯(lián)網(wǎng)公司最常見的Axure外，AI、Sketch、InDesign，甚至PPT都可以用來做交互文檔。畢竟交互設(shè)計的核心永遠(yuǎn)在邏輯層面，交互文檔自然也不會拘泥于表現(xiàn)層面。

5.1 站點地圖型 or 流程分解型

作為我個人來說，在實際項目用到的主要是以下兩種表現(xiàn)形式，為了講述方便，分別簡稱為“站點地圖型”和”流程分解型”。

站點地圖型是指按照產(chǎn)品的信息架構(gòu)，將頁面逐一繪制在目錄樹相應(yīng)的節(jié)點上，使用的設(shè)計工具是Axure，最終的輸出形式是HTML頁面。

流程分解型則是按任務(wù)流，將任務(wù)拆解為若干個盡可能短小的子流程，將子流程版式相對固定地按順序畫在橫向的A4紙上（一般我習(xí)慣一張最多排4個頁面），工具可以使用Sketch、AI和InDesign中的任一種。

公司項目的具體線框圖不方便放，用個人項目的線框圖做例子吧。兩種方法今年在公司的幾個主要項目中都采用過，反響都還不錯。

5.1.1 站點地圖型（Axure）

優(yōu)點：

1. 頁面帶有目錄結(jié)構(gòu)，站點地圖清晰
2. 頁面增刪較為方便
3. 可以便捷地制作高保真原型
4. 相比Sketch、AI等可用于視覺設(shè)計的軟件而言，Axure的功能更為精簡，幫助設(shè)計師更好地將注意力放在邏輯層面，而不是視覺層面。

缺點：

1. 缺乏規(guī)整的排版布局和明確的閱讀順序，難以對流程跳轉(zhuǎn)關(guān)系有全局的認(rèn)識，下游的UI、開發(fā)同學(xué)閱讀時容易遺漏。
2. 輸出HTML以外的其他格式較為困難。
3. 母版、元件功能相比Sketch偏弱。

5.1.2 流程分解型（Sketch/AI/ID)

優(yōu)點：

1. 分解成子流程后，邏輯和跳轉(zhuǎn)關(guān)系非常清晰，逐張瀏覽不會漏掉任何頁面和交互說明。
2. Sketch的Symbol功能比Axure的母版功能更強(qiáng)大，可以只修改字段值。這就意味著，Axure中只有文字、樣式完全相同的組件才適合做成母版。而Sketch中，只要樣式相同，就可以方便地做成文字、內(nèi)嵌圖片都可以單獨編輯的Symbol，統(tǒng)一設(shè)計、統(tǒng)一修改，這就大大提高了組件化的覆蓋范圍，和組件使用的便利性。
3. 版面范圍固定，一切交互說明和流程指向都在一張A4紙的范圍內(nèi)，開發(fā)同學(xué)不容易看漏。
4. 可以很方便地打印成規(guī)整的紙質(zhì)版，用于會議時條理清晰地逐張過稿、記錄筆記。
5. 交互稿可以提供給下游的UI同學(xué)無縫對接。

缺點：

1. 修改時排版工作量大：想象一下，在4張擺放整齊、且之間已經(jīng)拉好流程箭頭的頁面中間，忽然要插入一個頁面時，設(shè)計師心里一定是一萬頭羊駝奔過——不但要重新整理那些可愛的箭頭，更意味著最后一個頁面要移到下一頁。而這樣的改動在方案初期和中期實在是太常見了。所以，雖然拆解成若干子流程后，頁面的增刪并不會引起大面積的排版變動，但在子流程內(nèi)，還是不可避免會導(dǎo)致這樣復(fù)雜的重復(fù)勞動。因此，更建議這種類型的交互文檔用于方案定稿（或至少接近定稿）階段的輸出。
2. 制作可交互的高保真原型沒有Axure便捷，需要對接Flinto、Origami Studio等外部軟件。

以上兩種類型的劃分僅供參考，工具各有自己的優(yōu)缺點，實際項目中根據(jù)團(tuán)隊習(xí)慣和效率要求，靈活選擇最適合自己的方式才是最好的。

5.2 向優(yōu)秀的線框圖進(jìn)階

線框圖在完整地緊扣目標(biāo)、體現(xiàn)流程的基礎(chǔ)上，注意下面這些可用性問題，可以幫助自己的線框圖更好地向“優(yōu)秀”進(jìn)階。這里在總結(jié)時部分參考了鴻影的《交互設(shè)計方案衡量標(biāo)準(zhǔn)的五層總結(jié)》中提到的點，并結(jié)合自己的實際項目經(jīng)歷進(jìn)行了補(bǔ)充、解釋和完善。

1.信息層級簡單清晰、密度合理，元素排布符合平臺規(guī)范和排版習(xí)慣

2.建議使用黑白灰單色系（也有深藍(lán)、藍(lán)、淺藍(lán)的做法，同樣是單色系，這方面看個人喜好了）以避免色彩對下游UI同學(xué)造成先入為主的干擾。

當(dāng)然，在項目配備的人數(shù)較少時有一種例外情況，如果一個項目是同一個人兼做交互和UI，而且方案已經(jīng)大致確定的話，交互稿中的頁面可以考慮同時作為視覺設(shè)計的產(chǎn)出物，只要將頁面切出來加上標(biāo)注就可以作為視覺稿使用。這種情況下，交互稿直接按真實的UI規(guī)范進(jìn)行繪制也是可以的。

例如，在辦公管理平臺APP和光纜巡檢平臺兩個項目中，我同時兼任交互和UI，就采用了這種方式，根據(jù)開發(fā)同學(xué)習(xí)慣，兩個項目分別使用站點地圖型和流程分解型繪制交互稿，交互稿在基本定稿后就直接在交互稿上按照UI規(guī)范進(jìn)行視覺設(shè)計，進(jìn)而輸出視覺稿，都取得了同事和PM不錯的反響?？傊?，要么就嚴(yán)格按UI規(guī)范進(jìn)行文字和色彩設(shè)計，要么就用單色系，不要四不像。

和流程設(shè)計中同樣的，不在APP內(nèi)的頁面同樣不要在線框圖中遺漏，容易忘記重要的接觸點。

3. 操作控件易于發(fā)現(xiàn)和理解，符合用戶已有的平臺或者競品使用習(xí)慣，有較好的自解釋性，避免在成型的規(guī)范和習(xí)慣上大刀闊斧地發(fā)揮創(chuàng)意。跳轉(zhuǎn)形式、手勢、操作反饋等交互行為符合平臺和產(chǎn)品自有規(guī)范，降低用戶認(rèn)知和學(xué)習(xí)成本。同時，產(chǎn)品內(nèi)應(yīng)注意組件的一致性，這點可以通過控件、信息元素的組件化解決（這也是Sketch作為工具最大的優(yōu)勢）。

4. 必要時可以設(shè)計引導(dǎo)提示，但不應(yīng)打斷用戶。

5. 避免用戶的誤操作造成較大損失。涉及大段信息的文字、表單輸入時提供自動保存功能，在合理的情況下提供撤銷和恢復(fù)的可能性。

6. 文案在做到表意準(zhǔn)確的同時，C端的文案應(yīng)當(dāng)在合理的前提下考慮情感化、趣味化的設(shè)計，讓用戶感知產(chǎn)品的溫度感。B端的文案也可以在言簡意賅的同時注意這方面的考量，專業(yè)性和情感化并不是一對沖突的概念。同時，文案在評審時可以考慮邀請對本項目業(yè)務(wù)不熟悉的其他同事加入，他們更容易從普通用戶的角度發(fā)現(xiàn)文案中一些不清晰，或容易造成誤解的地方。

7. 在合理、不違反基本的用戶習(xí)慣的地方，可以考慮微交互層面的小創(chuàng)新，增加品牌辨識度。交互模式逐漸沉淀成一些通用的規(guī)范對這個行業(yè)來說是好事也是壞事，好的方面是體驗糟糕的產(chǎn)品會越來越少，只要遵循逐漸成型的通用規(guī)范就可以相對容易地做到不犯錯，但壞的方面是業(yè)務(wù)類似的產(chǎn)品在交互也趨同的情況下，顯得更加沒有辨識度了，這就對交互設(shè)計師的創(chuàng)新意識提出了更高的要求。同時，對經(jīng)驗足夠豐富的交互設(shè)計師而言，如果在設(shè)計過程中對產(chǎn)品業(yè)務(wù)層面的創(chuàng)新點有了一些靈感，也可以及時地與PM討論。

8. 能預(yù)估技術(shù)成本和風(fēng)險，詳見5.3節(jié)。

9. 在把方案提交審查前，進(jìn)行一次全面的自查，能避免很多審查中被challenge到啞口無言的尷尬場面。

5.3 方案的風(fēng)險預(yù)估

只會畫線框圖、給PM搬磚的交互很難稱得上是優(yōu)秀的交互設(shè)計師，隨著經(jīng)驗的成長，對方案風(fēng)險的預(yù)估是很重要的一項能力。其中包括上游產(chǎn)品層面的業(yè)務(wù)風(fēng)險和下游開發(fā)層面的技術(shù)風(fēng)險。將對風(fēng)險的預(yù)估體現(xiàn)在線框圖的具體方案考量和準(zhǔn)確的交互說明中，將很大程度上提高團(tuán)隊對你的方案的認(rèn)可度。

5.3.1 業(yè)務(wù)風(fēng)險的預(yù)估

對業(yè)務(wù)模塊之間耦合度高的大型B端產(chǎn)品，一個模塊的方案有不合理之處時，往往會牽一發(fā)而動全身地影響其他模塊正常的業(yè)務(wù)邏輯。單純?yōu)榱艘粋€模塊的用戶體驗考慮，很容易導(dǎo)致其他業(yè)務(wù)流程的復(fù)雜度呈幾何級數(shù)地增加。

例如，在一個項目的巡檢模塊（巡檢簡單說就是沿線檢查某種設(shè)施）中，如果允許用戶自行選擇簽到點的話，無論是簽到點的指定錯誤、遺漏還是延遲，都會導(dǎo)致整個工單的記錄出現(xiàn)非常多種異常狀況，使得巡檢記錄的準(zhǔn)確性大打折扣，而這恰恰是這一模塊存在的意義，也就是模塊的業(yè)務(wù)目標(biāo)。所以，最終取消了任何由用戶自行選擇路線和簽到點的功能，前端只記錄路徑、所有判斷由后臺完成，大大簡化了邏輯和用例的數(shù)量，并最終提高了巡檢記錄的準(zhǔn)確性。

再舉個簡單的例子，這個例子在另一篇文章《B端產(chǎn)品的角色與場景分析：以會議申請功能的設(shè)計為例》中詳細(xì)講過，這里簡單提一下。某辦公管理系統(tǒng)APP的會議申請模塊中，最終的設(shè)計方案中，已申請的會議（室）不允許修改任何信息，如果一定要修改必須取消后再重新申請。這樣可以通過犧牲一定用戶體驗（便捷地修改申請單），更好地有助于達(dá)到產(chǎn)品的短期目標(biāo)（提高用戶申請會議的決策成本）和長期目標(biāo)（教育員工養(yǎng)成對自己的會議申請負(fù)責(zé)的習(xí)慣）。

那篇文章中也提到過一個問題：交互設(shè)計師到底是應(yīng)該優(yōu)先站在用戶體驗角度考慮問題、把業(yè)務(wù)風(fēng)險交由PM判斷，還是應(yīng)該替PM將產(chǎn)品目標(biāo)和業(yè)務(wù)風(fēng)險的問題考慮進(jìn)自己提出的方案內(nèi)？

其實說到底，就是業(yè)務(wù)風(fēng)險是否要由交互設(shè)計師預(yù)估的問題。最近請教過Saga前輩和尤文文前輩。他們比較一致地認(rèn)為后者更有利于團(tuán)隊效率和個人成長。從團(tuán)隊效率上來講，交互設(shè)計師進(jìn)行風(fēng)險預(yù)判可以減少方案提出后的撕逼和返工。從個人成長上講，避免被“純粹的交互設(shè)計師”這個立場框住自己，學(xué)著既能做具體方案、又會替PM從產(chǎn)品目標(biāo)和商業(yè)角度通盤考慮業(yè)務(wù)風(fēng)險，這樣的設(shè)計師是很容易成長為leader的，這也是我在后面工作中的努力方向：）

5.3.2 技術(shù)風(fēng)險的預(yù)估

在學(xué)有余力的條件下，交互設(shè)計師擁有一些基本的CSS、JS功底是很好的一件事，雖然不一定自己去寫，但知道自己提出的哪些交互需求容易做、哪些很難做甚至做不了，可以一方面為團(tuán)隊提前預(yù)估技術(shù)成本和可能存在的問題，另一方面也幫助設(shè)計師對前端同學(xué)“這個做不了”、“這個太花時間”的答復(fù)心里更有數(shù)：是真的做不了，還是他只是想早點下班呢。

在出于技術(shù)成本的考慮做出設(shè)計方案的妥協(xié)時，可以寫在交互說明中，一方面幫助大家理解你的苦衷，另一方，比較nice的前端同學(xué)在評審時看到這些備注時，如果他有能力做到更好的方案，或許會主動告訴你他可以實現(xiàn)呢。如果沒有代碼方面的基礎(chǔ)，也可以通過不斷與開發(fā)同學(xué)協(xié)商可行性，或者從每次評審中逐漸積累”哪些能做哪些不能做“的概念，來幫助自己的方案減少技術(shù)方面的撕逼。

當(dāng)然，對于這個問題，Saga前輩的建議是，交互可以把上游（產(chǎn)品）的問題在做方案時就考慮進(jìn)自己的方案，而對下游（開發(fā)）的問題，不要過早地妥協(xié)。先按最有利于用戶體驗的方案提出，再交由開發(fā)自己去判斷實現(xiàn)的可行性。所以實際工作中視自己和開發(fā)同學(xué)的默契程度，是自行預(yù)估、交由開發(fā)判斷、還是不斷保持協(xié)商，選擇適合自己團(tuán)隊的方式才是最好的。

動效設(shè)計大概是最典型的一類容易牽扯到技術(shù)風(fēng)險的問題。包括我在內(nèi)的很多交互設(shè)計師都是動效控，在符合用戶心智模型的基礎(chǔ)上，帶給用戶驚喜的微交互能一兩撥千金地提升用戶對產(chǎn)品的好感度。

例如，還是剛才說的巡檢功能的例子。巡檢模塊是項目的核心模塊，本質(zhì)上有點類似運動APP的計步模塊，相比其他頁面單調(diào)的表單和列表操作，是一個比較容易通過動效進(jìn)行情感化設(shè)計、讓產(chǎn)品的精致程度上一個檔次的地方。因此在做方案時，在一些記錄狀態(tài)的切換、地圖/表單頁的轉(zhuǎn)場切換中，曾經(jīng)構(gòu)思過不少動效。

但在方案提交前的自查中，我自己去了解了一下通過animation和canvas實現(xiàn)這些動效的難度系數(shù)，發(fā)現(xiàn)如果讓開發(fā)同學(xué)自己造輪子的話開發(fā)成本會相當(dāng)高，看似簡單的動效在需要考慮H5頁面的多機(jī)型適配時，調(diào)試難度相當(dāng)大。我也在Codepen和一些成套的第三方動效庫里找過有沒有合適的輪子可用，但效果不盡理想。因此最終至少在一期階段我放棄了這些有趣的動效，先讓開發(fā)同學(xué)在有限的時間內(nèi)集中精力保證功能的實現(xiàn)，后續(xù)在有余力的情況下再進(jìn)行動效上的完善。

再舉個和開發(fā)保持溝通，及時調(diào)整方案的例子。在辦公管理平臺APP中，首頁需要一個日程表模塊。這里看一個最終未采用的初版方案吧，PO出來無妨。我起初的設(shè)計是這樣的形式：

但開發(fā)同學(xué)看到交互稿后，首先肯定了這樣的設(shè)計很漂亮，同時滿足了用戶從天、周、月三個維度查看過去、當(dāng)前和未來日程的需求。但同時提出，這個項目是Hybrid APP（H5內(nèi)容+iOS外殼），之前團(tuán)隊的組件積淀中沒有涉及這類組件的開發(fā)，因此沒有現(xiàn)成的組件可用。在上線時間緊迫（當(dāng)時馬上要給客戶做演示）的情況下從頭寫起的話，因為設(shè)計中三個維度的展現(xiàn)方式從樣式和展現(xiàn)的數(shù)據(jù)上都有較大差別，成本超乎我們的想象，因此建議我先設(shè)計更簡化的形式，后續(xù)再視客戶的意愿逐步在版本迭代中實現(xiàn)更完整的日程功能。

因此，我考慮只保留其中一個維度作為這一期上線的內(nèi)容。在和熟悉業(yè)務(wù)的產(chǎn)品同事詳細(xì)了解了客戶使用日程功能的實際場景后，我們決定只保留最核心的”周”維度。并且，查看所有歷史日程并非用戶的主要訴求，因此進(jìn)一步將“周”的選擇控件簡化為只能查看“上周/本周/下周”三周內(nèi)容的分段選擇控件。

6 小結(jié)

總而言之，交互文檔質(zhì)量的提高需要從前期的思考分析、中期的整體架構(gòu)和流程設(shè)計、最終具體線框圖的繪制等環(huán)節(jié)全方位著手。新人階段比較關(guān)注的工具、形式和格式實際上絕非交互文檔質(zhì)量的關(guān)鍵。能通過合理的分解將業(yè)務(wù)需求、用戶體驗?zāi)繕?biāo)轉(zhuǎn)化為具體的設(shè)計需求，能在信息架構(gòu)和流程設(shè)計上緊扣并體現(xiàn)產(chǎn)品目標(biāo)和需求，最后通過干凈清晰的交互稿將方案傳達(dá)給UI和開發(fā)同學(xué)，才是真正要關(guān)注的方面。

而做到這些，對交互設(shè)計自身一些通用方法和規(guī)范的熟練程度、對上游產(chǎn)品和業(yè)務(wù)的理解深度、對視覺和技術(shù)執(zhí)行方案可能遇到的問題，都有比較高的要求。我想，這也在交互設(shè)計這個崗位發(fā)展到今天，對自己、以及對覺得這篇文章有用的同行們一種更高的要求和努力方向吧。和大家共勉！

作者：Qinsman，通信行業(yè)UE設(shè)計師，微信公眾號：西市饅頭鋪子。博客：http://qinsman.com/，歡迎大家與我交流。

本文由 @Qinsman 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。