|
做互聯(lián)網(wǎng)設(shè)計最重要是為了運營，藍圖和文檔好比做作業(yè)打草稿、畫畫先描白，經(jīng)驗豐富可以考慮先省下這步驟。因為如果不表現(xiàn)在具體web-based原型上，藍圖、文檔再好也無法快速切入開發(fā)流程，做為有大局觀的Producer應(yīng)該盡快意識到這點。
UED團隊合作與開發(fā)流程優(yōu)化是以前在雅虎做產(chǎn)品同事寫的，雅虎團隊的產(chǎn)品工程師們技術(shù)好，而且有來自美國團隊的協(xié)作經(jīng)驗傳承，做前端編程一直是他們的強項。但傳統(tǒng)瀑布模型進程必然要面對“前松后緊”問題，根源在于設(shè)計、技術(shù)團隊要互相等。因此，如果規(guī)避必須從觀念上做出調(diào)整：快速產(chǎn)出、快速迭代，也就是軟件工程里的AgileandIterativeDevelopment。
以前我也常抱怨做互聯(lián)網(wǎng)設(shè)計沒譜，一是資源緊、二是變化快。項目周期和人手似乎永遠(yuǎn)都無法滿足，來自內(nèi)部考慮不周、外部競爭壓力雙方的需求變更頻繁。其實這就是互聯(lián)網(wǎng)設(shè)計的常態(tài)，接下來提到的方法，分為三個大步驟，版本僅供參考。
Alpha.快速完成核心功能開發(fā)這里“藍圖”只是個代名詞，也許只有些藍圖片段，或規(guī)劃片段。曾經(jīng)我們在老板辦公室開會，根據(jù)頭腦風(fēng)暴結(jié)果、會議記錄直接做原型。這么說可能有點一覺回到解放前的感覺，事實如此，第一步很關(guān)鍵，但質(zhì)量不重要。
因為開始就期望得到完善想法是不可能的。比如，你開會描述個東西，讓同事提意見，可能大家什么都說不出來。但只要你動手做出具體原型，同事親自測試體驗之后，意見噼里啪啦一大堆就來了。在這層意義上，絕大多數(shù)原型是炮灰也應(yīng)該。
最初工作用自己最熟悉、最快速的手法完成，別讓開發(fā)團隊等。當(dāng)然，這部分代碼質(zhì)量將直接影響以后的迭代工作量，根據(jù)時間靈活安排。不要考慮的過于復(fù)雜，總結(jié)起來有三點：
盡早用web原型評估設(shè)計質(zhì)量
制作避免過早陷入web結(jié)構(gòu)和表現(xiàn)細(xì)節(jié)
設(shè)計避免過早陷入功能細(xì)節(jié)
每個業(yè)務(wù)都會有核心功能，也就是用戶的核心需求，基本上做產(chǎn)品前都會考慮清楚。可能核心功能內(nèi)還會有核心模塊，意思就是逐步提煉，找準(zhǔn)關(guān)鍵點下手，這樣才能搭好框架。也許經(jīng)過幾次迭代后，這部分工作已經(jīng)是個可以跑起來的低保真產(chǎn)品，頗具alpha版本規(guī)模。
Beta.迭代完成固化需求功能開發(fā)
搭框架不要下手太狠，別自以為經(jīng)驗豐富把盤子搞大。因為剛才說了，互聯(lián)網(wǎng)產(chǎn)品靈活最重要，雖然需求變化是經(jīng)常的事，但我們要把風(fēng)險控制在最低點。接下來在已有框架內(nèi)，用同心圓放大的模式，按優(yōu)先級實現(xiàn)輔助功能迭代，直至需求固化。
與此同時，產(chǎn)品設(shè)計團隊除了對低保真原型的繼續(xù)支持，還應(yīng)并行完善和提煉高保真原型，并且著手對產(chǎn)品規(guī)范中復(fù)用模塊的持續(xù)化整理，主要分為三部分：
web呈現(xiàn)效果迭代。先做圖再切效率太低，因此我是直接用css美化低保真原型，通常這步可以把效果做的很得體。實在有必要，最后再截屏用photoshop處理細(xì)節(jié)并完善css。
web結(jié)構(gòu)和表現(xiàn)迭代。我自己可以完成htmlframework,cssframework兩大塊。
web行為迭代。需要工程師協(xié)助完成javascriptframework。
也就是說，在包括beta版本以及之前，重中之重是實現(xiàn)功能需求層的良好用戶體驗?？稍L問性、兼容性、可用性、標(biāo)準(zhǔn)化、搜索引擎友好這些具體指標(biāo)不要過早引入到應(yīng)用開發(fā)中，讓它們都在高保真原型的迭代內(nèi)準(zhǔn)備就緒。
比如可用性，做低保原型時盡量用最容易的方式解決問題，不要過早追求“用戶體驗”玩花樣。大量的js互動效果和ajax異步加載會給原型維護、迭代測試帶來大麻煩。
再比如標(biāo)準(zhǔn)化，良好結(jié)構(gòu)的web頁面，很受應(yīng)用開發(fā)工程師歡迎，樣式表則無傷大雅。因此我們可以多花功夫先處理html結(jié)構(gòu)，節(jié)省時間讓css樣式表與功能開發(fā)并行迭代優(yōu)化。
Release.模塊化迭代提升用戶體驗
至此如果一切順利的話，應(yīng)用程序已經(jīng)模塊化并測試通過，設(shè)計規(guī)范也已經(jīng)模塊化、并有針對性的給出了高保真原型界面標(biāo)準(zhǔn)。用戶體驗的具體指標(biāo)，已經(jīng)在高保真原型的迭代中測試通過。
經(jīng)驗豐富的Producer可能都了解，成熟網(wǎng)站真正模塊化后的內(nèi)容其實不多，無非頭、尾、導(dǎo)航、頁簽、表格、列表、搜索等等。傳統(tǒng)方法流程的沒有把操作體驗與功能體驗割裂開來，以至于來回折騰，反復(fù)做了大量工作才讓產(chǎn)品模塊化。根據(jù)設(shè)計規(guī)范迭代提升用戶體驗有兩步：
先處理界面視覺效果，比如分情況美化數(shù)據(jù)表格、文章列表等。
再處理界面交互效果，比如可以把某些跨頁流程改為層異步加載等。
永遠(yuǎn)記住不可能一步到位，花本錢的創(chuàng)意設(shè)計要用保守方案，用戶體驗是奢侈的。對多數(shù)應(yīng)用開發(fā)工程師來說，使用樣式表控制表現(xiàn)是件神奇而時髦的事情。光禿禿的一個架子，加上css馬上就能風(fēng)光起來，并且還不影響已經(jīng)開發(fā)出來的程序，有點不可思議。
其他
敏捷設(shè)計思路同樣來自前輩們總結(jié)過的軟件工程思想，只不過換在了設(shè)計支持角度。真正的敏捷設(shè)計必然與開發(fā)綁在一起，只在產(chǎn)品階段的砍掉文檔、砍掉步驟、砍掉管理對全局影響不明顯。
對產(chǎn)品團隊來說，應(yīng)該不斷利用等待空閑調(diào)整規(guī)劃，用任務(wù)分解、故事板等專業(yè)手法出文檔優(yōu)化結(jié)構(gòu)。敏捷設(shè)計關(guān)鍵不在技術(shù)有多高深莫測，而是動作要跟得上節(jié)奏，前后銜接得當(dāng)，才可能把時間一點點摳出來。不墨守陳規(guī)，把專業(yè)方法打散使用，融會貫通于每個思考點。
UCD翻譯小組的同學(xué)們已將BoxesandArrows的這篇PrototypingwithXHTML譯成中文，操作細(xì)節(jié)和心得很豐富，關(guān)于快速迭代總結(jié)的相當(dāng)好。類似方法我們也已實踐近兩年，并且主導(dǎo)執(zhí)行過兩款大型產(chǎn)品，核心思想超過90%重合，以上補充了部分本地化快速產(chǎn)出經(jīng)驗。
原文說“只需要花費幾個小時，學(xué)習(xí)一下網(wǎng)上眾多的在線教程，你就可以立即開始書寫xhtml?！笔聦嵣霞词褂嬎銠C背景的同學(xué)，沒有兩三年功力，要實現(xiàn)兼顧前后的無縫協(xié)作都很困難，搞不好還會返工增加工作量。但長遠(yuǎn)來看，這樣的訓(xùn)練很有意義，用web方式做web-based產(chǎn)品設(shè)計的優(yōu)勢將更垂直的專業(yè)、體系化發(fā)展。
Spendjustafewhoursfollowinganyoftheinnumerableonlinetutorialsandyou’llbewritingXHTMLmarkupinnotime.
團隊成員越少，溝通效率越高；每人承擔(dān)越多，整體風(fēng)險越低。這是行云流水的產(chǎn)品、技術(shù)并行迭代的優(yōu)勢體現(xiàn)?？傊龑ζ俨寄Ｐ瓦M程深刻認(rèn)識，方法流程得靠團隊的內(nèi)力來推動。
|