中文字幕在线观看,亚洲а∨天堂久久精品9966,亚洲成a人片在线观看你懂的,亚洲av成人片无码网站,亚洲国产精品无码久久久五月天

如何寫一份交互說(shuō)明文檔

2019-04-03    來(lái)源:Heidi格物志

容器云強(qiáng)勢(shì)上線!快速搭建集群,上萬(wàn)Linux鏡像隨意使用

離開(kāi)交互圈已經(jīng)有段時(shí)間了。但由于博客還在,還是能夠偶爾收到一些郵件,上周有位同學(xué)問(wèn)我:我在求職,我看到很多招聘說(shuō)明上需要交互設(shè)計(jì)師編寫界面交互設(shè)計(jì)文檔,請(qǐng)問(wèn)界面交互設(shè)計(jì)文檔是什么文檔?怎么編寫呢?

這讓我想起來(lái)2009年自己在項(xiàng)目里也大力推行過(guò)交互說(shuō)明文檔(在下文中,簡(jiǎn)稱為DRD),格式倒沒(méi)什么限制,交互設(shè)計(jì)師自己寫到界面上也行,單獨(dú)文檔成文也行,總之就是讓交互設(shè)計(jì)師能夠?qū)⒔缑娉休d不了的信息通過(guò)文檔沉淀下來(lái),降低項(xiàng)目里的溝通成本和風(fēng)險(xiǎn)。今天整理電腦,翻出以前的PPT,分享之。

這將涉及到幾個(gè)問(wèn)題:

一、什么是交互說(shuō)明文檔(DRD)?

所謂DRD即是用來(lái)承載交互說(shuō)明,并交付給前端、測(cè)試以及開(kāi)發(fā)工程師參考的文檔。

在項(xiàng)目中,交互設(shè)計(jì)師的主要產(chǎn)出物可能依次是:site map,page flow,wireframes。有的大型項(xiàng)目前期,交互設(shè)計(jì)師有可能還會(huì)產(chǎn)出用戶需求分析文檔(與PD產(chǎn)出的市場(chǎng)需求文檔不一樣的是,URD更多側(cè)重于對(duì)目標(biāo)用戶的需求分析)。

DRD則很少有人專門撰寫。如果需要對(duì)交互設(shè)計(jì)進(jìn)行說(shuō)明,聰明的交互設(shè)計(jì)師往往會(huì)直接標(biāo)注在線框圖里,或者在項(xiàng)目中不斷和前端工程師和開(kāi)發(fā)工程師口口相傳,反復(fù)驗(yàn)收,不斷迭代修改來(lái)確保所有的交互設(shè)計(jì)意圖最終得以呈現(xiàn)。

二、 為什么要寫?

DRD非項(xiàng)目必需環(huán)節(jié),一般情況下也不會(huì)為交互設(shè)計(jì)師專門留出相應(yīng)的時(shí)間預(yù)估。沒(méi)有這份文檔,項(xiàng)目也會(huì)繼續(xù),但是可能項(xiàng)目會(huì)為此承擔(dān)不必要的溝通成本和時(shí)間成本。嚴(yán)重的話,項(xiàng)目的質(zhì)量也會(huì)受到影響。所以寫與不寫,交互設(shè)計(jì)師需要做把握,時(shí)間被統(tǒng)一包含在“線框圖”環(huán)節(jié)內(nèi)——如果你要寫,請(qǐng)?jiān)谠u(píng)估時(shí)預(yù)留1-2天的時(shí)間。

那么,結(jié)合我過(guò)去的經(jīng)歷,談一下此文檔的必要性。

下圖是一個(gè)產(chǎn)品開(kāi)發(fā)項(xiàng)目基本的流程。

敏捷開(kāi)發(fā)意味著很多不同角色的流程需要并行操作。如果等到產(chǎn)品經(jīng)理的FRD已經(jīng)全部敲定,交互設(shè)計(jì)師再開(kāi)始去畫線框圖,固然會(huì)減少溝通成本和返工風(fēng)險(xiǎn),但是同時(shí)意味著交互設(shè)計(jì)師的很多想法不被采納。如果產(chǎn)品經(jīng)理再?gòu)?qiáng)一些,他甚至?xí)贔RD里連原始的DEMO也一并繪制出來(lái)了,功能性的需求和界面交互的需求有時(shí)無(wú)法區(qū)分太清楚——比如他會(huì)在FRD里直接要求每頁(yè)條目40條,超過(guò)40條即分頁(yè)。而交互設(shè)計(jì)師可能會(huì)認(rèn)為像蘑菇街那樣不斷裝載出足夠長(zhǎng)的頁(yè)面會(huì)更親和……所以,我們希望是和產(chǎn)品經(jīng)理同時(shí)開(kāi)始工作,在術(shù)業(yè)有專攻的時(shí)候相互補(bǔ)充。

同樣,開(kāi)發(fā)工程師也希望及早介入需求,在FRD并未確認(rèn)的時(shí)候就了解需求,進(jìn)而將商業(yè)需求和功能需求轉(zhuǎn)化為開(kāi)發(fā)工程師看得明白的開(kāi)發(fā)需求清單(這個(gè)清單,大部分叫做UC,即USE CASE),當(dāng)這份清單由工程師需求分析師——在過(guò)去,這個(gè)角色被叫簡(jiǎn)稱為RA,但是目前已經(jīng)取消此專門的職位,而是由開(kāi)發(fā)工程師代表?yè)?dān)綱此環(huán)節(jié)工作,為了便于描述,在此文里,我仍然將做這件事情的人稱為RA——交付給具體的執(zhí)行工程師后,執(zhí)行工程師基本上可以當(dāng)作一條條的checklist開(kāi)始高效工作,而不必再思考商業(yè)邏輯和需求。同樣,測(cè)試工程師也需要編寫具體的文檔去指導(dǎo)很多測(cè)試人員在開(kāi)發(fā)后高效測(cè)試,這也是基于UC和FRD去撰寫的。

所以,開(kāi)發(fā)需求分析是個(gè)很重要的環(huán)節(jié)。那RA是如何來(lái)完成需求分析工作的呢?

1、前期介入,對(duì)PD進(jìn)行開(kāi)發(fā)需求評(píng)估支持;

2、參與每次的FRD評(píng)審會(huì);

3、詳細(xì)審閱FRD文檔并不斷與PD確認(rèn)。

對(duì)于做這件事情的人來(lái)說(shuō),足夠詳盡的FRD是非常重要的。所以一份FRD雖然是PD產(chǎn)出,但是很多實(shí)施細(xì)節(jié)則是由開(kāi)發(fā)工程師不斷溝通評(píng)估并確認(rèn)下來(lái)的。而設(shè)計(jì)需求的傳遞,卻存在很多問(wèn)題。除了線框圖,沒(méi)有“詳盡的說(shuō)明性的文檔”告訴他們。比如:

一方面,交互設(shè)計(jì)師對(duì)產(chǎn)品經(jīng)理說(shuō):這塊由我們來(lái)考慮,你的文檔不必包含設(shè)計(jì)上的說(shuō)明,這隨時(shí)會(huì)調(diào)整的。

另一方面,線框圖的評(píng)審有時(shí)會(huì)讓RA參與,有時(shí)卻沒(méi)有叫他們。即使叫上了他們,他們也會(huì)發(fā)現(xiàn)交互設(shè)計(jì)的需求變化要比FRD變化快。另外,他們會(huì)認(rèn)為UC不必寫太多關(guān)于交互設(shè)計(jì)的需求。

在某個(gè)大型項(xiàng)目結(jié)束后,作為交互設(shè)計(jì)師,我進(jìn)行了一些調(diào)研,聽(tīng)聽(tīng)這相關(guān)人員是怎么表述問(wèn)題的:

開(kāi)發(fā)部門的需求分析師:

1、每次變動(dòng)都很痛苦,設(shè)計(jì)變了之后,我就要跟著改UC,改截圖,有時(shí)候UED改了還忘了通知我們,導(dǎo)致UC有問(wèn)題……

2、頁(yè)面交互的需求容易漏掉,因?yàn)閁C里面不可能寫太多交互方面的東西。

3、希望UED能夠在提交HTML DEMO給RA時(shí),能同時(shí)給出一份頁(yè)面元素描述文檔,需要介紹html demo中的文案、鏈接以及相關(guān)的圖片尺寸或顯示字符個(gè)數(shù),F(xiàn)在RA在這方面花費(fèi)的時(shí)間比較多,經(jīng)常要和UED去確認(rèn)這些內(nèi)容。

產(chǎn)品經(jīng)理:

前期RA和PD溝通過(guò)程中,有很多交互點(diǎn)點(diǎn)不能夠明確,比如“默認(rèn)顯示多少屬性值”,“標(biāo)題顯示多少字符”等。在以往的需求和項(xiàng)目中,對(duì)待這些問(wèn)題我們都是想到一點(diǎn)補(bǔ)一點(diǎn)的到FRD文檔或者郵件中去。既增加了溝通成本又會(huì)存在遺漏細(xì)節(jié)的風(fēng)險(xiǎn)。PD為了可控性的需求,往往會(huì)“越俎代庖”,直接在FRD注明這種需求(對(duì)于交互設(shè)計(jì)師來(lái)講,卻又導(dǎo)致沒(méi)有發(fā)揮余地)

走訪了一些交互設(shè)計(jì)師后,他們也存在如何清晰無(wú)遺漏將交互設(shè)計(jì)需求傳遞下去的困惑:

交互認(rèn)為很平常的設(shè)計(jì)需求,如果不表達(dá)出來(lái),還是容易被前端和開(kāi)發(fā)忽略掉。我經(jīng)歷的一個(gè)項(xiàng)目,前端從頭到尾更換了三個(gè)人,每次我都要重復(fù)去講解下設(shè)計(jì)需求,講得口干舌燥。而且做好后,還需要去驗(yàn)收。

DRD做為參考手冊(cè),一定程度上避免不吻合的問(wèn)題發(fā)生。

即使有問(wèn)題發(fā)生,也可以作為界面驗(yàn)收時(shí)的Checklist。將“我對(duì)A說(shuō),我對(duì)B說(shuō),A對(duì)B說(shuō)”,轉(zhuǎn)變?yōu)?ldquo;A和B共同參考同一份文檔”,減少溝通成本及信息不對(duì)稱。

全程影響用戶體驗(yàn)(一直到測(cè)試,都需要參照設(shè)計(jì)文檔)。

可是以下問(wèn)題都可以通過(guò)一份DRD來(lái)解決嗎?

標(biāo)簽: 用戶體驗(yàn) 交互設(shè)計(jì)文檔 界面交互設(shè)計(jì)文檔 

版權(quán)申明:本站文章部分自網(wǎng)絡(luò),如有侵權(quán),請(qǐng)聯(lián)系:west999com@outlook.com
特別注意:本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)!
本站所提供的圖片等素材,版權(quán)歸原作者所有,如需使用,請(qǐng)與原作者聯(lián)系。

上一篇:Path商業(yè)模式:銷售虛擬產(chǎn)品 使用戶獲得體驗(yàn)

下一篇:淺析iPhone平臺(tái)三種應(yīng)用類型的布局方式