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

希望自己在一年結(jié)束時(shí)留給自己感慨的不只是“我畫了幾百?gòu)埥换ジ濉被蛘吒砂桶偷摹巴瓿闪藥讉€(gè)上線項(xiàng)目”，也非常感謝網(wǎng)易saga前輩耐心的指點(diǎn)，還有“多總結(jié)、多思考”的建議。有感于這樣的建議，近期開始，將陸續(xù)把今年實(shí)際項(xiàng)目中遇到的一些經(jīng)驗(yàn)教訓(xùn)，以及團(tuán)隊(duì)協(xié)作過程中遇到的問題和解決方案以文章的方式做一整理。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3 用戶目標(biāo)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2 競(jìng)品分析

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

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

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

3.3 卡片分類

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

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

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

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

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

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

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

嗯，沒錯(cuò)，我還是喜歡表格：）

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

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

3.4 交付物：樹狀圖

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

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

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

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

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

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

4.1 接觸點(diǎn)：流程設(shè)計(jì)的線索

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

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

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

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

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

4.2 支線流程和異常流程

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

支線流程

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

異常流程

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

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

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

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

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

4.3 交付物：流程圖

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

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

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

5.1 站點(diǎn)地圖型 or 流程分解型

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

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

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

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

5.1.1 站點(diǎn)地圖型（Axure）

優(yōu)點(diǎn)：

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

缺點(diǎn)：

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

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

優(yōu)點(diǎn)：

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

缺點(diǎn)：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6 小結(jié)

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

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

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

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