為什麼我不推薦敏捷開發
當專案成員越多，我越不推薦敏捷開發，原因在於「當連自己要做什麼事、為什麼這樣做、這樣做為了解決什麼問題」都搞不清楚前，就跳下去玩敏捷開發，那和比通靈還慘，通靈起碼還有個目標物在前面，搞不清楚狀況的人只能陪他跳世界迷霧開地圖了。
請體諒 Planner
最近調了部門，從 F2E 調去設計部，做 Planner 的工作。大開眼界，看到另一個角度。本來實作人員就是會私下幹醮 Planner 或 PM 搞不清楚狀況，產出的文件怎麼丟三落四、不切實際，或是時程這麼趕也不先問兩句之類。現在我也在寫企劃書，看到些覺得奇怪的問題點。和她們請教後發現很多時候不是她們願意的，而是人在江湖身不由己。
UX，設計的方法（專案執行）
專門開始執行初期會分成兩個可能，1. 鬼打牆。2. 什麼問題意見都沒有先出幾版讓某看看。不管是跳針或是通靈，每個階段都有不同的研究方法可以幫助設計師和以後的 RD 不用把人生都填在修改到死上。
UX，設計的方法（專案初始）
本文內容取自 設計的方法 ，這是本 UX 必備的工具書，整理大量的研究、實驗方法，讓 Designer 可以照著做，產出有模有樣的文件。以下是我自己掏摸的心得。
注意，本文所寫內容不應該是一個人的工作，UX 研究都該是由兩人小組、甚至由團隊執行，但業界環境不許可、當公司喊 UX 同等喊反清復明的情況下，能靠自己的力量扭轉多少才是重點。
避免捅到自己的工作流程
再強調一次，為什麼他接的案子比我多？：設計業界潛規則，讓你接案上班都無往不利 這本書的書名雖然很鳥，卻是每位設計師都該看過的必備好書。裡面提到許多工作方法，其中包含工作流程、工作清單等非常實用的職場技巧。基於老是一稿 20 改的前提下，不把工作流程、工作清單列清楚根本是自挖的屎坑。
工作清單：Functional Map
自從看過 Burn Your Portfolio: Stuff they don’t teach you in design school, but should 這本書後，就想整理個工作清單出來。工作流程這回事通常是公司訂的很難更改，但自己的工作領域內弄個 SOP 、整理出標準作業流程和待辦清單是被允許的。就從 Functional Map 開始吧。
RainFont 開發流程
雖然我和老公合作過多個上架 App，這款字級表倒是我們第一次在沒有客戶的干涉下完成的作品。來談談設計理念和製作過程吧。
官方網址：rainstep.co
初學者的 Functional Map
功能規格書、產品規格書、系統分析、需求分析等等，是 PM 或 SA 或其他同事的工作，反正不是 UI 的工作，很多 UI 不願意去接觸這類文件，（就說了字太多圖太少設計人看不下去、有沒有懶人包？）但看不懂這些文件的 UI 絕不能被稱為好 UI…連這個軟體要做什麼都不熟悉、一知半解，要怎麼說服別人設計的介面是適合這套軟體（或網站）的好介面？
使用者經驗藏寶圖：序
Peter Morville 設計出「使用者經驗藏寶圖
」，如圖，說明一個構想是怎麼合理且適切地無中生有，一直到完成設計提出各式文件給客戶的開發流程。我覺得這是每位UI、RD、PM都該知道的流程，同時也是開發產品的必經之路。身為專案成員不應該悶著頭只做自己份內的事，了解團隊如何運作、每個階段該產出什麼，這點非常重要。
為什麼要畫3次 Wireframe？
每個新案子進來，我通常會畫至少 3 次的 Wireframe，記錄靈感 > 完整繪製 > 電子化。好像重工了喔？可是你哪來的自信覺得設計 App 介面能一次到位呢？靈感乾涸對設計師來講理所當然、RD 都跳坑了才發現設計有錯缺東漏西也很正常、接手修改前人留下的舊案子卻找不到相關文件也不是什麼稀奇的事。為了要避免發生這種慘況，畫 3 次以上的 Wireframe 比較保險。
文章分類
