延續與 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 等等不同的工具。這個工具嘗試的清單我想還會持續下去，我一直想試試不同的工具在不同的情境下溝通，有什麼好處跟壞處。而我現在可能正好有這個機會可以讓我進行這項行動研究。
其實我處理的個案經歷也有限，所以也還沒有什麼確定的心得可以分享的。只不過，看來台灣的網頁開發專案可能跟這塊土地一樣：都是「荒溪型」的居多：要嘛枯乾的要死，要嘛暴漲個幾天。恐怕是沒有什麼機會像國外那樣，有個「整個夏天的原型開發」這類奢華享受。