寫交互說明容易忽略的幾件事

6 評論 12841 瀏覽 57 收藏 10 分鐘

上一篇文章寫了畫線框圖需要注意的一些問題,本篇想說說關(guān)于寫交互說明容易忽略的一些問題,供大家參考。

盡管我做交互工作已經(jīng)有幾年了,但還是時(shí)常會(huì)犯一些常見的錯(cuò)誤,相信這也是其他設(shè)計(jì)人員在工作中會(huì)出現(xiàn)的:比如交互說明寫的不夠清楚詳細(xì),導(dǎo)致和前端、開發(fā)人員的溝通成本增高、返工增多、工作效率下降等。為了解決這些問題,一方面需要加強(qiáng)溝通,另一方面還需要多站在前端、開發(fā)的角度考慮交互說明的表達(dá)形式,使大家的配合更默契。

關(guān)于交互說明的文章,網(wǎng)上也有不少,這篇文章不會(huì)講什么是交互說明文檔,也不會(huì)講應(yīng)該怎樣寫交互說明文檔,僅聚焦于工作中容易忽略的幾點(diǎn)問題以及個(gè)人的一些經(jīng)驗(yàn)總結(jié),希望對大家有所幫助。

一、盡量使用真實(shí)、符合邏輯的數(shù)據(jù)內(nèi)容

以前我做交互時(shí),更多的是考慮極端情況的展示(比如每個(gè)數(shù)據(jù)項(xiàng)里都寫盡量大一點(diǎn)的數(shù)值),而不注重?cái)?shù)據(jù)之間的邏輯對應(yīng)關(guān)系,殊不知這樣會(huì)給開發(fā)人員帶來很多困擾。比如下面這個(gè)圖,開發(fā)就會(huì)產(chǎn)生很多問題:網(wǎng)易價(jià)、優(yōu)惠金額、積分、小計(jì)之間是什么關(guān)系?優(yōu)惠金額和什么有關(guān)?而這些問題又和后臺(tái)算法緊密相關(guān)。

我之前還幫朋友做了一個(gè)票務(wù)產(chǎn)品的頁面設(shè)計(jì),當(dāng)時(shí)為了省事,界面上的文案都是隨便寫的,僅作示意用。雖然自己覺得很正常,但是對方看著心里很別扭:沒有這個(gè)票的名稱啊,這里是什么內(nèi)容呢?看不太明白……所以為了減少溝通成本,還是盡量使用真實(shí)、符合邏輯的數(shù)據(jù)內(nèi)容比較好。

二、不遺漏特殊狀態(tài)的描述

在寫交互說明的時(shí)候,總是更多的考慮正常情況的狀態(tài),卻經(jīng)常忽略了一些特殊狀態(tài)(用戶極少用到)。但對于前端和開發(fā)來說,各種狀態(tài)都是不能缺失的,否則會(huì)導(dǎo)致工作無法進(jìn)行。

ux2

比如上圖,看似操作邏輯很簡單:“勾選上面的人名后,下面會(huì)相應(yīng)的顯示對應(yīng)的信息”。但如果交互說明只寫這些,前端或開發(fā)就要瘋掉了,他們會(huì)冒出無數(shù)的問題,比如:常用被保險(xiǎn)人如何排序?最多顯示多少?超出一行怎么辦?名字有無字?jǐn)?shù)限制?名字超長(外國人、少數(shù)民族)怎么辦?勾選了3個(gè)人怎么辦?重名怎么辦?勾選人名后,在下方修改信息后怎么辦?…… 而這些,都是交互設(shè)計(jì)師需要提前考慮到,并寫在交互說明里的。交互設(shè)計(jì)師想的多一些,前端或開發(fā)就會(huì)省心很多。

三、避免過長的說明

還是上面這個(gè)例子,后來我們按照前端提的要求把所有交互說明都補(bǔ)充完了,內(nèi)容很可觀,寫了一整頁的標(biāo)注,密密麻麻的。但是在評審的時(shí)候還是被拍回去了,這是為什么呢?

我后來總結(jié)了一下,大概有以下幾點(diǎn)原因:

1. 需求或設(shè)計(jì)方案有問題,導(dǎo)致邏輯異常復(fù)雜

2. 這個(gè)方案開發(fā)成本是否很高,有沒有這個(gè)必要?(有些異常情況出現(xiàn)頻率極小,可以適當(dāng)舍棄,保證體驗(yàn)和開發(fā)成本之間的平衡性)

3. 如果需求和設(shè)計(jì)方案都沒問題,是否表述方式有問題?應(yīng)盡量避免文字堆砌(具體請看下面“避免流水賬式的說明”)

四、避免流水賬式的說明

A 流程圖代替文字說明

舉個(gè)例子,假如現(xiàn)在界面上有個(gè)“收藏”的鏈接,點(diǎn)擊它會(huì)觸發(fā)一系列操作,在交互說明上,我們該如何表述?

有些人可能會(huì)這樣表述:

點(diǎn)了“收藏”鏈接,判斷用戶是否登錄。如果沒登錄的話,就彈出登錄框,如果登錄的話,再判斷用戶是否首次收藏該商品,如果不是的話,彈出一個(gè)提示框(旁邊配個(gè)提示框的樣式);如果是的話,再判斷用戶是否首次收藏商品,如果不是的話,彈出收藏成功的提示,如果是的話……

還有些人可能會(huì)這樣表述:

ux3

很明顯后者更清晰,更有條理。當(dāng)然為了讓大家更容易理解,我找了個(gè)比較夸張的例子,一般情況下不會(huì)這么極端。我只是想說明一件事情:盡量用更有條理,更容易讓人理解的方式來展示操作邏輯關(guān)系,而不要用流水賬式的文字,這樣誰看了都會(huì)暈的。

B 表格羅列各種狀態(tài)

除了使用流程圖外,還可以用表格的形式把各種狀態(tài)圖羅列出來。

ux4

C 巧妙組織文字說明

用“if、else、case”等來組織說明文字也是我喜歡的方式,當(dāng)然開發(fā)更喜歡。比如下面的交互說明:

ux10

D 制作動(dòng)態(tài)效果

如果有動(dòng)畫效果的話最好制作出演示效果(axure等軟件可制作出很多逼真的動(dòng)態(tài)效果)。

五、關(guān)于重復(fù)出現(xiàn)的模塊

為了方便閱讀,很多設(shè)計(jì)師習(xí)慣把交互說明直接寫在原型上對應(yīng)的模塊旁邊。但這樣就會(huì)遇到一個(gè)問題:有些模塊會(huì)重復(fù)出現(xiàn)在多個(gè)頁面,關(guān)于該模塊的交互說明如果只寫一次,那么開發(fā)可能會(huì)找不到;如果每個(gè)頁面都復(fù)制一份,開發(fā)可能又會(huì)疑惑(前后是否有區(qū)別?)更要命的是,如果要修改的話,所有頁面都要跟著一起修改,工作量就會(huì)很大。

比如下面這個(gè)模塊,在購物車、個(gè)人中心等多個(gè)頁面都會(huì)出現(xiàn)。為了節(jié)省時(shí)間,提高效率,我把這個(gè)模塊獨(dú)立出來,并起名“迷你收藏夾”,然后在其它頁面上只留個(gè)空位就可以了。

ux5

比如購物車頁面下半部分要用到這個(gè)模塊,那么我就在這里留個(gè)空位。這樣我省事,開發(fā)也省事(很多模塊看上去是類似的,給常用模塊命名再組合,不容易出錯(cuò),一目了然)。

ux6這個(gè)例子雖然看上去比較白癡,但是想通過這個(gè)告訴大家的是:盡量用模塊化的思維方式來處理較復(fù)雜的問題,對提高工作效率很有幫助。

六、如原型有修改,不要口頭溝通,而要更新交互說明并告知大家

看了下面這個(gè)圖,相信大家就都明白了:

ux7

以上就是我總結(jié)的一些小問題。其實(shí)我認(rèn)為用什么方法不是最重要的,重要的是在合作的過程中,不僅把自己該做的做好,同時(shí)站在合作伙伴的角度上考慮問題,給大家提供更多的便利,才能使團(tuán)隊(duì)的效率越來越高,大家配合的越來越默契。

來源:PMTOO

 

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評論
評論請登錄
  1. 你是《破繭成蝶》的作者?

    來自北京 回復(fù)
  2. 好文,學(xué)習(xí)了!

    來自浙江 回復(fù)
  3. 來自上海 回復(fù)