線框(wireframe),要還是不要?
有言道“一圖勝千言”,可敏捷的世界里卻沒有銘記這句話。至少,很多敏捷團隊中的設計人員這么想。在某些團隊中,設計人員必須創建小的設計增量,而這個過程不一定能產生最好的結果。對于其他團隊來說,“線框”是官僚體系的產物,阻礙了開發工作的高效推進。
Booshtukka提到,在當前的情境下,很難怪罪設計人員對于敏捷的不忿。敏捷流程希望讓設計人員以小步增量的方式交付設計。創意因此面臨困境。
這根本沒有意義:創意本身是一個整體。假如有人要你畫一棟房子,但是要一點一點地畫。首先,畫出煙囪;然后是窗戶;然后畫做為背景的山;然后是正門。你非給逼瘋了不可,而且,你在畫下一筆的時候,必須要改變之前的部分,以保證整個作品符合常理。
Sam在敏捷可用性論壇上發起一個類似的討論,以理解“線框”的相關性和重要性。William Pietri回應了Sam,提到這在很大程度上應該由團隊和個人來決定,決定他們是否需要線框,以及細節所應達到的程度。他認為:
對于這些問題,我覺得沒有統一的答案。我們在尋找的,是個人差異、團隊差異和最小浪費之間的交集。對我來說,達到目的的唯一方式是不斷微調具體流程,看看如何盡量減少不良影響,同時仍能產出出色的工作成果。
Gene Arch和Paul Spencer提到:根據他們的經驗,線框有其固有的價值,在很多時候,它可以幫助他們預見困難情形。對于他們來說,他們的設計人員與產品負責人一起工作,為下個sprint設計優先級最高的內容。
Pat Cheugn引用了文章“HTML線框和原型:都是收益,沒有痛苦”,他認為:對于設計人員來說,就應該使用線框。在他看來,線框的好處在敏捷世界中更為彰顯。
產生HTML線框和原型的確能讓開發團隊盡可能接近最終產品。它有助于過濾壞主意,并讓好想法涌現出來……特別是在線框能夠展示出用戶流程和頁面流程的情況下……
最大的收益來自于:線框能夠開綠燈,告訴大家一切都已準備齊備,可以開始實現后端編碼。從紙上到電腦不需切換,也不用從PSD文件切換到HTML,很多CSS風格都已經定義完成,而且實現也很快,因為HTML線框總是以范圍的方式定義的。
Sascha Brossmann回應了類似的討論,并認為:在敏捷環境中進行用戶體驗設計活動,最重要的原因,是要在開始開發之前把握更清晰的全局,并不斷更新。他補充道:如果線框能夠先于開發一個迭代創建出來,這也會很有幫助。Yoni補充說到:
我發現:(保真程度不同的)互動原型是敏捷環境(也包括其他環境)中最有效的交付物。提供這樣一個人工產出,對于開發人員來說更為熟悉,而且在交付之后也不需要更多解釋和手把手的指導,溝通的溝壑也在不意間降低了。
William提出一種有趣的方法,用來驗證線框對于團隊的需求和意義。他認為:開發人員和設計人員對于線框的認識總是存在差異。如果設計人員能夠展示出線框的意義,這將會很有幫助。
要想說服開發人員你的方法的價值所在,你要試著在某些用戶故事中嘗試各種方法,并在回顧會議中談論發生的事情。如果你能發現他們沒有看到的東西,想辦法展示給他們看。
Jér?me Gravel-Niquet補充了他們團隊認為有效的方法。他認為:
- 從用戶故事的基本描述中,我們迅速創建出了線框。
- 線框完成后,我們在訪談中展示給最終用戶并收集反饋,并會根據反饋調整線框。
- 當我們有了堅實后盾(用戶和委員會審核通過)并充滿自信之后,我們馬上就會設計界面。
- 有了這些東西,我們會創建文檔,解釋不同的交互和功能(用wiki的方式)。
- 作為擅長整合的用戶體驗設計人員,在開發人員著手用戶故事之前,我也會盡量整合界面和其相關的互動。
因此,大家一致同意線框的意義。它能幫助團隊內部、以及與利益相關者之間取得更好的效果。關鍵在于做剛剛夠好的工作,并保證流程輕量級。保證線框的高質量也很重要,因為在Alex Jones看來,概略的線框相當于用戶體驗的comic sans字體。
查看英文原文: Wireframes or No Wireframes
來源:http://www.infoq.com/cn/news/2010/06/agile-wireframes
- 目前還沒評論,等你發揮!