當(dāng)前位置:圖趣網(wǎng)(Tuquu) > 網(wǎng)頁設(shè)計(jì)教程 > 交互設(shè)計(jì) > 交互設(shè)計(jì)的輸出文檔撰寫方法

交互設(shè)計(jì)的輸出文檔撰寫方法

交互輸出文檔的作用

文檔這個(gè)東西,我們又愛又恨,愛的是它能夠記錄并且在工作中讓大家高效的協(xié)調(diào)合作,恨的就是很多人對(duì)文檔嗤之以鼻非常敷衍,以至于文檔不但沒有起到它應(yīng)有的作用,反而成為了一個(gè)不負(fù)責(zé)任的借口。所以一份合格或者優(yōu)秀的交互輸出文檔對(duì)于一個(gè)項(xiàng)目的流轉(zhuǎn)以及團(tuán)隊(duì)的配合來說是至關(guān)重要的。交互文檔的主要利益相關(guān)者通常是以下幾個(gè)角色:交互、產(chǎn)品、開發(fā)、UI


交互

首先優(yōu)秀的交互文檔必須在交互組內(nèi)部進(jìn)行過審核,包括一致的撰寫標(biāo)準(zhǔn)和模式的使用,一個(gè)比較規(guī)范的交互設(shè)計(jì)組對(duì)于交互的撰寫標(biāo)準(zhǔn)也是有嚴(yán)格的規(guī)范的,以及在什么情況使用什么交互模式還有組件庫的調(diào)用都會(huì)有詳細(xì)的說明,那么你的交互輸出文檔就必須滿足團(tuán)隊(duì)設(shè)定的規(guī)范。


其次對(duì)于其他交互設(shè)計(jì)師來說,你的設(shè)計(jì)方案中是否會(huì)出現(xiàn)其他人負(fù)責(zé)的模塊,那么在評(píng)審的時(shí)候需要同步,雖然交互輸出文檔對(duì)于其他交互來說不是直接受益人,但是在團(tuán)隊(duì)同步過程中也是非常重要的。


產(chǎn)品

每個(gè)公司對(duì)于文檔的要求和規(guī)則不一樣。小公司可能沒有交互設(shè)計(jì)這個(gè)崗位,那么可能產(chǎn)品連prd文檔也沒有,僅僅只是一個(gè)簡易的需求說明文檔,就更不用說針對(duì)交互規(guī)則的說明文檔了。


很多有完善規(guī)模和流程的團(tuán)隊(duì)不僅會(huì)有詳細(xì)的需求說明文檔也有很完善的交互說明文檔。我們首先要明確的一點(diǎn)是那么多文檔最后是給誰看的,一共在項(xiàng)目中會(huì)有多少文檔產(chǎn)生。


通常產(chǎn)品經(jīng)理會(huì)在項(xiàng)目初期做一份prd文檔(Product-RequirementDocument,需求說明文檔),這個(gè)prd文檔主要是給業(yè)務(wù)方、交互和開發(fā)看的,在這個(gè)文檔中需要包含一些業(yè)務(wù)規(guī)則以及交互規(guī)則,所以交互的輸出文檔是需要和產(chǎn)品的prd文檔合并的。


當(dāng)然如果你是一位很有自驅(qū)力的人,那么你可以自己推進(jìn)需求并落地,一個(gè)人就可以完成prd文檔的撰寫和需求的落地了。


開發(fā)

特別想給各位提個(gè)醒,在開發(fā)需求評(píng)審的過程中,請(qǐng)一定記住你們?cè)u(píng)審的目的,開發(fā)同學(xué)也要注意,請(qǐng)把重點(diǎn)放在需求是否能實(shí)現(xiàn)以及開發(fā)相關(guān)的地方即可,請(qǐng)不要考慮為什么要這樣做,或者你覺得應(yīng)該怎么設(shè)計(jì),一旦進(jìn)入了開發(fā)對(duì)需求和設(shè)計(jì)的評(píng)頭論足那么這個(gè)會(huì)議效率就相當(dāng)?shù)拖隆?/strong>專業(yè)的事情就交給專業(yè)的人去做吧,可以私下討論但不要在評(píng)審會(huì)上各抒己見。


交互輸出文檔對(duì)于開發(fā)的作用就是,開發(fā)可以更好的還原該功能中交互的跳轉(zhuǎn)以及邏輯,所以我們盡量把交互規(guī)則寫明白寫詳細(xì),比如按鈕在press和default時(shí)候是否樣式會(huì)有變化,或者頁面轉(zhuǎn)場的方向,這都是一些細(xì)節(jié),減少不必要的低效溝通。你會(huì)發(fā)現(xiàn)有些時(shí)候?yàn)槭裁撮_發(fā)總是來問一些規(guī)則,就是因?yàn)槲臋n中沒有描述準(zhǔn)確,所以開發(fā)和交互都需要花時(shí)間去同步這個(gè)細(xì)節(jié)。



所以這個(gè)也非??简?yàn)交互設(shè)計(jì)師對(duì)需求文檔撰寫的功底,并不是圖片文字隨意擺放就可以的。和開發(fā)合作時(shí)也是一項(xiàng)內(nèi)部的體驗(yàn)設(shè)計(jì),你把文檔寫好了,開發(fā)看起來也舒服,滿意度也高。如果是一堆文案,連基本的對(duì)齊都沒做到的話,誰來看都會(huì)看不下去。


UI

交互輸出文檔對(duì)于UI來說,作用就非常簡單了,但是這里也會(huì)碰到問題,那就是交互同學(xué)只需要把信息的層次表示出來即可,千萬不要畫到連視覺同學(xué)都沒有發(fā)揮余地的程度。所以為什么現(xiàn)在UXD體驗(yàn)設(shè)計(jì)那么火,就是因?yàn)榻换ズ蚒I其實(shí)重合度是很高的,只要有智能化組件庫和工具做支撐,那么在交互和UI的設(shè)計(jì)流程中,時(shí)間就會(huì)大大降低。


交互輸出文檔的內(nèi)容

在這里,我們就將整個(gè)prd文檔的內(nèi)容給大家分享一下,不僅僅是交互需要輸出的部分。因?yàn)橐粋€(gè)高階的交互是需要能夠獨(dú)自產(chǎn)出prd文檔的。然后不同的公司對(duì)與文檔的要求也是不同,大家做參考即可。


一份基礎(chǔ)的prd文檔主要由這幾部分組成(其實(shí)就是這個(gè)需求的來源以及推導(dǎo)過程和如何落地的說明):



1.項(xiàng)目概要

a.需求背景

這個(gè)是一個(gè)項(xiàng)目最重要的部分,可以說背景沒有搞清楚,后面都可以不用做。這個(gè)指的就是我們做這個(gè)需求的價(jià)值和原因。比如我們app中業(yè)務(wù)方(運(yùn)營)需要做一個(gè)掃一掃功能,那么這個(gè)功能首先我們就從業(yè)務(wù)價(jià)值和用戶價(jià)值兩個(gè)方面去評(píng)估,根據(jù)對(duì)業(yè)務(wù)方的溝通之后我們發(fā)現(xiàn)掃一掃功能將會(huì)在周年慶的時(shí)候通過物流包裹上的二維碼,讓用戶進(jìn)行掃碼參與活動(dòng)這樣的玩法。



所以這個(gè)需求對(duì)于業(yè)務(wù)方來說是一個(gè)轉(zhuǎn)化手段,通過掃碼參與活動(dòng)-領(lǐng)券-消費(fèi),確實(shí)是一個(gè)不錯(cuò)的玩法,但是大家如果只盯著眼前的問題或許就不夠了,比如當(dāng)周年慶結(jié)束之后這個(gè)功能還有什么用,他在以后的規(guī)劃中的存在是怎樣的。在所有的包裹中印上活動(dòng)的二維碼這個(gè)時(shí)間周期和成本有多大。


其次,對(duì)于用戶來說,掃一掃并不是幫助他們解決了某個(gè)問題,而是我做了一個(gè)東西,同時(shí)搭配著這個(gè)功能讓你們?nèi)ナ褂?,?duì)用戶來說是一個(gè)很可有可無的功能,如果線下包裹上的二維碼破損了也是非常影響體驗(yàn)并且是不可控的。那么綜上所述,既然要做一個(gè)臨時(shí)的活動(dòng)用其他的方式會(huì)不會(huì)更好?


所以在這個(gè)文檔中的第一步,首先就是要確定需求的背景、價(jià)值,也就是說,你這個(gè)需求是怎么來的,比如再來講我們一個(gè)店鋪的優(yōu)化項(xiàng)目,在這個(gè)項(xiàng)目中,首先我們必須在評(píng)審的時(shí)候說清楚我們?yōu)槭裁匆獙?duì)其進(jìn)行優(yōu)化和改版,一定是出現(xiàn)了或者我們定義到了某個(gè)比較嚴(yán)重的問題,這邊大家對(duì)我們app業(yè)務(wù)可能不是很了解我就簡單說了,就是個(gè)人中心和店鋪營銷場景重合過多,并且賣家的同時(shí)可以買和賣兩個(gè)場景存在,所以店鋪頁通過我們的數(shù)據(jù)分析和用戶的訪談我們發(fā)現(xiàn)了一些機(jī)會(huì)點(diǎn),以及我們必須突出一個(gè)核心場景讓用戶有明確的分辨。


另外就是背景的描述也可以帶上你的調(diào)研結(jié)果和分析,比如之前我們做首頁優(yōu)化,我們觀察了近5個(gè)月的數(shù)據(jù),都呈現(xiàn)下降的趨勢(shì),所以之后有進(jìn)行了一系列的訪談和用戶體驗(yàn)地圖分析才有了這個(gè)需求的背景產(chǎn)生。



b.需求目標(biāo)

目標(biāo)很好理解,就是我們希望通過這次需求迭代達(dá)到一個(gè)什么成果,比如我們之前做過一次整體的體驗(yàn)優(yōu)化改版,那么我們的目標(biāo)就是減少用戶的流程跳失、提升整體體驗(yàn)滿意度、提高用戶的任務(wù)轉(zhuǎn)化率,其中我們做了一個(gè)商品關(guān)注的功能,由于是限時(shí)特價(jià)商品所以是限量的,在規(guī)定時(shí)間進(jìn)行搶購,為了讓用戶的使用場景統(tǒng)一我們打算在應(yīng)用內(nèi)做一個(gè)商品關(guān)注功能,所以在這個(gè)需求的初期,我們對(duì)這個(gè)功能的目標(biāo)和預(yù)期是提升xx百分比的轉(zhuǎn)化,提高x%比的gmv,提高用戶對(duì)關(guān)注商品下單的效率和滿意度,之前很多用戶想要購買商品需要自己在手機(jī)端設(shè)置鬧鐘,不方便。所以這個(gè)功能的一個(gè)目標(biāo)就是解決用戶場景遷移的問題。設(shè)定目標(biāo)之后,就是為了在上線后對(duì)其進(jìn)行復(fù)盤和數(shù)據(jù)跟蹤還有用戶跟蹤。

可以用一句話來描述:針對(duì)什么用戶在什么場景下解決用戶的什么問題,達(dá)到什么目的?



c.需求范圍

需求范圍也相當(dāng)于范圍層,指的就是在該需求中我們需要做哪些相關(guān)功能以及功能涉及面。舉個(gè)例子,之前說的掃一掃功能,不同的產(chǎn)品定位對(duì)于掃一掃功能的要求也是不同的,比如說微信在掃一掃功能中承載了:掃一掃、相冊(cè)、封面、街景、翻譯、手電筒等諸多功能,再比如淘寶,有掃一掃(ar、拍立淘)、相冊(cè)、歷史、幫助、手電,這說明了不同產(chǎn)品對(duì)掃一掃功能有不一樣的要求,所以在需求范圍內(nèi)我們需要把本次需要做的功能進(jìn)行描述,并且該功能是否影響其他功能的使用和對(duì)整個(gè)產(chǎn)品的影響范圍。并且我們也會(huì)講所需要的功能進(jìn)行拆解和優(yōu)先級(jí)拆分,在表格中編輯。



d.調(diào)研分析

調(diào)研分析其實(shí)就是為我們第一步背景和價(jià)值做準(zhǔn)備,由于匯報(bào)方案和評(píng)審,或者在項(xiàng)目推進(jìn)時(shí),我們需要有相應(yīng)的論據(jù)來支撐我們方案的客觀性,所以在這一板塊中輸出的結(jié)論就非常重要,比如之前的首頁改版,經(jīng)過用戶研究小組的訪談和數(shù)據(jù)分析得出相關(guān)的結(jié)論,通過埋點(diǎn)找到相應(yīng)板塊的點(diǎn)擊數(shù)據(jù)和異常點(diǎn),然后再進(jìn)行一系列的問卷和訪談研究,找到結(jié)果,都是為了輔助項(xiàng)目的背景以及在評(píng)審中大家對(duì)需求價(jià)值的靈魂拷問。由于數(shù)據(jù)和調(diào)研結(jié)果比較敏感就不過多放了。

e.版本日志

日志是一個(gè)非常重要的組成部分,做過開發(fā)的同學(xué)都知道log 的重要性,當(dāng)我們跑不通的時(shí)候我們都會(huì)去檢查log,然后多測試幾遍可能就找到問題所在了,其實(shí)我們的版本日志的作用也是這樣,但是一個(gè)是對(duì)自己來說可以記錄自己的工作過程,還有思路的變化,第二就是對(duì)外,包括和需求方的討論,會(huì)議的紀(jì)要等。


要注意的是會(huì)議紀(jì)要在備注中需要詳細(xì)說明,以做證據(jù)。同時(shí)也要郵件通知相關(guān)人員和負(fù)責(zé)人。可能有些公司還會(huì)放一些評(píng)審記錄,比如各部門負(fù)責(zé)人對(duì)方案和需求的建議,業(yè)務(wù)方和技術(shù)負(fù)責(zé)人的一些建議也會(huì)放在項(xiàng)目概要中,而這個(gè)prd文檔也可通過內(nèi)部服務(wù)器進(jìn)行實(shí)時(shí)更新和保存,如svn。方便大家對(duì)需求的進(jìn)度和迭代有一個(gè)直觀的追蹤。

f.項(xiàng)目成員

這個(gè)就不用多說了,產(chǎn)品、運(yùn)營、交互、視覺、開發(fā)各司其職,照相館人員即可,就不至于當(dāng)項(xiàng)目開始進(jìn)行了人員分配還沒到位就尷尬了。


2.需求方案設(shè)計(jì)

a.業(yè)務(wù)、任務(wù)、界面流程圖

有些同學(xué)不是特別明白業(yè)務(wù)流程圖和任務(wù)流程圖的區(qū)別,這邊給大家簡單介紹一下


業(yè)務(wù)流程圖:

意思就是在這個(gè)需求系統(tǒng)中,相關(guān)利益者的業(yè)務(wù)關(guān)系,任務(wù)信息的流向的一個(gè)圖標(biāo)。比如這個(gè)簡單的例子,用戶在點(diǎn)外賣這個(gè)場景中,相關(guān)的利益者有用戶、店家、外賣員三者,那么當(dāng)用戶開始觸發(fā)流程后,這3者在這個(gè)流程中就會(huì)各司其職,而業(yè)務(wù)流程圖也很明顯的告訴大家所有聯(lián)動(dòng)者的指責(zé)和流程走向。


任務(wù)流程圖:

用戶在具體執(zhí)行某一個(gè)任務(wù)時(shí)候的工作流程,以及其核心任務(wù)的操作步驟,比如在登錄注冊(cè)這個(gè)任務(wù)中,用戶需要進(jìn)行一系列的操作,在這個(gè)流程中用戶的操作引發(fā)的系統(tǒng)判斷需要詳細(xì)說明。



界面流程圖:

界面之間的跳轉(zhuǎn)關(guān)系和路徑,在這個(gè)流程圖中,我們不需要吧詳細(xì)的說明寫上,只需要將需求中涉及到的頁面跳轉(zhuǎn)進(jìn)行敘述即可。

b.相關(guān)說明和規(guī)則

接下來就要開始我們交互文檔最為關(guān)鍵的部分了,如何書寫交互說明,以及交互說明應(yīng)該包含的內(nèi)容。


1.全局思考

在做交互方案也就是我們畫原型的時(shí)候會(huì)思考一些問題:

a.整體思考

1.信息架構(gòu)是否容易理解,信息分類是否合理,比如我們的信息架構(gòu)是否采用了用戶容易理解的,市面上常用的信息架構(gòu)。


2.信息層級(jí)和路徑是否合理,不一定要最簡,但是要高效,信息的優(yōu)先級(jí)是否放置準(zhǔn)確,信息組織是否具有相關(guān)性、邏輯性。


3.主題是否清晰,3秒內(nèi)告訴“我”在哪里,并且可以做什么


4.方案的延展和后續(xù)功能規(guī)劃的可擴(kuò)展性


b.用戶權(quán)限

根據(jù)不同用戶的權(quán)限對(duì)該需求進(jìn)行檢查,比如普通用戶、vip用戶、內(nèi)外網(wǎng)用戶、游客用戶,在登錄未登錄時(shí)候?qū)π枨髢?nèi)功能的使用是否有影響


c.登錄方式

用戶登錄和注冊(cè)、終端的兼容,不同方式注冊(cè)的用戶是否需要補(bǔ)填相關(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)后臺(tái)的配置獲??;并且獲取的方式是如何的,是需要手動(dòng)下啦刷新還是切換頁面自動(dòng)刷新,還是設(shè)定時(shí)間自動(dòng)刷新。


字段、圖標(biāo)是從接口獲取還是前端寫死,以及氣泡展示的規(guī)則等等。另外一張圖片可能用在多個(gè)地方,而可能呈現(xiàn)的尺寸不同,所以在涉及到相關(guān)圖片使用時(shí)要注意剪裁規(guī)則和圖片的來源。

b.緩存機(jī)制

圖片以及一些資源通常我們需要對(duì)其進(jìn)行緩存,有些同學(xué)不清楚什么是緩存,緩存是在計(jì)算機(jī)上的一個(gè)原始數(shù)據(jù)的復(fù)制集,一般來說需要緩存的內(nèi)容是通過瀏覽產(chǎn)生的,包括圖片以及cookie等,瀏覽過的視頻和廣告也會(huì)被緩存。同時(shí)在不同的網(wǎng)絡(luò)環(huán)境下緩存的時(shí)間標(biāo)準(zhǔn)也不同,無網(wǎng)絡(luò)那肯定只能讀取緩存文件,wifi環(huán)境下緩存時(shí)間可設(shè)置的短一些,而流量環(huán)境下時(shí)間就可以設(shè)置的偏長。


c.狀態(tài)

狀態(tài)大家都應(yīng)該都會(huì)寫,主要包含的就是初始狀態(tài)(冷啟動(dòng)無緩存第一次進(jìn)入)、空狀態(tài)(無任何內(nèi)容比如空的購物車)、常規(guī)狀態(tài)、異常狀態(tài)(網(wǎng)絡(luò)中斷、接口報(bào)錯(cuò))還有過期狀態(tài)等

d.顯示

數(shù)據(jù)和內(nèi)容的極限值,最大和最小,比如粉絲和關(guān)注的數(shù)量,小于1萬人則顯示完整的數(shù)量,大于等于1萬小于11000則顯示1萬,大于11000小于12000則顯示1.1萬,這樣的方式。另外包括標(biāo)題極限為一行顯示,超過部分的顯示規(guī)則。敏感信息、錯(cuò)誤提示以及超時(shí)的信息提示。金額的格式使用¥xxx還是xxx元,小數(shù)點(diǎn)保留的規(guī)則。日期的顯示格式是xxxx年xx月xx日還是xxxx-xx-xx還是xxxx/xx/xx等等

3.反饋、提示、手勢(shì)

反饋和提示的樣式有很多種,一般反饋指的是用戶對(duì)某一個(gè)控件進(jìn)行觸發(fā)后獲得的反饋,比如按鈕按下的反饋,以及之后收到的反饋,是進(jìn)行跳轉(zhuǎn)還是給用戶提示,采用的是模態(tài)還是非模態(tài)的提示。比如點(diǎn)擊關(guān)注某個(gè)人的按鈕后會(huì)提示關(guān)注成功,比如退出某個(gè)圖文編輯會(huì)二次確認(rèn)是否退出,再比如抖音長按后出現(xiàn)的3個(gè)操作反饋,還有支付成功后的動(dòng)效提示、惡意多次操作后的提示等等


如果有手勢(shì)交互也需要說明,比如滑動(dòng)后內(nèi)容置頂、拖拽、左右輕掃的tab滑動(dòng)、重按的3dtouch等等


4.加載

使用模態(tài)還是非模態(tài),如果是模態(tài)加載請(qǐng)盡量使用情感化設(shè)計(jì)來減少用戶焦慮。如果是非模態(tài),根據(jù)信息呈現(xiàn)和體驗(yàn)采用分步加載還是預(yù)加載還是智能加載。如果是分布加載就選擇先加載資源較小的內(nèi)容,再加載圖片,可以先將圖片模糊化粗渲染給用戶呈現(xiàn),包括在瀏覽信息流的時(shí)候的分頁加載也是可以的。如果更智能化一些也可以預(yù)判用戶的行為進(jìn)行內(nèi)容加載,例如當(dāng)用戶在某個(gè)圖文前停留時(shí)間達(dá)到某個(gè)值后就預(yù)先給用戶加載里面的內(nèi)容。


加載的全局方式在方案中需要考慮,頁面加載、下啦刷新等等,需要統(tǒng)一。


5.環(huán)境、設(shè)備與場景

a.不同設(shè)備、廠商的不同版本


都會(huì)影響到方案的落地和用戶體驗(yàn)這個(gè)要非常注意。比如一些交互控件我們?cè)?、iphonex和大屏幕尺寸上使用起來效果很好,但是小屏幕的時(shí)候這個(gè)交互控件顯得就很難受,所以需要仔細(xì)斟酌用戶的使用情況。另外還有橫豎憑情況的交互方案是否兼容、是否需要與其他硬件進(jìn)行兼容。


b.白天和晚上是否需要做不同的風(fēng)格設(shè)計(jì),以及在是否需要給用戶遮擋隱私的功能。


6.文案

文案這點(diǎn)很多設(shè)計(jì)師都忽略了,你們有沒有聽說過一個(gè)叫文案設(shè)計(jì)師的崗位。其實(shí)文案在我們產(chǎn)品設(shè)計(jì)中是非常重要的。首先一個(gè)產(chǎn)品的文案對(duì)應(yīng)的語氣和產(chǎn)品調(diào)性也是相關(guān)的,就好比我們說產(chǎn)品有它自己的性格一樣,另外文案的使用直接就影響用戶對(duì)該信息的理解,比如一個(gè)對(duì)話框的文案是:確定退出嗎?下面會(huì)有兩種不同的選擇,一個(gè)確定,一個(gè)是退出,大家覺得哪個(gè)比較好?還有就是不加“嗎”,就變成了:確定退出?這樣描述出來的語言給人感覺很冰冷,甚至有一些威脅。


所以首先我們的文案是否有溫度,和產(chǎn)品的個(gè)性是否相匹配。其次文案的表述是否準(zhǔn)確和通俗易懂,比如你告訴程序員一句話,幫我去菜市場買西瓜,如果有西紅柿,幫我買兩個(gè),你會(huì)帶什么東西回家?程序員版:if(看到西紅柿)西瓜等于2;else 西瓜=1。buy 西瓜。條件:看見西紅柿 執(zhí)行命令:買兩個(gè)西瓜一語道破版:其實(shí)吧,看到西紅柿呢是賣兩個(gè)西瓜的觸發(fā)條件…沒看到就買一個(gè)西瓜,看到就買兩個(gè)西瓜。所以這里出現(xiàn)的不僅僅是程序員的思維和我們的差異化,也說明了一句話沒有表述清楚所帶來的問題是很大的。


另外就是文案用語的一致性,在整個(gè)產(chǎn)品同樣的場景中,我們需要統(tǒng)一文案用語。


7.常見控件

具體見下方列表

8.撰寫方式

作為一個(gè)設(shè)計(jì)師,不管是否在做視覺,我們都需要對(duì)文檔有一個(gè)美化意識(shí),如果你的文檔非常凌亂,那么在別人眼里就會(huì)覺得你是一個(gè)比較粗心大意,不夠負(fù)責(zé)任的人,所以我們盡量在做交互輸出文檔的時(shí)候也畫的美觀一些。


目錄

首先在目錄的撰寫時(shí)候要進(jìn)行分類,通常我做的時(shí)候會(huì)對(duì)該需求以頁面父子集關(guān)系進(jìn)行創(chuàng)建,父集為核心頁面,子集為其下的相關(guān)子頁面,這樣頁面的流轉(zhuǎn)和歸屬關(guān)系就不會(huì)搞錯(cuò)。


說明

在撰寫規(guī)則與說明時(shí)可以通過標(biāo)簽法進(jìn)行標(biāo)簽說明的撰寫方式,同樣在視覺上保持美觀,對(duì)比與對(duì)齊的運(yùn)用,具體該寫什么東西上面已經(jīng)說明就不贅述了。除了交互規(guī)則以外,高階的交互設(shè)計(jì)或者產(chǎn)品經(jīng)理還需要補(bǔ)充業(yè)務(wù)規(guī)則,比如排序、商品抓去規(guī)則、權(quán)重、算法、活動(dòng)規(guī)則等等這里就不展開說了。


總結(jié)

文檔的形式有非常多種,針對(duì)不同的公司和產(chǎn)品也需要作出相應(yīng)的調(diào)整,能夠滿足需求和方便協(xié)作,目的就達(dá)到了,我們并不希望過多的時(shí)間花在文檔的撰寫上,而是希望大家在做設(shè)計(jì)時(shí)多思考業(yè)務(wù),本次分享就到這里啦~

[教程作者:應(yīng)駿]
免責(zé)聲明:本站文章系圖趣網(wǎng)整理發(fā)布,如需轉(zhuǎn)載,請(qǐng)注明出處,素材資料僅供個(gè)人學(xué)習(xí)與參考,請(qǐng)勿用于商業(yè)用途!
本文地址:http://likemindfilms.com/tutorial/id4204.html
下一篇:沒有了
設(shè)計(jì)語言 - 表單(高級(jí)搜索、基礎(chǔ)校驗(yàn)表單、控件校驗(yàn)表單、彈窗)
沒有了
×