C'est la vie
生命是一襲爬滿蝨子 華美的袍,放下一切和我一起環遊世界
韓國之旅的照片,可以點選側欄流浪版圖觀看

【其他】 我部落格的單篇文章人氣為何壞掉了?!
update:很好!我又從韓國回來惹!又是寫不完的遊記!累積800篇惹!

不知道該怎麼給這篇文章下 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 時順便修改功能,降低大規模大工程的回頭修改,但這是理想化的情況,一般中小公司企業,在搶占市場時間以及公司資源人力與成本考量上,很難面面俱到如此理想化....


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

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


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


最後大魔頭問題
Q:我應該要會寫程式嗎?
(我覺得這題應該被獨立做申論題~~~)

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

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

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

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

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

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

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

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

噢~~不要誤會 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 之一,如果可以讓你們都用、人人都愛,那當然是PM/產品企劃 的光榮 也是終極目標~

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


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

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


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

露。 發表在 痞客邦 PIXNET 留言(2) 人氣()


留言列表 (2)

發表留言
  • pig4042
  • 文章寫得很好呢!
    謝謝版主的無私推薦喔!
  • pig4042
  • 文章寫得很好呢!
    謝謝版主的無私推薦喔!