交互說明，是交互設(shè)計(jì)師必不可少的‘寫作能力’，它能讓研發(fā)同事更加了解你的方案說明、交互想法。

但寫得不好，容易出現(xiàn)流水賬式、邏輯不清楚、文案臃腫等情況，給自己帶來額外的工作量，還影響著與研發(fā)同事的對接效率。

所以今天想總結(jié)個(gè)人對‘交互說明’這塊的知識，讓你和研發(fā)同事更加愉快地玩耍~

目錄：

01.技術(shù)型交互說明

02.只寫最重要的

03.它只是個(gè)‘黑板報(bào)’

04.按模塊來展示說明

05.建立交互說明庫

06.真實(shí)的數(shù)據(jù)展示

07.復(fù)雜說明另外展示

08.有更改時(shí)及時(shí)告知

09.好的心態(tài)

01.?技術(shù)型交互說明

傳統(tǒng)的交互說明，是根據(jù)自己的意識、主觀想法進(jìn)行描述，但由于每個(gè)人的文筆不同、思維方式不一樣，容易出現(xiàn)特別雜亂的說明，相關(guān)同事看了表示壓力山大想拔刀...

其實(shí)我們可以利用開發(fā)熟悉的技術(shù)術(shù)語、代碼邏輯來闡述交互說明，使開發(fā)對交互說明有更加直觀的理解，比如if else邏輯、switch case邏輯、數(shù)據(jù)庫標(biāo)識字段。

· if else ：

一種判斷邏輯，根據(jù)判斷條件正確與錯(cuò)誤來執(zhí)行對應(yīng)的操作。它可以更直觀地表達(dá)邏輯關(guān)系，更利于開發(fā)同事的理解。

比如用戶登錄的多邏輯說明，可以這么寫：

· switch case：

一種選擇邏輯，根據(jù)選擇項(xiàng)執(zhí)行對應(yīng)的操作。比如根據(jù)用戶投入鈔票的面值，決定可選擇的商品類型。

‘default’是容易疏忽的選項(xiàng)：匹配不存在時(shí)做的事情。

比如上面的例子，若是用戶投了1元，或者投了一張紙?jiān)趺崔k？

這是就需要‘default’的處理了。

· 用數(shù)據(jù)庫標(biāo)識字段

另外，一些‘動(dòng)態(tài)參數(shù)’用數(shù)據(jù)庫里的字段名稱來標(biāo)記也是一個(gè)不錯(cuò)的選擇。

比如：‘用戶’，在數(shù)據(jù)庫里的儲存字段是 #UserName#，用它來代替交互說明里的動(dòng)態(tài)參數(shù)，可以提升開發(fā)的理解效率。

怎么知道每個(gè)字段對應(yīng)數(shù)據(jù)庫的表達(dá)?

接口文檔：前端和后臺之間用來傳輸信息的文檔，那里既有數(shù)據(jù)庫的表達(dá)，也有對應(yīng)的中文描述。

注：以上例子來自-唐韌《產(chǎn)品經(jīng)理必懂的技術(shù)那點(diǎn)事兒》

02. 只寫最重要的

密密麻麻的文字說明，是早期交互設(shè)計(jì)師比較常見的‘毛病’。

一是列全所有說明，可以減少被diss‘考慮不周到’的可能；二是間接證明自己的專業(yè)能力。

但是！交互說明畢竟是要給人看的，堆積的文字誰看得下去？？

只會帶來額外的閱讀壓力和極高的理解成本，交互設(shè)計(jì)師修改起來也麻煩。

一倆個(gè)頁面還好，多個(gè)頁面都是這樣的說明，開發(fā)沒約你‘一起去爬山’就不錯(cuò)了。

圖片來自百度圖庫

所以個(gè)人建議，只針對有異常狀態(tài)、特殊交互、分支流程、關(guān)鍵節(jié)點(diǎn)等特殊地方進(jìn)行說明即可。

對于一些常識性、無異常點(diǎn)的地方就不用寫了。

無特別需交代的地方，寫了只會讓開發(fā)產(chǎn)生懷疑：這個(gè)地方是不是在特殊交互？

03.?它只是個(gè)‘黑板報(bào)’

不要幻想單憑一份交互說明，就能讓開發(fā)完全、正確明白你的想法，那幾乎是不可能的事。

在我看來，交互說明只是個(gè)和開發(fā)傳達(dá)內(nèi)容的黑板報(bào)，一個(gè)溝通工具。

圖片來自百度圖庫

想讓開發(fā)真正理解你的交互說明、方案邏輯等，還是得基于黑板報(bào)上的內(nèi)容，親自與開發(fā)溝通對齊。這樣才能確定方案的有效性、實(shí)現(xiàn)難度、是否有需要調(diào)整的內(nèi)容等，讓雙方的想法保持對齊。

前期與開發(fā)溝通清楚了，后面交互說明可以起到一個(gè)‘回顧、確定’的作用。

而對齊的方式可以是交互評審會、工位口述、電話溝通等。只要目的能讓開發(fā)理解你的交互稿，對齊形式可自主調(diào)整。

04. 按模塊來展示說明

這個(gè)‘模塊’有2層意思：

一是類似于‘內(nèi)容組件’：對于重復(fù)性強(qiáng)、出現(xiàn)頻率高的內(nèi)容，設(shè)置一個(gè)模板內(nèi)容及說明即可。

對于重復(fù)出現(xiàn)的地方，直接代替過去就行，能夠大幅度減少交互設(shè)計(jì)師的工作量，開發(fā)也方便理解。

二是分頁面/位置來展示：當(dāng)整體交互原型較多時(shí)，沒必要全都鋪在同一個(gè)頁面進(jìn)行展示說明，會顯得整體頁面很臃腫、瀏覽起來比較費(fèi)力（尤其是文件很大時(shí)）。

可以嘗試：單獨(dú)展示某個(gè)模塊、分支流程、場景等下的交互稿。小而聚集，內(nèi)容更精簡、理解更方便。

若各模塊/分支流程/場景中的交互稿存在一定的關(guān)聯(lián)性，可以先弄成一張總體性的‘概覽圖’，再去單獨(dú)展示。

讓開發(fā)知道整體方案之間的關(guān)系、又能了解各個(gè)細(xì)分方案里的交互說明。

05.建立交互說明庫

像一些常見、使用頻率較高的說明，完全可以建立起一個(gè)‘交互說明庫’。

一是方便自己及時(shí)調(diào)取，節(jié)省時(shí)間與精力。

二能統(tǒng)一你的交互說明風(fēng)格，減少開發(fā)的理解成本，也能提現(xiàn)出你的專業(yè)素養(yǎng)。

06. 真實(shí)的數(shù)據(jù)展示

想必這個(gè)大家都知道，隨便性地舉例、描述數(shù)據(jù)，會讓開發(fā)對內(nèi)容的真實(shí)性、有效性、邏輯關(guān)系等產(chǎn)生懷疑。

比如以下哪個(gè)‘發(fā)文數(shù)’，更容易讓人理解與‘啟用數(shù)、啟用率’之間的邏輯關(guān)系？

為了減少這種誤解，還是用最新、真實(shí)合理、上線數(shù)據(jù)等進(jìn)行描述。

如果在會議上讓leader、boss對這些數(shù)據(jù)/內(nèi)容提出了疑問，就丟大發(fā)了，也會讓同事質(zhì)疑你的基礎(chǔ)能力、責(zé)任心。

07.復(fù)雜說明另外展示

交互稿里總有一些比較復(fù)雜、難以文字來說明的想法，像是一些動(dòng)效、狀態(tài)、流程演示等。

對于這一些比較復(fù)雜的說明，完全可以用demo演示、視頻、gif圖等形式來演示你的想法，讓你的說明更加可觀性。

像一些按鈕或功能存在多種狀態(tài)時(shí)，也可以‘表格/列表’的方式進(jìn)行展示。

08.有更改及時(shí)告知

除了以上情況外，若交互原型有了調(diào)整（包括交互說明），一定要與團(tuán)隊(duì)成員告知！！并提示修改位置（在哪個(gè)頁面）。

否則產(chǎn)品、前端、后臺、測試等同事的相關(guān)想法、工作會停留在上個(gè)交互稿里。

別因?yàn)樾畔]對齊而造成了不良影響。就算改了一處小東西，也盡量和同步一下。

09.好的心態(tài)

最后想說一句，沒有人百分百、完完全全顧慮到所有細(xì)節(jié)和場景，即使你完全地走查了一遍甚至好幾遍...

但由于不同角色的職業(yè)視角、預(yù)覽目的、經(jīng)驗(yàn)想法等都會提出新的疑問、挑戰(zhàn)你的方案說明。

這是很正常的事~

更何況，在方案沒對齊前，交互稿（包括交互說明）上都存在太多的未知性、待優(yōu)化點(diǎn)。

即使當(dāng)前階段確定了所有的細(xì)節(jié)與場景，隨著方案時(shí)間的推進(jìn)，后續(xù)總有新的想法、遺漏點(diǎn)、優(yōu)化點(diǎn)涌現(xiàn)出來，那些我們覺得的‘完全OK的方案說明’，也都變成了‘過去式’...

我們要做的，必須是多聽聽多方視角的聲音，并尊重、虛心接受他人的意見，而不是抱怨自己為啥考慮不周全、停留在原地鉆牛角尖。

↘好文推薦：

產(chǎn)品問答?|?入職一家公司，你的選擇依據(jù)是什么？
TO B 產(chǎn)品經(jīng)理：如何推動(dòng)產(chǎn)品商業(yè)化？

數(shù)據(jù)產(chǎn)品經(jīng)理：埋點(diǎn)的設(shè)計(jì)、管理與應(yīng)用

點(diǎn)個(gè)“在看”吧

總結(jié)

以上是生活随笔為你收集整理的这样写交互说明，开发不会约你去爬山~的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。