Prototype 大觀園：Prototype 優劣分析步步來
本文同步刊登於 NTUChallenge Blog 挑戰誌
很多專案在開發過程中，會製作 Prototype（原型）測試與驗證構想。專案開發會經過許多階段，也有很多種製作 Prototype 的方式。該如何配合專案開發進度，製作適合的 Prototype？
讀者來信：學生專題-1
這是封讓我覺得有點困擾的讀者信，收到的瞬間傻了一陣子，不知道該怎麼回應比較好。反覆看了很多遍，因為他附上學校專題作品，我還去把該系所近幾年的課程與學分全翻一遍。只能對這位學生說：「你爬的文太少！」 而且還爬錯方向…
User Story 和 Customer Journey Map
UI 入門班的 QA 時間，有學員問「User Story 和 Customer Journey Map 有什麼不同？」順便把 Persona 和 Scenario 混在一起…
- Persona （人物誌）
- Scenario （情境故事法）
- User Story（使用者故事）
- Customer Journey Map （使用者旅程地圖）
UI/UX 工作的職責劃分
網路上對於 UI 和 UX 的謬談 這篇留言數量頗多，其中一則留言我另開這篇文來回答。
這張圖是 Dan Saffer 畫的，指的是 UX 包含那些範圍，可以看到並沒有「UI」的圓圈。
網路上對於 UI 和 UX 的謬談
最近 FB 上常看到有人分享這篇 UI & UX 差別是什麼，看圖大整理 ，這篇文有一半的圖都有問題啊，根本不是 UI…除非它指的是視覺設計。
介面設計必須考慮 輸入、輸出、運作內容 這三項，但幾乎所有的圖片都沒有提到怎麼輸入、輸出什麼、運作內容的規則。
UX 包含 UI，很難切開來講，但硬要分細的話，UX 講的是使用者感覺到什麼。UI 著重在互動和操作的媒介上。
設計是解決問題的方法
至少 10 個人轉了這篇文 設計一定要解決問題嗎？ 給我，問我的看法如何。該文傳達 2 個概念：「設計一定要解決問題嗎？」、「設計的目的」。
就我自己的角度，設計是解決問題的方法 這點始終不變。但要看解決的是什麼問題，也就是「為什麼你會這樣做」。
初學者的 Prototype
（我竟然忘記寫這篇），和群裡設計師聊，發現 Prototype、Wireframe、Mockup 因為翻譯有時候皆統稱為「原型」的關係，導致大混淆，所以來說明下這三者的不同。
活用狩野分析搞定意見分岐
設計的方法 這本書不管是 UI、UX、PM、Planner 桌上都該擺一本，不知道報告/企劃書怎麼寫的時候拿來跑一下實驗很好用。從中我認識到「狩野分析」，參考 UX，設計的方法（專案初始） 這篇文，當時預期狩野分析適合用在專案初始、分析這個功能要不要做。最近簡單地跑了一遍，來寫點筆記…步驟雖然多，但只要會加減乘除就行了。
UX，設計的方法（專案後期、追蹤）
前一篇提到的 RITE 就是種「可用性測試」的方法，照傳統的 UX 流程，可用性測試會排在開發後期才製作 Prototype 進行測試，到這階段要修改什麼都太遲了，所以 Lean UX 的作法才會推行用 MVP 執行 RITE。這篇要敘述的就是傳統 UX 做可用性測試的方法。
此外，雖然免洗專案很多，但也很多是需要持續追蹤改版的產品。搞定一回合的專案還會有下一回合要戰，需要透過研究方法去追蹤使用者對推出後的產品有什麼回應，像是「網路分析」。
UX，設計的方法（專案中期）
這篇要講的是專案已經執行一陣子了，有哪些方法可以驗證初期發想和規劃方向無誤的方式，採用大家最熟悉的「原型法」和「快速反覆測試評估法」以及「MVP」的概念。可以當成是投入專案一段時間後做測試，了解苦海無涯回頭是岸所設的停損點。越早發現方向有誤並修正、比開到海中央撞冰山了才發現救生艇不足來的好。
UX，設計的方法（專案執行）
專門開始執行初期會分成兩個可能，1. 鬼打牆。2. 什麼問題意見都沒有先出幾版讓某看看。不管是跳針或是通靈，每個階段都有不同的研究方法可以幫助設計師和以後的 RD 不用把人生都填在修改到死上。
UX，設計的方法（專案初始）
本文內容取自 設計的方法 ，這是本 UX 必備的工具書，整理大量的研究、實驗方法，讓 Designer 可以照著做，產出有模有樣的文件。以下是我自己掏摸的心得。
注意，本文所寫內容不應該是一個人的工作，UX 研究都該是由兩人小組、甚至由團隊執行，但業界環境不許可、當公司喊 UX 同等喊反清復明的情況下，能靠自己的力量扭轉多少才是重點。
文章分類
