Prototype 幫倒忙？

近年來，隨著軟體開發 SOP 逐漸成熟，分工日趨清晰，Prototype 工具開始像雨後春筍那樣冒出來。但這些工具真的有在幫忙嗎？還是只是在裝逼？這篇將會簡單地分享一下 prototype 在工作中的實戰心得。

這篇將簡單分析各項 prototype 工具，並就其使用方法歸納整理出優點，確定，與現實面。

依照需求，Prototype 工具簡單分成兩大類，一是解決使用流程(userflow)的問題，二是解決畫面跳轉特效(interaction)跟動畫的問題。

如何區分這兩者？

目前市面上的使用流程(userflow)工具通常不能做複雜動畫，頂多做轉場。而跳轉特效(interaction)工具通常不太能管理串好的 flow。

也可參考 Prototypr 這個網站做的詳細分類
http://www.prototypr.io/prototyping-tools/

這類工具以 invision, Marvel, Axure, mirr.io 為主，製作簡單的使用流程體驗，通常支援網站跟 app 的產品原型，讓用戶或是相關開發人員知道整個產品的使用流程有沒有什麼問題的測試用流程。

能夠比實際開發更早玩到產品，看到產品在裝置上呈現的樣子，驗證產品流程與想法，甚至有些團隊會在報告上拿去做 demo。特性是易於修改，技術上手難度低，只要有設計圖任何人皆可維護，上述軟體表現最好的是 axure 跟 mirr.io，只是一個費用高，一個限 mac 系統(但免錢)，免錢又跨裝置就是 Marvel 跟 invision。

設計師工作加重，維護跟修改成本高，易於上手也等同於難以深入跟難以實作很多細節（舉例：請用 invision 做有 side navigation 的登入前後的完整的 app 產品狀態，包準玩死一堆設計師)， 而且通常這種需求為一次性，隨著產品開發越完整，該 prototype 就越走向死亡，毫無用處。但設計師的工作將會變成，討論，修改設計稿，而所有的流程節點都會多加一個 prototype。

prototype 是很有用的東西，他是產品的雛形，但不是必要，公司設計師包山包海，工作範圍大至產品全部面貌下至公司公告，如果你還要他另外娜時間做一個用 HTML 就可以寫但是卻要用綁手綁腳的軟體來做的東西，說明清楚性還低於 sitemap 跟 flowchart，而且展示完就丟掉，這樣的需求可能真的要審慎考慮才是。當然，這也得考量設計師本身熟悉的技能範圍。也許，當向投資人展示戰鬥力時，它會是一個很好的輔助，但不建議太過複雜跟太多次，而同為軟體出身的投資人也是知道那只是表面的。而溝通良好的團隊，flowchart + wireframe 能引出更多的細節，更易於修改，包括錯誤訊息列表，跟各種不同的結果。

這類工具主要是解決很多畫面轉場特效，或是小動畫，為的是讓工程師能知道這個地方該怎麼做效果才好，依照這個效果重現在產品上，讓產品更加豐富的工具，舉凡 Hype 3，Framer，Principle，After Effects，flinto等。

特效絕對可以讓產品加分，流暢的體驗與轉場都牽動整個產品的使用邏輯，讓使用者在使用上如魚得水，加上產品本身如果有打到痛點，佳評就會如潮將你的產品推向更多人，在行動裝置上尤其重要，目前 Principle，After Effects 仍是市場上主流。

大部分轉場特效最終還是由工程師做出，而且大部分特效如果不影響使用流程，那麼就是… 多餘的，除非你想放上影片檔，或是像 After Effect 可以藉著 bodymovin 外掛將動畫變成 .json 或是 SVG 動畫匯出，並可以讓工程師用套件直接跑，不然就是加重他們的工作量而已，而且動畫不管是占掉的容量，硬體效能也相當吃重，卡卡的動畫不但不會加分，只會讓人覺得產品不太行。加上工具學習成本其實不低，設計師如沒有動畫經驗則需時間學習。

現實

動畫吃掉的是設計師與工程師的時間，而實際運用在產品上卻是兩面刃，嶄新的動畫跟轉場會成為市場新標準，壞的動畫與轉場會惹惱使用者。而且設計與工程的重工幾乎不可避免，又何必弄個動畫互相傷害呢？能用現成的，用講的提到哪個產品的轉場，在 codepen 或是 github 找看看的就可以解決的問題，就別讓費時間做去給工程師打槍了吧，溝通才是較好的解法。

明白你想靠 prototype 解決什麼問題，並如何用這些工具改善工作與溝通流程，不然很可能本末倒置，反而是幫自己跟團隊增加工作量，最後成效不好問題又回到你身上，通靈還需解靈人，試著讓自己成為靈媒吧，多多溝通說不定會比做 Prototype 效果更好呢。

如果你對 prototype 工具有不同見解，歡迎讓我知道！