2022-3-2 純純
交互輸出文檔的作用
文檔這個東西，我們又愛又恨，愛的是它能夠記錄并且在工作中讓大家高效的協(xié)調(diào)合作，恨的就是很多人對文檔嗤之以鼻非常敷衍，以至于文檔不但沒有起到它應(yīng)有的作用，反而成為了一個不負責(zé)任的借口。所以一份合格或者優(yōu)秀的交互輸出文檔對于一個項目的流轉(zhuǎn)以及團隊的配合來說是至關(guān)重要的。交互文檔的主要利益相關(guān)者通常是以下幾個角色：交互、產(chǎn)品、開發(fā)、UI
交互
首先優(yōu)秀的交互文檔必須在交互組內(nèi)部進行過審核，包括一致的撰寫標準和模式的使用，一個比較規(guī)范的交互設(shè)計組對于交互的撰寫標準也是有嚴格的規(guī)范的，以及在什么情況使用什么交互模式還有組件庫的調(diào)用都會有詳細的說明，那么你的交互輸出文檔就必須滿足團隊設(shè)定的規(guī)范。
其次對于其他交互設(shè)計師來說，你的設(shè)計方案中是否會出現(xiàn)其他人負責(zé)的模塊，那么在評審的時候需要同步，雖然交互輸出文檔對于其他交互來說不是直接受益人，但是在團隊同步過程中也是非常重要的。
產(chǎn)品
每個公司對于文檔的要求和規(guī)則不一樣。小公司可能沒有交互設(shè)計這個崗位，那么可能產(chǎn)品連prd文檔也沒有，僅僅只是一個簡易的需求說明文檔，就更不用說針對交互規(guī)則的說明文檔了。
很多有完善規(guī)模和流程的團隊不僅會有詳細的需求說明文檔也有很完善的交互說明文檔。我們首先要明確的一點是那么多文檔最后是給誰看的，一共在項目中會有多少文檔產(chǎn)生。
通常產(chǎn)品經(jīng)理會在項目初期做一份prd文檔（Product-RequirementDocument，需求說明文檔），這個prd文檔主要是給業(yè)務(wù)方、交互和開發(fā)看的，在這個文檔中需要包含一些業(yè)務(wù)規(guī)則以及交互規(guī)則，所以交互的輸出文檔是需要和產(chǎn)品的prd文檔合并的。
當然如果你是一位很有自驅(qū)力的人，那么你可以自己推進需求并落地，一個人就可以完成prd文檔的撰寫和需求的落地了。
開發(fā)
特別想給各位提個醒，在開發(fā)需求評審的過程中，請一定記住你們評審的目的，開發(fā)同學(xué)也要注意，請把重點放在需求是否能實現(xiàn)以及開發(fā)相關(guān)的地方即可，請不要考慮為什么要這樣做，或者你覺得應(yīng)該怎么設(shè)計，一旦進入了開發(fā)對需求和設(shè)計的評頭論足那么這個會議效率就相當?shù)拖隆?/strong>專業(yè)的事情就交給專業(yè)的人去做吧，可以私下討論但不要在評審會上各抒己見。
交互輸出文檔對于開發(fā)的作用就是，開發(fā)可以更好的還原該功能中交互的跳轉(zhuǎn)以及邏輯，所以我們盡量把交互規(guī)則寫明白寫詳細，比如按鈕在press和default時候是否樣式會有變化，或者頁面轉(zhuǎn)場的方向，這都是一些細節(jié)，減少不必要的低效溝通。你會發(fā)現(xiàn)有些時候為什么開發(fā)總是來問一些規(guī)則，就是因為文檔中沒有描述準確，所以開發(fā)和交互都需要花時間去同步這個細節(jié)。
所以這個也非?？简灲换ピO(shè)計師對需求文檔撰寫的功底，并不是圖片文字隨意擺放就可以的。和開發(fā)合作時也是一項內(nèi)部的體驗設(shè)計，你把文檔寫好了，開發(fā)看起來也舒服，滿意度也高。如果是一堆文案，連基本的對齊都沒做到的話，誰來看都會看不下去。
UI
交互輸出文檔對于UI來說，作用就非常簡單了，但是這里也會碰到問題，那就是交互同學(xué)只需要把信息的層次表示出來即可，千萬不要畫到連視覺同學(xué)都沒有發(fā)揮余地的程度。所以為什么現(xiàn)在UXD體驗設(shè)計那么火，就是因為交互和UI其實重合度是很高的，只要有智能化組件庫和工具做支撐，那么在交互和UI的設(shè)計流程中，時間就會大大降低。
交互輸出文檔的內(nèi)容
在這里，我們就將整個prd文檔的內(nèi)容給大家分享一下，不僅僅是交互需要輸出的部分。因為一個高階的交互是需要能夠獨自產(chǎn)出prd文檔的。然后不同的公司對與文檔的要求也是不同，大家做參考即可。
一份基礎(chǔ)的prd文檔主要由這幾部分組成（其實就是這個需求的來源以及推導(dǎo)過程和如何落地的說明）：
1.項目概要
a.需求背景
這個是一個項目最重要的部分，可以說背景沒有搞清楚，后面都可以不用做。這個指的就是我們做這個需求的價值和原因。比如我們app中業(yè)務(wù)方（運營）需要做一個掃一掃功能，那么這個功能首先我們就從業(yè)務(wù)價值和用戶價值兩個方面去評估，根據(jù)對業(yè)務(wù)方的溝通之后我們發(fā)現(xiàn)掃一掃功能將會在周年慶的時候通過物流包裹上的二維碼，讓用戶進行掃碼參與活動這樣的玩法。
所以這個需求對于業(yè)務(wù)方來說是一個轉(zhuǎn)化手段，通過掃碼參與活動-領(lǐng)券-消費，確實是一個不錯的玩法，但是大家如果只盯著眼前的問題或許就不夠了，比如當周年慶結(jié)束之后這個功能還有什么用，他在以后的規(guī)劃中的存在是怎樣的。在所有的包裹中印上活動的二維碼這個時間周期和成本有多大。
其次，對于用戶來說，掃一掃并不是幫助他們解決了某個問題，而是我做了一個東西，同時搭配著這個功能讓你們?nèi)ナ褂?，對用戶來說是一個很可有可無的功能，如果線下包裹上的二維碼破損了也是非常影響體驗并且是不可控的。那么綜上所述，既然要做一個臨時的活動用其他的方式會不會更好？
所以在這個文檔中的第一步，首先就是要確定需求的背景、價值，也就是說，你這個需求是怎么來的，比如再來講我們一個店鋪的優(yōu)化項目，在這個項目中，首先我們必須在評審的時候說清楚我們?yōu)槭裁匆獙ζ溥M行優(yōu)化和改版，一定是出現(xiàn)了或者我們定義到了某個比較嚴重的問題，這邊大家對我們app業(yè)務(wù)可能不是很了解我就簡單說了，就是個人中心和店鋪營銷場景重合過多，并且賣家的同時可以買和賣兩個場景存在，所以店鋪頁通過我們的數(shù)據(jù)分析和用戶的訪談我們發(fā)現(xiàn)了一些機會點，以及我們必須突出一個核心場景讓用戶有明確的分辨。
另外就是背景的描述也可以帶上你的調(diào)研結(jié)果和分析，比如之前我們做首頁優(yōu)化，我們觀察了近5個月的數(shù)據(jù)，都呈現(xiàn)下降的趨勢，所以之后有進行了一系列的訪談和用戶體驗地圖分析才有了這個需求的背景產(chǎn)生。
b.需求目標
目標很好理解，就是我們希望通過這次需求迭代達到一個什么成果，比如我們之前做過一次整體的體驗優(yōu)化改版，那么我們的目標就是減少用戶的流程跳失、提升整體體驗滿意度、提高用戶的任務(wù)轉(zhuǎn)化率，其中我們做了一個商品關(guān)注的功能，由于是限時特價商品所以是限量的，在規(guī)定時間進行搶購，為了讓用戶的使用場景統(tǒng)一我們打算在應(yīng)用內(nèi)做一個商品關(guān)注功能，所以在這個需求的初期，我們對這個功能的目標和預(yù)期是提升xx百分比的轉(zhuǎn)化，提高x%比的gmv，提高用戶對關(guān)注商品下單的效率和滿意度，之前很多用戶想要購買商品需要自己在手機端設(shè)置鬧鐘，不方便。所以這個功能的一個目標就是解決用戶場景遷移的問題。設(shè)定目標之后，就是為了在上線后對其進行復(fù)盤和數(shù)據(jù)跟蹤還有用戶跟蹤。
可以用一句話來描述：針對什么用戶在什么場景下解決用戶的什么問題，達到什么目的？
c.需求范圍
需求范圍也相當于范圍層，指的就是在該需求中我們需要做哪些相關(guān)功能以及功能涉及面。舉個例子，之前說的掃一掃功能，不同的產(chǎn)品定位對于掃一掃功能的要求也是不同的，比如說微信在掃一掃功能中承載了：掃一掃、相冊、封面、街景、翻譯、手電筒等諸多功能，再比如淘寶，有掃一掃（ar、拍立淘）、相冊、歷史、幫助、手電，這說明了不同產(chǎn)品對掃一掃功能有不一樣的要求，所以在需求范圍內(nèi)我們需要把本次需要做的功能進行描述，并且該功能是否影響其他功能的使用和對整個產(chǎn)品的影響范圍。并且我們也會講所需要的功能進行拆解和優(yōu)先級拆分，在表格中編輯。
d.調(diào)研分析
調(diào)研分析其實就是為我們第一步背景和價值做準備，由于匯報方案和評審，或者在項目推進時，我們需要有相應(yīng)的論據(jù)來支撐我們方案的客觀性，所以在這一板塊中輸出的結(jié)論就非常重要，比如之前的首頁改版，經(jīng)過用戶研究小組的訪談和數(shù)據(jù)分析得出相關(guān)的結(jié)論，通過埋點找到相應(yīng)板塊的點擊數(shù)據(jù)和異常點，然后再進行一系列的問卷和訪談研究，找到結(jié)果，都是為了輔助項目的背景以及在評審中大家對需求價值的靈魂拷問。由于數(shù)據(jù)和調(diào)研結(jié)果比較敏感就不過多放了。
e.版本日志
日志是一個非常重要的組成部分，做過開發(fā)的同學(xué)都知道log 的重要性，當我們跑不通的時候我們都會去檢查log，然后多測試幾遍可能就找到問題所在了，其實我們的版本日志的作用也是這樣，但是一個是對自己來說可以記錄自己的工作過程，還有思路的變化，第二就是對外，包括和需求方的討論，會議的紀要等。
要注意的是會議紀要在備注中需要詳細說明，以做證據(jù)。同時也要郵件通知相關(guān)人員和負責(zé)人。可能有些公司還會放一些評審記錄，比如各部門負責(zé)人對方案和需求的建議，業(yè)務(wù)方和技術(shù)負責(zé)人的一些建議也會放在項目概要中，而這個prd文檔也可通過內(nèi)部服務(wù)器進行實時更新和保存，如svn。方便大家對需求的進度和迭代有一個直觀的追蹤。
f.項目成員
這個就不用多說了，產(chǎn)品、運營、交互、視覺、開發(fā)各司其職，照相館人員即可，就不至于當項目開始進行了人員分配還沒到位就尷尬了。
2.需求方案設(shè)計
a.業(yè)務(wù)、任務(wù)、界面流程圖
有些同學(xué)不是特別明白業(yè)務(wù)流程圖和任務(wù)流程圖的區(qū)別，這邊給大家簡單介紹一下
業(yè)務(wù)流程圖：
意思就是在這個需求系統(tǒng)中，相關(guān)利益者的業(yè)務(wù)關(guān)系，任務(wù)信息的流向的一個圖標。比如這個簡單的例子，用戶在點外賣這個場景中，相關(guān)的利益者有用戶、店家、外賣員三者，那么當用戶開始觸發(fā)流程后，這3者在這個流程中就會各司其職，而業(yè)務(wù)流程圖也很明顯的告訴大家所有聯(lián)動者的指責(zé)和流程走向。
任務(wù)流程圖：
用戶在具體執(zhí)行某一個任務(wù)時候的工作流程，以及其核心任務(wù)的操作步驟，比如在登錄注冊這個任務(wù)中，用戶需要進行一系列的操作，在這個流程中用戶的操作引發(fā)的系統(tǒng)判斷需要詳細說明。
界面流程圖：
界面之間的跳轉(zhuǎn)關(guān)系和路徑，在這個流程圖中，我們不需要吧詳細的說明寫上，只需要將需求中涉及到的頁面跳轉(zhuǎn)進行敘述即可。
b.相關(guān)說明和規(guī)則
接下來就要開始我們交互文檔最為關(guān)鍵的部分了，如何書寫交互說明，以及交互說明應(yīng)該包含的內(nèi)容。
1.全局思考
在做交互方案也就是我們畫原型的時候會思考一些問題：
a.整體思考
1.信息架構(gòu)是否容易理解，信息分類是否合理，比如我們的信息架構(gòu)是否采用了用戶容易理解的，市面上常用的信息架構(gòu)。
2.信息層級和路徑是否合理，不一定要最簡，但是要高效，信息的優(yōu)先級是否放置準確，信息組織是否具有相關(guān)性、邏輯性。
3.主題是否清晰，3秒內(nèi)告訴“我”在哪里，并且可以做什么
4.方案的延展和后續(xù)功能規(guī)劃的可擴展性
b.用戶權(quán)限
根據(jù)不同用戶的權(quán)限對該需求進行檢查，比如普通用戶、vip用戶、內(nèi)外網(wǎng)用戶、游客用戶，在登錄未登錄時候?qū)π枨髢?nèi)功能的使用是否有影響
c.登錄方式
用戶登錄和注冊、終端的兼容，不同方式注冊的用戶是否需要補填相關(guān)信息等等
d.流程
1.該需求中的功能流程是否和其他類似或者相同功能流程保持一致性；
2.逆向流程和非正常流程的思考有沒有完全；
3.流程的閉環(huán)有沒有做好；頁面跳轉(zhuǎn)的方式是否合理；
4.中斷后的恢復(fù)狀態(tài)如何呈現(xiàn)；
5是否保留原信息等等
2.內(nèi)容、狀態(tài)和顯示
a.內(nèi)容的獲取來源
例如下方的圖片為例，banner的圖片來源和發(fā)現(xiàn)feed流的圖片來源肯定是不同的，那么就要寫清楚，圖片或者數(shù)據(jù)的來源是來自于用戶的上傳還是系統(tǒng)后臺的配置獲?。徊⑶耀@取的方式是如何的，是需要手動下啦刷新還是切換頁面自動刷新，還是設(shè)定時間自動刷新。
字段、圖標是從接口獲取還是前端寫死，以及氣泡展示的規(guī)則等等。另外一張圖片可能用在多個地方，而可能呈現(xiàn)的尺寸不同，所以在涉及到相關(guān)圖片使用時要注意剪裁規(guī)則和圖片的來源。
b.緩存機制
圖片以及一些資源通常我們需要對其進行緩存，有些同學(xué)不清楚什么是緩存，緩存是在計算機上的一個原始數(shù)據(jù)的復(fù)制集，一般來說需要緩存的內(nèi)容是通過瀏覽產(chǎn)生的，包括圖片以及cookie等，瀏覽過的視頻和廣告也會被緩存。同時在不同的網(wǎng)絡(luò)環(huán)境下緩存的時間標準也不同，無網(wǎng)絡(luò)那肯定只能讀取緩存文件，wifi環(huán)境下緩存時間可設(shè)置的短一些，而流量環(huán)境下時間就可以設(shè)置的偏長。
c.狀態(tài)
狀態(tài)大家都應(yīng)該都會寫，主要包含的就是初始狀態(tài)（冷啟動無緩存第一次進入）、空狀態(tài)（無任何內(nèi)容比如空的購物車）、常規(guī)狀態(tài)、異常狀態(tài)（網(wǎng)絡(luò)中斷、接口報錯）還有過期狀態(tài)等
d.顯示
數(shù)據(jù)和內(nèi)容的極限值，最大和最小，比如粉絲和關(guān)注的數(shù)量，小于1萬人則顯示完整的數(shù)量，大于等于1萬小于11000則顯示1萬，大于11000小于12000則顯示1.1萬，這樣的方式。另外包括標題極限為一行顯示，超過部分的顯示規(guī)則。敏感信息、錯誤提示以及超時的信息提示。金額的格式使用￥xxx還是xxx元，小數(shù)點保留的規(guī)則。日期的顯示格式是xxxx年xx月xx日還是xxxx-xx-xx還是xxxx/xx/xx等等
3.反饋、提示、手勢
反饋和提示的樣式有很多種，一般反饋指的是用戶對某一個控件進行觸發(fā)后獲得的反饋，比如按鈕按下的反饋，以及之后收到的反饋，是進行跳轉(zhuǎn)還是給用戶提示，采用的是模態(tài)還是非模態(tài)的提示。比如點擊關(guān)注某個人的按鈕后會提示關(guān)注成功，比如退出某個圖文編輯會二次確認是否退出，再比如抖音長按后出現(xiàn)的3個操作反饋，還有支付成功后的動效提示、惡意多次操作后的提示等等
如果有手勢交互也需要說明，比如滑動后內(nèi)容置頂、拖拽、左右輕掃的tab滑動、重按的3dtouch等等
4.加載
使用模態(tài)還是非模態(tài)，如果是模態(tài)加載請盡量使用情感化設(shè)計來減少用戶焦慮。如果是非模態(tài)，根據(jù)信息呈現(xiàn)和體驗采用分步加載還是預(yù)加載還是智能加載。如果是分布加載就選擇先加載資源較小的內(nèi)容，再加載圖片，可以先將圖片模糊化粗渲染給用戶呈現(xiàn)，包括在瀏覽信息流的時候的分頁加載也是可以的。如果更智能化一些也可以預(yù)判用戶的行為進行內(nèi)容加載，例如當用戶在某個圖文前停留時間達到某個值后就預(yù)先給用戶加載里面的內(nèi)容。
加載的全局方式在方案中需要考慮，頁面加載、下啦刷新等等，需要統(tǒng)一。
5.環(huán)境、設(shè)備與場景
a.不同設(shè)備、廠商的不同版本
都會影響到方案的落地和用戶體驗這個要非常注意。比如一些交互控件我們在6、iphonex和大屏幕尺寸上使用起來效果很好，但是小屏幕的時候這個交互控件顯得就很難受，所以需要仔細斟酌用戶的使用情況。另外還有橫豎憑情況的交互方案是否兼容、是否需要與其他硬件進行兼容。
b.白天和晚上是否需要做不同的風(fēng)格設(shè)計，以及在是否需要給用戶遮擋隱私的功能。
6.文案
文案這點很多設(shè)計師都忽略了，你們有沒有聽說過一個叫文案設(shè)計師的崗位。其實文案在我們產(chǎn)品設(shè)計中是非常重要的。首先一個產(chǎn)品的文案對應(yīng)的語氣和產(chǎn)品調(diào)性也是相關(guān)的，就好比我們說產(chǎn)品有它自己的性格一樣，另外文案的使用直接就影響用戶對該信息的理解，比如一個對話框的文案是：確定退出嗎？下面會有兩種不同的選擇，一個確定，一個是退出，大家覺得哪個比較好？還有就是不加“嗎”，就變成了：確定退出？這樣描述出來的語言給人感覺很冰冷，甚至有一些威脅。
所以首先我們的文案是否有溫度，和產(chǎn)品的個性是否相匹配。其次文案的表述是否準確和通俗易懂，比如你告訴程序員一句話，幫我去菜市場買西瓜，如果有西紅柿，幫我買兩個，你會帶什么東西回家？程序員版：if（看到西紅柿）西瓜等于2；else 西瓜=1。buy 西瓜。條件：看見西紅柿 執(zhí)行命令：買兩個西瓜一語道破版：其實吧，看到西紅柿呢是賣兩個西瓜的觸發(fā)條件…沒看到就買一個西瓜，看到就買兩個西瓜。所以這里出現(xiàn)的不僅僅是程序員的思維和我們的差異化，也說明了一句話沒有表述清楚所帶來的問題是很大的。
另外就是文案用語的一致性，在整個產(chǎn)品同樣的場景中，我們需要統(tǒng)一文案用語。
7.常見控件
具體見下方列表
8.撰寫方式
作為一個設(shè)計師，不管是否在做視覺，我們都需要對文檔有一個美化意識，如果你的文檔非常凌亂，那么在別人眼里就會覺得你是一個比較粗心大意，不夠負責(zé)任的人，所以我們盡量在做交互輸出文檔的時候也畫的美觀一些。
目錄
首先在目錄的撰寫時候要進行分類，通常我做的時候會對該需求以頁面父子集關(guān)系進行創(chuàng)建，父集為核心頁面，子集為其下的相關(guān)子頁面，這樣頁面的流轉(zhuǎn)和歸屬關(guān)系就不會搞錯。
說明
在撰寫規(guī)則與說明時可以通過標簽法進行標簽說明的撰寫方式，同樣在視覺上保持美觀，對比與對齊的運用，具體該寫什么東西上面已經(jīng)說明就不贅述了。除了交互規(guī)則以外，高階的交互設(shè)計或者產(chǎn)品經(jīng)理還需要補充業(yè)務(wù)規(guī)則，比如排序、商品抓去規(guī)則、權(quán)重、算法、活動規(guī)則等等這里就不展開說了。
總結(jié)
文檔的形式有非常多種，針對不同的公司和產(chǎn)品也需要作出相應(yīng)的調(diào)整，能夠滿足需求和方便協(xié)作，目的就達到了，我們并不希望過多的時間花在文檔的撰寫上，而是希望大家在做設(shè)計時多思考業(yè)務(wù)，本次分享就到這里啦～
文章來源：站酷 作者：應(yīng)駿
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責(zé)聲明：藍藍設(shè)計尊重原作者，文章的版權(quán)歸原作者。如涉及版權(quán)問題，請及時與我們?nèi)〉寐?lián)系，我們立即更正或刪除。
藍藍設(shè)計( www.alimai.net )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、
cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標定制 、 用戶體驗 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)
藍藍設(shè)計的小編 http://www.alimai.net