先瞭解使用者操作，還是先畫 Wireframe？
設計 UI 的思考順序各位覺得該是什麼樣子的呢？
- 先出 Wireframe，再來想使用者會怎麼操作。
- 先確認使用者會怎麼使用產品功能，再來思考 Wireframe 怎麼畫。
讀後感：設計思考改造世界（1）
「設計思考改變世界」在剛出版的時候就入手，並快速翻閱過。這陣子重看「為真實世界設計」，發現有些觀念自己並沒有好好思考過，兩本書一起比對時有點吃力，只好先暫時放下「為真實世界設計」，回過頭慢慢推敲「設計思考改變世界」書裡的各種概念。
簡易工時安排法
年代久遠，我忘記當時待在哪間公司、是哪位 PM 發起這種方式來安排時程，就某些角度來講很實用，起碼 減少許多 UI 設計師必須和人到處喬工時和工作內容的麻煩。有問題你們 PM 自己出去打一架，打贏的再回來跟我說那個時段要做什麼事。
讀者來信：UI 設計流程
收到一封 Mail，其中提到幾個關於設計流程和 Prototype 的問題。
UI設計流程:Wireframe->低保真Prototyple->Mockup->高保真Prototyple
這樣的流程是對的嗎?
根據上過課的學員回應、以及自身經驗，目前業界的情況大多是 UI 設計師收到「開工啦」的通知，然後就從 Wireframe 開始下手。使用者怎麼操作、有哪些功能、使用者和客戶的需求是什麼往往靠 PM 簡單口述。
Wireframe 為什麼會長這樣？在 Wireframe 之前還有哪些事要做？
全部都靠通靈。
所以執行專案期間都在改來改去，撐到最後一天總是可以結案就解脫了嘛，再開始下個改來改去的輪迴。
UI 設計師應該要會寫的文件
身為 UI 設計師，工作內容不是只有做 PSD 和切圖，只會這兩樣的叫美工。基本一位合格的UI設計師必須要具備撰寫文件的能力，文件最低限度需包含：企劃書、規格書、Wireframe、Mockup、切圖、標示文件、UI Kit、UI Pattern、Guideline。
設計師的版本控管
群裡來了位「全端」，一入群就在討論版本控管這件事。我的 Git 雖然不敢說熟，好歹也懂 Push 和 Pull、發生衝突怎麼解決，多少還能和 RD 槓兩句，不然依 RD 開口就是滿天術語、根本無視對方聽不聽得懂的習性，群裡的氣氛會結凍…
UX，設計的方法（專案後期、追蹤）
前一篇提到的 RITE 就是種「可用性測試」的方法，照傳統的 UX 流程，可用性測試會排在開發後期才製作 Prototype 進行測試，到這階段要修改什麼都太遲了，所以 Lean UX 的作法才會推行用 MVP 執行 RITE。這篇要敘述的就是傳統 UX 做可用性測試的方法。
此外，雖然免洗專案很多，但也很多是需要持續追蹤改版的產品。搞定一回合的專案還會有下一回合要戰，需要透過研究方法去追蹤使用者對推出後的產品有什麼回應，像是「網路分析」。
UX，設計的方法（專案中期）
這篇要講的是專案已經執行一陣子了，有哪些方法可以驗證初期發想和規劃方向無誤的方式，採用大家最熟悉的「原型法」和「快速反覆測試評估法」以及「MVP」的概念。可以當成是投入專案一段時間後做測試，了解苦海無涯回頭是岸所設的停損點。越早發現方向有誤並修正、比開到海中央撞冰山了才發現救生艇不足來的好。
UX，設計的方法（專案執行）
專門開始執行初期會分成兩個可能，1. 鬼打牆。2. 什麼問題意見都沒有先出幾版讓某看看。不管是跳針或是通靈，每個階段都有不同的研究方法可以幫助設計師和以後的 RD 不用把人生都填在修改到死上。
UX，設計的方法（專案初始）
本文內容取自 設計的方法 ，這是本 UX 必備的工具書，整理大量的研究、實驗方法，讓 Designer 可以照著做，產出有模有樣的文件。以下是我自己掏摸的心得。
注意，本文所寫內容不應該是一個人的工作，UX 研究都該是由兩人小組、甚至由團隊執行，但業界環境不許可、當公司喊 UX 同等喊反清復明的情況下，能靠自己的力量扭轉多少才是重點。
