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