昨天群裡聊到各種沒有設計流程又趕得要死的公司現況，我就在想，有沒有什麼辦法能在短時間內產出一份還像樣又不用教 PM 或企劃怎麼看的文件，且門坎低、人人好上手，又能當成開發依據。想來想去，大概是心智圖吧。

心智圖我覺得是整理和記錄腦中思考和推理邏輯的好方法，一層層演進的關係讓閱者可以快速理解為什麼會這樣分類歸納。就以設計來說，分析、歸納、找出秩序是最重要的事。

上圖是群裡設計師分享電量圖表，已徵得他的同意，放出來當範例。

這張圖一看就知道沒有事前做過規劃，直接從 Wireframe 或 Mockup 就下手了。漏了很多可以加強深入、能更完善的部份，也多了幾個不合理的地方。

繪製圖表的心智圖

為什麼要做張電量圖表？這張圖表想呈現什麼內容？

不管什麼圖表，這是一定要先被弄懂的兩大題目，設計師不知道要這圖表幹嘛、不知道圖表有哪些內容要呈現，畫個屁...不被修改到死才奇怪吧？中午不知道吃什麼還可以丟銅板抽個籤，不知道畫圖表幹嘛只能求神拜佛抱 PM 大腿了。

所以第一步要先思考這個圖表的目標，必需有哪些資訊。初步整理如下：

在畫心智圖的時候請把所有和「視覺」有關的部份全部捨棄。什麼標題加租、紅色突顯電量這種形容圖表外觀的敘述通通拔掉。心智圖整理的是內容，不是視覺條件。只有在非常特例的情況下才能把視覺條件放進考量點。

心智圖不可能一次到位，通常也會重畫個 3 次左右。手寫版大概訂出方向、大分類；進電腦做電子版時繼續細化；電子版寫得差不多時重新檢視所有文字內容，找出共通點規納分類。

這是經過整理的心智圖（八成還是有漏），可以看到分 3 大類顏色，目標、資訊、功能。

目標：製作這個圖表的目的。
資訊：這個圖表要呈現哪些內容，一堆 Data。
功能：怎麼把 Data 拿出來用。

資訊和功能有點不太一樣，資訊就是一堆的數據資料，功能指的是要用什麼方式把資料拿出來用。雖然心智圖上資訊和功能的內容看起來似乎是一樣的，但就以 RD 的角度來講是不同的兩回事。

不知道怎麼劃分功能和資訊沒關係，反正圖畫完拿給 RD 看，他們會教你。（不教你就是等案子進度到了他們要接手的時候會叫苦連天了。）

漏洞

自己一個人在畫心智圖的時候往往寫得很順，長分岔長得很開心，表面上邏輯是通的，但仔細一想就會有問題。

上圖其實就有個大漏洞：單日用電時間總計。

誰家冰箱會為了省電所以定時拔插頭？又不是上節目黃金傳說啊！那電量誰家不是 24H 在消耗？這個圖表的面向若是一般大眾家庭，單日用電時間總計這數值就變的很可有可無、甚至不應該存在。

所以心智圖畫完記得拿給其他人看看啊！不要畫完就直接開工了，起碼也給專案相關人士瞧瞧，同步下對產品的看法。

文件

到這裡你發現了嗎，這份心智圖包了一點點的企劃書部份、也包了一點點規格書的部份，如果你身處小公司、沒流程、上至老闆下只同事都不懂設計、PM 和企劃只會叫你改的工作環境，被交辦任務後還是先快速畫一張心智圖，把該列的資訊列一列，請他們確認。

很多時候修改是因為雙方溝通落差，PM 沒什麼想法就叫設計先開工，設計自己有想法也沒和 PM 講。等做下去後 PM 想的和設計想的又不同，這落差就是改到死的原因之一。

不過拿心智圖當文件這個作法只適用於公司內部，給 PM、企劃、RD 同事看看確認無誤可以，開明一點的主管或老闆可以，傳統些的主管、老闆或是拿給對外的客戶看就不夠正式。既然都能畫出完整心智圖了，再花點力氣修改成一份有標題分段落的文件給客戶確認吧。

SimpleMind Free

通常我都用 XMind，不過心智圖不需要把每個格子都對得整整齊齊，就會用 SimpleMind Free。

App Store https://itunes.apple.com/tw/app/simplemind-free/id439654198?l=zh&mt=12

收到一封快 3 千字的 mail ，看完敘述覺得自己可能沒辦法給妳什麼樣有用的建議，只能分享我的經驗。（常常看到有人說「大神求帶飛」之類的文，都想吐槽 「林北還活著，只有死人才會變神，而且我不會飛。」）

（圖片取自 http://imgbuddy.com/fluffy-baby-penguins.asp）

當你的才華還撐不起妳的野心時，妳要做的是靜下心來學習。

我也一樣，陷入同樣的瓶頸：覺得自己能力不足，實力不夠。基於處女座某方面的強迫症，既自信又自卑的矛盾問題在我身上會被 N倍放大鑽牛角尖，曾嚴重到連續半年跑精神科。（推薦看 卡內基 人性的優點一書，很大程度幫助擺脫憂慮。）

正面點的想法是：看到的實力派大神哪一位不是練個十年八年、三十幾歲四十歲起跳？但人呢就是愛作夢，不會去想別人花的多少苦心在做練習，只會看到他好厲害我也想這麼厲害被捧被崇拜。

也許妳會說我是本科生出身，高職＋四技＋研究所共 9 年的訓練，起點比別人高了。高職 3 年我被當掉 21 學分，最後怎麼過關的不知道，大概是有學校念卻畢不了業太難看老師放水；四技都在打工存錢還助貸和搞定新一代，對去學校上課的印象不怎麼深；研究所不怎麼教實技，論文是地獄。我的所有基本功幾乎是 0 ，都是出社會後整個重來。

某位四技同學（現在是遊戲代理商的設計總監）在我準備去考師大研究所的時候挺不屑地跟我說：「妳幹嘛去考研究所，妳又不會做設計，就那張嘴厲害，怎麼不改行當 業務專案經理 ？」

在我考上後，她酸我說：「這樣妳都考得上，妳真的不改行嗎？那張嘴超厲害的耶～」

妳可以猜想我在 2010 年時專業能力不怎麼樣，就會出張嘴。但時間可以改變一切，何況專業能力。像我這樣被人瞧不起的渣渣努力幾年都能扭轉能力不足這個窘境了，相信妳也可以。（說有多努力其實也沒有，漫畫照看電動照打，只是願意正視自己的弱點，有勇氣敢面對現實並解決而已。）

食戟之靈

介紹一套我很喜歡的漫畫：食戟之靈。

沒有必要劃地自限，妳看到的是在業界打滾十年二十年的老手作品，自己入行才多久，就想和人相提併論？這句話同時也是我自己說服自己的理由。只看到光鮮神技的一面、沒靠到他們在背後努力練習了多久。大多數人都努力不夠，根本不到拼天賦的程度。「能夠平靜面對自己的不足」是非常重要的能力。

食戟之靈還有一句名言是：「如果有真正想貫徹到底的東西，那就放下矜持，不顧一切緊緊抓住。」

回到初衷，妳為什麼想放棄本科轉而當設計師？妳真正想貫徹到底的東西是什麼？把它找出來，擺脫會讓自己憂慮的心態。妳會發現大部份的瓶頸都是自己給自己下的限制。

因為開了 Q 群的關係，收到很多 Mail，非常有意思。就數量上來看，大約 80% 是簡中、20% 繁中。有照我提的要求寫 Mail 的卻反過來，80% 繁中信都做到了，簡中信卻一半一半。太多人無視信件禮儀，寫 Mail 給陌生人用寫微博的口氣。

態度

加群的要求只有 2 點。

1. 簡歷或作品。
2. 附上QQ號碼。

完全沒要求設計師、F2E 的能力或作品品質，只要附上這 2 項寄 Mail 給我都能進群，篩選的只是「態度」而已。本以為這麼簡單的事很容易辦到吧？才怪，一堆人不附作品、或不附 QQ 號。先不提禮貌問題，第一關就不過了。

E-mail 禮儀

我也沒要歌功頌德或像寫情書一樣，起碼基本禮貌得有吧？來個一行文就沒了？摘錄幾封信件當錯誤示範。以下為完整內文，有些沒有發語詞，有些連自己是誰都沒寫...

範例 A：

平面设计师一枚，准备转型UI。求加群

就這樣沒頭沒尾一句話，沒附作品也沒附 QQ 號。

範例 B：

中国邮政贺卡设计师。000000。

Mail 有附作品有 QQ 號，就扔這樣一句話過來，好歹多幾個字吧？

範例 C：

有兴趣到你的群里玩一玩。求加我QQ：000000。谢啦

設計吃貨群是很歡樂沒錯，但也不是來玩的，大家討論起設計時都很激烈認真。別這樣瞧不起...

範例 D：

qq : 0000000

...就扔串號碼給我，什麼文字說明都沒，你想幹嘛？這裡有批牛肉好便宜？

範例 E：

难道这个群是为吃货而设计的么？QQ：000000

是群吃貨沒錯，不過你是誰？寫這信來是做什麼的？請不要不熟裝熟。

範例 F：

20150327 補充，才發完這篇文沒多久就收到一封標題寫著「求加入 谢谢」的信。

CTRIP UED UI设计师 QQ:000000

沒附作品、也沒說自己是誰，就這樣一句話。我不打算因為「公司名號」就破壞入群的規則，拔掉公司頭銜你剩什麼？只會讓我覺得「原來你們公司接受這樣子的員工」。

題外話：

本來群名不是吃貨，但聊天常常歪樓。就連要求把暱稱改成【所在地】名字 （【台灣】AkaneLee）也是為了分辨口味，畢竟群裡設計師北到黑龍江、南至香港、東到台灣、西至四川，什麼口味都有。我才不會被群裡成都設計師說川菜不辣騙騙去...

發生過一次超妙的狀況，因為不喜歡把群號撒出去，所以我都會加來信人的 QQ 再拉他進群（其實是我不太會用 QQ）。有一位設計師在我送出邀請時她按了拒絕，也沒下文。拒絕加群那妳寫 Mail 給我做什麼？

正確的 Mail 寫法

網路上隨便翻都有一堆 E-mail 禮儀教學，基於設計師喜歡看圖不愛看字，推薦 Mark 的文章。

職場禮儀-eMail篇 @ 我是馬克 i'm mark :: 痞客邦 PIXNET ::

雖然正經商業信件寫法絕對不會有問題，但那也太生硬我覺得少了點人情味。第一次寄 Mail 給對方，最起碼要有信件主旨、稱謂、你找我有什麼事、你是誰 這幾項。不懂禮貌會少掉很多和人交流的機會的，就只是多打幾個字而已。

喔對，一行文這類型的 Mail 我智能不足以知道怎麼回信，容我無視它的存在...

有人說現在業主付費買的是設計師的「時間」，付出高額的薪水買的是「素養」。套一句設計師 Paula Scher 說過的話：「我花了幾秒鐘來畫它，但卻花了 34 年來學習怎麼在幾秒鐘內把它畫出來。」我想，業主買的「時間」、「素養」指的是設計師在過去所投入的努力，而不單是執行這項任務所耗費的時間和所需能力。

我看了四本能影響設計師職涯方向的書：

• Michael Janda 《Burn your portfolio》 為什麼他接的案子比我多
  
• Eric Karjaluoto 《The Design Mothod》設計的方法
• David Calvin Laufer 《Dialogues with Creative Legends and Aha Moments in a Designer's Career》頓悟時刻 設計大師訪談錄
• David Airey 《Logo Design Love: A Guide to Creating Iconic Brand Identities》超越LOGO設計

這 4 本書中談論到的大師們都用很委婉的方式提到「專業不值錢」這件事，並說明設計師該怎麼調適心態、如何面對。對於工作所收到的報酬因人而異，每個人心中的底限也不同，能做到的就是加強心理建築，當遇到被貶低或無限修改時自己該採取什麼樣的行動和準備。

Michael Janda

因為客戶堅持，導致設計師的職責從創作獨特概念設計變成只需要遮醜。遮醜不是要設計師放棄設計原則，而是使出渾身解數，讓它看起來像樣。醜也要醜得體面。

Heinz Edelmann

不要以環境糟糕、腳本糟糕，甚至身體不適當藉口，痛苦和不利環境在業界非常常見。你的最終作品就是呈現在公眾眼前的一切。

客戶會給你一定的期望：「這些觀眾並不是很有經驗，你的作品必須直接打動他們。」但設計師會認為這很醜陋，但如果某些觀眾喜歡它、客戶又從中賺到了錢，他們就會跑回來找你。此時你處在一個尷尬的境地，因為你做了一個「好、卻糟糕」的設計。

Eric Karjaluoto

設計只是設計師工作中的一部份，另一部份是提供服務給客戶。客戶想知道你是為了他們而工作，不是做些豐富自己作品集的事。客戶需要知道設計師為什麼這樣做。

與客戶意見一致前製作任何設計作品都是錯誤的，過早完成設計是冒險的行為。在沒有完全了解客戶需求的本質及整體情況前，不要按照直覺行事

Hermann Zapf

你該清楚自己在工作上做的每一個決定都會在一定程度上影響你的發展方向，如果上司分配給你的工作只是種交易，則有個選擇：我要接受這份薪水並盡可能地學習知識和經驗並向前發展嗎？還是此工作對我的能力陪養沒有絲毫幫助，這份工作僅是養活自己的一個手段？

所以你得去學習如何保持平衡，什時候該爭取你認為對的事，什麼時候該虛心學習他人的長處。

Seymour Chwast

當你為自己作畫時，當然可以遵循自己內心的情感，但當為別人做畫時，必須用他們喜愛的表達方式。我們受雇於他人，很多時候必須站在別人的角度和立場去體會並不屬於自己的情感。客戶的洞察力所具有的重要性遠遠超乎我們的想像。

James Burke Jr

設計是創作者對解決一個問題、或是為生活需求所服務的欲望表達。享受你的工作是很重要的，但沒有人能用自己的方式命令別人的工作變的有趣。你必須自己完成。

Ruedi Ruegg

只有當你足夠專業時，你才會有完全的創作自由。

Ivan Chermayeff

我們很少給客戶很多設計方案，這會讓他們更加疑惑。他們付我們錢是為了消除疑惑，而不是製造更多疑惑。他們付我們錢的目的是為了獲得一個明確、有幫助的設計。

Paul Rand

你可以選擇堅持自己的設計或妥協，但如果想追求極致，你必須堅持自我。

.
.
.

我是很嚴重的認人白癡，不管是人臉或人名。上述一堆大師其實只知道得 Michael Janda。我人微言輕，總是得拉點知名人士背書。專業值不值錢，不只是從業主眼裡看到，我也不想去探討業主心理糾結什麼。重點在於設計師本身的專業在哪裡，被糟賤時用什麼樣的態度面對。最終目的當然是成為夠知名、夠有實力的大師，讓客戶不敢隨便亂改....（喂）

這 4 本書都是設計師該入手的巨作，想當設計師工作流程的草稿起點、或是心靈雞湯看都行，但我能保證這 4 本書能帶給設計師全新不同的思考角度。

UI 設計師要不要懂技術？廢話，當然要啊！不然怎麼把幻想變成現實？在實際產出之前設計師做的一切都是「美美的幻想」，還有可能不怎麼美，直到最後的產出才是真實。

舉個例子：建築師除了畫圖外，需不需要知道蓋房子每個階段的建造方式？要不要理解各種材料的特性和規格？需不需要熟悉當地環境的限制？

但建築師需不需要知道水泥車怎麼開？需不需要操作吊高機？

他們最後的成品是那疊圖紙嗎？誰去看圖紙啊，當然是實體的建築啊！那 UI 設計師最後的成品為什麼是 Mockup？

懂技術

比較常聽到「PM/Planner 需不需要懂技術」這個議題，UI 設計師較少被這樣要求。為什麼 PM 最好懂技術的理由網路上已有許多文章提過。

就我自己和 RD 出身的 PM 合作經驗，只能用「輕鬆愉快」來形容，這類技術型 PM 絕對不會規劃出沒有樑柱的摩天大廈。和他合作可以全力以赴，不用故意留一手預防「無法實作」而整個專案大轉彎的情況發生。

UI 設計師很大的工作量會放在前期規劃 Flow 上，這關係到產品的操作邏輯、能不能被實作，不過現階段看到的公司都以「美美的圖」優先，導致 UI 的工作就是美工在幹的事。

UI 設計師一定要懂技術

我指的是「懂」技術，不是「會」技術或「熟」技術。只是沾點水的程度。

比如 iOS 用 Swift，並沒有說要 UI 自己學習 Swift 這種語言，但至少要知道自己切的圖會用什麼方式被 RD 兜成畫面。

要了解自己切出來的圖會如何被實作，最快的方式就是學會手寫 HTML+CSS。如果能進階到 Responsive Web 的程度，相信和這位 UI 設計師合作不會慘到哪裡去。因為他已清楚實作出一個畫面需考慮哪些事、什麼樣的作法才能達到目的。而且他也知道不懂該問誰、有問題要怎麼尋求答案，不用太擔心他亂搞。

RD 不是設計師的敵人

常聽到設計師抱怨「那個 RD 整天唱反調，只會說這個做不到、那個也做不到」。

怎麼沒先想過是不是自己天馬行空想出「有創意」的點子，卻沒考慮現實，只能讓 RD 回辦不到？有沒有想過當 RD 講多「辦不到」後，就會把老提這種點子的人當成和蚱蜢同一水平？

曾聽過 RD 抱怨：「幹！說時程太趕不蓋 1 樓了，直接蓋 2 樓和 3 樓，是要我綁多少氣球演天外奇蹟！」（這句是偷聽到的，害我憋笑憋得很痛苦。）

這就是 RD 為什麼只會說「辦不到」的原因，他們是把幻想變成現實的工作者。

舉個殘酷點的例子...把照片 PS 成林志玲或范冰冰，不代表真人就是美女。大部份女性要當現實的美女得靠整容手術找醫生動刀，但落差太大醫生也只能說辦不到，甚至有可能後遺症很多嘴歪眼斜等等。

企劃＝告訴你為什麼要 PS 照片、動手術的人
PM＝協調開刀時間、叫各單位做事的人。
設計師＝負責 PS 照片、提出理想（妄想）的人
RD＝執行醫美手術的醫生，負責把理想變成現實的人。

必須了解很多時候說辦不到就是辦不到！

很難理解嗎？試想看看把如花整容成范冰冰。是把如花的照片 PS 成范冰冰比較容易，還是把現實的如花整容成范冰冰比較容易？常聽到 UI 不諒解 RD 為什麼拒絕，實作上的難易度根本不是同個水平。

UI 設計師要懂技術

除了前述讓自己瞭解理想和現實的差距外，UI設計師有個非常重要的任務卻很少被提到：「當 RD 的坦。」

從（現實的常見）開發流程來看，PM、Planner、UI 在專案開發最前期就開始工作，RD 卻在專案進行到一定程度後才會加入。加入後就碎念 A 也辦不到、B 也辦不到的。正常人誰會喜歡聽自己的構想這也不行那也不行，當然造成不諒解和對立。就算雙方各退一步修改內容，礙於時程、主管同意、方向已定等種種原因，硬是把產品開發出來...出現歪掉的四不像完全在意料之內。

PM、Planner、UI，這三個職務最接近技術的人是誰？當然是 UI 啊！UI 是技術活、是講求實作面的角色！

所以 UI 有責任當坦，在專案開發初期就把所有「不可行」的構想通通擋下來。有的人會說那 RD 呢？通常在啟動會議之前很少有 RD 會參與討論，等他們加入都已經太遲了。（視公司開發流程而定，不過我看到很多公司的 RD 都是代工中的代工。）

UI 在開發前期不先坦住，後期一定因為「不可行」而修修改改，之前的工全部白費。專案合作就是這麼回事，想說反正之後是別人的工作不關自己的事...最後都會回到自己身上。有時候修改到死是自找的，多幫別人想一點就能避開地雷大坑。

形式服從於功能

在專案開發裡要考量的就是「可行性」，任何不能實作的點子都是空談。再美的設計都需要有人實作成品出來，形式服從於功能。

某位 F2E 說過：「RD不是設計師的工具。我們是專案成員，不是實現設計師個人作品的代工打字員！」

什麼是個人作品、什麼是專案產品，這就是最大的差別。

.
.
.

...靠、想起當年打 WOW 我是暗牧、老公練盜賊，他說我有護盾所以把我推出去當坦的事了。

最近在找做 Prototype 的軟體或服務，狂測了一堆眼都花了。 Prototyping Tools搜集很多做 Prototype 的工具，我還沒把每一款都摸過，先筆記有沾水的部份。可能某些服務的功能我沒摸透，如果你有其他的想法歡迎補充。

我需要的 Prototype 條件：

1. 可產出運行在各種平台上的Prototype。
2. 可產出實際能操作的介面，包含過場動畫、動態特效。
3. Prototype 可供多人同時操作測試。
4. 不用寫太多Code。（<<不要為難設計師好嗎？）
5. 高保真原型，同最終產品長相。

Keynote

https://www.apple.com/mac/keynote/

在電腦上簡報給客戶看很讚！操作簡單、內建各種轉場動畫模式，是最容易上手的一款。原本產出 PDF，用點擊某區、跳到某頁的方式可以做放到手機上的 Prototype。

不過現在越來越講求動態效果，比如下拉後圖片會彈跳放大回縮之類，Keynote 就有點心有餘而力不足。

（試過用手機上的 Keynote 開 設好動畫的 .Key 檔，想說可以這樣 DEMO...手機上的 Keynote 竟然是 Landscape ，是橫的～是橫的～是橫的～打錯算盤...）

香港設計師 希羅 補充

Rotate Keynote Document for use as an app Prototype
AdulteTerrible/DuplicateAndRotateKeynoteDocumentDroplet

可以試試，祝好運。

Justinmind

http://www.justinmind.com/

這套很紅，但我在操作官網的 DEMO 範例時很頓，不管做什麼操作都要等讀取等等等等等。做使用者測試時不能等 Loading，就先 Pass 了。

Hype3

http://tumult.com/hype/pro/

很好玩！非常靈活！內建很方便的動作庫，不用寫 Code就能產出 HTML 檔這點很棒！像 Keynote 一樣可以分頁分場景做編輯。而且介面有中文喔！

時間軸設計有點像 AE 或 Flash，設計師上手還算容易，但要進階做點特效什麼的要再摸索。目前最喜歡的是這套，產出 HTML還挺乾淨的樣子，自主性很強。如果是網頁設計師用 Hype3 會如虎添翼。

提醒：用 Hype3 產出的檔案不要逼 RD 直接用！

Axure、Omnigraffle

http://www.axure.com/
https://www.omnigroup.com/omnigraffle

目前我都用 Axure 畫 Wireframe，可以像 Keynote 做簡單的點擊換場 Prototype，並產出網址方便內部展示。不過要擬真要動畫這套似乎不怎麼適用。

Omnigraffle 有點類似 Axure，改版後介面漂亮很多，不過這套適合做 Flow、畫 Wireframe，實際可操作有動效的高保真 Prototype 不是它的強項。

InVision

http://www.invisionapp.com/

和 POP有點類似，現在很多這樣子的 Prototype 平台。上傳 jpg 圖檔、在圖上拉個可操作區域、設定點擊後跳到哪一頁。

InVision 內建數種轉場特效和手勢操作，非常方便。還可以產出網址，用手機開啟該網址就能操作，共享功能做得不錯。Prototype 頁數一多讀取速度似乎不太穩定...

缺點是沒有複雜的元件動態效果可套用，只能設定預設的那幾款。拿來測操作 Flow 、多人團隊合作是個好工具。

Pixate

http://www.pixate.com/

Taiwan UI/UX Designers舉辦的 UI/UX Designers’ Night - 2015 Apr. 活動中提到這款工具。

試了下，很好用！靈活度也很高！入門的門檻有，不過比 3D MAX 簡單多了（喂）。亮點在內建的動作庫和細部設定，擅用細部設定可以搞出很多花樣。

可惜不是像 Hype3 或 Keynote 的分場景方式，比較像 Sketch 雜在一起的邏輯。所以若 Prototype 很多頁要測過場的話，應該會疊非～～常多圖層群組，很可怕...

結論

基於 RD 心態，所有只要平台/服務伺服器掛掉就不能工作的皆不在考量範圍內。再考慮到文章一開始的 Prototype 條件，就 Pixate 和 Hype3 這兩款符合我的需求。

只是我真的很擔心 Pixate 在製作超過 20 頁的 Prototype 圖層會有多複雜，以及 Hype3 的動態特效細節自己有沒有能力掌握...

補充：應該會買 Hype3+吧，以功能和價錢來看，這套不貴啊～～～（大量購買還有折扣、學生也有折扣呢！）

（好像 Get 到什麼點，知道為什麼 UI 設計師會跑去學寫 Swift 和 Html5 動畫...）

最近調了部門，從 F2E 調去設計部，做 Planner 的工作。大開眼界，看到另一個角度。本來實作人員就是會私下幹醮 Planner 或 PM 搞不清楚狀況，產出的文件怎麼丟三落四、不切實際，或是時程這麼趕也不先問兩句之類。現在我也在寫企劃書，看到些覺得奇怪的問題點。和她們請教後發現很多時候不是她們願意的，而是人在江湖身不由己。

（以下是我這陣子遇到身份轉換的課題，很努力在克服中。）

Planner 兼 PM

台灣的風氣似乎如此，為了避免工作交接上的落差，很多時候 Planner 會兼 PM 的工作，慘一點的還要兼當 UX 和美工，但在公司地位往往是最低下的那群。RD 自負有專業能力就對 Planner 很不客氣、順帶瞧不起只出張嘴的 PM。（比如當「Post Man」的 PM）。但基本上不會有人想故意搞砸自己在做的專案，只是沒發現問題或沒能力解決問題而已。

Planner 的目標很飄渺

實作人員習慣一個口令一個動作，起碼是有個很明確的目標擺在眼前，時間到、完成它就是。但對 Planner 來說並非如此，也許仍有個目標放在眼前，比如：「提升廣告宣傳效益」。這目標往往非常抽象，不會知道要用什麼手段完成。

提升廣告宣傳效益？很多種手段可以達到啊，比如砸更多的錢買廣告、或是請藝人代言等等。講得很簡單，真要實行也要人去做，要怎麼做、找誰做、預算多少、預估工時、預估收益等等，這些沒有 Planner 規劃也不會有小精靈半夜幫忙做完。但自己想得到的大家也都想得到，太多手法都被做爛了，都說要有「創意」，創意怎麼生？生了又要怎麼實現？

Planner 不會有明確的文件知道自己在這個目標下有哪些資源可以使用，只能不停的收集內外部資料。並且要把這些抽象的思考轉化成「真正可被執行」的企劃。沒有經驗或沒有實作背景的 Planner 常被罵不切實際，就是在想辦法實現抽象目標的時候，規劃的執行手段不夠踏實。

所以實作人員在碎念 Planner 怎麼這樣亂搞的時候，先想看看這個問題：

• 我不知道要做成什麼樣耶～反正就是要讓顧客有辦法找到我們、要推廣啦...你先做個發想，我們再來討論一下好了。

如果你想翻桌罵聲「靠夭這是要我通靈喔」的同時，要知道這就是 Planner 的工作，他們的工作往往沒有明確的目標，卻一定又要產出個什麼，所以每天都在通靈。

Planner 的工作時間

PM/Planner 很大的工作落在「溝通」上，溝通是種需要大量點數支援的能力！遠超過專業技術。進了職場後發現，很專業的技術在基層人員身上根本沒差多少，怎麼樣把專案壓在時程內搞定才是核心。能沒有落差和別人溝通，遠比專業技術重要。

溝通需要花時間、花耐心，有的人吃 A 這套、另一個人要用 B 才有辦法心平氣和接受「又要改了」的訊息。完全不是理想中出張嘴開個簡單小會、寫寫文件就能解決的事。開會要花掉多少時間和人力成本？

假如溝通和開會時間一天 3 小時好了，再扣 1 小時的休息＋轉換的時間，以不加班情況下就剩 4 小時的工作時間而已，還有可能是被切割零碎的 4 小時。想看看自己如果這邊 20 分鐘、那邊 40 分鐘的零碎時間要寫 Code 或做設計，還隨時可能被打斷要討論事情，效率肯定低落。但 Planner 長期在這樣子的工作環境下撰寫各種文件，在目標飄渺的情況下通靈還能產出這些文件，真的覺得她們很了不起！

改來改去是理所當然的事，不管是在哪個位子上都會遇到。RD 抱怨怎麼需求一直改... Planner 被改的次數更多哩！好的 Planner 絕對能發揮「坦」的功能，通常上面一聲「 1 個月後我要看到XXX做出來」，第一個抱著頭燒的絕對不是 RD 或設計，而是 PM/Planner。

在有限的時間裡要完成目標，除了分輕重緩急優先次序外，她們會考慮「最小可行方案」。如果一個月不可能做出20個功能，那先挑出一定要做的 10 個功能行不行？剩下的下次改版再說？Planner 往往沒有專業訓練，不能和大學四年都在念資訊/設計相關科系的人比，Planner 要學的事決不比實作人員少，拿 RD/UI/UX 的常識去要求 Planner 的常識會不會太過份了一點？

不看 Spec 的 RD 也大有人在，Planner 辛辛苦苦硬在時間碎片裡寫完的文件竟然不看，有問題也不講，等到東西都出來後再說當初不是這樣、或是對自己不照 Spec 做找理由...對得起這麼辛苦拼命的 Planner 嗎？

.
.
.

可以說我這篇文在幫 Planner 說話，但若不是自己轉換身份當了 Planner ，我也不會注意到問題且被搞到快抓狂、進而發現 Planner 的難為之處。（然後看著 RD 在刁Planner，就覺得她們好可憐...）

換個位置會換個腦袋，去年某大大對我說「要預設別人都是善意的，只是遇到某些事所以會有這樣的反應」。換位思考非常重要、又很難辦到，最快的方式真的是直接丟進戰場實際跑一遍才會懂。

（實作人員體諒歸體諒，看到問題還是要主動提出來，不要拿到 Spec 問行不行時都說沒問題，做下去開始各種抱怨...當初問有沒有問題時就要反應了，別用自己的專業能力去壓 Planner。）

補充：搞不清楚狀況又教不會講不聽的，不管哪個職務都一樣，被釘只是剛好。

動態效果、轉場動畫對UI的戲份越來越重...其實一直都很重只是大多用在遊戲上，功能型 App 運用這種技巧最近越吃越兇，且製作真正能裝在手機、拿在手上操作的擬真 Prototype 對不會寫 Code 的設計師來說有難度。我找到好用的方式可以解決這個問題：Hype3＋Frameless。

這篇是最簡單的過場設定、最偷吃步、不需要技術，只要會寫簡報 PTT 或是 Keynote 就做的出來，所以連 Planner 和 PM 也保證上手無問題。

會選 Hype3 的原因在Note：Prototype 製作軟體有提過，就不多說，直接從範例開始吧。

Hype3

官網：http://tumult.com/hype/
App Store：https://itunes.apple.com/tw/app/hype-3/id685096913?l=zh&mt=12

場景設定

示範： iPhone 內建的音樂 App

1.打開 Hype3 ，官網下載的試用版可以用很久，還有簡中介面，先抓下來玩看看，喜歡再買。（這套定價也很便宜！）

2.既然是 iPhone 的 Prototype，來改一下場景尺寸。我用的是 640x1136px，畫質比較細。

3.因為畫面是長型的，所以我把時間軸和圖層從下方挪到右邊去。

匯入圖檔

4.手機截圖，直接扔進 Hype3 裡。

（表示做自己的東西實可以直接拿 Mockup 的 jpg 或 png 圖直接上！）

設定動作範圍

5.來做「動作觸發的範圍」，在圖上先拉個矩形。

6.右邊選單設定無填色、無筆劃。

7.下方 Tab Bar 第 2 顆的位置就有一塊透明的區域，也就是「動作觸發的範圍」。

8.設定動作，雖然手機上不會有游標，但我還是喜歡把可觸發的區域游標換成手指，在 Browser 預覽時可以快速確認自己Link設對了沒有。

9.記得，所有場景、圖層什麼的，要重新命名成有意義的名字，當頁數和元件一多時才不容易出錯。

10.像 Keynote 一樣，可以一次做了好幾個元件，選起來好拷貝到其他場景貼上。

（圖層前後會影響操作和元件顯示，如果有時候發現某個地方怎麼點都沒效果、或是看不到，檢查下圖層順序。）

過場方式

11.點著個 BTN、播放中的頁面是由右往左推進。

12.所以記得把過場動效改成「推動」（由右往左）。

13.秒數我習慣設 0.3s，依個人感覺不同，請自己試看看。

14.這個 Btn 點下去、會由下往上出現歌曲列表頁。記得設定「推動」（由下往上）

15.點了「完成」後，頁面會由上往下。

（當很多頁面都有一樣的回前頁、Tab 的Link要處理時，可以先做完一頁，剩下 Copy、Past 就好。）

匯出 HTML 檔

選 HTML5、文件夾，檔名命名好。

會出現一個 HTML 檔和一個資料夾。把這兩個檔傳到伺服器上，就可以用手機開網址測試了。

如果想預覽自己做的如何，工具列上有個 Chrome 或 Safari 的 icon，按下去就是了。不過它不是即時的，每次修改存檔就要再點一次這 icon 重新產生預覽，直接點 Browser 重新整理看到的會是修改前的樣子。

Prototype 專用 Browser

Frameless - a full-screen web browser

官網：http://stakes.github.io/Frameless/
App Store：https://itunes.apple.com/us/app/id933580264

這是個連「狀態列」都沒有，真正全螢幕的瀏覽器。免費！
輸入你的Prototype網址，就可以像真的 App 一樣，用手機做測試了。

祝順利！

範例

上面做的範例請用手機開 http://goo.gl/0X0sWV
或是掃這個 QRcode。

最好的瀏覽方式請用 Frameless開啟。

（熟練了大約20分鐘內絕對搞的定上述步驟。範例有些細節、瑕疵、落差就不調整了。比如由下往上推不該是真的推走，有些更精緻的設定我留著下次經驗分享。）

快一個月沒有發文了，忙著寫企劃案、做 Prototype、跑實驗生報告。最近要整理大量的 UI Flow，越整理腦袋越像醬糊。就來聊聊 UI Flow和 Flow Chart吧。Flow 就是「流程」，UI Flow 是頁面流程，而 Flow Chart 是流程圖，兩者是完全不同的圖表。

UI Designer 很熟悉 UI Flow，對 Flow Chart 可能不太熟。在軟體開發中 Flow Chart 通常是由 SA 撰寫，重點在「判斷」上...沒有那麼難，把它當成雜誌附的心理測驗，選「是」走右邊、選「否」走左邊就好了。

對 RD 來說，寫程式前都必需先知道「邏輯」，也就是由各種「判斷」組成的操作架構。對 UI 而言邏輯也很重要，不然使用者操作後要給他什麼回應？

最陽春的會員登入

以「會員登入」為例，使用者輸入帳號密碼，輸入正確就自動跳轉到會員資訊頁，輸入錯誤就提示錯誤...

光從 Functional Map 就想畫 UI Flow 常常忽略「使用者操作錯誤怎麼辦」，最後一刻才發現有缺就是 UI 緊急加畫漏掉的頁面、 RD 苦命塞功能不優雅，提示錯誤又不是放下一個階段或是有空再補的東西，頁面和程式也不是靠嘴巴在畫在寫...

亂輸入就給你驗證碼

好像很簡單喔？才不只這樣。實際畫起來會發現很多東西在 UI Flow 上很容易忽略沒考慮到的部份。（而且怎麼可能就只有這樣不加功能？）

有時候使用者會一直輸入錯誤，合理猜想是有人試著盜帳號。常見的阻擋方法是讓輸入多次錯誤的使用者多填一個驗證碼的欄位。所以 Flow Chart 就變成：

上圖只是簡單的流程示範，不過是隨口多一句「喂、幫我加個驗證碼功能」，Flow Chart 就會突然肥一截。真正的會員登入驗證還有更多花樣以及安全性考量，比如登入錯誤 3 次就多提示一句「忘記密碼」等等，更狠的直接鎖帳號請使用者找客服申訴。

Flow Chart 和 UI Flow 相輔相成，甚至是先有 Flow Chart 才有 UI Flow 。在沒有 Flow Chart 、不知道要處理多少判斷時就產出 UI Flow，規劃不周掉頁面漏功能的機率非常非常高。

若只有 UI Flow 沒有 Flow Chart，RD 勉勉強強可以憑畫面想像 Flow Chart、判斷式怎麼下，但系統越大會容易出包有 Bug，依 RD 經驗值決定出包機率。但連 UI Flow 都沒有，光憑幾張 Wireframe 或 Mockup，根本就是瞎子摸象，看單張靜態圖 RD 不會知道頁面怎麼串，純靠腦補不錯才怪。

如果什麼都不給，直接扔 Prototype 給 RD 叫他照抄，說一模一樣做一個出來、很簡單吧？RD 還要每個畫面每個按鈕按都戳戳看、試過各種錯誤才會知道功能怎麼接。對 RD 是有多大恨這樣整人家...

參考資料：
流程圖 - MBA智库百科
流程圖說明

就 UI Designer 的角度可以把 Flow Chart 看成「這個情境下使用者怎麼操作完成任務、軟體怎麼回應」，把 UI Flow 延伸為「因為使用者這樣操作、以及我們有這些功能和資訊要呈現，所以頁面和頁面之間如此串接」。

UI Designer 不一定要會畫 Flow Chart，但一定要看得懂。常見流程圖符號是固定的，不要因為長得醜就自己設計個新樣式，RD 絕對來翻桌。

有句名言「婚前腦袋進的水就是婚後流的淚」，套到軟體開發上，開工前少花的腦就是開工後要傷的肝。有多少功能前期沒想到、就有多少工時後期沒料到...

設計的方法這本書不管是 UI、UX、PM、Planner 桌上都該擺一本，不知道報告/企劃書怎麼寫的時候拿來跑一下實驗很好用。從中我認識到「狩野分析」，參考 UX，設計的方法（專案初始）這篇文，當時預期狩野分析適合用在專案初始、分析這個功能要不要做。最近簡單地跑了一遍，來寫點筆記...步驟雖然多，但只要會加減乘除就行了。

不加新功能就會死恐慌症

很多人都曉得「少就是多」，也都知道越簡單越容易被理解和操作，卻得了一種「不加新功能就會死」的恐慌症。（我覺得自己得了一種求你不要亂加新功能的恐慌症。）

為什麼要加功能？加了這個功能有什麼好處？解決什麼問題？這些問題企劃書要掰都掰得出來，但有沒有客觀點的研究方法能驗證這個功能真的是使用者/業主重視的？

以下內容參考 KANO模型 - MBA智库百科一文，該文講得很清楚，不過有點硬不好啃，我用自己的理解重新整理。

需求有 6 種

在狩野分析裡有 6 種需求，最重要的只有 3 種： M 基本型需求、O 期望型需求、A 魅力型需求。

M 基本型需求（Must-be）

顧客對企業提供的產品／服務因素的基本要求。
產品一定、理所當然要有的功能／服務／特性。有是應該的，使用者不會因為有就覺得滿意；但沒有一定會被罵到臭頭。

O 期望型需求（One-dimensional）

顧客的滿意狀況與需求的滿足程度成比例關係的需求。
產品有這功能會比較好，但不是一定要具備。如果有則會讓使用者滿意度變高。

A 魅力型需求（Attractive）

不會被顧客過分期望的需求。
讓使用者覺得驚喜的功能。如果有，則會讓使用者感到滿意，但沒有也不會因此表現出明顯的不滿。

I 無差異需求（Indifferent）

使用者對這一因素無所謂。（時間可以不用浪費在這裡的功能。）

R 不需要（Reverse）

使用者不需要這種功能，甚至對該功能反感。（多做多錯不如不做。）

Q 有疑問（Questionable）

表示有疑問的結果，一般不會出現這個結果，除非這個問題的問法不合理、受測者沒有很好地理解問題、或者是在填寫問題答案時出現錯誤。（出錯乃 UX 常事，大俠請重新來過。）

優先度：M (Must-be) > O (One-dimensional) > A (Attractive) > I (Indifferent)

1. 質量特性評價表

剛提到 6 種需求，那我們怎麼知道該功能屬於哪個需求呢？可以透過「質量特性評價表」來取得數據。針對某功能請使用者／業主／客戶回答正向問題和負向問題。

正向問題：具備這個功能時，你覺得如何？
負向問題：沒有這個功能時，你覺得如何？

1. 喜歡
2. 應該的
3. 無所謂
4. 能忍受
5. 不喜歡

簡單來說就是遇到意見分岐，發問卷下去給大家寫，問卷只有 2 題，選項就這 5 個。寫完回收統計數據就知道這個功能到底受不受使用者/業主重視了。有時候使用者/業主很傲驕的，嘴巴上不會給你心裡想的真正答案（也有可能他們真的沒有想法只是隨口講講）。質化研究在處理意見分岐要花太多時間，改用量化較能快速取得方向。

2. KANO 評價結果分類對照表

問卷填完回收後，可以對照「KANO 評價結果分類對照表」進行分析，每一張問卷都會取得一個英文代號（需求類型）。

A 魅力型需求
O 期望
M 基本需求
I 無差異需求
R 不需要
Q 有疑問

3. 評價結果

根據剛剛整理的問卷數據，算出每個英文代號的百分比。

根據上方我亂掰的數據，可以得出結果是「I」， I 是「無差異需求」，也就是有沒有做都不影響使用者滿意度。如果只針對單一功能做分析，偷懶的話到這個步驟就可以了。如果同時對數個功能做優先排序，請繼續下一個步驟。

優先順序為：M > O > A > I

4. 敏感性分析結果

這個步驟要計算分數，取得某功能滿意、不滿意的影響力數據。對照「功能評價結果」的百分比數據，套下列公式計算。記得先算 () 括號裡的數字。

SI：滿意影響力
DSI：不滿意影響力

計算公式

SI =（A+O) / (A+O+M+I)
DSI = (O+M) / (A+O+M+I) × -1

SI = 40 / 90 = 0.44
DSI = 20 / 90 x -1 ＝ -0.22

5. KANO 模型分析結果

參考下圖，原點在左上角。對照敏感性分析結果把每個功能座落在哪一個位置標出來。

在灰色圈子裡的就是質量特性敏感性不大，可暫時不予以考慮的功能。離原點越遠的優先程度越重。

結論

整個狩野分析的操作步驟為：

1. 發問卷，正向問題、負向問題 5 選1。
2. 對照「評價結果分類表」，每張問卷都有一個英文代號。
3. 統計完所有的英文代號數量，換算成百分比。
4. 套用計算公式，算出 SI 滿意影響力和 DSI 不滿意影響力的數值。
5. 用影響力數值當座標，把該功能標在 KANO 模型分析結果上。

開會還在吵要不要做哪個功能嗎？工時這麼短、要做的事那麼多，卻不能決定哪個先哪個後嗎？狩野分析能用量化的方式幫你快速決定要或不要。只求真正有決策權的人在跑完狩野分析看到報告文件後能多考慮一下，產品不是功能越多越好用啊！

反正問題就那 2 項，隨時備個幾份帶去開會，再爭執要不要做某功能就發下去填一填會後統計交分析報告...還是沒辦法克服「不加新功能就會死恐慌症」的話我也不知道該怎麼辦了...orz

延伸閱讀：04【译】利用卡诺模型（KANO）选择最优结果，學習更多不同的圖表分析。

（我竟然忘記寫這篇），和群裡設計師聊，發現 Prototype、Wireframe、Mockup 因為翻譯有時候皆統稱為「原型」的關係，導致大混淆，所以來說明下這三者的不同。

這是最簡單的分法。（擬真＝模擬真實最後產出，不是擬物風。）

Wireframe

靜態的「線框圖」

Wireframe 是線框圖，除去各種視覺影響元素，只用線條和方塊來繪製，可以專注在功能和操作上。不管是用手繪或是軟體繪圖都可以。

這是手繪的 Wireframe。

這是用 iPad 亂撇的 Wireframe。

這是用軟體畫的 Wireframe。

Wireframe 通通是靜態的，不會動、不能被操作，就只是圖片。

Mockup

靜態的「視覺稿」

用 Photoshop、Sketch 製作的視覺稿，下一步就是切圖交給 RD 套版的成品。視覺上和最終可操作的產出一樣，就差 Mockup 是單張圖片（檔案）而已。

很像最終產出的 Web 設計，是 Mockup。

很像最終產出的 App 設計，Dribbble上有很多都類似長這樣，叫 Mockup，Mockup 也是靜態的，不會動、不能被操作。（會不會動不是指動畫，而是指有沒有串後台資料。）

Prototype

可操作的「原型」

要被稱為 Prototype 最重要的一點就是「它會動」也就是它可以被操作、有反應。有人會把 Prototype 分成低保真原型、高保真原型等等，不要想得那麼複雜，只要會動的、可操作的、還沒正式發布上線的，都能被稱為 Prototype 。

參考 用 Hype3 做 Prototype：基礎過場一文，這裡的 Prototype 是用 Mockup 做的。

低保真原型 ＝ Wireframe ＋ 可操作
高保真原型 ＝ Mockup ＋ 可操作。
已經切圖交給RD 套版、尚未套後台資料（先用假資料）的也會被稱為高保真原型。

Prototype 最重要的就是「可以被操作」。所以手繪撇一撇數張 Wireframe，做成可以被操作的模式，就能叫它做 Prototype。像上圖所示，幾張 Mockup 串一串設定操作範圍，可以被操作，也是 Prototype。

結論

中國有很多奇怪的簡中譯文，如果跟著把 Wireframe、Mockup、Prototype 通通喊做原型的時候，就分不出來對方講的原型指的是哪一種。硬要翻成中文不如稱它是線框稿、視覺稿、原型，當然最好的情況下還是使用英文吧。

如果溝通的對象、尤其是交辦工作的人開口就是「原型」，請一定要問清楚是哪一種， Wireframe？Mockup？還是 Prototype？不然雞同鴨講之後的下場絕對讓專案小組雞飛狗跳。

老公每天下班路上和人乾一樣，工作高壓被搾得半死不活。結果管理員跟他說有包裹，還這麼大箱，瞧他樂得小跳步的，雀躍到會飛了。吵著要我幫忙做開箱記錄...你是不會去除自己 BLOG 的草嗎？他說 PO 我這才有人看，他想炫耀林北在一年前就訂了等到現在同事都玩到有貓貓了林北的包裹還在美東迷路所以Amazon免收運費等得有夠久的苦盡甘來心情。

（老公說他不想露臉，就這樣了。）

以下圖多又大張。

還以為這箱這麼大箱裡面塞滿填充材，沒想到比我家水波爐還大啊！！

打開...據說這些是開發者簽名。是印刷的不是手工簽，嘖～

拿出最上層的大盒子，狼頭反光燙銀質感超好！真的有鐵鏽的感覺。

一開就有原畫集！我最喜歡原畫集了～～～

遊戲光碟和收藏盒、項鍊。

特典項鍊，刺很尖的狼頭。在調拍照角度的時候見血了，牠的牙超超超超利！手指被戳個洞...老公還說穿T恤時可以戴這條出去擺顯...身為一位 RD 宅氣逼人也是很合理的事？（拜託不要)

重頭戲來了！超大箱寶麗龍製寶箱！

打開～裡面包得好好的是傑洛特和獅鷲獸！

寶劍和獅鷲獸的椅巴要另外組裝...(方型的菊花！）

老公爆了獅鷲獸菊花...

（我還在用 iPhone 5s，模型各個角度的照片就加減看吧。）

.
.
.

以上是娶了 UI Designer 的 RD 逼他老婆寫的 The Witcher 3 典藏版開箱文，可想而知接下來好一陣子我會當巫師寡婦了。

南港園區的食物很難吃，快比交大慘了。扣掉連鎖沒幾間環境乾淨又好吃的小店。中午吃了一間義大利麵，最基本的肉醬麵 $150 元，附自助式湯和飲料無限。飲料果汁加水調得很稀，玉米濃湯鍋裡滿滿黑胡椒，什麼味道都被蓋掉了。最後上來份量很多的一盤義大利麵，我卻什麼胃口都沒有。胡亂吃了幾口，和意料中的一樣，沒有蕃茄味、肉醬平淡，麵條普通，還咬到硬骨頭。

老公點了白酒蛤蜊麵，狀況更慘，整盤麵死鹹、滿滿的大蒜。沒有白酒味，連蛤蜊的味道都被大蒜蓋過去。

最後我們只吃了半盤後放棄，結帳離開了。（昨天晚上滿燒肉丼好吃多了！也是 $150元啊！）

使用者在意的點

南港軟體工業園區的餐飲業主力在中午吃飯人潮，上班族在意的是吃飽，還是好吃？我自己會選「好吃」。套回義大利麵身上，就會是「味道」而不是份量。比起擺盤精不精緻，我會更要求吃起來新不新鮮、合不合胃口、會不會咬一咬喀到骨頭。（因為咬到硬骨崩過牙齒，我對這點非常在意。）

色、香、味俱全才是好料理，其中並不包含「份量足」。那最重要的是色還是香或是味？

如果

• 色＝視覺呈現
• 香＝視覺以外的誘人因素
• 味＝實用操作性

大家一定吃過聞起來很香，吃起來很難吃的食物，或是去了很貴的餐廳，侍者送上擺盤精美的法式料理，吃了第一口大失所望。也可能遇到跟我一樣，份量超足可是味道讓人沒辦法吃完只能放棄的餐點。少數幾次有遇過送上桌看起來一整個糟，吃起來卻很好吃的菜色（我不習慣整盤黑黑的福建炒麵，但很好吃喔！）。

同理，對 App 來說，重要的是色、香、味的哪一個？還是功能數量多最重要？

（我自己寧可吃不飽沒關係，起碼給我好吃的食物，總比難吃放棄浪費好多了。）
（咬到骨頭一定是操作到一半突然遇到 Bug 的感覺，這不是 Bug 是功能...唬誰啊！）

自己煮、去外面買現成、訂做

講 UI/UX 有點難懂，講吃的大家一定有經驗。嫌外面便宜的路邊攤食物太油太鹹不健康，買菜回家自己煮，結果煮出來不怎麼好吃，或是下班太累還要自己煮花太多時間不如去外面吃一吃再回家。點碗麵順便跟老闆說不要蔥、不要香菜、不要豆牙菜、醬放多一點之類。

UI 設計和吃飯也差不多了，看是要自己煮還是去外面買現成、叫老闆不要加蔥不要味精這種簡易客製化。路邊攤一定比較便宜、餐廳就是比較貴，但口味粗糙精緻與否一定和價錢有關。一分錢一分貨，東京咖哩和自助餐咖哩根本天差地別。（不代表便宜沒好貨，貴的也是有雷店。）

當然 UI/UX 不是自助餐，現成模組挑一挑就裝便當盒結帳，但買的人一定會挑自己喜歡、或對有益的菜色。回家邊吃邊對口味挑三揀四嫌太油之類。

使用者就是買便當的那個人，邊操作邊對 App 嫌東嫌西很正常。真的要像 60 元自助餐一樣，拿 A 的註冊方式、B 的文章版型、C 的操作選單、D 的會員中心湊一個便當，會好用順暢到哪裡去？我對自助餐的印象就是「過日子」而不是「過生活」的選擇，如果自己的 UI/UX 設計是這種自助餐湊菜色便當，會接受這種模式的是什麼樣的客群？

（當然也有貴到爆炸的自助餐，菜色會精緻很多。）
（無限修改次數大概就是吃到飽的自助餐吧，看是欣葉還是艾美寒舍的差別。）

份量多八成口味不怎麼樣

仔細想想，我看到主打「份量足」的餐廳，對它的印象都不是「精緻好吃」路線，反而認為是吃粗飽，甚至會對這種餐廳的口味打個問號、抱持懷疑態度。比如跳舞香水這類的甜點吃到飽，和 Laetitia 泡芙或 LIVE SWEETS TOKYO 東京半熟凹蛋糕比，哪邊比較精緻？（大部份吃到飽的店根本是讓一群人聊天用，不是去吃好料吧？）

究竟是「份量足」比較容易辦到，還是「好吃」比較簡單？對 App 開發來說，功能豐富比較容易辦到，還是易用精緻？有時候把 App 變成 食物，使用者體驗什麼的就很容易想像了。

App 醜一點、功能少一點沒關係，給我好用的 App 啊！

（醜太多也不行，吸引不了使用者...）

來聽演講：當設計師遇上敏捷開發
講者：陳威宇 Dix Chen

老樣子，即時聽打...（19:30～21:30）

一定是我誤會了，預期這場演講會講方法論...

19:40

（自我介紹）

Dix：「稍微有點經驗的設計師都會知道，在交付檔案的時候都會有圖層管理和命名等等。」
Dix：「收到很多公司檔案，打開都會覺得...呃...所以在場各位要有點自信。」

（自我介紹）

駭客松 A（自我介紹）
駭客松 B（自我介紹）
駭客松 C（自我介紹）
駭客松 D（自我介紹）
設計松 A（自我介紹）

（現在 20:08，說好的敏捷開發呢？說好的敏捷開發呢？說好的敏捷開發呢？）

20:10

為什麼要加入新創公司
大公司是非很多～金字塔底層、奇怪的氛圍、新創公司隨時修正工作流程...
大公司....新創公司...地點、彈性、工作流程...

20:15

怎麼參加新創公司的面試、面試過程
中間很多有趣的事情...面試時間...有困難...怎麼解決...

20：18

在拼貼趣的敏捷開發
每個星期推出一點點的改版，比如換個顏色、改個字...
某功能需要幾天？NO、週五就要上線了。
每週都有使用者訪談，可能網路或路上拉人。

20:20

改變設計思維
大公司：主管導向。
新創公司...

20:23

拼貼趣的一週...

.
.
.

附近有間甜點店讓我驚為天人啊！WUnique Pâtisserie 無二烘培工作室
大推「翻轉蘋果」，真是太太太好吃了！！

當專案成員越多，我越不推薦敏捷開發，原因在於「當連自己要做什麼事、為什麼這樣做、這樣做為了解決什麼問題」都搞不清楚前，就跳下去玩敏捷開發，那和比通靈還慘，通靈起碼還有個目標物在前面，搞不清楚狀況的人只能陪他跳世界迷霧開地圖了。

敏捷開發 - MBA智库百科最下方有段「對敏捷開發的誤解」。可順便參考 敏捷軟體開發 - 維基百科。

誤解一：敏捷對人的要求很高

說高不高啦，撇開實作技術不談，你覺得要找到清楚專案開發流程、知道每位專案成員的工作內容、職責範圍、產出，並清楚專案目標、需求、使用者需要的開發人員（含設計師）很容易嗎？

如果上述條件無法達成，又怎麼確定運用敏捷開發方式後，所有專案成員方向都是正確的？就因為這種人太難找，所以會產生「對人要求很高」印象。

連在有企劃書、規格書、使用者研究報告的文件情況下都還不知道自己要幹嘛、同事在幹嘛，能談敏捷嗎？

誤解二：敏捷沒有文檔，也不做設計

文件撰寫與否和敏捷開發一點關係也沒有，敏捷開發強調「適應性而非預見性」，並沒有強硬規定。雖然有一句「可用的軟體：重於 詳盡的文件」，但它沒有叫你不要寫文件。

先想看看寫文件是為了解決什麼問題？如果不寫文件會產生什麼問題？

以 UI 設計師來講，交出 UI Flow、Wireframe 這種文件是為了解決什麼問題？要敏捷開發嘛就不用寫了跳過，直接出 Mockup 吧。因為發現出包有漏改來改去改到死，和找到產品問題改良，是兩回事啊！

敏捷開發不是沒文件沒流程的包裝紙。

誤解三：敏捷好，其他方法不好

敏捷開發就是一直小幅度改啊改啊改啊，可以增加工作效率，讓大家工作更順利喔～～（就算是瀑布流式的傳統開發流程，設計師也是一直改啊改啊改啊，效率了什麼、順利了什麼啊！？）

先承認有問題，才能找出問題，之後找解決方法。而不是先有方法，再想這個方法能解決什麼問題。敏捷開發只是一種「方法」，方法論用在敏捷開發上，要回答兩個問題：

1. 現有模式為何不能滿足你的需求？
2. 敏捷式開發為什麼可以？

敏捷開發不是萬靈丹，先找到問題點、知道為什麼要採取敏捷，重點是卡在哪裡需要敏捷這個「方法」來解決。設計師改來改去是為什麼解決什麼問題？敏捷開發的小幅度改來改去、和現況設計師的改來改去有什麼不同？如果都一樣為什麼要採取敏捷？（不要跟我說因為軟體開發主力是 RD 所以忘記算上設計師。）

現實的扭曲

個人與互動：重於 流程與工具

開會是非常燒錢的行為，如果專案成員一多，要用什麼方式降低溝通落差、盡量讓每個人理解到的都相同？怎麼確保部門和部門間的資訊交流順暢？靠出張嘴溝通就能辦到嗎？

可用的軟體：重於 詳盡的文件

有文件產生/解決什麼問題？沒有文件產生/解決什麼問題？不寫文件最愛用「我們是敏捷開發」當藉口了，不會寫就不會寫、不知道文件寫來幹嘛就老實承認，少拿這個當說詞。

與客戶合作：重於 合約協商

如果客戶沒有在好的引導下一起合作，現實狀況會變成「最後一次-確定最終版-說好不改了-V21.psd」。嗯？改來改去不就是敏捷開發嗎？（喂）

回應變化：重於 遵循計劃

這不是改來改去改到死的好理由！為什麼要「變化」，變化是為了解決什麼問題？沒有問題改它幹嘛？完全不代表可以沒計劃就上啊！

結論

敏捷開發宣言裡各種許願...拔掉敏捷二字不也是所有專案開發的理想？所以為了解決什麼問題而採用敏捷式開發？為了改善工作流程加快效率？

那設計師修改到死的工作情況在敏捷開發裡要怎麼被改善？

我覺得敏捷開發適用「頭腦清楚」的人，只是這種人往往是大神級的了。和大神 PM、大神 Planner、大神 RD 合作，都清楚知道自己在幹嘛、別人在幹嘛，還能 Cover 一點別人的領域，知道解決這個問題可以往目標更進一步，這種合作模式才有辦法做到「敏捷」，而不是因為抓漏抓蟲在修改。是啦這也算朝目標邁進，但「創新改良產品」和「讓產品看起來洞沒那麼大」的改來改去本質上是兩回事啊！敏捷開發只是個方法，不是萬靈丹。

敏捷式開發就是改來改去？
那「字大一點、Logo大一點、換一張照片、多出幾版讓我挑」也算啊～

哪來有畫 Wireframe 就是有做 UX 的錯覺？UX 不是 Wireframe，使用者體驗為什麼會是線框稿？當然不是啊！很多人以為有畫 Wireframe 就等於有做 UX 了，那整天抱著數據統計寫文件的 UX 設計師在幹嘛？會把有畫 Wireframe 當成有做 UX 的人，合作的 RD 同事通靈技能大概 LV99 點滿了。

UX 在做的事和 Wireframe、Mockup 息息相關但表面上看不出來，這牽涉到到專案開發和架構、功能需求，已不再是表面的視覺而已。大家都知道 UX 做好就能讓增加使用者滿意度、或是讓更多的人註冊付費...所以有畫 Wireframe 就能夠吸引使用者？怎麼推導出來的結論？

先找到問題才能解決問題

1.如果問題是「如何透過增加使用者體驗的方式吸引更多使用者？」
2.解決問題的方法是「畫 Wireframe」。
3.那問題就變成「為什麼畫 Wireframe 可以增加使用者體驗？」。

Wireframe 傳達的是「UI」，User Interface 使用者介面，是「文件」的一種。在除去所有視覺影響的情況下，能讓閱者把注意力放在介面構成、操作、元素配置上。

UI 是 UX 的一部份，但 UX 不是 UI ，獨角仙是昆蟲的一種，但決不會把昆蟲都叫做獨角仙一樣。如果這句還是不懂...你媽是女的，所以女的就是你媽？（某大大這句話真好用，迫力十足。）參考舊文 我是UID，不是UXD。

常見 UI 的工作是 Flow、Wireframe、Mockup、切圖、標示文件...等。
UX 的工作應該是使用者測試、數據統計、研究報告...等。

（不過都被混在一起講了，業界現況喊做 UI/UX 的大多只是平面設計，少數在做視覺設計、更少數是 UI、極少數做 UX。）

研究方法

真正的 UX 很像實驗室那群披白袍的研究僧，整天和數據、實驗打交道，寫不完的報告和文件。針對專案開發不同階段和目的，有各式各樣的研究方法求取答案。之前也寫過一串的文章，簡單介紹專案各個階段會遇到什麼問題、可用哪種研究方法解決。

UX，設計的方法（專案初始）
UX，設計的方法（專案執行）
UX，設計的方法（專案中期）
UX，設計的方法（專案後期、追蹤）

如果問題是「如何透過增加使用者體驗的方式吸引更多使用者？」那該問的下個問題是「現有產品遇到什麼問題需要改進？」、或是「使用者特別在意產品的什麼部分？」有了問題，才能找解答方式。

現有產品遇到什麼問題需要改進？

1.可用性測試 Usability Testing
記錄使用者在操作上有什麼不順的地方加以改進。

2.最簡可行性產品 MVP、快速反覆測試評估法 RITE
甚至在開發階段就用簡易 Prototype 做測試，是不是就能解決產品上線了才知道哪裡有問題要改的情況。

使用者特別在意產品的什麼部分？

1.狩野分析
這功能到底有沒有做的必要，是使用者需要的嗎？

2.使用者旅程圖 Customer Journey Maps
找出使用者在什麼情境下會遇到什麼狀況，將產品修改得更符合使用者需求。

遇到問題，尋找解決方法。而不是「我看到有這種方法，咱們來研究下這方法能解決什麼問題」，順序錯了。而 Wireframe 就更不可能回答上述的使用者體驗問題，根本找錯方法。

結論

回到文章一開始提到的，畫 Wireframe 為什麼就是有做 UX？做 UX 是為了解決什麼問題？想解決的問題透過畫 Wireframe 就能解決嗎？Wireframe 為什麼能改善使用者體驗？

UX 不是 Wireframe，使用者體驗不會因為畫了 Wireframe 就有所提升，Wireframe 只能降低通靈程度、減少溝通落差、讓專案開發進行順利，並不附加提升使用者體驗的屬性。真的想解決產品遇到的問題、提升使用者體驗，還是運用下研究方法、跑點數據寫點統計報告吧。

女人錢到底有多好賺？只要扯到愛情和面子，多少錢都捨得砸吧我覺得...自認某些角度比身為 RD 的老公還冷血理智，遇到這兩點自制力還是被挑戰。最近接觸兩款乙女向的遊戲，差點就掏錢了，還好 UI 爛到爆炸...就算熱情和沸水一樣，當環境是北極圈時也早結凍光光...

男讀者別看到是乙女遊戲就直接關視窗，這篇沒有要講乙女遊戲是怎麼擄獲芳心。

我一向不屑爛 UI，這輩子從沒像這時候這麼感謝爛 UI 的存在，難用到讓我想放棄這款遊戲，免去無止境貢獻大把金錢的可能性（但好奇心又會讓我留著玩免費的部份）。這兩款遊戲做的很好，產品策略太精準了，直擊女性的弱點，要是 UI/UX 被改善，獲利肯定更可怕...（再次感謝爛 UI 讓我省一筆。）

新章大奧 / 月下灰姑娘

數量眾多的二次元美男＋好劇本

新章美男大奧◆秘戀情緣

美男宮殿◆月下灰姑娘

這遊戲就是賣男色賣劇本。幾年前還常常聽到「情感行銷」，我也買過幾本講情感行銷的書，還在思考要怎麼和 UX 結合。新章大奧 / 月下灰姑娘在劇本、人物立繪上水準是夠的，但操作介面大概是公家單位等級，絕對會讓人迷路不知道下一步怎麼操作的程度。

Love plus 在日本多紅就甭提了，大奧的開發商 CYBIRD 可能沒有那麼多資金可燒，用 HTML 開發這兩套遊戲，賣故事券、賣道具。以往這樣子厚度的 AVG 整套遊戲了不起就是 NT3000 左右，還有知名配音員全程語音，搞不好還附特典。

但在手遊課金制度下，想全收齊不小心就會花破萬...怎麼可能全收齊，CYBIRD 常推出期間限定的劇情，說是免費，但對遊戲內主角的數值要求很高、不達到就看不到、不掏錢提升素質也達不到。（更慘的是這遊戲沒音樂沒配音。）

（圖片取自 http://www.itmedia.co.jp/mobile/articles/0703/19/news040.html）

日本很習慣這樣子的操作介面，字很多的留言板形式，Link 就是文字＋底線，可能還是藍色的，Web嘛。所以這兩款遊戲的首頁 UI 長這樣...

有沒有超長一頁？它就是 Web！還一堆廣告...美少年再帥看到這種網頁，心都涼一半了。

個人內頁長這樣，上方還是跑馬燈喔！所有有底線的文字都是 Link。老實說我第一次開啟 APP 的時候還以為穿越回 IE6 時代，各種字體大亂鬥＋表格排版，按鈕 icon 很有 DOS Game 風格，讓我回想起當年玩的仙劍 1 代。（是說這遊戲又不是賣UI ，賣色慾和貪念。）

當一個頁面可操作的元件越多，Flow 就更重要，不是說每天有 5 張免費故事卷嗎？隔天我想繼續看故事的時候找半天不知道點哪裡，因為我一直以為畫面最上方長駐的 Tab Bar 和最下方的 Bar 內容是一樣的。（事實上有幾個真的是一樣的）

就不截道具畫面和小遊戲的介面了，整個系統為了課金搞得有點複雜...不過掌握住中心思想就能理解操作：「給錢才有美少年」。

在玩遊戲的時候，我腦海的不停交雜這樣的對話：

「然後呢？」（敲碗！）
「幹、介面好醜要按哪？」（想付錢還不知道怎麼付）
「然後呢？」（敲碗！）
「幹、介面好醜要按哪？」（想付錢還不知道怎麼付）

看到 UI 提示看故事請付一張故事券的時候會瞬間冷卻出戲，一位差這麼一點點的付費用戶就這樣流失掉。要我付錢起碼加上全程語音或美麗炫目的 UI 來迷惑人心吧！

暖暖环游世界

大概要數百坪衣櫃才裝得完的紙娃娃系統

暖暖环游世界（中國或日本的 Store 才有）

NDS 有一款紙娃娃系統做得很棒的遊戲「自我時尚‧淑女風範」，當年我玩了 1 代，是款當服飾店新手店長依客人需求推薦穿搭的遊戲。

暖暖環遊世界也是款紙娃娃穿搭遊戲，不過服裝數量和撈錢技巧超過 NDS 那款太多，（劇情就算了，很多都鬼扯，不過誰期待這遊戲的劇情了？）這遊戲剛推出我就下載試玩，到後期不花錢買衣服道具分數都很難看。

剛推出的衣服有點讓我懷疑暖暖的衣櫃和明星志願 2 方若綺的衣櫃互通。大概有賺錢，越來越精緻、越來越誇張，完全走中國式 OLG 財大氣粗 Cosplay 路線。最有趣的是開發商和電視節目合作，女明星穿什麼衣服上節目，暖暖就有同款的衣服可穿搭。

UI 比大奧好太多，可以按、不能按的地方分得清楚（我的標準真低），原生的 App 不是用 HTML 湊數，全程音樂＋全程中文語音（改版後），感受得到開發商的賺了不少（被獵豹買了的關係？）（喂）

不過這 App 也有「設計債」還不掉的情況，後期一直塞新功能、新課金機制、新活動，導致原本中規中舉的 UI 和 Flow 變得很肥，常常有很突兀的頁面或不知道怎麼操作的情況產生。只要讓使用者不知道怎麼操作，付錢的意願就降低了。

.
.
.

這兩款都是我很看好、很有錢途的遊戲，而且市場競爭者少，同樣類型的遊戲不多，也沒有完整龐大如它們一般的水準。就是 UI/UX 差了一點，改善空間很大。雖然 UI 不是遊戲賣點，但稍微整理下不要讓使用者太出戲，付費的人肯定會更踴躍。

下午和群裡的設計師唇槍舌戰了一番，然後發現溝通落差，設計思考階段根本不在同一階。他希望要大家幫忙 Brainstorming 提意見，結果我一直拿可行性和他杠。（老公看到肯定覺得欣慰，養出一個會幫 RD 擋可行性的 UI 老婆。）

我是接案公司出身，最長時間合作的 RD 又是老公，可以說大部份的 UI 觀念都是從 RD 那邊來的。稍微有個「可行性」問題沒被考量到就是 UI 老婆被 RD 老公拎去牆角碎碎念。養成不管什麼階段都會問「資料怎麼來」、「頁面怎麼串」的習慣。

導致我設計 UI/UX 的邏輯根本不像一般設計師，還比較偏 RD 式思維，這是一個很大的優勢也是劣勢。我的作法就是所謂的「守舊派」，雖然會去鑽研新技術，但不打算拿來實用，非得 RD 說辦得到才會考慮。不管什麼情況下我第一思考的都不會是「使用者好不好用」，而是「這個東西 RD 做不做得出來」，這種思維方式不會做出讓人驚豔的作品，簡單來說就是成不了大器。

創意發想最知名的方式就是 Brainstorming 頭腦風暴了吧，在 Brainstorming 中不能指責、不要思考可行性。如果一開始就思考可行性，創意在萌芽階段就被扼殺掉。講是這樣講，我也認同在找靈感的時候不能考慮可行性，但是...

.
.
.

再好的點子，RD 做不出來有屁用啊？

這世界不缺點子，缺的是執行的方法和實作的人。做不出來一切白搭，又不是霍華德·史塔克（鋼鐵人他爸）留下「一個並不存在於自然界中的全新元素」給東尼·史塔克去解，做專案誰跟你玩父子情深代代相傳...

我對於創意的看法一直有個偏見：「幹、連基本的東西都做不好了跟人談三小創意。」把轉運站、停車場、巨蛋都蓋成百貨公司就是創意了嗎？不會切圖、不會畫 Wireframe 的 UI Designer，跟人說想做出改變世界的偉大設計，這是夢想不是創意。

創意和可行性總是得取得平衡，不管是很棒的點子結果做不出來，還是根本沒想法先兜一個，死線到了就是要產出個東西。

既然找不出個能說服自己的答案，所以我跑去問大神的看法。

.
.
.

東西做不出來，代表砸的錢還不夠多。

大神鏮鏘有力地回了這句名言。

我還在糾結創意和可行性要怎麼取得平衡點，大神這麼霸氣十足的一句話讓我頓悟了，在錢的力量下，可行性真的沒有創意重要啊！有多少錢、做多少事，創意和可行性的平衡點該是如此吧。

我總煩惱著要在最小成本下完成專案（家庭主婦思維？），當有足夠的資源可用、有足夠的發揮空間時為什麼不試著燒看看？看手上有多少資源可以燒來決定要創意先行、還是可行性優先也是種決策方式吧。

判斷可行性這件事是 RD 的工作，UI 的工作是以使用者為中心，在這點上我做得不夠好。UI 該做的應該是拿著以使用者為出發點的設計和 RD 好好溝通是否可行，並加入 PM 確認有多少資源可燒，從中三方協調出可實現的方案。

清書櫃！二手書，某幾本有畫線寫字，附光碟的光碟都未拆，內頁乾淨、有幾本年代較久泛黃。
依照片標價出售，下半段一本換無咖啡因的飲料一杯～

有興趣的請到 粉絲團私訊或 mail 給我，全包優先喔！

限自取，板橋新埔捷運站。

粉絲團： https://www.facebook.com/uiux.akane

剛從溫哥華回來，被氣候和時差整得很慘。不過扣掉天氣冷、餐餐馬鈴薯之外，溫哥華真適合人類居住。出國旅遊基本上我是室內派的，很喜歡往博物館跑，這次去了科學世界和海生館，先來聊聊科學世界吧。圖多慎入

溫哥華 科學世界官網：Science World British Columbia

這張是溫哥華的天鐵站月台拍的。其實在溫哥華走到哪都有類似這樣子大 icon 標示，就算看不懂文字也看得懂這 icon 圖表達什麼含意。（為了 icon，整理照片的時候發現我拍了很多垃圾桶和資源回收桶的照片...）

靠碼頭的科學世界，適合排 2~3 小時逛逛，很多小學生會來此校外教學。

這邊的展區比較像是讓小朋友動手玩科學的設計，進去館裡會看到很多桌子，擺滿各種可以動手操作的道具，都不怕被摸走搞破壞。只能說教育良好從小做起。

看不懂英文說明沒關係，這邊大部份的說明都有附圖，看圖都能理解，不愧是多語系人種的泱泱大國...

餐聽招牌，背影是老公不是廚師。趁他抬頭看招牌時拍下的照片，位置真剛好XDD

搭上這股侏羅紀恐龍熱，餐廳提供恐龍兒童餐，館裡也有恐龍特展。我很喜歡這塊看板，雖然元素有點多，風格也挺雜的，但版面編排很活潑，感覺上就是套很有趣又不幼稚的兒童餐。

空氣砲！這個很受小孩子歡迎、也很受我和老公歡迎...每個展品旁邊都會放解說牌和簡單圖解，家長可以很輕易現學現賣說明給小孩聽。

館內很多這類大型的「動手玩科學」，就算是大人也會不小心玩瘋 XDD

這是台超大的可觸控桌面，展示各種物體在可見光、不可見光下呈現什麼模樣。可以透過點擊或兩指放大、縮小操作。很流暢、解析度也很高。

恐龍特展門口，瞧瞧他們的字體設計，很普通的黑體，但只微調幾個字的角度和位置就變的很活潑有趣。溫哥華街頭到處是這類型的英文字體或書法字型，走在路上東張西望也很安全，人行道很寬很乾淨。

展區看板，很少看到用這種粉筆手寫的展板設計，台灣沒用標楷體就謝天謝地了還談版面...

觸控螢幕，講地球板塊移動，可以拖動年代Bar、或是轉動地球、點擊恐龍 icon。（顏色配得很舒服乾淨，又不僅僅面向小孩子。）

柱子上有這張貼紙，Beacon 搭配室內導覽喔！

免費的搜集鋼印活動，我和老公全場跑到處找鋼印蓋。台灣只會用印泥印章，乾得慢染得到處都是，用鋼印好貼心，浮雕效果又很優雅，也不用擔心小朋友亂蓋一通。在 Capilano Suspension Bridge 的搜集活動裡也是鋼印喔！

我去過馬來西亞吉隆坡的科學世界，也去過台灣台中科博館，三者完全不是同個檔次，一分錢一分貨。

台灣就別提了，根本「有就好」而已，溫哥華門票最貴，但內容和展品也最精緻，完全對得起它的票價，甚至比預期得到的還更多。你能從博物館各個小地方感受到他們對教育的重視，也感受到他們在很多細節上的貼心設計。不管是 UI 還是 UX，都會讓人覺得「很順啊沒什麼障礙」，甚至會有「驚喜」的感受。

到這裡，你真的會人來瘋，和一群小朋友東摸摸西碰碰，排隊等著玩各種科學道具，或是發出「喔喔喔怎麼會這樣」「喔喔喔原來如此」的呼聲。

BETA 5

附帶介紹下附近的甜點店，這間藏在離科學世界 10min 路程的工業區小倉庫裡。大概是我這輩子吃過最好吃的泡芙了。泡芙皮是千層派啊！

BETA5 Chocolates - Award-Winning Chocolates, Pastries and Desserts - Vancouver, BC

我們倆在逛完科學世界後跑去拎了原味和巧克力，散步回旁邊的碼頭邊等船邊吃，當下午茶很幸福。（小心烏鴉半途叼走，我就看到隻搶了甜甜圈的大烏鴉從頭上飛過。）