迭代的設計 - 網頁設計

http://webdesign.zoapcon.com

從大的發展來看,
網站就是一塊試驗田,一塊在錯誤中成長、在錯誤中變強變大的試驗田。這決定了互聯網產品的成長路線,一定是一個反復修正和迭代的曲線。
很多,多年前的產計,當時未能取得成功,又得還一敗涂地。拿到今天,稍加包裝就成了最熱門最合適的設計。究其原因,我認為大多數都屬于“時機問題”,當初那些產品設計,面臨的很多環境并不成熟。究其錯誤,我認為大多數都屬于過于“激進”,在互聯網這個世界,如果你要從一開始就做徹徹底底的去創新,基本沒有成功的可能。
回顧互聯網歷史,我們不難發現,幾乎所有成功的產品都是一個不斷在演變的產品。包括yahoo、google、myspace、facebook、taobao、QQ等等,乃至MS。

回到產品設計本身,
早期“階段性”的流程方式給我們產品開發和設計,帶來了無盡的“返工”和低質量設計。往往前一個“階段”的細節失誤,就能導致后一個階段的徹底垮工。
特別是我們從目錄網站走到內容網站,又走到了今天的社區,網站本身的跌代性和反復修改變得越來越快。“階段性”的流程方式無法“多團隊同時協作”,導致的低效率,越來越凸顯。

于是我們開始針對“產品更新快”、“迭代頻繁”、“多團隊協作”,等特性需求而改進的一些產品設計流程。這樣的流程從大體上可以分成三個要點:按階段發展相互依賴 + 表現層和底層相對分離 + 循環漸進反復迭代。

可以嘗試用這樣的一張草圖來表現這種“流程”:

 

1、產品團隊是核心。
產品團隊發起項目,做前期的整體調研和評估,確定產品的定位、方向,以及大的產品概念設計。
在這個基礎上將所面向的用戶群進行大致劃分,對不同用戶群體的需求進行概要分析和總結。
最后產出:產品的整體框架,重要需求點的業務邏輯。

2、表現層和底層相對分離。
對于研發來說,產品的產出物都是數據。產品架構就是他的底層數據結構,業務邏輯就是他的數據邏輯。(研發我只懂皮毛,具體內容不一定完全正確)
對于設計來說,之前對于用戶群的劃分、對于需求的分析將演變成未來網站的內容設計;產品架構將演變成網站的信息架構(欄目、布局、導航等),業務邏輯是未來交互設計的依據。
最后,研發的前端的接口和設計的前端開發相結合。

3、這樣做最大的好處在于:
業務發展到一定時候,當底層需要升級或者改進,表現層可以不用變化;
如果表現層的設計需要“改版”,底層可以不用變化;
只有當產品方向有變,或者業務邏輯發生變化,才會牽扯到底層和表現層同時變化。

4、按階段發展相互依賴。
單看產品+研發,或單看產品+設計,每一個從上至下的過程都必須具備先后的階段性,上一個的過程決定了下一個過程的大致范圍,下一個過程影響并補充了上一個過程的詳細內容。
比如,沒有大的產品框架就沒有具體的信息架構,在具體的信息架構設計過程中,又會修正并補充整體的產品框架。
再比如,沒有需求分析,就不能有具體的內容設計,在具體的內容設計過程中,又會細化需求并有可能合并或者拆分已經修改需求。

5、循環漸進反復迭代。
這一點和第四點有很大的關系,理解這一點可以先看一下Jesse James Garrett 在《THE ELEMENTSOF USER EXPERIENCE》一書中(這是一本每個產品設計者都應該閱讀的入門好書,中文叫《用戶體驗的要素》,由Angela翻譯,因為我很討厭這個書名里莫名其妙多了一個“的”字,所以以后我只會引用英文書名。),關于“迭代”的解釋:

 

JJG在把體驗分成了戰略、范圍、結構、框架、表現五個層面。我認為這五個層在細化的過程中,已不很適合如今的互聯網產品設計,而且內容過于粗略,屬于概念性質的東西,很難應用到操作層面。但,他在這里講述這五個層在具體應用中的迭代關系,可以應用現在的設計中。

Angela是這樣翻譯的:“你應該計劃好你的項目,讓任何一個層面中的工作都不能在其下層面的工作完成之前結束。… 在我們知道基本形狀之前,不能為房屋加上屋頂。… 要求每個層面的工作在下一個層面可以開始之前完成,會導致你和你的用戶都不滿意的結果。… 一個更好的方法是讓每一個層面的工作在下一個層面可以結束之前完成”。

拿到這里會有一點小變動,應該這么說:不能完整結束了這個階段的工作,才開始下個階段;在下個階段該結束的時候,完成這個階段這個階段的工作。(這也是為了我在前面給“完整”“整體”“大致”等關鍵詞加粗的原因)
比如,不要把需求整理的非常詳細以后再去內容設計,只要在內容設計該結束的時候完成需求整理;不要在開始信息架構設計的時候完全確定內容設計,只要在信息架構該確定的時候完成內容設計。也就是說“需求整理在信息架構開始的時候完成即可”。

(當然,這種做法一個更大的問題會出現:文檔維護比以往階段性的方式更繁復。 這一點,后面會詳細談到。 )

不可分割的“用戶調研”
細心的人可能已經看出,上面的設計并沒有加入“用戶”的內容。沒錯,上面的圖只是在說“設計”,并沒有提到用戶調研。
用戶調研應該貫穿于設計的任何一個環節,在整個設計過程中既起到“引導”的作用,又起到“校驗”的功效。加入了對用戶的研究以后,整個“迭代的設計過程”才會變得完整和豐滿。

事實上這邊文章應該屬于“迭代設計”的一半內容,在以往的培訓中我會加入用戶調研部分進去(比如,這張圖白板左邊是上面的內容,右邊就是用戶調研加入進去之后的“產品設計”過程。右邊的一半內容都是用戶調研)。這篇文章就不細說了,《Design IT.》 系列正式完成的時候再補充進去。

.

PS:
《Design IT.》將是一個很長期,很完整的系列。從設計方法,到產品市場、到具體的設計,到最后的測試和產品類的線上運營。
歡迎有興趣的朋友對每篇文章進行指正和補充。(為了保證更高質量的評論,我將關閉這個系列文章的評論。請在你自己的博客用“文章”回復,或者將你的文章發布到UCD大社區里。咱們可以把這些文章都聚合成話題)

 

arrow
arrow
    文章標籤
    網頁設計 web design
    全站熱搜

    inspirr 發表在 痞客邦 留言(0) 人氣()