← UI/UX

NaniClub

建立獨立的會員系統，涵蓋身份權限、驗證及資訊安全設計

從與子公司共用的舊系統獨立出來，重新梳理老師、學生、家長與補教老師的身份權限， 並重新設計註冊登入、教師身份驗證與帳號安全機制。

NaniClub 桌機版首頁與手機版個人資訊：首頁上方為黃色安全提示與藍色權限提示，下方為密碼與帳戶活動紀錄兩張狀態卡；手機版顯示身份資訊與修改、驗證按鈕

團隊資訊

專案期間
2025 / 10 - 2026 / 07
團隊成員
PM*1｜UI/UX*1｜前端*1｜後端*2
擔任角色
UI/UX 設計：舊會員網站研究、網站架構、註冊 / 登入 / 忘記密碼流程、教師身份驗證流程、介面設計與驗收

問題狀況

01

公司長期與子公司共用會員系統，帳號、權限及資安綁在一起。

02

老師、學生、家長及補教老師等身份權限驗證混雜。

03

各產品各自登入，帳號無法互通。

產品目標

01

建立獨立會員系統，帳號與資料自主管理。

02

重新設計角色權限與教師身份驗證流程。

03

各產品統一接入 NaniClub 登入與第三方登入。

前後對比概覽

從共用的舊系統獨立，重新設計會員註冊、身份驗證流程

Before ｜ 共用舊會員系統
OneClub 個人資料修正頁：單一長表單，身份、姓名、身分證字號、性別、生日、電話、地址、服務學校、級任科任等欄位一次全部呈現
  1. 僅有基礎功能修改資料/密碼、忘記密碼
  2. 不合情境的功能使用者可自行修改身份；無法驗證重要資訊，也無從維護帳號安全
  3. UI/UX 問題過長的表單讓使用者感到填寫負擔
After ｜ NaniClub
NaniClub 個人資訊頁：依主題分成身份資訊、聯絡資訊、基本資料三張卡片，每張各自有修改與驗證按鈕，欄位旁顯示已驗證或尚未填寫狀態
  1. 補齊帳號管理功能身份驗證、聯絡資訊驗證、帳號活動紀錄、全裝置登出
  2. 教師身份驗證流程新增教師身份驗證流程，透過系統或人工審核，讓教師取得權限
  3. UI/UX 改善依主題拆成獨立卡片，可局部修改；欄位旁直接顯示驗證狀態
項目 共用舊會員系統 NaniClub
角色權限 身份混雜，權限無法獨立規劃 老師/學生/家長/補教老師四種角色分流
教師身份驗證 無明確流程 內部資料自動比對 + 人工審核雙路徑
跨產品登入 各產品各自登入 統一接入 NaniClub 單一登入
帳號安全 僅基本密碼管理 新增手機/Email 驗證、帳號活動紀錄、全裝置登出、密碼更新提醒

設計核心 01

教師身份驗證流程：自動化與人工介入並行的雙路徑

問題
教師專屬功能需驗證為教師後才可使用，而老師並非數位原生使用者。除了讓系統自動判定是否驗證成功之外，還需要一條人工介入協助的路徑。
系統自動比對
用公司內部資料當自動驗證的依據。老師只要填入負責自己學校的業務手機，比對通過即完成驗證。
人工審核
人工路徑接進公司內部頻道。由相關人員協助審核驗證，有疑慮時直接聯繫。此處的設計對象不只是老師，還包括內部審核人員。

輸入業務手機

業務手機號碼欄位：標示「驗證教師身份」，提供「輸入業務手機」與「無業務手機，將由人工方式驗證教師身份」兩個選項

一開始就把兩條路都攤開欄位下方直接放「無業務手機」的選項，沒有業務手機的老師不必先失敗一次，才知道還有別的做法。

號碼有誤時的提示

錯誤提示視窗「業務手機號碼有誤」：內文寫「請重新輸入，或改選『無業務手機』註冊完成後將由人工方式驗證教師身份」，下方為確認按鈕

錯誤訊息要帶著解法不只說號碼有誤，而是接著寫「請重新輸入，或改選『無業務手機』」——把下一步寫進提示裡，老師不會卡在原地。

設計核心 02

把資安防線藏進節奏與文案

問題
簡訊驗證碼可能被大量觸發，造成成本與困擾；而登入、忘記密碼的錯誤訊息若寫得太「貼心」，等於直接告訴攻擊者哪些帳號真的存在。
機制 A
驗證碼節流：同一號碼 60 秒內不可重複發送、單日上限 5 次。提早提醒使用者，讓使用者有心理預期，不必按下去才知道被擋。
機制 B
錯誤訊息一律中性：登入失敗只顯示「帳號或密碼錯誤」，不寫「查無此帳號」。攻擊者無法從訊息差異逐一測出有效帳號。

機制 A ｜ 驗證碼節流

輸入驗證碼頁面：上方黃色提示「您今日已申請忘記密碼 3 次，若超過 5 次需於 24 小時後再試」，下方說明驗證碼已透過簡訊寄送至遮蔽後的手機號碼

次數用完之前就先說提示直接寫出「今日已申請 3 次，若超過 5 次需於 24 小時後再試」，使用者按下去之前就知道還剩多少額度。

機制 B ｜ 不洩漏帳號是否存在

NaniClub 登入頁：錯誤提示為「帳號或密碼錯誤」，不區分帳號不存在或密碼錯誤；下方提供教育雲端帳號登入、南一帳號登入與行動條碼登入

錯誤訊息只說「帳號或密碼錯誤」不寫「查無此帳號」——帳號不存在與密碼打錯回覆完全一致，攻擊者無法逐一測出哪些帳號真的存在。

設計核心 03

安全性：為「在裝置間移動的老師」設計活動紀錄

問題
老師在教室、辦公室、家裡不同裝置間切換上課，對「我的帳號被誰用過」的焦慮比一般使用者高，卻看不懂技術性的登入紀錄。
判斷
紀錄要能回答焦慮，不只是列出事實。展開後看得到裝置、瀏覽器、IP，以及從哪個南一產品進來——最後這欄讓 SSO 架構對使用者可見。
結果
補救動作用情境語言帶出：不是「撤銷所有工作階段」，而是「遺失裝置？從各裝置登出」。
帳戶活動紀錄 今天，11:06 Mac 登入成功 瀏覽器 Chrome IP 114.36.14.5 登入路徑 NaniPaper 南一雲端出題 來自哪個 南一產品 昨天，14:48 Windows 昨天，14:47 Windows 遺失裝置？ 從各裝置登出 ↑ 用老師會遇到的情境命名，而不是系統術語

把 SSO 架構變成使用者看得見的資訊「登入路徑」讓老師知道自己是從哪個產品進來的——這是跨產品單一登入唯一在介面上留下痕跡的地方。

NEXT

Moodmate 情緒陪伴日記 App →

個人專案 Side Project