不想被開發約爬山?你需要先寫好交互說明
編輯導讀:交互說明文檔,是交互設計師的輸出物中必不可少的一項,它關系著設計方案能否最大程度的被實現。本文作者依據工作中項目實踐的所思所想,并結合案例等分享了寫交互說明時需要注意的一些問題,希望對你有用。
交互說明,是交互設計師必不可少的‘寫作能力’,它能讓研發同事更加了解你的方案說明、交互想法。
但寫得不好,容易出現流水賬式、邏輯不清楚、文案臃腫等情況,給自己帶來額外的工作量,還影響著與研發同事的對接效率。
所以今天想總結個人對‘交互說明’這塊的知識,讓你和研發同事更加愉快地玩耍~
目錄:
- 技術型交互說明
- 只寫最重要的
- 它只是個‘黑板報’
- 按模塊來展示說明
- 建立交互說明庫
- 真實的數據展示
- 復雜說明另外展示
- 有更改時及時告知
- 好的心態
01 技術型交互說明
傳統的交互說明,是根據自己的意識、主觀想法進行描述,但由于每個人的文筆不同、思維方式不一樣,容易出現特別雜亂的說明,相關同事看了表示壓力山大想拔刀…
其實我們可以利用開發熟悉的技術術語、代碼邏輯來闡述交互說明,使開發對交互說明有更加直觀的理解,比如if else邏輯、switch case邏輯、數據庫標識字段。
1. if else
一種判斷邏輯,根據判斷條件正確與錯誤來執行對應的操作。它可以更直觀地表達邏輯關系,更利于開發同事的理解。
比如用戶登錄的多邏輯說明,可以這么寫:
2. switch case
一種選擇邏輯,根據選擇項執行對應的操作。比如根據用戶投入鈔票的面值,決定可選擇的商品類型。
‘default’是容易疏忽的選項:匹配不存在時做的事情。
比如上面的例子,若是用戶投了1元,或者投了一張紙怎么辦?
這是就需要‘default’的處理了。
3. 用數據庫標識字段
另外,一些‘動態參數’用數據庫里的字段名稱來標記也是一個不錯的選擇。
比如:‘用戶’,在數據庫里的儲存字段是 #UserName#,用它來代替交互說明里的動態參數,可以提升開發的理解效率。
怎么知道每個字段對應數據庫的表達?
接口文檔:前端和后臺之間用來傳輸信息的文檔,那里既有數據庫的表達,也有對應的中文描述。
注:以上例子來自-唐韌《產品經理必懂的技術那點事兒》
02 只寫最重要的
密密麻麻的文字說明,是早期交互設計師比較常見的‘毛病’。
一是列全所有說明,可以減少被diss‘考慮不周到’的可能;二是間接證明自己的專業能力。
但是!交互說明畢竟是要給人看的,堆積的文字誰看得下去??
只會帶來額外的閱讀壓力和極高的理解成本,交互設計師修改起來也麻煩。
一倆個頁面還好,多個頁面都是這樣的說明,開發沒約你‘一起去爬山’就不錯了。
所以個人建議,只針對有異常狀態、特殊交互、分支流程、關鍵節點等特殊地方進行說明即可。
對于一些常識性、無異常點的地方就不用寫了。
無特別需交代的地方,寫了只會讓開發產生懷疑:這個地方是不是在特殊交互?
03 它只是個‘黑板報’
不要幻想單憑一份交互說明,就能讓開發完全、正確明白你的想法,那幾乎是不可能的事。
在我看來,交互說明只是個和開發傳達內容的黑板報,一個溝通工具。
想讓開發真正理解你的交互說明、方案邏輯等,還是得基于黑板報上的內容,親自與開發溝通對齊。這樣才能確定方案的有效性、實現難度、是否有需要調整的內容等,讓雙方的想法保持對齊。
前期與開發溝通清楚了,后面交互說明可以起到一個‘回顧、確定’的作用。
而對齊的方式可以是交互評審會、工位口述、電話溝通等。只要目的能讓開發理解你的交互稿,對齊形式可自主調整。
04 按模塊來展示說明
這個‘模塊’有2層意思:
一是類似于‘內容組件’:對于重復性強、出現頻率高的內容,設置一個模板內容及說明即可。
對于重復出現的地方,直接代替過去就行,能夠大幅度減少交互設計師的工作量,開發也方便理解。
二是分頁面/位置來展示:當整體交互原型較多時,沒必要全都鋪在同一個頁面進行展示說明,會顯得整體頁面很臃腫、瀏覽起來比較費力(尤其是文件很大時)。
可以嘗試:單獨展示某個模塊、分支流程、場景等下的交互稿。小而聚集,內容更精簡、理解更方便。
若各模塊/分支流程/場景中的交互稿存在一定的關聯性,可以先弄成一張總體性的‘概覽圖’,再去單獨展示。
讓開發知道整體方案之間的關系、又能了解各個細分方案里的交互說明。
05 建立交互說明庫
像一些常見、使用頻率較高的說明,完全可以建立起一個‘交互說明庫’。
一是方便自己及時調取,節省時間與精力。
二能統一你的交互說明風格,減少開發的理解成本,也能提現出你的專業素養。
06 真實的數據展示
想必這個大家都知道,隨便性地舉例、描述數據,會讓開發對內容的真實性、有效性、邏輯關系等產生懷疑。
比如以下哪個‘發文數’,更容易讓人理解與‘啟用數、啟用率’之間的邏輯關系?
為了減少這種誤解,還是用最新、真實合理、上線數據等進行描述。
如果在會議上讓leader、boss對這些數據/內容提出了疑問,就丟大發了,也會讓同事質疑你的基礎能力、責任心。
07 復雜說明另外展示
交互稿里總有一些比較復雜、難以文字來說明的想法,像是一些動效、狀態、流程演示等。
對于這一些比較復雜的說明,完全可以用demo演示、視頻、gif圖等形式來演示你的想法,讓你的說明更加可觀性。
像一些按鈕或功能存在多種狀態時,也可以‘表格/列表’的方式進行展示。
08 有更改及時告知
除了以上情況外,若交互原型有了調整(包括交互說明),一定要與團隊成員告知??!并提示修改位置(在哪個頁面)。
否則產品、前端、后臺、測試等同事的相關想法、工作會停留在上個交互稿里。
別因為信息沒對齊而造成了不良影響。就算改了一處小東西,也盡量和同步一下。
09 好的心態
最后想說一句,沒有人百分百、完完全全顧慮到所有細節和場景,即使你完全地走查了一遍甚至好幾遍…
但由于不同角色的職業視角、預覽目的、經驗想法等都會提出新的疑問、挑戰你的方案說明。
這是很正常的事~
更何況,在方案沒對齊前,交互稿(包括交互說明)上都存在太多的未知性、待優化點。
即使當前階段確定了所有的細節與場景,隨著方案時間的推進,后續總有新的想法、遺漏點、優化點涌現出來,那些我們覺得的‘完全OK的方案說明’,也都變成了‘過去式’……
我們要做的,必須是多聽聽多方視角的聲音,并尊重、虛心接受他人的意見,而不是抱怨自己為啥考慮不周全、停留在原地鉆牛角尖。
結語
好了,以上就是個人平時寫交互說明的一些感悟,完全是處于個人習慣和主觀經驗得來的,可能不太對,請多指教~
#專欄作家#
和出此嚴,微信公眾號:和出此嚴,人人都是產品經理專欄作家。一枚在鵝廠成長中的‘90后老干部’,主產各種接地氣的交互/產品干貨。以做產品的方式,寫好每一篇文章。
本文原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議。
if else 寫交互說明受教了
不懂就問,交互先于開發請問數據庫的字段是哪來的?
哈哈哈哈哈哈,這個APP竟然沒有點??
您好,我是沒有做過開發的產品,我對您這個技術型需求文檔很感興趣,很想學,請問您有完整的一套技術型需求文檔嗎?能發給我參考不。跪求/(ㄒoㄒ)/~~
你好,可以轉載嗎
微信(elffzh)私聊
奶一口
受教了
很好