【．不如歸去．】

不知道該怎麼給這篇文章下 title, 這恐怕是我第一次在部落格裡提起網路業相關知識(？還是甘苦談？)的文章。

從來不想寫，是因為我其實仍不夠專業，不適合談專業性的議題，但從 2002 年到現在，從事網路相關行業似乎也到了一個可以被冠上資深兩個字的年份了，也從 2009 年開始接下一些件簡單的分享講師，不過前輩實在太多了，網路變化的速度又太快了，誰敢說自己擁有專業呢？何況我也不是一個喜歡拋頭露面的個性，心態上就像賈馬克一樣，只想低調的做自己喜歡的事就好...

因為最近看著很多身邊新生代的 PM 正再走我以前曾走過的天堂路，加上這兩天跟幾個夥伴討論到關於一些東西的定義，我希望我淺薄的經驗和理解能給予一些幫助（對不起自己手邊正有大專案，一直沒時間給你們做分享），但仍必須再三強調一點 - 網路變化的太快、網路業 buzzword 太多，有時候連已知的 ”定義“ 都有可能跟著時間一起改變 e.g.,這兩年台灣出現了一個 UX....(國外早討論了很久，但台灣是近年才紅，成為buzzword），以前都直接認為 UI 就得包含思考現在所謂 UX 的工作不是嗎？XD

回歸正題

跟大家分享關於 Wireframe、prototype、mockup 在專案之中擁有的功能意義


Wireframe - 我們叫它線框或線稿

• 低成本，修改快速，它應該包含這個頁面中該有的元素內容，靜態的。

• 它是一個基本可視的界面，對於討論概念、功能、檢查有沒有漏掉的元素都很有幫助，絕對比大家空靈幻想要有溝通效率。
  
  
• 一般正規 Wireframe 是黑色、白色、灰色，最多加上藍色，藍色通常用在 navigationbar 做與下方區塊的區分，或用在特別的功能上或連結上，總之藍色多數是用做區分的代表，再來就是 LOGO 有時候會帶有顏色，其他顏色基本上是都不會出現在典型的 Wireframe 中。

它是否需要考慮到 UI ？當然要！線框不是一個無意義的框架，它討論到最後(一定會改個幾版)應該包含這個產品頁面中每一個重要元素、功能的代表，而這些功能、元素你不可能完全沒有 UI 的，有些功能本身就是 UI 的一部份 e.g., sidebar 還是 topbar 。

但 Wireframe 不該俱有太多的細節，我指的是太多的視覺化，因為那容易讓你溝通的對象誤會並且被引導到「這一塊好像就是長這樣、這個顏色」於是大家的討論會失焦～
不要忘記 Wireframe 的功用是加速討論與增進溝通效率，如果要用很多時間來製作或是讓討論失焦就失去它的意義了。


mockup - 視覺的雛形、實品的模型

• 比實品的成本低一些，有點像是打樣的概念，可以算是視覺化的 Wireframe ，是被設計過的視覺化，也是靜態的。
  
  
• 它應該包含頁面的結構內容，因此靜態的 UI，在 mockup 要被呈現出來，當 mockup 階段結束時靜態 UI 應該是被確認完的。
  
  
• mockup 最重要的功能是收集使用者、老闆、客戶的建議與回饋。

prototype - 原型

• 動態的，是用來模擬使用者交互界面，成本高，不過現在有很多線上的工具可以比較快速做出基本的 prototype

• 功用是體驗產品與內容，用來測試接近最後成品的感覺，prototype 不可能跟最後成品一樣，但應該是接近最終產品，不過 prototype 由於成本高，因此一般都會省略來加快開發時間。

prototype 可以是使用 Wireframe 來做，也可以是 mockup 來做，不過 mockup 當然會更接近更能體驗出最終產品。


如果專案可以經過這三個階段，就比較少會在最終產品 QA 時順便修改功能，降低大規模大工程的回頭修改，但這是理想化的情況，一般中小公司企業，在搶占市場時間以及公司資源人力與成本考量上，很難面面俱到如此理想化....


最後就是
最近常被問到的幾個問題

Ｑ：Wireframe 是我畫嗎？
正規來說會是 UI 畫，因為 PM、產品企劃應該跟 UI 是非常緊密的工作在一起，一直在討論產品的架構與長相，不過中小企業應該都是 PM、產品企劃來做，以便加速討論，所以這時候 PM、產品企劃恐怕就必須有一定程度了解 UI ，否則就只要做手繪圖來跟團隊溝通概念，再由 UI 建議後 PM、產品企劃畫成 Wireframe ，如果你的 Wireframe 跟 mockup 長相差很多，那不是PM、產品企劃有問題就是 UI、設計有問題(廢話)


Ｑ：我可以用截圖 PS 拼湊美美的當 Wireframe 嗎?
請看 Wireframe 的意義與功用～
如果你覺得美美的視覺化可以加速你溝通，那就可以，不過那應該不叫 Wireframe 它也不是 mockup ，不然會有嚴重的溝通落差，除非你們團隊都畫押過你們心中的定義相同 XD


最後大魔頭問題
Ｑ：我應該要會寫程式嗎？
（我覺得這題應該被獨立做申論題～～～）

通常 PM 一問我這個問題，我現在都會大笑，因為他們會這麼問，一定是委屈了，而這是一個永遠解不了的答案

Facebook 創辦人馬克佐伯克(Mark Zuckerberg)是工程師，微軟創辦人比爾蓋茲(Bill Gates)也是，Google創辦人之一 賴瑞佩吉（Larry Page）也是，感覺好像要懂程式才能做產品？好像不會程式的人除非你是業務跟美術，不然你根本不該在十分需要技術的網路公司出現？

我認同懂程式你比較有機會成為一個創辦人（當然你還要懂 business），但會寫程式不一定等同你知道 end user 要什麼服務，更不等同你知道市場結構在什麼時間推出什麼商品最好，因為「術業有專攻」，每個人的天份都在不同的地方，這是團隊的意義，不然獨立作戰就好～

PM 到底該不該懂程式？
技術出身的人會告訴你「要，PM 不懂技術怎麼做產品？就是因為 PM 不懂技術，所以做不出好產品」，非技術出身的人會告訴你「不一定需要，但有助於你溝通」

其實這問題應該要問老闆，如果這家公司的ＰＭ角色偏向技術面向那恐怕需要，如果公司的ＰＭ角色偏向市場需求與缺口，那這些ＰＭ多數肯定不太容易懂程式，因為人格特質影響著專業取向～

我以前剛開始從設計轉做企劃到當 PM，很常被技術嘲笑（至今也是，只是遇到我也比較不放心上了），他們嘲笑你不知道專有名詞、不知道最新技術、不知道其實有更好的技術方式可以解決 user 問題，就連剛開始出現 ROR（Ruby on Rails）時，我都被工程師當成嘲弄的對象，anyway 我以前會很生氣，我會跟他們說「如果你有更好的 solution 為什麼不說？推出半殘的東西你很開心嗎？嘲笑別人你很開心嗎？」

我直接氣急攻心大家對幹，RD笑你蠢，我笑他們未社會化，雙方滿身是傷誰都不開心，得到什麼好結果嗎？沒有～對公司有幫助嗎？沒有～

後來我氣的去學了 php、mysql、apache、Javascript，學完入門後我真心覺得我到底在幹嘛？這是我要的嗎？就算我學了這些，只要我的程式邏輯沒有公司的ＲＤ好，在他們眼裡有比較好嗎？

噢～～不要誤會 RD 都壞心會嘲笑 PM ，有些 RD 人真的很好也非常專業，他們會幫你想 solution，讓產品更好，會主動拿著你的企劃書來跟你討論細節、對焦以便確保產品是符合期待，如果運氣夠好，他們還很善於溝通，講話比較不像把刀～


總之 PM 抱著不對的心態去學了程式，結果真的不會因此比較好，所以不要再傻了～如果你去學是為了興趣那就去吧，是為了爭一口氣就別了吧，你不會程式就代表你很蠢嗎？那些歷史偉人都會寫程式嗎？他們都很蠢嗎？


PM 可以和 RD 說你想要的目的是什麼，討論怎麼做更好，拿別人家的 case 詢問對方是怎麼做也不是不行，但不要質疑為什麼別人可以我們不行，其實工程師們都很厲害，畢竟他們會寫程式邏輯都不錯的(雖然有些時候邏輯跟我們不太一樣 XD)，他們也一直在追求更厲害、追求更接近神，但有時候你家網站底子不同，你要的時間上對他們而言恐怕真很困難～而他們只是沒有修飾回答你的方式～也有少數情況是他真的不會！可是誰都有不會的東西，不會的東西很多人是不想承認的，這很正常，是人都一樣！


而 PM 在提出需求時，也請務必有做過一定程度的研究，在沒有數據的情況下做功能的決定很危險，如果是資深的 PM、產品企劃，多少有很多專案的經歷，有一定的程度可以直接判斷基本功能與使用者取向（就像 UI 有標準 UI 一樣）不過網路變很快，使用者也跟著行為會改變，舊經驗不一定 100% 有效，當然在管理專案的經驗上是可以延續，但決定功能、產品不是靠累積的經驗就足夠的，經過調查有數據會最好，調查、訪問的對象也很重要，有時候對象不一定是你產品的 end user，這也是現在最熱門的 UX 在做的事情，協助你確認你的 Persona use case，在這兩個前提下去做調查與研究再來決定產品長相，再提出需求，新手 PM 常因為沒有經驗又沒有數據而讓技術擔心你不夠專業，就會被問很多問題感覺被刁了～他們不是有心的，就像我們也會不小心踩到他們底線一樣～


但請工程師們也體諒 PM，當你不喜歡 PM 說出「可是我的工程師朋友跟我說.....」感覺像是被質疑時，將心比心，有些話 PM 也不喜歡聽到...

其實只要口氣好一點，大家都會開心，PM、RD、designer 三種人天生人格特質上有不同，說話方式不同，不小心讓你們覺得是質疑你們專業也並非我們的本意，也請不要常常跟 PM 說「做不到」或者「你確定嗎？我就不會用這產品」，後面這句話對 PM 的刺耳程度大概等同「我覺得這個視覺很醜」、「你是不是技術能力很差？」差不多，有時候你不會用可能是因為你剛好不是這個 use case 之一，如果可以讓你們都用、人人都愛，那當然是ＰＭ/產品企劃 的光榮 也是終極目標～

BUT Design for everyone, please no one！任何一個產品都應該從一種群體再來逐漸擴大，或者就集中目標做深～


以上～～ murmur完了....好多字......我不是專業，只是分享我的淺見，謝謝耐心看完的各位.....
要是不小心有得罪到 RD ，先說抱歉，請不要戰我 XD

偷偷再 murmur 一下，我其實不喜歡 ROR 系列的冷笑話，真的不好笑，我以前不想臥軌，現在不想，未來也不想，「Ruby 好聰明噢～喔我是說那個 ROR」更難笑....


PS. 我會一點點css跟html和常使用Photoshop，是因為我以前做設計，不代表 PM 一定要會，PM 最主要的工作是調度資源處理問題與掌控時程，但當你身兼產品企劃開發時，常吸收新知絕對有幫助