中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

所謂交互說明，簡單的理解就是對交互原型的解釋、強調(diào)或補充的說明文字。原型頁面往往無法展示全部的交互細節(jié)，即便完全做到了，團隊中的下游也不一定能夠全部get到。所以，一份足夠完整和詳細的交互說明文檔可以減少溝通成本及信息不對稱。

一、寫給誰看

首先需要明確交互說明的讀者在和項目中的作用；

1、視覺設計師：輸出視覺稿

2、前后端開發(fā)工程師：代碼實現(xiàn)產(chǎn)品設計

3、測試工程師：寫測試用例

4、產(chǎn)品經(jīng)理：項目緊張的情況下，可能會需求和原型設計并行，這時候，交互說明可以協(xié)助產(chǎn)品經(jīng)理整理并輸出需求文檔

5、自己：原型細節(jié)自檢，優(yōu)化設計邏輯

二、由誰來寫

很明顯作為項目的交互設計師是交互說明的主要撰寫人和維護者。

在項目進程中，交互說明應由設計師發(fā)起，前端開發(fā)工程師也會協(xié)助修訂細節(jié)。交互設計師更多的關(guān)注點在需求到原型的轉(zhuǎn)化，對于前后端能否實現(xiàn)并不是很確定。前端開發(fā)工程師對交互說明的把關(guān)和疑問，能夠幫助設計師將設計思想轉(zhuǎn)為工程師能夠理解和實現(xiàn)的語言。這樣交互說明也能幫助前端工程師明確設計實際執(zhí)行方案。

三、寫什么內(nèi)容

寫交互說明文檔時，很多人都會疑惑，到底需要寫什么呢？我的意見是，站在下游的角度，視覺設計師和開發(fā)工程師在需要考慮的與頁面相關(guān)的邏輯和用戶操作相關(guān)的內(nèi)容基本都是需要在說明中體現(xiàn)出開的。另外我們應該盡量寫得詳細些，避免研發(fā)同事多次來討論或者直接按照自己的理解直接實現(xiàn)，這樣最終的驗收效果也會比較好。那么具體的該寫什么，不該寫什么，這里也做了整理供參考。

Axure原型演示及下載地址：https://1vcc4r.axshare.com

3.1 這些要寫

(1)頁面整體說明模塊

頁面統(tǒng)一布局：頁面整體的排版布局簡單說明（比較直觀可不寫）

相同的交互動作：統(tǒng)一的頁面切換方式、手勢、彈窗等

相同的處理規(guī)則和注意點：比如所有的表格在自適應時的變化規(guī)則

(2)對象

用戶身份和系統(tǒng)功能頁面緊密相關(guān)。比如后臺系統(tǒng)常見的會區(qū)分管理員身份，普通管理員還是超級管理員

(3)限制

范圍值：比如列表超過10項出現(xiàn)滾動條

極限值：比如某個字段文字超過展示極限值才有缺省

(4)表單校驗

表單校驗邏輯：是實時校驗還是觸發(fā)按鈕后做校驗，還是兩者結(jié)合，表達清楚邏輯并將相關(guān)的提示和反饋描述清楚。

(5)操作

交互方式：點擊、拖動、長按、縮小、放大等

文本框：獲取焦點、失去焦點（比如app鍵盤的呼出和隱藏）

熱區(qū)范圍：比如卡片展示形式有時將整個卡片作為可出發(fā)操作的區(qū)域

(6)反饋

提示內(nèi)容：系統(tǒng)對用戶操作的基石反饋比如報錯提示、失敗提示、成功提示等

提示形式：提示的控件樣式，比如彈出框是否可關(guān)閉等

跳轉(zhuǎn)：跳轉(zhuǎn)形式是當前窗口/新窗口？跳轉(zhuǎn)到哪里？寫清楚標號或頁面名稱

Axure原型演示及下載地址：https://53oo64.axshare.com

(7)狀態(tài)變化

默認：默認選項選中、默認顯示的文案、默認排序的方式

正常：正常場景下的操作帶來的變化，比如點擊表格的表頭排序

特殊：功能特殊，比如兩個復選框必須有一個選中/場景特殊，比如無數(shù)據(jù)情況、加載失敗、網(wǎng)絡錯誤

(8)其他交互細節(jié)

根據(jù)項目內(nèi)容特性和業(yè)務將邏輯細節(jié)和交互細節(jié)表達清楚。比如app可能有鎖屏推送，項目是否有數(shù)據(jù)埋點

(9)這些不寫

商業(yè)邏輯：比如；某個功能的實現(xiàn)有怎樣的意義，跟產(chǎn)品實現(xiàn)無關(guān)的前期準備，就不要畫蛇添足

視覺規(guī)范相關(guān)：術(shù)業(yè)有專攻，尊重和相信團隊視覺設計師

研發(fā)代碼的邏輯和規(guī)則等：PRD需要解決的問題，不要闡述

3.2 怎么寫

(1)目錄

提供一個參考的目錄，可以進行適當?shù)恼{(diào)整作為項目交互原型的目錄

(2)格式

相比較word等文本記錄工具比較推薦Axure，原因有三：

1. 和原型文件放在一起，方便維護
2. 生成html文件后，研發(fā)閱讀方便
3. 熟悉Axure操作，能夠便捷的添加跳轉(zhuǎn)和動作

(3)排版布局

根據(jù)項目類型和情況確定具體合適的排版，基本可以按照從上到下、從左到右的順序去排版

web的頁面一般比較寬，可以采用先上下，后左右的結(jié)構(gòu)

app的頁面比較窄，可以放在原型頁面中做說明：

五、怎么做才是不錯的交互說明

以上都能理解和做到，已經(jīng)可以完成一份合格的交互說明文檔了。那么怎樣才算是一份不錯的交互說明呢？

(1)固定的目錄結(jié)構(gòu)

對接的下游有時候是同一部門或同一個同事，目錄保持基本的統(tǒng)一，可以降低下游的學習成本，另外也讓自己在寫說明時不必每次都去思考目錄的劃分。當然，針對不同的產(chǎn)品類型和產(chǎn)品特性需要去調(diào)整制訂目錄

(2)簡潔文字

拒絕流水賬式說明，另外當描述文字過長，可能需要重新考慮是否是設計邏輯存在問題。那么如何讓說明文字盡可能的簡單呢？

流程圖代替純文字說明：流程性強的功能可以嘗試這種方式，簡單且直接

(3)盡量使用真實、符合邏輯的數(shù)據(jù)

原型設計的過程中，需要展示數(shù)據(jù)，對數(shù)據(jù)的模擬盡可能的真實，撰寫交互說明可以將場景還原更加貼近真實可能性。而且，真實符合邏輯的數(shù)據(jù)，研發(fā)也比較能更快理解頁面邏輯，所以也可以減少溝通成本

(4)處理重復內(nèi)容

原型頁面很多內(nèi)容是復用，那同樣的這些重復的內(nèi)容，按照常見的處理方式，就會重復寫很多次的交互說明，但是這樣帶來2個問題，一是研發(fā)會不會懷疑前后的交互說明是否有區(qū)別，二是如果需要修改的話，需要對所有的相關(guān)頁面修改，維護的工作量就變大了很多。

(5)更新后及時周知

每次更新都是一次改進的過程，添加新內(nèi)容的同時，保留舊的內(nèi)容，讓其他人也看到走過的彎路，讓他們 知道每次修改都是深思熟慮后的決定。

另外，當我們在項目中寫交互說明寫多了就會發(fā)現(xiàn)，組件可以自己設計生成元件庫，調(diào)用元件庫就可以快捷使用，那么組件的交互說明也可以組建化進行歸類入庫，在需要的時候直接拿出來根據(jù)具體情況調(diào)整使用。

六、總結(jié)

以上就是我在項目進行過程中發(fā)現(xiàn)的問題和個人思考的解決方案。但是，并非所有人都喜歡寫說明文檔或者看說明文檔。有必要的情況下，需要跟團隊成員強調(diào)交互說明的存在意義，推動大家去閱讀和反饋，這樣辛辛苦苦寫出來的說明才能對項目的發(fā)展起到真實的作用。

另外在項目合作的過程中，除了做好自己的任務以外，要多站在項目的角度上去思考，要去考慮團隊中其他角色尤其是下游伙伴是否能夠較好及時地實現(xiàn)或完成相關(guān)人物，這樣思考后才去決定自己手下急需和應該完成的任務項。