B端UI設(shè)計(jì)師的交互文檔應(yīng)該怎么寫(xiě)?
交互文檔該怎么寫(xiě)呢?這個(gè)問(wèn)題不只是新手在問(wèn),在工作中要負(fù)責(zé)交互問(wèn)題的產(chǎn)品經(jīng)理、設(shè)計(jì)師,都在糾結(jié)這個(gè)問(wèn)題。本篇文章就從基本認(rèn)識(shí)、工具選擇和制作過(guò)程這三部分內(nèi)容來(lái)為大家講解交互文檔要怎么寫(xiě),快來(lái)看看吧。
今天要分享的,是后臺(tái)和社群里幾乎每天都有人問(wèn)的交互文檔該怎么寫(xiě)的問(wèn)題。不只是想要往交互設(shè)計(jì)師方向發(fā)展的新手,還有工作中要負(fù)責(zé)交互問(wèn)題的產(chǎn)品經(jīng)理、設(shè)計(jì)師,都對(duì)它存在大量的疑問(wèn)。
所以我們?cè)诮裉爝@篇分享里完成一次深入的掃盲。
一、交互文檔的基本認(rèn)識(shí)
1. 交互文檔是什么
交互文檔,是一份用來(lái)解釋項(xiàng)目交互方式、內(nèi)容、規(guī)則的說(shuō)明文檔,也叫 DRD ( Design Requirement Document )。
在過(guò)去的分享中,我們有解釋過(guò),B端項(xiàng)目會(huì)包含大量的交互內(nèi)容,需要前期繪制交互原型來(lái)展示和確認(rèn)交互方案。
如果是比較簡(jiǎn)單的小型項(xiàng)目,或成熟產(chǎn)品的小迭代,那么這樣的連線圖確實(shí)就足以表達(dá)交互的意圖和方案了,寫(xiě)太多注釋文字反而會(huì)畫(huà)蛇添足提高觀看者的認(rèn)知成本。
但是,如果項(xiàng)目和展示的流程內(nèi)容,邏輯非常復(fù)雜,包含非常多的選項(xiàng)和狀態(tài),那么單靠原型和連線是絕對(duì)不夠的,添加更多的圖文說(shuō)明就變得非常有必要了。
同時(shí)在團(tuán)隊(duì)協(xié)作場(chǎng)景中,就需要將這些內(nèi)容制作成一份規(guī)范的 “文檔”,用來(lái)進(jìn)行統(tǒng)一的展示、備份、歸檔。
所以做交互光靠畫(huà)交互原型是不夠的,“文檔” 就成為必要的輸出成果。
2. 它和產(chǎn)品文檔的區(qū)別
在產(chǎn)品側(cè)(非開(kāi)發(fā)),文檔就有好幾類:
- 商業(yè)需求文檔:BRD,Business Requirement Document
- 市場(chǎng)需求文檔:MRD,Market Requirement Document
- 產(chǎn)品需求文檔:PRD,Product Requirement Document
- 交互說(shuō)明文檔:DRD,Design Requirement Document
- 設(shè)計(jì)規(guī)范文檔:DGD,Design Guidline Document
BRD 和 MRD 是一個(gè)產(chǎn)品經(jīng)理行業(yè)內(nèi)部也在反復(fù)科普討論的東西,和我們沒(méi)多大關(guān)系可以暫時(shí)忽略。設(shè)計(jì)規(guī)范文檔 DGD 大家應(yīng)該也有概念,比較容易辨識(shí),也不需要在這里強(qiáng)調(diào)。
而產(chǎn)品需求文檔 PRD,是和交互文檔最撞臉的文檔類型。它們的文檔規(guī)格、樣式幾乎一致,還包含大量界限模糊、相互交叉的內(nèi)容范疇,會(huì)對(duì)新手的理解造成很大的不便。
要理解產(chǎn)品文檔和交互文檔的核心差異,就得從他們各自的工作職能說(shuō)起,產(chǎn)品經(jīng)理的主要產(chǎn)出是解釋產(chǎn)品要做的功能和邏輯,所有的原型和連線的目標(biāo)都是為了解釋功能本身。
部分產(chǎn)品經(jīng)理會(huì) “順帶” 在這個(gè)基礎(chǔ)上增加交互的元素,以及相關(guān)的說(shuō)明。這恰恰是問(wèn)題的關(guān)鍵所在,因?yàn)楫a(chǎn)品經(jīng)理制作產(chǎn)品原型的過(guò)程是可以覆蓋一部分交互信息的,所以很多設(shè)計(jì)師也天真的認(rèn)為交互內(nèi)容是應(yīng)該由產(chǎn)品來(lái)出的。
這當(dāng)中一定要關(guān)注里面的 “順帶”,因?yàn)橐环萦行У?PRD 主旨一定不是以交互為核心的,在面對(duì)需要大量圖例、連線、方案、解釋的交互問(wèn)題下面,產(chǎn)品經(jīng)理往往選擇直接跳過(guò),只把功能描述清楚,剩下的就交給交互設(shè)計(jì)師還是 UI 設(shè)計(jì)師來(lái)完成具體的交互方案。
所以,交互文檔就是在產(chǎn)品文檔的基礎(chǔ)上,進(jìn)行交互內(nèi)容的補(bǔ)充,專注于解釋項(xiàng)目的交互內(nèi)容,讓設(shè)計(jì)師和前端開(kāi)發(fā)可以更直觀得理解后續(xù)的工作內(nèi)容。
來(lái)自 UEDART 的付費(fèi)文檔,案例地址:http://vip.uedart.com/interactive.html
交互文檔和產(chǎn)品文檔是相互獨(dú)立和補(bǔ)充的,當(dāng)產(chǎn)品文檔無(wú)法完成對(duì)產(chǎn)品交互的有效解釋時(shí),我們就應(yīng)該選擇輸出獨(dú)立的交互文檔,來(lái)提升項(xiàng)目協(xié)作的效率。
二、交互文檔的工具選擇
1. 主流的交互文檔工具說(shuō)明
主流的交互文檔輸出有三種方式:
- Axure/墨刀 導(dǎo)出
- 一般文檔制作
- 線上 Wiki 記錄
Axure 和墨刀是用來(lái)制作產(chǎn)品原型的軟件工具,也是目前在產(chǎn)品經(jīng)理、交互設(shè)計(jì)行業(yè)中應(yīng)用最廣泛的原型工具。
它的主要優(yōu)勢(shì),在于可以比較方便的制作可交互的組件、連線、導(dǎo)出。
當(dāng)然,光制作原型圖并不能叫交互文檔,它們還提供了比較全面的內(nèi)容標(biāo)注、文本記錄、圖形繪制的功能。
這就可以讓我們完成原型繪制以后,結(jié)合頁(yè)面結(jié)構(gòu)的管理,添加交互文檔所需的其它信息,并最終輸出文件。
而在一些比較傳統(tǒng)的行業(yè)或外包領(lǐng)域,使用的記錄文檔往往要使用 Word 或 PPT(方便開(kāi)會(huì)演示或要打?。_@就要在原型完成以后,導(dǎo)出原型圖例,并使用這些文檔軟件進(jìn)行文字的記錄和連線。
受限于 Word、PPT 的布局限制(強(qiáng)行分頁(yè)),使用它們做交互文檔是非常難受的,并且這些文檔需要保存到本地,存在各種文檔版本管理的問(wèn)題。
所以還有另一部分也希望使用普通文檔格式記錄,并滿足云端同步、備份、版本管理的團(tuán)隊(duì),就會(huì)使用 Wiki 類的工具來(lái)制作交互文檔。如語(yǔ)雀、飛書(shū)、Confluence、Notion 等工具。
如果只是一些比較小的項(xiàng)目迭代、一次性使用的交互文檔,使用前兩種方法都可以勝任。而真正大型、系統(tǒng)性的交互文檔,往往都使用團(tuán)隊(duì)內(nèi)部的 Wiki 進(jìn)行創(chuàng)建和管理。和設(shè)計(jì)稿不同,這些使用了內(nèi)部賬號(hào)或需要內(nèi)網(wǎng)訪問(wèn)的文檔資料,是不會(huì)沒(méi)事發(fā)到網(wǎng)上來(lái)分享的,這也是在網(wǎng)上找不到完整交互文檔的主要原因。
2. B端設(shè)計(jì)師的交互文檔工具建議
和你們網(wǎng)上可以找到的大多數(shù)交互設(shè)計(jì)干貨不同,我即不推薦你們使用 Axure/墨刀 來(lái)畫(huà)原型,也不推薦用它們或普通文檔、Wiki 的形式來(lái)輸出交互文檔。因?yàn)椋?/p>
—— 太低效了!
產(chǎn)品經(jīng)理和交互設(shè)計(jì)師的主要產(chǎn)出物就是文檔,自然可以耗費(fèi)比較多的精力和時(shí)間去制作原型和編寫(xiě)內(nèi)容。而 UI 設(shè)計(jì)師的主要工作肯定是最終的視覺(jué)界面和交付,所以用最復(fù)雜的方法去制作交互文檔,顯然是不合理的。
同時(shí)還要提一句,Axure/墨刀 等軟件用來(lái)制作一般的線框圖原型,效率實(shí)在是太低了。且絕大多數(shù)情況下的頁(yè)面跳轉(zhuǎn)、交互都是可以忽略不做的。而且隨頁(yè)面增加,它的左側(cè)導(dǎo)航層級(jí)、數(shù)量會(huì)非常龐大,導(dǎo)致查找和瀏覽的效率進(jìn)一步降低。
我始終都建議直接使用你們正在用的云端 UI 設(shè)計(jì)軟件直接繪制產(chǎn)品、交互原型并輸出文檔,如即時(shí)設(shè)計(jì)或 Figma。原因包含:
- 速度快:能用 Axure 五分之一的時(shí)間完成所有原型繪制
- 可復(fù)用:做好的原型方便復(fù)用,而且可以直接在原型上完成后續(xù)設(shè)計(jì)
- 交互性:對(duì)于表達(dá)交互流程所需的基礎(chǔ)跳轉(zhuǎn)和動(dòng)效都能滿足
- 更自由:一些需要復(fù)雜圖文結(jié)合的說(shuō)明方式不再受到普通文檔布局限制
比如下面這樣的原型案例,就可以通過(guò)一個(gè)簡(jiǎn)單的鏈接快速分享出去,或者添加團(tuán)隊(duì)成員自由查看。
在我過(guò)去長(zhǎng)期的實(shí)踐體會(huì)中,這種方式是優(yōu)勢(shì)最明顯、效率最高、最易懂,也符合 UI 設(shè)計(jì)師工作需要的。如果項(xiàng)目中有其它因素要求,你們也可以選擇前面的方式輸出。
任何文檔的目標(biāo)都是為了書(shū)面記錄和讓看的人更容易理解我們要表達(dá)的信息,不要被固定的方法局限住,要努力去探索適合團(tuán)隊(duì)當(dāng)前場(chǎng)景的方式。
三、交互文檔的制作過(guò)程
1. 文檔框架結(jié)構(gòu)制定
前面把基本的信息聊完了,這里就來(lái)具體講講交互文檔應(yīng)該如何進(jìn)行輸出。
當(dāng)然,輸出交互文檔前需要先理解交互是什么,交互設(shè)計(jì)的具體設(shè)計(jì)內(nèi)容和步驟。交互文檔是對(duì)你已經(jīng)設(shè)計(jì)出來(lái)的方案的書(shū)面記錄,你不能在對(duì)交互一無(wú)所知的情況下強(qiáng)行編寫(xiě)文檔。
交互文檔制作首先要確認(rèn)文檔的記錄內(nèi)容和文檔結(jié)構(gòu)。
記錄內(nèi)容指的是你在該文檔準(zhǔn)備放哪些交互內(nèi)容進(jìn)去,并不是每次項(xiàng)目設(shè)計(jì)都要把項(xiàng)目所有頁(yè)面和流程交互都重做一遍。
比如一次中等規(guī)模的迭代,新增幾個(gè)通用的列表頁(yè)面,調(diào)整了一些細(xì)節(jié)字段,增加了一個(gè)功能流程。那么文檔重點(diǎn)記錄內(nèi)容肯定就是流程而不是所有頁(yè)面。畢竟通用的列表頁(yè)和細(xì)節(jié)更改,在產(chǎn)品需求評(píng)審階段就可以完整的解釋,而功能流程則不行。
如果是全新的項(xiàng)目,包含數(shù)十上百個(gè)頁(yè)面。把所有流程、頁(yè)面的交互內(nèi)容全部表現(xiàn)出來(lái)的工作量是頂不住的,在繪制原型的過(guò)程中,你就會(huì)發(fā)現(xiàn)有大量的重復(fù)頁(yè)面、流程和交互。所以制作文檔就要有目的性的對(duì)重復(fù)的內(nèi)容進(jìn)行合并,以及只保留重要的頁(yè)面和流程。
具體該放什么要考慮項(xiàng)目的實(shí)際情況,需要設(shè)計(jì)師自己評(píng)估。除此以外,標(biāo)準(zhǔn)的交互文檔里面會(huì)包含背景介紹、編輯日志、文字圖例、業(yè)務(wù)流程、名詞解釋、頁(yè)面結(jié)構(gòu)等等。
這些 “文縐縐” 的細(xì)節(jié),并不是必備的,你可以根據(jù)當(dāng)前場(chǎng)景自己決定需要加哪些。比如項(xiàng)目、業(yè)務(wù)背景前面的產(chǎn)品需求已經(jīng)講清楚了,業(yè)務(wù)流程、名詞解釋團(tuán)隊(duì)成員也都了如指掌的時(shí)候,那么這些頁(yè)面模塊就完全沒(méi)有放的必要。
并且,基于前面對(duì)放置內(nèi)容的考慮,結(jié)構(gòu)的順序并不一定要類似下方案例,完全按照產(chǎn)品的導(dǎo)航目錄來(lái)走。
所以,根據(jù)一個(gè)中等規(guī)模的迭代項(xiàng)目,我會(huì)制定一個(gè)這樣的一級(jí)文檔結(jié)構(gòu):
- 基本信息:項(xiàng)目的簡(jiǎn)單信息,快速目錄,參與人信息等
- 基本組件:涉及的相關(guān)組件展示和交互規(guī)則說(shuō)明
- 原型一覽:本次迭代涉及的所有頁(yè)面原型和連線一覽
- 流程介紹1:流程1的所有頁(yè)面、狀態(tài)、說(shuō)明展示
- 流程介紹2:流程2的所有頁(yè)面、狀態(tài)、說(shuō)明展示
- 流程介紹3:流程3的所有頁(yè)面、狀態(tài)、說(shuō)明展示
每個(gè)1級(jí)文檔結(jié)構(gòu)對(duì)應(yīng) UI 軟件中的 Page 目錄,力求所需的 Page 數(shù)量越少越好,而不是像 Axure 的做法一樣密密麻麻的。
結(jié)構(gòu)可以根據(jù)復(fù)雜程度做進(jìn)一步的細(xì)分,它像寫(xiě)文章的大綱一樣,幫助我們提前規(guī)劃好后續(xù)完成文檔所需的內(nèi)容和工作量。
2. 關(guān)于連線和標(biāo)注信息
有了結(jié)構(gòu),就要在對(duì)應(yīng)的 Page 中填充內(nèi)容了。其中一般的文字介紹、流程圖、思維導(dǎo)圖,只要正常輸入或?qū)?dǎo)出的圖例黏貼進(jìn)來(lái)就可以。
而針對(duì)具體的交互內(nèi)容,流程解釋上,則重點(diǎn)處理連線和標(biāo)注說(shuō)明。比如下面是我自己在課程演示中的一個(gè)簡(jiǎn)單的交互流程演示案例。
在 UI 軟件中,制作連線其實(shí)是很簡(jiǎn)單的事情,只要畫(huà)出一個(gè)直線,再設(shè)置箭頭和尾部圖形、描邊色彩和粗細(xì)即可。
然后,將該線段的圖層放置在畫(huà)布之外,起點(diǎn)放置在觸發(fā)交互的區(qū)域之中,終點(diǎn)尖頭則緊貼目標(biāo)畫(huà)布的邊緣(不用特意延伸進(jìn)畫(huà)布內(nèi))。如果使用水平、垂直的方式連接兩個(gè)畫(huà)布,那就可以雙擊進(jìn)去添加錨點(diǎn)制作 90 度的折角。
連線的應(yīng)用是非常簡(jiǎn)單的操作,不要舍近求遠(yuǎn)通過(guò)插件或是其它的一些功能來(lái)實(shí)現(xiàn)。而除此之外,我在文檔中添加的解釋性文本主要有兩種,交互事件和交互規(guī)則。
交互事件代表了連線的兩個(gè)頁(yè)面是如何被觸發(fā)跳轉(zhuǎn)的,所以我會(huì)在線段中帖一個(gè)文字卡片,解釋觸發(fā)的條件和交互操作是什么。
然后,就是頁(yè)面或流程中的交互細(xì)則,包含兩個(gè)部分,數(shù)字標(biāo)簽和對(duì)應(yīng)文字注釋。它們都是用 Auto layout 可以快速制作出來(lái)的組件,每次要做備注的時(shí)候,只要復(fù)制標(biāo)簽到頁(yè)面上,設(shè)置對(duì)應(yīng)的數(shù)值,再將右側(cè)的文字卡片復(fù)制到頁(yè)面旁邊,再加上對(duì)應(yīng)的數(shù)字、內(nèi)容信息即可。
在設(shè)計(jì)軟件中,畫(huà)布的自由度極高,你想要怎么備注和添加內(nèi)容都沒(méi)關(guān)系,只要在內(nèi)容翔實(shí)的基礎(chǔ)上保證 —— 團(tuán)隊(duì)成員能看懂,就是一份優(yōu)秀的交互文檔。多在繪制過(guò)程中和同事溝通,優(yōu)化展示的做法,可以避免很多會(huì)出現(xiàn)的問(wèn)題,進(jìn)一步加速我們的制作效率。
3. 文檔的團(tuán)隊(duì)協(xié)作應(yīng)用
將文檔全部做完以后,最終就是關(guān)于交付和協(xié)作的問(wèn)題了。
既然我們使用線上的 UI 軟件來(lái)完成交互文檔的制作,那么文件設(shè)置公開(kāi)訪問(wèn)權(quán)限,再分享鏈接自然是最簡(jiǎn)單的辦法。
但每次項(xiàng)目分享個(gè)網(wǎng)頁(yè)鏈接,或者并行有好幾個(gè)項(xiàng)目,需要其它成員自己去收藏網(wǎng)址,也是挺麻煩的。所以盡量充分應(yīng)用軟件中的團(tuán)隊(duì)協(xié)作功能,通過(guò)創(chuàng)建一個(gè)團(tuán)隊(duì),添加成員,讓他們自行查看當(dāng)前文件目錄中的交互文檔。
查看過(guò)程中,團(tuán)隊(duì)其它成員可以通過(guò)評(píng)論的功能對(duì)交互內(nèi)容進(jìn)行糾錯(cuò)、提問(wèn)、建議,方便我們進(jìn)行優(yōu)化改進(jìn)。
通過(guò)這種簡(jiǎn)單高效的文檔協(xié)作模式,我們可以非??斓猛瓿烧w交互內(nèi)容的定稿,并開(kāi)始后續(xù)的工作。
再回到前面的話題,我們是 UI 設(shè)計(jì)師,不是全職交互設(shè)計(jì)。原型文檔輸出完了,下一步可是要做視覺(jué)界面的,所以交互文檔就可以不用管了嘛?
交互文檔的最佳狀態(tài)是 —— 應(yīng)用最終界面圖例解釋交互內(nèi)容。
也就是當(dāng)我們把所有頁(yè)面內(nèi)容設(shè)計(jì)完成后,強(qiáng)烈建議將界面的展示和交互文檔進(jìn)行整合。除了前端和產(chǎn)品可以看到最終的交互落地效果外(有時(shí)候最終設(shè)計(jì)和前面的交互不一致),還可以直接通過(guò)這個(gè)文檔查看界面數(shù)值標(biāo)注,而不用往返于交互和設(shè)計(jì)文檔來(lái)回切換,這才能讓文檔作用最大化。
四、結(jié)尾
以上就是關(guān)于交互文檔的相關(guān)解釋,下一篇,我們會(huì)聚焦在和表單有關(guān)的交互干貨分享。
我們下篇再見(jiàn)。
作者:酸梅干超人;公眾號(hào):超人的電話亭(ID:Superman_Call)
本文由 @超人的電話亭 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來(lái)自Unsplash ,基于 CC0 協(xié)議。
該文觀點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)。
為啥 我打開(kāi)這圖片 沒(méi)有一張可以看清楚的呢
做產(chǎn)品7年了,從來(lái)沒(méi)有交互文檔,只有原型
文檔格式,每個(gè)團(tuán)隊(duì)之間都有差異,有的是作者這種直接在原型里面標(biāo)注,有的是在word文檔左圖右文,也有大廠里面,按照需求管理系統(tǒng),一項(xiàng)一項(xiàng)填寫(xiě)的…不管哪一種,只要能說(shuō)明你干的啥事,怎么干的,團(tuán)隊(duì)能高效溝通即可。
嗯學(xué)到了,工欲善其事,必先利其器。產(chǎn)品經(jīng)理在這方面需要足夠熟練。