1
移除 Email：先列出所有受影響的畫面
拿掉一個欄位看似簡單，但帳戶資訊、安全等級、推薦好友、優惠申請、重新驗證等功能都依賴 Email。我在 production 上逐頁檢查所有會用到 Email 的地方，再和工程師從前端與後端兩個方向交叉確認，並設計統一的補救機制：用戶進入這些功能卻沒填過 Email 時，彈出 bottom sheet 補填並完成 OTP 驗證。
012025.12 – 2026.09
跨三品牌 Onboarding 優化
看似只是新增一條註冊路徑，但三個品牌、三個市場的欄位規則各不相同，還得同時移除 Email。我花了一年依序重新設計三個品牌的註冊與登入，最後把三套規則統一成一套。移除 Email 後，也一併重做了品牌 A 的帳號找回流程。
Background|
背景與問題
舊的註冊頁把 5 個欄位一次攤開：用戶名、密碼、手機號碼、Email 和推薦碼。推薦碼雖然選填，對新用戶來說仍像是 5 個都得填完。這次的需求只有一句話：「新增手機號碼註冊」，給用戶一條更快的路。
我每次畫 mockup 前都會先在 production 上實際操作一遍，很多舊流程的問題就在這一步被抓出來。例如註冊和登入原本擠在同一頁用 tab 切換，加入手機號碼後資訊會過多，因此拆成兩頁；同時又接到「把 Email 從註冊表單移除」的需求。專案就從「加一條註冊路徑」擴大成整體註冊與登入流程的優化。
5 → 1註冊欄位
這個需求來自上層，背後的假設很直接：舊的註冊要填 5 個欄位，改成手機註冊後只剩 1 個，預期能大幅提升轉換率。當時沒有舊流程的流失數據或用戶回饋，所以要等上線後的數據，才能驗證這個假設。
Constraints|
限制條件
硬 deadline
前兩個品牌必須在年度流量最高的檔期前上線。
兼顧既有會員
移除 Email 牽動所有用到 Email 的舊功能，登入頁也不能套用新規則。
規則各自不同
三個品牌、三個市場，加上 Web 和 App 多個平台，同一個欄位的現行行為都不一樣。
沒有 baseline
上線前沒有同樣的追蹤數據，成效只能用前後期與對照品牌比較。
Key decisions|
關鍵決策與取捨
2
「沿用原本規則」不是規格
第一個品牌的驗證規則只寫了「沿用原本規則」，到 QA 和 UAT 才發現幾乎每個欄位在不同市場或平台的行為都不同，QA 無從測起。之後我做了兩個改變：
- mockup 上用「新增」「修改」標註與 production 的差異，讓 QA 知道該測什麼
- 與其他設計師統一驗證時機：錯誤訊息一律 onBlur 才顯示，onChange 只做長度上限的靜默截斷，唯一性檢查留到送出時
取捨：登入頁刻意不套新的註冊規則。登入 API 本來就不驗長度，密碼上限設太緊，舊用戶會永遠登不進來。
3
同一個 tab 元件，兩套切換邏輯
註冊和登入都有「手機／帳號」兩個 tab，但規則刻意不同，因為用戶在這兩頁的目標不一樣。這些切換的邊界情境是在品牌 C 開發時由 PDM 提出，再由我們設計師定案：
註冊
目標是盡快完成，共用欄位（手機、推薦碼）切換時連動、不清空。
登入
兩種方式是不同憑證，各自記住、互不干擾。
這次也一併修正了「記住我」：原本對外說明與實際行為衝突，決議統一記住帳號＋密碼，checkbox 文案也跟著調整，不再用語意模糊的「記住我」。取消勾選時，原本記住的登入資料會立即清除、不需要送出表單，因為這符合用戶預期，也有資安上的考量。
4
登入驗證順序：清楚，但不洩漏資訊
加入手機號碼登入時，後端直接把手機驗證接在原本的登入 API 後面，再請團隊確認。我檢視後提出這套驗證順序和統一的錯誤訊息，讓用戶看得懂，也不讓有心人從中得到資訊：
- 1 格式檢查
- 2 帳號／手機是否存在
- 3 密碼是否正確
- 4 帳號狀態
- 格式錯誤先在前端擋下，不浪費一次 API 呼叫，提示也最精準
- 帳號不存在、帳號或手機號錯、密碼錯，一律顯示「帳號或密碼錯誤」，不讓人從錯誤訊息判斷某個帳號或手機號是否已註冊，避免枚舉攻擊
- 帳號狀態放在最後：帳密都正確之後，才需要處理停用、未驗證等情況
5
帳號找回：卡住時都有下一步，但不洩漏誰註冊過
註冊移除 Email 後，新用戶很可能根本沒有 Email，舊的「收信點連結」找回方式對他們完全走不通。我負責品牌 A 找回流程的設計與上線，三個市場、App 與 Web 同步上線：
- 拉回主站：原本要收信、點連結、在新分頁重設密碼，連結過期就得重來；改成同一頁輸入 OTP，手機和 Email 都能用，全程留在主站
- 不回答「有沒有註冊」：輸入未註冊的手機或 Email，一樣進到 OTP 頁、倒數照跑，只是不會寄出驗證碼，沒辦法用這個入口逐一試探
- 卡住時先給下一條路：手機對應不到唯一帳號時，主按鈕是「改用 Email 找回」；OTP 次數用完就換另一種方式，兩種都用完才擋下，客服是最後一步
- 和鎖帳接起來：登入失敗 5 次的鎖帳 popup 直接帶進找回流程，重設密碼成功即解鎖
6
三個品牌，一路收斂
- 品牌 A｜2025.12 – 2026.04最先上線手機註冊與移除 Email，欄位驗證問題在這一輪浮現。
- 品牌 B｜2026.04 – 06（約 6 週）統一後的欄位驗證規則先在這裡落地。
- 品牌 C｜2026.06 – 09統一後的規則在這一輪全部上線，tab 切換規則也是這時定案，之後再補回品牌 B。品牌特有手機不可重複・兩條錯誤同時顯示深淺色模式
全品牌統一：預設手機 tab、系統自動產生帳密並排除 O／0、I／l／1 等易混淆字元。最後也盤點了品牌 A 尚未跟上的地方，做成對齊狀態表與設計稿。
Collaboration|
跨部門協作：Banner 規格
註冊流程上的 banner 由品牌團隊製作、從後台上架，再由前端顯示。我和前端一起訂定各版位的尺寸與顯示行為，再整理成給品牌設計師的出圖規範，讓素材上架後在每種裝置上都正確顯示。
- 01依版位給固定尺寸：桌機註冊頁、手機註冊頁、註冊成功頁各一種，皆以 2 倍圖交付，並限定 PNG 格式與檔案大小
- 02素材不變形、不裁切，載入時也不造成版面跳動
- 03四周預留邊距，文字與重點只放在安全區內，各裝置都完整可讀
- 04上方 40px 不放複雜圖案，避免擋住 logo 與關閉按鈕
- 05建議用半透明或漸層收邊，讓 banner 融入背景，不用硬切的去背圖
- 06兩張以上自動輪播，重點內容不能被輪播指示點蓋住
- 07Mobile Web 與 App 同時提供深色、淺色兩套素材
- 08後台讀取失敗或未設定時，自動顯示預設 banner，不留空白
Outcome|
成果
+18.6%註冊送出日均（同期對照品牌 +11.8%，扣除大環境約多 6–7 個百分點）
1.36 → 1.11每人平均送出次數（約 −19%，對照品牌反而 +9%）
22–33% → 91%團隊 Sprint 完成率（團隊成果）
改版前 39 天、改版後 37 天，排除事故期間，比較日均。數據限制：指標記錄的是「送出」而非「註冊成功」；對照品牌並非完美對照組。前兩個品牌都在年度流量高峰前上線。
Reflection|
反思
設計交付完整，不代表上線時會同步到位
移除 Email 的周邊畫面都畫好了，卻沒有和主要功能一起上線，第一次發版後 rollback。之後我會逐張確認 AC 和 mockup 一致，並在每次 sprint 開始前的 planning 會議，主動提出功能之間的開發相依性。
「沿用原本規則」只是把問題往後延
寫起來省事，但各市場、各平台的差異最後還是要有人處理，通常就落到 QA 身上。
如果重來一次
畫 mockup 前我一直會先操作 production，但當時看的是流程，沒有逐一比對各市場、各平台的欄位驗證規則。重來一次，我會在專案一開始就把這些規則整理成對照表，再開始設計。
012025.12 – 2026.09
Onboarding redesign across three brands
It looked like just one more way to sign up, but field rules differed across three brands and three markets, and Email had to come off the sign-up form at the same time. Over one year I redesigned sign-up and login for each brand in turn and unified three sets of rules into one. With Email gone, I also rebuilt Brand A’s account recovery.
Background|
The problem
The old sign-up page laid out 5 fields at once: username, password, phone number, Email and a referral code. The referral code was optional, but to a new user it still looked like five fields to fill. The brief was one line: "add phone number sign-up," to give users a faster way in.
Before drawing any mockup I walk through the live product, and that is where most of the old flow's problems surfaced. Sign-up and login shared one page behind tabs, which would get crowded once phone options were added, so I split them into two pages. A request to remove Email from the form landed at the same time, and the project grew from "one more sign-up path" into a redesign of the whole sign-up and login flow.
5 → 1SIGN-UP FIELDS
The request came from leadership, and the hypothesis was simple: the old sign-up had 5 fields, mobile sign-up needs just 1, so conversion should rise sharply. There was no drop-off data or user feedback on the old flow, so only post-launch data could test that hypothesis.
Constraints|
Constraints
A hard deadline
The first two brands had to launch before the busiest traffic period of the year.
Existing members
Removing Email touched every older feature that relied on it, and login could not adopt the new rules.
Inconsistent rules
Across three brands, three markets and both web and app, the same field behaved differently.
No baseline
Without prior tracking, impact could only be read from before/after periods and a control brand.
Key decisions|
Key decisions & trade-offs
1
Removing Email: map every affected screen first
Dropping one field looks trivial, but account info, security level, refer-a-friend, promotion applications and revalidation all depended on Email. I checked, page by page, every place in production that used Email, cross-checked front and back end with engineers, and designed one recovery pattern: if a user without Email opens one of these features, a bottom sheet asks for it and verifies it by OTP.
2
"Keep the existing rules" is not a spec
The first brand's validation said only "keep the existing rules". In QA and UAT we found nearly every field behaved differently by market or platform, and QA had nothing to test against. I changed two things:
- Mockups now mark "new" and "changed" against production, so QA knows what to test
- With the other designers, I aligned validation timing: errors show on blur, typing only enforces a silent length cap, and uniqueness is checked on submit
Trade-off: login deliberately kept the old rules. The login API never checked length, and a tight password cap would have locked existing users out for good.
3
One tab component, two behaviors
Sign-up and login both have Phone / Username tabs, but they deliberately behave differently, because users want different things on these two pages. These edge cases were raised by the PDM during Brand C, and we designers decided the rules:
SIGN-UP
The goal is to finish fast, so shared fields (phone, referral code) carry over when switching tabs.
LOGIN
The two methods are different credentials, so each tab remembers its own and never overwrites the other.
We also fixed "Remember me": public messaging contradicted actual behavior, so it now remembers username and password, and the label moved away from the vague "Remember me". Unchecking it clears the saved credentials immediately, with no need to submit the form, because that is what users expect and it is safer.
4
Login validation order: clear, but revealing nothing
To add phone login, the back end appended phone validation to the existing login API and asked the team to confirm. I reviewed it and proposed this validation order with a single shared error message, so errors are clear to users without giving anything away to people probing for accounts:
- 1 Format
- 2 Account / phone exists
- 3 Password
- 4 Account status
- Format errors are caught on the front end, saving an API call with the most precise hint
- Unknown account, wrong username or phone, wrong password all show "Incorrect account or password", so no one can tell from the error whether an account or number is registered (preventing enumeration attacks)
- Account status comes last: suspended or unverified cases only matter once the credentials are correct
5
Account recovery: a next step at every dead end, without revealing who is registered
With Email gone from sign-up, many new users have no email at all, so the old email-link recovery simply didn’t work for them. I designed and shipped recovery for Brand A, live across three markets on app and web:
- Back on-site: instead of opening an email, clicking a link and resetting in a new tab (and starting over when the link expired), users enter an OTP on the same page, by phone or email
- Never answering “is this registered?”: an unregistered phone or email still reaches the OTP page with the countdown running, but no code is sent, so the entry can’t be used to probe accounts
- A way forward first: when a phone maps to more than one account, the primary button is “Recover with email”; when one OTP channel runs out, users switch to the other, and support is the last resort
- Tied to lockout: the lockout popup after five failed logins leads straight into recovery, and a successful reset unlocks the account
6
Three brands, converging
- Brand A — 2025.12 – 2026.04Shipped phone sign-up and Email removal first; the validation gaps surfaced here.
- Brand B — 2026.04 – 06 (about 6 weeks)The unified validation rules landed here first.
- Brand C — 2026.06 – 09All the unified rules shipped in this round. The tab-switching rules were settled here too, then added back to Brand B.Brand C onlyUnique phone numbers, two errors at onceLight & dark modes
Shared across brands: Phone tab by default, and auto-generated credentials that skip look-alike characters such as O/0 and I/l/1. I also audited where Brand A still lagged and prepared an alignment table and designs.
Collaboration|
Cross-team: banner specs
Banners in the sign-up flow are made by the brand team, uploaded through the CMS and displayed by front-end. With front-end I defined the size and behavior of each slot, then turned it into artwork guidelines for the brand designers, so every banner displays correctly on every device once it goes live.
- 01One fixed size per slot (desktop sign-up, mobile sign-up, success page), delivered at 2x as PNG within a file-size cap
- 02Assets are never stretched or cropped, and loading never shifts the layout
- 03Margins on every side; text and key content stay inside the safe area so every device shows them in full
- 04No busy patterns in the top 40px, so the logo and close button stay visible
- 05Translucent or gradient edges that blend into the background, not hard cut-outs
- 06Two or more banners rotate as a carousel; key content stays clear of the indicator dots
- 07Mobile web and app each get a dark and a light asset
- 08If the CMS fails or nothing is set, a default banner shows. Never a blank slot
Outcome|
Outcome
+18.6%daily sign-up submits (control brand +11.8%, about 6–7 points above the market)
1.36 → 1.11submits per user (about −19%, while the control rose 9%)
22–33% → 91%sprint completion rate (team result)
39 days before vs 37 days after, compared as daily averages, incident period excluded. Limits: the metric counts submits, not successful sign-ups, and the control brand is not a perfect control. Both early brands launched before the yearly traffic peak.
Reflection|
What I learned
Complete designs don't guarantee a complete release
Every screen affected by the Email removal was designed, yet they didn't ship with the main feature, and the first release was rolled back. Since then I check each AC against the mockup and raise feature dependencies at every sprint planning meeting.
"Keep the existing rules" just postpones the problem
It is quick to write, but someone still has to deal with the differences across markets and platforms, and that usually ends up being QA.
If I did it again
I always walked through production before designing, but I was looking at flows, not comparing field validation rules across every market and platform. Next time I would map those rules into a comparison table at the very start, before designing anything.