a fieldnote about prototyping

延續與 acer, asker 對prototype的討論。我現在的工作,IA(資訊架構師),需要配合不同的PM、不同的企劃人員、不同的視覺設計人員、不同的程式設計人員、以及不同產業的業主。而且都是同時平行進行的!! A wonderful job!!

一些專案偏重視覺表現,一些則偏重資訊系統功能;有些專案允許有探索與訪談的時間,有些專案要「馬上看到」;
有的合作夥伴願意傾聽,有的則是本位主義;有的天馬行空,有的保守務實。

我的一個發現是,每個人對於「wireframe」、「prototype」、「moch-upmock-up」的定義與用法都不太一樣。該要去整合這些不同的看法,提出一種標準的定義嗎?我也不知道能不能,或這樣作對不對。我現在的態度是,先摸索每個人的認識基礎,與認知需求。然後試著丟出一些專案內大家都「可能」接受的溝通方式(但是也還是常常會有溝通不良)。我認為,原意上 prototype
應該是以「驗證(evaluation)」為主,但是實際上真的不常常有餘裕去作「開發測試」,而是在開發以及設計過程中,prototype
成為將設計概念呈現出來,以作為溝通以及輔助設計決定的工具。

目前我粗淺的觀察是:

  • PM 需要掌握工作分配、進度、報價。基本上,所有的溝通與文件PM都應該要知道裡面在講些什麼東西。
  • 企劃需要將他的想法表達出來。
  • 視覺設計需要知道他設計工作的資訊材料與規格、也許也要知道頁面編排的要求,需要產出能跟客戶溝通或確認的文件。
  • 程式設計需要知道功能需求以及邏輯動線,所有會使用到以即將會產生的資訊數量、更新頻率以及規格。
  • 業主會執行他們所擁有的「否決權」,假設你的努力並沒有打動或說服他的時候。

不同的專案生態

  • 有些專案生態中,只會有「一個語彙」用來作設計上的規格確認、測試與溝通。因此,這種專案中,不管叫做 「wireframe/prototype/mock-up」什麼的,反正都是同義詞。
  • 有的專案生態會分兩階段,一份是由由企劃或PM,為了作為專案規格文件之用,另一份是視覺設計為了與客戶確認視覺表現風格的。這會區分為兩個詞彙,可能會是「wireframe/prototype」、「prototype/mock-up」、「storyboard/A-copy」等等。這些詞彙受到專案參與人員各自固有文化領域的影響,會試著沿用或挪用以往的某種概念。
  • 應該也會有三階段的專案生態?不過我目前還沒碰到。

而我現在在不同的專案、不同的階段、不同的對象,分別都使用了:紙與筆,白板,Axura RP, PowerPoint, Visio, Excel, HTML 等等不同的工具。這個工具嘗試的清單我想還會持續下去,我一直想試試不同的工具在不同的情境下溝通,有什麼好處跟壞處。而我現在可能正好有這個機會可以讓我進行這項行動研究

其實我處理的個案經歷也有限,所以也還沒有什麼確定的心得可以分享的。只不過,看來台灣的網頁開發專案可能跟這塊土地一樣:都是「荒溪型」的居多:要嘛枯乾的要死,要嘛暴漲個幾天。恐怕是沒有什麼機會像國外那樣,有個「整個夏天的原型開發」這類奢華享受。