所謂「交互」，全稱是「人機(jī)交互」，意思是人和機(jī)器的交流互動。交互設(shè)計，就是在 UI 方案之前，先構(gòu)思用戶如何操作機(jī)器（App/網(wǎng)站/軟件/硬件……），又如何從機(jī)器獲取信息反饋的。

通常來說，交互設(shè)計是 UI 設(shè)計之前的步驟。不同公司分工不同，可能有專職交互設(shè)計師，也可能交給 UX 設(shè)計師，還可能由產(chǎn)品經(jīng)理負(fù)責(zé)。

交互設(shè)計交付的東西，有兩種，一是交互方案，二是交互文檔。

這兩個東西別看都叫交互 XX，但截然不同。交互方案是在設(shè)計階段，用來確定核心交互流程和規(guī)則的。而交互文檔是設(shè)計階段結(jié)束后的落地階段，用來給開發(fā)和測試確定完整交互細(xì)節(jié)的。

交互方案與 UI 方案類似，但通常是沒有顏色的線框圖，旁邊標(biāo)注了很多規(guī)則說明和狀態(tài)展示。

交互文檔與需求文檔類似，但是會貼很多方案圖，然后用大量文字寫清楚各種規(guī)則和特殊狀況的處理細(xì)節(jié)。

我自己在大廠做過很多年的交互設(shè)計師，又是人機(jī)交互碩士科班出身，對這個領(lǐng)域，我還是比較有經(jīng)驗(yàn)的。

然而我很少講交互文檔。哪怕有好幾個人來問我怎么做交互文檔，我都說暫不提供相關(guān)課程，為什么呢？

主要原因是，我真不太建議大家花費(fèi)太多心思在交互文檔上。尤其我們學(xué)習(xí)社叫做「體驗(yàn)設(shè)計學(xué)習(xí)社」，里面大部分人是設(shè)計師。我是尤其不太建議設(shè)計師死磕交互文檔的。

至于原因，就是我接下來要講的了。

一、領(lǐng)導(dǎo)不會關(guān)注交互文檔

因?yàn)榻换シ桨笐?yīng)該已經(jīng)把核心的交互流程和規(guī)則確定下來了，遺漏的細(xì)節(jié)，才會需要額外寫到交互文檔上。

領(lǐng)導(dǎo)都是大忙人，能參加交互設(shè)計評審，就已經(jīng)很用心了。怎么可能再去看那密密麻麻的交互文檔呢？

所以，交互文檔這個東西，或者大部分落地階段的過程，只要沒出大問題領(lǐng)導(dǎo)都不會太關(guān)注。

所以交互文檔這個東西，你做得再好，也對績效評定沒有直接影響。除非交互文檔寫錯了，或者寫得不詳細(xì)你又拒絕補(bǔ)充解釋，影響到項(xiàng)目進(jìn)度了，以至于被投訴到領(lǐng)導(dǎo)面前。

雖然這么說比較功利，但大部分人上班不就是為了賺錢？而決定自己能賺多少錢的就是領(lǐng)導(dǎo)。我們把力氣多用在領(lǐng)導(dǎo)關(guān)心的事，少用到領(lǐng)導(dǎo)不關(guān)心的事，才是性價比更高的生存之道，不是嗎？

二、開發(fā)也未必有耐心仔細(xì)看文檔

說實(shí)在的，沒人喜歡看說明書吧？但是看地圖，還是有點(diǎn)意思。

交互文檔就好比說明書，而交互方案就好比地圖。

對開發(fā)來說，也是覺得看方案比看文檔輕松。如果方案能看清楚，巴不得不要看文檔。

而且那么多密密麻麻的文字，語言一點(diǎn)也不風(fēng)趣幽默。這種文檔看起來很累，很難確保沒有遺漏，或者完全能理解。說不定到頭來還是要找本人來問。

所以，寫得過于細(xì)致也是沒必要。

三、把設(shè)計規(guī)范和組件化做好，交互文檔就不那么重要了

之所以需要交互文檔，就是因?yàn)楹芏嗉?xì)節(jié)的交互規(guī)則，在方案上展示不全。

但是如果這個項(xiàng)目本身就已經(jīng)有一套完整的設(shè)計規(guī)范，常用組件都整理得很好呢？

那么絕大部分交互都只需要復(fù)用規(guī)范和組件即可，需要創(chuàng)新的地方很少。

而復(fù)用規(guī)范和組件的部分，并不需要過多的文檔說明，反正開發(fā)也是去找老代碼。

而創(chuàng)新的部分，因?yàn)檎急容^少，交互方案就已經(jīng)可以展示得差不多了。

這樣一來，交互文檔是不是就可有可無了呢？

順便說一句，支撐我做設(shè)計規(guī)范和整理組件的主要動力之一，就是為了以后不用事無巨細(xì)地寫交互規(guī)則了。

四、對設(shè)計師來說，不背 KPI 就不用對落地負(fù)責(zé)

如果設(shè)計師背 KPI，一旦方案沒通過用戶測試，或者滿意度評分低了，就影響績效。那么設(shè)計師肯定有動力把整個落地過程好好推進(jìn)，生怕自己被開發(fā)坑了。

可問題是，大部分設(shè)計師不背 KPI 啊。那么只要方案通過評審，得到了領(lǐng)導(dǎo)的認(rèn)可，后續(xù)的落地就跟設(shè)計師關(guān)系不大了。

至于開發(fā)沒理解交互細(xì)節(jié)，落地沒做好……那都是開發(fā)和產(chǎn)品經(jīng)理的責(zé)任——他們才是負(fù)責(zé)落地環(huán)節(jié)的。

相反，如果設(shè)計師把大量精力用在落地上，追著開發(fā)事無巨細(xì)地把方案細(xì)節(jié)做出來，會怎樣？那設(shè)計師就沒時間好好打磨方案了，交付一推再推，領(lǐng)導(dǎo)對方案也不滿意，該怎么辦呢？這就是設(shè)計師本人對鍋，甩不掉了。

所以，我是能理解產(chǎn)品經(jīng)理在交互文檔上多費(fèi)心思——畢竟落地效果可能影響到個人KPI，需要多些責(zé)任心。但是對設(shè)計師來說，就沒這個必要性了。

除非領(lǐng)導(dǎo)指明讓設(shè)計師做交互文檔，推都推不掉，那就沒辦法了。否則，我還真不建議設(shè)計師多費(fèi)精力去做交互文檔。

總結(jié)一下

建議大家好好打磨交互方案，把最核心的交互流程和規(guī)則，都盡量在方案上展示清楚了。

對于那些不太重要，且設(shè)計規(guī)范和常用組件覆蓋不到的交互細(xì)節(jié)，才寫到交互文檔上。

而且，不建議設(shè)計師主動攬交互文檔的活，因?yàn)檫@事的直接受益者是看文檔的開發(fā)和背 KPI 的產(chǎn)品經(jīng)理，對設(shè)計師來說沒有直接好處。

以上是我的經(jīng)驗(yàn)之談，如果你有其它觀點(diǎn)，歡迎友好交流。

作者：體驗(yàn)進(jìn)階