Hello

I'm Hungyu Chien

An UI/UX Designer

#具備切版合併GIT協作實務經驗

#擅長設計功能邏輯UI與Prototype建立

#專注易用性與美感平衡的使用者介面

Portfolio  →

About me

我是一位 UI/UX 設計師，專精符合功能邏輯與RWD設計，透過Figma動態原呈現操作流程，提升使用經驗與介面一致性。
熟悉網頁切版，於 C#.NET 環境修改設計，與後端緊密合作。 Angular 框架專案中，配合前端修改 SCSS 進行版面優化。
具 Git 基礎，將修改檔案推送至開發分支，協助團隊順利開發。

CakeResume 與我聯繫
skills experience

Html

使用Html架構網頁雛形。
可直接於調整cshtml， 節省後端比對合併切版損耗時間。

Css

透過SCSS設計UI樣式，制定設計系統使整體風格保持一致。

Javascript

使用初階Javascript調用元素和製作動作效果。

Figma

使用Figma繪製元件、圖形，制定設計系統，Prototype模擬動態流程。

git

透過Git 拉取、合併、推送修改程式碼，與工程師緊密協作，真正參與設計落地過程。

May, 2023 - May, 2025

UI/UX設計

梅科科技股份有限公司

1.

部門主要醫療系統開發之UI、Figma prototype模擬操作流程。

2.

協助總經理承接的外包專案，後台系統UI設計或靜態網頁設計，包含切版。

3.

跨部門合作專案，配合業務與工程師開發後台系統，UI設計與切版。

4.

支援其他部門平面設計與影像剪輯。

May, 2015 - May, 2021

陳列/平面設計

新光三越 台北南西分公司

1.

負責經常性檔期/特賣會/展覽，陳列規劃提案、預算控制、設計發包、現場進撤。

2.

與營業部門合作完成檔期平面/電子刊物，偕同企劃向印刷廠溝通刊物印刷事宜。

3.

主管交辦特殊設計，實際施作或發包。

4.

協助各部門製作專案需求設計物品。

5.

尋常性事務處理:樓面陳列維護、經費申報、協助營業支援...等。

What i do

設計與開發橋接

熟悉基礎版控流程，能與工程師協作於Git環境中，確保設計稿交付精準、版本管理清晰。

策略導向與落地並行

以公司策略與市場方向為出發點，制定兼顧美感與可行性的設計方案。確保每項設計皆能支撐商業目標，並順利落實於開發端。

團隊效率提升

我具備直接在C#.net環境修改調整cshtml與建置CSS的能力，大幅節省後端比對、合併切版程式碼的時間。

latest work

All 專案 北經殘卷
view project

專案/健康運動後台

view project

專案/社會公益平台

view project

專案/醫療整合後台

view project

作品集/北經殘卷

Get In Touch

如您對我有興趣，請透過人力銀行、電子郵件或是社群聊天功能留言給我。

Message / 留言

Instagram Chat
Email / 郵箱

ddnstarAhora@gmail.com
Resume / 履歷連結

CakeResume
因104隱私權限制，此處放置
Cake，兩者皆可與我聯繫。
© 2022-2025 布榖豬/BOKU-PIG.  
More info.

版權聲明

本人簡宏祐(Google Account ID 布穀豬) 以合理之努力載明圖像、影片版權或來源出處。 北經殘卷作品集之網頁設計、影像圖形均為簡宏祐 (Google Account ID 布穀豬) 繪製創作，非AI或任何無機物生成圖像， 版權為本人所有，除法律規定或特別指明外，非經本人書面授權同意，不得以任何方式轉載、 修改、傳輸、再製、散佈、出版或是傳播。 羽衣悔換作品集之設計、影像圖形均為簡宏祐 (Google Account ID 布穀豬) 繪製創作，非AI或任何無機物生成圖像， 版權為本人所有，除法律規定或特別指明外，非經本人書面授權同意，不得以任何方式轉載、 修改、傳輸、再製、散佈、出版或是傳播。 北經殘卷及羽衣悔換中所載之作品，基於職業倫理，模糊處理並化名公司和專案名稱，揭示內容為已修改的虛構資料。如欲瞭解更多，歡迎與我聯繫。

Theme Colors

Project Brief:

簡介

內部開發專案，涵蓋手機APP與後台管理系統。包含會員管理、影音訂閱、部落格文章管理、推播訊息、廣告設定、問卷設計與統計，以及跑步/物理治療課程管理...等。

除了支援前台APP的功能外，同時加入其他營運需求。此專案部分功能是公司「延伸既有系統」搬運而來，因此我主要針對新舊功能的UI做統整，以及部分功能的UX調整，使後台系統操作邏輯與視覺風格保持一致。

我的角色與貢獻

◢

協作流程

  • a.

    在 Git 分支（feat/fourth）上完成設計系統實作，與後端工程師同步開發，處理合併衝突與視覺調整。

  • b.

    調整Razor view 模板結構，討論需要重新串接的細項，確保UI與後端整合順暢

◢

設計系統建立

  • a.

    使用 Figma 規劃色彩基調，定義字體、按鈕。

  • b.

    創建表單、元件（Component）CSS 規則。

◢

UI/UX 實作

  • a.

    MVC 架構下，建立設計系統與各頁面CSS。

  • b.

    直接修改cshtml class 與 HTML tag，調整部分結構，將設計系統應用到各功能頁面。

  • c.

    調整排版、布局與互動細節，確保跨模組一致性與良好使用體驗。

  • d.

    重新調整工程師使用的第三方套件樣式，使其符合設計系統，確保後台整體視覺與操作一致。

基於職業倫理，模糊處理並化名公司和專案名稱，揭示內容為已修改的虛構資料。如欲瞭解更多，歡迎透過人力網站與我聯繫。

Project info

  • 時間 -

    2025

  • 類型 -

    內部開發專案

  • 成員 -

    UI/UX設計師x1 全端工程師x2

Project Brief:

簡介

涵蓋前端頁面與後台管理系統。主要功能為購物車、商品上下架管理、會員系統、部落格、投稿與票選活動、學術性社會影響力數值公式建立與圖表呈現。

設計稿由客戶方平面設計師製作提供。

我的角色與貢獻

◢

UI邏輯重建

  • a.

    與客戶溝通使用情境與問題定義，重新規劃使用流程與 UI 版型。

  • b.

    CSS建立設計系統與元件庫，統整視覺風格。

  • c.

    不依賴視覺設計稿，依現有資源靈活調整配合開發，直接進行切版。

◢

GIT協作

  • a.

    透過GIT與工程師協作，推送前端版型供後端開發串接。

  • b.

    後期於.cshtml 結構微調、第三方功能套件樣式調整。

◢

UI/UX 實作

  • a.

    MVC 架構下，建立設計系統與各頁面CSS。

  • b.

    直接修改cshtml class 與 HTML tag，調整部分結構，將設計系統應用到各功能頁面。

  • c.

    調整排版、布局與互動細節，確保跨模組一致性與良好使用體驗。

  • d.

    重新調整工程師使用的第三方套件樣式，使其符合設計系統，確保後台整體視覺與操作一致。

基於職業倫理，模糊處理並化名公司和專案名稱，揭示內容為已修改的虛構資料。如欲瞭解更多，歡迎透過人力網站與我聯繫。

Project info

  • 時間 -

    2024~2025

  • 類型 -

    外包專案/老闆朋友

  • 成員 -

    UI/UX設計師x1 全端工程師x2 隱藏PMx1

Project Brief:

簡介

公司內部開發專案，商業行為結合醫療控管的整合型後台系統。客群目標為公司內部營運、醫療、醫美產業，物理治療及健身教室。

功能涵蓋門店權限、療程控管、產品售賣、營收數據、帳務管理、會員、資產、行銷...等。

我的角色與貢獻

◢

UI設計

  • a.

    與PM、前端工程師、後端工程師溝通功能，確認畫面操作。

  • b.

    設計具操作邏輯的UI，並保持整體視覺風格一致。

◢

GIT協作

  • a.

    透過GIT與前端工程師協作，推送CSS檔案，使頁面視覺與設計稿一致。

基於職業倫理，模糊處理並化名公司和專案名稱，揭示內容為已修改的虛構資料。如欲瞭解更多，歡迎透過人力網站與我聯繫。

Project info

  • 時間 -

    2024~2025

  • 類型 -

    內部專案

  • 成員 -

    UI/UX設計師x1 UI/UX設計師x2 全端工程師x3 PMx1

Project Brief:

< / >

至今為止，包含放入作品集中的練習作品，都是為了北經殘卷的誕生而存在。這是我的第一個完全創作網頁，所有網頁語言為我的繪圖創作服務。
為了不向技術妥協，我跟著Youtube影片練習許多不同的小計畫，透過網路資源解決困難。或許在語言的使用上仍不夠成熟完美，但是靠自己尋找解決方法完成作品，是我在製作此作品集中，獲得最寶貴的經驗。

Figma

技術層面 / 以熟悉Figma繪圖為主要訴求，以鋼筆工具一點一滴的繪製我腦海裡的畫面。大量的圖檔造成網頁肥胖，在學習到簡易控制<svg>之後，將部分圖檔換置取代。
設計概念 / 以大荒北經為名，章尾山燭龍為主軸，佐以極光學說、長夜星河為景，描繪出壯麗雄偉的史詩神話。

Project info

  • Date - 2022~2025
  • Tools - figma,html, css, javascript
web

展開專案簡介

Healthy Aerobic Exercise Management System

健康有氧運動APP
後台管理系統

此專案作品集主要說明我如何與後端工程師協作，解決既有系統的 UI 邏輯問題，工程師搬運功能導致畫面排版混亂，重新整理與比對介面，建立一致且清晰的使用體驗。

配合專案需要
滾動調整自己的角色

由於公司的決策限制，此專案時程僅有35天，同時有其他專案必須進行。在與後端工程師討論後，我調整自己的角色與工作流程。跳脫制式的設計流程，直接進入MVC 架構，與工程師同步開發，大幅縮短傳統切版檔案交付、節省反覆比對的時間消耗，使專案如期完成。

此專案作品集主要說明我如何在有限資源下，與後端工程師協作，解決既有系統的 UI 邏輯問題，並在功能搬運導致畫面排版混亂時，重新整理與比對介面，建立一致且清晰的使用體驗。

  • 1.

    跳脫制式設計流程，透過Git 與後端工程師同步開發。

  • 2.

    既有系統的UI邏輯問題，工程師搬運功能後排版紊亂，一併統整與優化展示。

Section 1

跳脫制式開發流程
屬於我自己分支

在 Git 中，我建立了本地分支 feat/fourth，完成檔案修改後，推送至遠端 develop。工程師git pull之後，可以透過畫面，直觀的了解那些功能需要修改，大幅省去反覆比對、合併程式碼的時間耗損。

以下使用Popup window 顯示資料為範例，說明Component 套用與協作流程。

Component Library

在wwwroot內直接建立元件庫，制式化各種元件的基礎樣式。特殊細節或不同需求在各頁scss中另外編寫。

此處以Popup為例，建立Popup window 基礎視覺風格與完整RWD。下面透過影片展示，說明Component 套用與協作流程。

搬運後的UI問題

工程師搬運其他系統Popup window ，出現視覺風格不統一與圖文排版問題。Popup window的關閉按鈕在原系統中，也有畫面尺寸改變導致按鈕超出螢幕畫面，無法關閉視窗的情況。

上圖

內容的布局樣式，寫在廣告管理頁的SCSS中，檔案命名與Razor View相同，各頁面引用同名的CSS，方便後續的維護。如果工程師有臨時需要，也可快速縮小範圍查找，避免大海撈針。

影片

接修改結構，套用class，因工程師將Popup 內容另外做成 PartialView，而主標題與關閉按鈕等共用功能在主頁面裡，所以將部分Code 移到主功能頁cshtml 內。

  • 在MVC架構中，有許多PartialView，需要在不同檔案之間調整<tag>與架構，以確保Class 套用正確。

透過Git 與工程師合作

因其他修改混在同一次提交，而當天正好要進行測試機與正式機同步，工程師會來不及修正Popup window 關閉功能。因此我使用 cherry-pick 將廣告管理 Popup window 的提交單獨挑出，推送到遠端 develop；其餘修改則保留在遠端 feat/fourth，供工程師後續串接。

  • 推送完成後，知會工程師確認需要重新串接或修正功能。 工程師git pull之後，可以透過畫面直觀了解損壞的功能進行修正，或是透過Git快速比對，不需要反覆擷取、合併切版程式碼。

確認測試機與本地一致

在工程師更新至測試機後，確認操作流程與UI視覺細節，確保沒有遺漏或錯誤。

  • ◆

    相較於只有製作、交付設計稿和切版，我真正參與設計落地的過程，實際的解決問題。

  • ◆

    透過Git與工程師協作，為團隊效率大幅提升。

Section 2

調整布局RWD
基礎功能邏輯統一

解決既有系統的UI擠壓問題，拓展新的Sidebar階層。 邏輯性歸納篩選功能，制定規則，標準化功能性設計視覺。

問題(上圖)

在既有的後台中，Sidebar與右側主區塊相互擠壓，導致Table 變形。Sidebar標題文字換行後，被容器壓迫，難以閱讀。

解決(影片)

人類肉眼與大腦，不可能一次接收畫面上的全部訊息，因此使用水平Scrollbar，優先顯示重要資訊，次要訊息或操作按鈕放置於右側，於滾動卷軸後顯示。 Sidebar 為導航功能按鈕，文字需清晰方便閱讀為優先考量。因此固定Sidebar寬度，給予充裕空間。使用階層化的方式，展開各功能標題下的功能按鈕，以可拓展第三階層方式設計，以利後續平台的擴充。

配合RWD設定Breakpoint :
991px →Sidebar position: fixed;
767px →table 改為卡片型態

  • 在MVC架構中，有許多PartialView，需要在不同檔案之間調整<tag>與架構，以確保Class 套用正確。

問題(上圖)

篩選條件歸納邏輯不同，部分頁面集中、部分被散落在外。

解決(影片)

我設計了將篩選條件統一收納進『篩選側欄』方案，觸發按鈕則固定放在 _Layout.cshtml 的<header>。由於不確定單一按鈕是否能對應不同頁面的篩選邏輯，我先準備了兩個方案與工程師討論：

  • a.

    使用單一按鈕，依頁面內容切換不同的篩選側欄

  • b.

    每一頁各自放置一個篩選按鈕與對應的側欄

最後討論決定採用 a，但實作邏輯是共用同一個篩選側欄，由各頁的 View 提供自己的篩選條件。

Section 3

第三方套件樣式修改
視覺風格標準化

規則化統整<select>與第三方套件樣式。

問題(上圖)

在原系統中，<select>未統一樣式。

解決(影片)

<select>元件受系統影響，難以客製化，我與工程師討論後決定進行大規模改造。奠基於團隊已建立良好的 Git 協作流程，我可以安全地在 cshtml 中進行結構修改並套用 CSS component，工程師則在此基礎上負責資料串接與 JS 實作。

  • 基於團隊的信任與分工，讓我們能順利完成一般工程師不太願意嘗試的改動。

問題(上圖)

第三方套件樣式沒有與設計系統相符，導致許多常見功能的視覺風格跳脫。

解決

時間成本有限，由我直接創建CSS 覆蓋套件樣式，透過設計系統規則化第三方套件，使後台UI 整體視覺風格一致。

  • 基於團隊的信任與分工，讓我們能順利完成一般工程師不太願意嘗試的改動。

Section X

專案尾聲與心得

有鑑於先前專案合作經驗累積，我和工程師在 Git 協作上越來越有默契，直接修改 cshtml 與 CSS ，大量節省後端工程師反覆對照設計稿的時間與精力。他們也因此樂於把前端畫面交給我處理，甚至願意和我一起挑戰一些 UI 實驗，例如重新設計串接 select、套件修改 ，使我能實現UI 的100% 統一。


我在專案中，視資源條件調整自己的角色，跳脫單純設計的限制，得以參與設計落地的過程。也因為團隊的支持，學到許多設計之外的技能。未來，我希望繼續帶著這份互助與信任的精神，與更多團隊一起創造更好的產品。

-- Thank you --

A co-creation platform supporting marginalized communities

回饋社會弱勢
公益平台

此專案作品集主要呈現我如何在有限資源下，了解客戶需求、幫助客戶重建設計系統與介面。以及調整自己在專案中的角色，透過Git與工程師協作、溝通，在時限內完成專案。

客戶混淆的
痛點問題核心

在手機使用成為主流的時代，觸控滑動螢幕，完成行為目的，相當便利且體驗良好。但是，當人們成為這些便利性背後的開發者時，卻不願意正確理解其本質與歷史脈絡:

客戶提供的設計稿為平面設計師製作，規劃書為普通業務建立，不具備開發經驗與專業，導致無法被操作的 "網頁平面設計" 反覆出現。

  • 協助客戶釐清功能需求、建立操作流程成為重中之重。

無法被使用的設計
推播訊息功能

推播功能為常見且基礎的功能，在商用平台中，扮演重要角色。使用者感受到的簡單便利，其背後有著嚴謹邏輯與複雜流程設定支撐。

上圖

透過上圖可清楚得知客戶提供的前台設計稿操作邏輯缺失 ，並且無法了解接收對象與任務目標。與客戶溝通過程中反覆出現疑問迴圈:

  • " iPhone 明明就是這樣啊! 為什麼不可以操作? "

手機便利操作習慣，使客戶混淆了手持式裝置與電腦端的介面操作行為，以及應用程式與響應是網頁的差異。導致客戶將訊息懸浮冒泡，直接設計於響應式網頁。解決問題前，必須先向客戶說明:

  • 專案為響應式(RWD)網頁，非手機應用程式(APP)，兩者有本質上的不同，操作者透過瀏覽器進入網頁才能獲得訊息。同時，UI操作必須平衡手持裝置與電腦端用戶的使用情況。

透過溝通了解使用情境
建立解決方案

  • 功能依需求而生，是所有開發的核心。

  • 我需要了解客戶的使用情境: 有哪些訊息內容，需要發給誰，訊息的推送次數與時間。

我請客戶依據前台功能，以及他們預期會使用到的訊息內容，統整成文字檔案提供。我將文字訊息大致分類如下:

上圖

整理歸納出分類與規則後，為了設定時間的可行性，因此我將預想的方案雛形與工程師討論。

  • 與工程師討論，同時也能進一步驗證自己的思維邏輯。

上圖

與工程師討論後，我將內容化為功能邏輯圖如上。各階段(圖形符號)之間屬於相乘，用來完成一項訊息的發送任務，做為 UI 介面配置與開發串接的重要依據。

  • 例如: 購物訂單通知 「您的訂單編號: AERD 445389 已成立, 我們將於確認訂單後，盡快為您出貨。詳情可於 會員中心 > 訂單 查詢。」

  • 依上圖流程設定為 -- 系統訊息 > 單次發送 > 立即發送 > 選擇會員類別(全部類別)」

邏輯架構圖含類型、模式、時機、對象四層。我主要提出訊息類型、發送時間設定及選擇會員ID等功能邏輯，經討論後，工程師認為將時間設定拆成發送方式與發送時機，加入排程設定、會員類別，可以使功能更完善。

  • ●

    訊息類型:

    將訊息內容依不同來源或形式進行分類。

    系統訊息 -

    用戶行為觸發後，統一傳送的訊息內容。

    模板訊息 -

    常用的制式功能訊息，可帶入參數以改動部分目標內容。

    自由編輯訊息 -

    依據管理者需要，發送自編內容給用戶。

  • ▲

    每一頁各自放置一個篩選按鈕與對應的側欄

    重複輪播 -

    固定一個日期區段，區段內每到特定時間點，系統自動進行發送。

    單次發送 -

    訊息只發送一次，如要再發送需手動發送。

  • ■

    發送時機:

    為了系統的使用彈性提升，加入時間選擇器與排程系 統，使訊息可以在設定時間之後，依照排程送出。(感恩工程師，讚嘆工程 師)

    定時發送 -

    設定時間後，於指定時間發送。

    立即發送 -

    訊息內容編輯完成後，直接進行發送。

  • ★

    對象選擇:

    由於會員有四種類，因此將目標選擇方式區分。

    選擇會員ID -

    可直接選擇單一或多個會員，進行指定發送對象。

    選擇會員類別 -

    針對某單一類別或負數類別下的全部會員進行發送。

先等等
我們先看看後台

功能之間的各流程環環相扣，前台和後台必須同步梳理操作邏輯。

上圖

客戶提供的後台設計稿(上圖)無法完整支撐訊息功能任務，並且缺少發送歷史這項重要功能。 我將功能邏輯圖與客戶溝通，並以客戶提供的訊息內容做文字操作流程示範。

  • 依功能邏輯圖示範設定流程:

  • 聖誕活動訊息 -- 自由編輯訊息 > 重複發送 > 設定時間 > 選擇會員類別(全部類別)

在溝通過程中，我了解到客戶因現實面需求，流程在可再被簡化。為了操作更加簡單，我將訊息功能入口拆分成兩大類，重複的子功能分開放入其下。

由於客戶在可編輯訊息功能，只需要單次發送，因此自由編輯訊息只需要設定單一時間。在與工程師討論後，系統訊息與模板訊息直接由工程師寫入資料庫，設定觸發方式，滿足客戶節省設定制式訊息的時間。

  • 與工程師反覆討論需求功能和操作流程，

  • 確立解決方案，再與客戶討論。

我們以此方案 (同時有前台) 向客戶進行溝通，經確認後進入開發，頁面設計由我依照設計系統切版。

進入開發
透過git 即時切版協作

在有限資源下，調整自己的角色，跳脫設計師的框架，協助工程師節省時間。

上圖

由於時間有限，不允許我先進行設計UI、設定prototype 的正常流程。經過內部討論，確認需要的功能元件以及需引用的外部套件，開發流程調整為--

  • 直接切版推上開發分支，由工程師建立View，引用外部套件功能完成。

  • 我於本地環境運行並修改 CSS，將 Select2 樣式客製化為符合系統設計風格。

回到原本問題
建立功能到流程優化

在最開始的問題中，客戶誤解操作模式，提供了無法被操作的設計稿。響應式網頁的操作，需要顧及電腦與手持裝置的使用方式。

我先透過蒐集客戶的所有訊息內容，並且完成後台的訊息推播功能。如此可以掌握前台會員中心出現的訊息內容、類型、目的，從而制定前台畫面的呈現方式與功能。

上圖

依據客戶提供的訊息內容，我將前台會員會收到的訊息分類，透過Tab切換種類。以每頁10則訊息為限，下放設計頁碼。每則訊息可展開收合，過時訊息也可由會員自行刪除。

直觀的基礎操作流程，透過與工程師討論，確認此方案先進行開發，待完成後，與後台一起給客戶確認。

接近收尾的錯誤
損耗開發成本

  • 由於專案快進入尾聲，全站功能接近完整，我沒有將訊息中心的前台操作流程提供客戶進行溝通，使團隊損耗開發時間成本。

上圖

在上圖的操作中，前台畫面已具備完整的展開收合、切換、刪除、換頁等基本功能。客戶反饋需求為"希望所有訊息內容不要隱藏，要完整露出內容"。

  • [錯誤核心]

  • 開發前未清楚與客戶溝通，確認需求。
    如果需求是一台體重計，不要做體脂計。

完成後的比對
前台

完成後的比對
後台

完成專案
與心得總結

在此專案中，平面設計師製作的設計稿問題，使我深刻體會到設計稿是否符合功能邏輯與功能開發需要反覆溝通、需求釐清的重要性。主動協助客戶釐清概念混淆與操作誤解 ，確保能正確掌握功能需求的核心目標，並補足設計稿與規劃文件中未呈現的操作邏輯。

作為部門中唯一的 UI/UX 設計師，我全程掌握專案視覺統整，與操作體驗的品質，不僅將設計轉換為符合響應式規範的網頁介面，避免客戶持續在不同頁面出現超出視覺規範的設計風格。同步與工程師持續討論功能與介面整合的可行性，確保在既有資源與時限內達到最佳使用體驗。

由於協助客戶了解每一個功能與畫面操作邏輯與了解需求，耗費大量時間，指數縮減的時程，使我調整自己的角色與作業模式。我直接在 MVC 架構下，進行切版與後續 CSS 調整。(非常感謝工程師願意讓我進入專案架構直接修改 cshtml 與 CSS) 這種開放式協作方式，讓我們能透過 Git 即時同步版本，後端邏輯可無縫串接，免除反覆傳遞與比對靜態頁面的低效流程，顯著提升交付速度與一致性。這不僅讓我熟悉 Git 的版本控制，深化了與工程師之間的默契與互信，也使我增加設計落地與操作流程驗證的經驗。

-- Thank you --

Integrated Healthcare Business Management System

具備商業行為的
整合醫療系統

此專案展示我如何將原本複雜、缺乏操作邏輯的介面重新整理，並以步驟引導與易上手為核心重新設計。以尼爾森十大易用性原則為基礎"一致性原則" 與 "辨識優於回憶"，讓操作模式統一且更貼近使用者心智模型。透過 Figma 模擬，呈現更直覺、降低學習成本、減少記憶負擔的使用體驗。

優化說明

在此專案中，我主要負責使用者體驗與介面設計的優化。由於專案決策限制，導致系統出現邏輯不連貫、操作流程不一致，讓使用者難以學習並養成習慣。此外，介面缺乏統一的設計原則、無法RWD，大幅降低易用性與使用者體驗。

我的作品集專注於解決這些痛點，透過尼爾森十大易用性原則，系統化的梳理與歸納，重新優化使用者體驗。以「一致性、易用性、低學習成本與降低記憶負擔」為核心，整體優化主要分成兩個章節:

  • 1.

    拆分重組基礎操作區塊的布局與流程，使用者可以快速上手，並依照操作經驗更直覺的尋找所需功能。

  • 2.

    以"產品設定"功能為例，回到功能原點，重新設計操作步驟，建立秩序、有邏輯的UI引導，優化後的介面讓使用者易於理解每一步驟的意義，正確完成目標，不需要再付出學習成本。

Section 1

系統化 UI 布局
實現RWD

因團隊決策，在原UI設計中，相同的基礎功能功能在各頁面被放在不同的位置，導致操作方式不同。不符邏輯的UI也無法RWD，使用者體驗與易用性大幅下降。 下列依序展示問題清單，可透過連結快速到達說明區塊，優化結果以Figma prototype模擬展示。

  • 有問題的使用者介面:

  • → 篩選條件未統一

  • → 選單佔用畫面

  • → 子功能雜亂無章

  • 強制攤平的功能UI:

  • → UI 無法 RWD

  • RWD優化說明:

  • → Figma模擬

1.1

有問題的
使用者介面

"第一眼就必需看到全部功能和資料" 為此系統開發的巨大難關。

篩選功能問題(上圖)

透過上圖呈現可得知，非邏輯性的需求造成篩選功能在不同功能頁面中，出現A、B、C三種不同的設計型態，使用者無法套用相同的經驗進行操作行為，上手難度提升。

解決(影片)

將散亂的篩選統整到右側，依序排列。給予完整的功能按鈕，操作簡易明瞭。 讓使用者更快養成固定行為模式，學習成本低，快速上手!
影片經壓縮較模糊，下方提供Figma prototype連結，歡迎點擊進入。

1920px 390px

選單問題(上圖)

透過上圖呈現可得知，主功能分類下的子功能沒有經過邏輯整理在同一區，導致a、b、c三種不同的情況出現。使用者無法透過主功能列快速找到子功能入口，解決問題的難度上升。

  • a.

    點擊 Sidebar主功能 > 無其他選單 > 進入主功能頁面。

  • b.

    點擊 Sidebar主功能 > 有子功能 > 進入第一個頁面，選單隱藏 > 展開後選擇其他選單功能。

  • c.

    點擊 Sidebar主功能 > 有子功能 > 進入第一個頁面，選單直接放在右側。

解決(影片)

選單內的選項，實際上就是主功能下的系列功能或子功能，應統整歸納進入左側Sidebar，將導航功能回歸到Sidebar主體。
影片經壓縮較模糊，下方提供Figma prototype連結，歡迎點擊進入。

1920px 390px

還有各項子功能(上圖)

除了篩選和選單，頁面中的操作流程介面，為了全部攤平在同一層，沒有一個標準規則定義功能權重，排序優先使用右側版面。

  • 多重操作的畫面，更應好好梳理每一個功能流程，定義功能權重，規劃秩序統一的操作介面，建立易上手的操作循環。 解決方案於Section 2，以產品設定作為解說案例。

1.2

頁面被強制攤平
無法進行響應式設計

"便利性" 導致過多跳轉功能與附加訊息，再加上 "第一眼就可以看到全部功能"為重要先決條件，所有東西都不可隱藏。導致UI無法無法進行響應式設計，使用環境被限制，易用性大幅下降。

RWD 問題1

在"便利性"與"第一眼就可以看到全部功能"這兩項決策中，header放置過多常用功能。在裝置寬度改變後，仍堅持此需求，導致按鈕被擠壓難點擊，角色身分 icon甚至被擠出畫面之外。

  • 人類無法一次性接收全部視覺訊息，應收斂不必要的"便利性"入口連結，透過有邏輯的規劃，階層化功能顯示。

RWD 問題2

導航欄與選單未統整，與"便利性"、"第一眼就可以看到全部功能"的重要前提，導致畫面被功能多占用空間，導致主區塊的展示空間被壓縮。

  • 人類無法一次性接收全部視覺訊息，應收斂不必要的"便利性"入口連結，透過有邏輯的規劃，階層化功能顯示。

RWD 問題3

沒有統整的篩選，不可隱藏也不可改為直向排列的篩選，被擠壓後無法操作。 (直向排列會使資料table空間大幅減少，故不可修改排列，成為取消RWD計畫的主因之一)

  • 操作者使用的螢幕解析度和尺寸比例各不相同，不可能所有功能與資訊全部攤平在同一層。

  • 不合理需求應被收斂，使 UI 易於操作。

1.3

RWD優化展示

在功能龐大複雜的後台系統中，一致性的設計準則與操作行為必須被重點強調，建立規則制定統一操作流程，讓使用者可以快養成固定行為模式，快速上手!

篩選介面RWD

大型解析度裝置(min-width: 1367px;)，篩選與主內容可同步展現，做為比對。

中小型析度裝置(max-width: 1366px;)，將篩選隱藏，透過icon按鈕觸發，觸發方式與大型解析度裝相同，操作流程統一又簡單，可使操作者快速上手。

導航選單RWD

統整導航與選單，將頁面導向功能回歸Sidebar。如果主功能下只有一個子功能，仍然遵循規則，設定一個子功能標題，以利未來主功能擴展新子功能。

設定Breakpoint 991pxw以下時，改變Sidebar型態與整體布局，不擠壓主內容區。

Section 2

操作流程優化
回歸主功能子頁

在Section 1 中，子功能散亂的RWD問題懸而未解。在此以產品設定作為範例，將操作流程回歸主功能頁面，優化操作流程，同時解決UI RWD。

  • 產品設定UI 問題

  • → 操作介面難上手

  • → 訊息混亂

  • 先等等，回到目標原點

  • → 重新理解需求，梳理流程

  • 優化解說與prototype展示

  • → Figma模擬

2.1

產品設定為例
使用者介面問題

新增/編輯功能

產品設定功能主要用來定義分類，並在各分類下建立產品。原分類共有三階級: 第一級-大分類、第二級-中分類、第三級-分類，產品可隨意建立在任一階級下方。

以及為"便利性"與"一目了然"的需求，直接將階級分類與產品名稱以束狀階層展示於右側可點擊選則，配合功能icon按鈕點擊後跳出popup window 操作。

這種方式不僅使畫面資訊過多、使用困難，也造成某些情況下，後續有新分類或新產品時，資料難以被擴展。

  • ●

    訊息模糊

    a.

    Table沒有出現大分類、中分類、小分類的標題

    b.

    操作右側欄位時，並無法準確得知正在操作哪一個階層。

    c.

    無法在Table內得知產品被歸屬在哪一個階層裡。

  • ▲

    階級混亂:

    a.

    商品可直接分配在大分類與中分類下，而非最小分類下的產品內容

    b.

    商品容許被分配在各類階級非常彈性，但是資料上的查詢邏輯會變得複雜。

    c.

    使用者在設定產品歸屬時也容易在分類階層上出現混亂。

    d.

    當新的產品使新的分類階級出現時，無法將不同階級的同類產品在一起，必續全部刪除重新建立。

  • ■

    難以操作

    a.

    畫面訊息與功能過多，導致操作者無法聚焦重點。

    b.

    新增編輯功能被限制在畫面小範圍，在手持裝置中難以操作。

    c.

    沒有引導操作流程，上手難度增加。

    d.

    當分類下的項目越來越多，使用者很難快速找到目標。

  • ●

    Table標題文字與內容拆分，正確顯示分類階級。

  • ▲

    正確梳理分類階層與產品關係，將產品統一歸屬到最小級別。暫無分類或未確定的，歸屬為"其他"。

  • ■

    透過"隱藏" 漸進式引導使用者操作，聚焦目標，也確保不遺漏任一步驟。

RWD 問題(上圖)

為了便利性，建立詳細資料設定功能被放置在Popup window，畫面與操作行為受到限制。無邏輯順序的排列與不合理需求導致無法RWD。

Popup window在視覺與操作上也是另外"開啟頁面"，與子分頁的行為模式相同，都必須經過 "點擊 > 開啟/進入頁面 > 進行設定 > 儲存/關閉"。實際上沒有減少使用者的操作步驟，反而限制畫面可用空間。

  • 複雜的畫面，應定義權重順序，梳理排列邏輯，規劃秩序統一的操作。

2.2

優化前先等等
我們先回到原點

每一個功能的開發，時常在討論時偏離主題，尤其是為了"便利性附加功能"。回到"目標原點" 思考，以樹狀圖梳理階層關係，透過Flow chart 正確定義操作流程，是設計畫面前，非常重要不可以被省略的步驟。越多流程的功能，越需要花時間梳理，才能進一步設計出符合邏輯的UI 。

為減少內容長度，流程示範減去"小分類"。
下面以服務產品為解說範例:

解決階級混亂(上圖)

透過樹狀圖梳理階級關係，定義規則標準。

在四個主要類型之下，透過旗下商品類型劃分出大分類、中分類，產品內容固定在最小級別。

例:
大分類 > 中分類 > 服務內容
徒手 > 物理治療師 > 肩頸矯正
運動 > 有氧運動 > 慢跑30分

解決操作問題

透過Flow chart 將流程中的事件與步驟統整，排除不必要的支線任務，瞄準核心目標。拆分A、B流程:

  • A流程- 專注於大分類、中分類、產品內容的編輯/刪除功能。
    B流程- 產品內容的詳細資料處理。

  • 當目標完成後，不增加任何不必要的便利功能。

B流程(上圖)

B 流程僅設定產品內容，分為基礎設定與進階設定，基礎設定為全部必填；進階設定全部為選填，進階設定不需要檢查。

2.3

RWD介面優化

解決子功能散亂的RWD問題，將操作流程回歸頁面主功能區域，取代彈窗模式與側邊工作欄。

管理列表RWD (上圖)

Table設定在 media-width: 768 px 改變展示狀態，方便閱讀與操作。

子功能頁面RWD(上圖)

將散亂在右側的子功能統一回歸主區域，以產品新增編輯為例，版面以操作流程規劃排列。

769pxw以上，將column 改為3。
768pxw以下，將column 改為2。
640pxw以下，將column 改為1。

透過閱讀順序配合隱藏顯示，階段性引導操作者進行設定，實際操作請見prototype影片展示。

其他功能移出Popup window(上圖)

許多設定與資料編輯功能被困在Popup window，導致RWD後無法操作。

  • 統一回歸移回頁面主區域，或獨立的子分頁流程，取代彈窗模式。透過 邏輯梳理 建立流程關聯，協助使用者順利達成功能目標。

Section 3

Prototype 設計原型
操作影片展示

醫療後台系統的主要使用者是繁忙的醫護人員，他們需要的是 操作簡單、學習成本低且防範出錯的流程。因此，我採用漸進式揭露的設計方式，逐步引導使用者完成操作，確保不遺漏任何步驟。

每個任務流程獨立、簡化，並維持 穩定一致的操作模式，不僅降低使用難度，也有助於未來功能的擴充與平台的營運維護。

  • 醫護人員需求
    → 簡單易用、低學習成本、降低出錯率

  • 設計方式
    → 採用漸進式揭露，逐步引導操作

  • 任務流程
    → 獨立、標準化，維持穩定一致的操作模式

  • 效益
    → 降低使用難度，並利於 未來功能擴充與平台營運維護

介面與操作流程優化(上圖)

在原系統的設計中，為了一次完整顯示所有功能與資料訊息，右側功能欄內的分類會因醫療服務與藥品項目越來越多，造成醫護人員非常難尋找自己的目標。

因此，我加入搜尋以及自動比對功能，結合Section 2 的優化方式，修改產品設定主分類、次分類、服務內容的新增、修改、刪除流程。

同時加上完整RWD，支援手持式裝置操作。

影片展示: 產品設定> 修改次分類

影片經壓縮模糊， Figma Prototype 有完整服務次分類的流程展示(修改、刪除、新增)，請由下方連結進入。

1920px 390px

介面與操作流程優化(上圖)

影片展示: 產品設定> 新增服務內容> 編輯服務內容資料
影片經壓縮較模糊，下方提供Figma prototype連結，歡迎點擊進入。

1920px 390px

專案心得

此專案中，我學到的最大挑戰是設計師在他人強主導決策環境與有限時間下如何配合團隊協作，以及UI設計的邏輯問題與落地實現。如果若有更多主導空間並且時間成本允許，我會在前端工程師重構時，以用戶易上手操作與標準化流程為原則，改善目前規則邏輯不統一的畫面與操作流程。並透過醫護人員的問卷結果，為產品功能做出優化迭代。

在與團隊合作上，透過前端工程師使用的Angular 框架，我學習到如何以套件為基礎，統一修改視覺顏色、微調部分元件，加速設計稿的完成，確保專案進度符合公司時程規劃。同時，我也學習透過GIT與功程師協作，拉取、推送修改的SCSS，確保頁面視覺與設計稿保持一致。

由於篇幅有限，GIT 在其他專案作品集中，進一步說明。

-- Thank you --

作品集計畫
從蒐集資料開始

好的作品集模板，都能具體且清楚的介紹自己並呈現作品，及最重要的聯絡方式。

網路上有很多模板，像是Bootstrap直接套用、也有webflow這類不需寫程式的網站提供服務。

Figma社群也許多的模板分享，直接在軟體內製作作品集與流程模擬，不做成完整網頁的形式呈現。

使用模版若不吸收深化，加以設計成獨具風格的設計，就流於形式、空洞而沒有靈魂。

我發現簡易的排版方式，具體清楚的簡介自己並呈現作品，是傑出範例的共同點。

Figma社群也許多的模板分享，直接在軟體內製作作品集與流程模擬，不做成完整網頁的形式呈現。

我發現簡易的排版方式，具體清楚的簡介自己並呈現作品，是傑出範例的共同點。

自己的作品集
自己做做自己

我想跳脫流於形式的作品集與西方風格框架。

我很喜歡古代神話元素，在思考視覺風格時，最先想到的是山海經裡的燭龍。

現代科學研究山海經，燭龍被認為是北歐極光的神化現象，因此我將極光轉化與星河長夜作為視覺風格。

雲海、山跡是古代墨畫中不可或缺的部分，我用自己視覺風格，以夜幕成色、霞光捻絲織就。

網路上有許多山海神獸圖，如同作品集模板，它們都不是我。因此我重新繪製。(圖像來自《觀山海》與網路資源。)

作品呈現方式跳脫流於形式空洞的整齊排列，以卷軸滑動設計，以金線菱梭赤絨、檀木為骨，與星夜相襯。

標題以墨漬暈染，朱砂點綴，文字同古文縱向右書，使視覺風格一致。

技能說明以三足金烏、廣寒玉蟾融匯於紫微星陣，將技能名繪成星符。(星圖詳見下方說明)

設計淵源至此渠成，星河長夜為基、雲海山相為輔、神獸綴飾章節、卷軸入制。燭龍載於大荒北經，故作品集以北經為名，是謂- 北經殘卷。

現代科學研究山海經，燭龍被認為是北歐極光的神化現象，因此我將極光轉化與星河長夜作為視覺風格。

網路上有許多山海神獸圖，如同作品集模板，它們都不是我。因此我重新繪製。(圖像來自《觀山海》與網路資源。)

標題以墨漬暈染，朱砂點綴，文字同古文縱向右書，使視覺風格一致。

設計淵源至此渠成，星河長夜為基、雲海山相為輔、神獸綴飾章節、卷軸入制。燭龍載於大荒北經，故作品集以北經為名，是謂- 北經殘卷。

讓程式語言
為我服務

為了不向技術妥協，我跟著Youtube影片練習許多不同的小計畫，透過網路資源尋解決困難。

為使首頁雲海有動態層次，在youtube 學習Parallax Scrolling Effect 的寫法。

圖片響應瀏覽器和螢幕縮放，透過沙漠旅遊首頁，學習背景圖片位移控制。

大量背景圖檔過大，造成網頁不易讀取，縮放時也有模糊情況，我找了許多壓縮或轉檔方法，並不能改善。

在製作第二作品集-羽衣悔換，無意間學會用程式語言換置<svg>顏色及尺寸。

故將部分北經殘卷圖片換成<svg>程式，減少大圖檔案，同時解決圖像縮放的模糊問題。

加入Loading畫面，彌補等待網頁下載時間。

引入第三方程式Swiper(swiperjs.com)呈現卷軸滑動更換。

為方便平板與手持裝置閱讀，響應各式裝置螢幕。

圖片響應瀏覽器和螢幕縮放，透過沙漠旅遊首頁，學習背景圖片位移控制。

在製作第二作品集-羽衣悔換，無意間學會用程式語言換置<svg>顏色及尺寸。

加入Loading畫面，彌補等待網頁下載時間。

為方便平板與手持裝置閱讀，響應各式裝置螢幕。

解決困難
為目標堅持到底

技能說明呈現的發想與實行，我遇上許多困難和挫折，曾數度想放棄計畫。

技能說明的呈現很多: %、星評、水準形容詞，優缺點眾說紛紜，我只覺得它們千篇一律。

我參考陰陽家陣法、紫微星圖、魔法陣、黃道十二宮。吸收消化後，將技能名稱畫成星符。(白色區域陣圖出自網路資源)

古代人類崇拜光，日月在東方、西方的玄學、理學裡皆為重要象徵，我繪製三足金烏、廣寒玉蟾呈現。

編寫程式語言時，我希望做點擊按鈕後出現文字內容，卻遇上了很大的阻礙，幾乎要放棄。

第一個困難是:hover。點擊元素後，該元素無法刪除:hover響應，我找了許多網頁卻不得解法。

換角度思考解決問題，改為點擊後禁用該技能的pointer-events。

第二個困難是陰影效果。為指引觀看者明白目前停在哪一個星符，以星符光圈定位，但是:hover禁用後無法維持。

在練習小計劃時，學習到::before和::after應用，改為將陰影拆分圖層寫入，以利配合JS調用。

第三個困難是我遇到的最大阻礙，我為此改變HTML多次...最後才發現closest()抓不到<p>、也難以配合向下抓取。

苦惱許久才找到實用好操作的.parentNode和.children[ ]，並修改HTML配合JS。

第四個困難，解決星陣圖因螢幕縮小被裁切，尋找解法時發現w3schools教學是舊版。

我不知道更新後的addEventListenter中，" event " 該使用什麼。好在stackoverflow有大神解答。

至此技能說明與星陣圖融匯完成，同時響應螢幕改變，方便使用者。

我參考陰陽家陣法、紫微星圖、魔法陣、黃道十二宮。吸收消化後，將技能名稱畫成星符。(白色區域陣圖出自網路資源)

編寫程式語言時，我希望做點擊按鈕後出現文字內容，卻遇上了很大的阻礙，幾乎要放棄。

換角度思考解決問題，改為點擊後禁用該技能的pointer-events。

在練習小計劃時，學習到::before和::after應用，改為將陰影拆分圖層寫入，以利配合JS調用。

苦惱許久才找到實用好操作的.parentNode和.children[ ]，並修改HTML配合JS。

我不知道更新後的addEventListenter中，" event " 該使用什麼。好在stackoverflow有大神解答。

為方便使用者
做出改變

朋友第一次操作後，我發現許多誤區。為方便使用者，做出改變。

Loading時，金烏也在下載而沒出現造成黑幕。

加入進度條，在沒有金烏的況下，使用者也能明白網頁在Loading。

觸控操作下，作品展示的捲軸很難滑動，Swiper預設的點點很小很難點。

結合不同的Swiper Demos，修改Thumbs，使用者在觸控操作下能輕易點選觀看不同卷軸。

原本覺得星陣圖的提示句很破壞氣氛，朋友試用後，我發覺提示非常重要，它快速有效的指引使用者操作並養成習慣動作。

在手機上使用時，習慣將手指放在螢幕上的人，容易喚醒圖片的長按動作反饋。

用CSS與JS阻止滑鼠右鍵發生。

Nav選項在:hover時，觸發其他選項的透明度問題。

Nav修改後:hover正常反應。

Nav選單在手機閱讀不易，關閉按鈕錯位與難觸及。

修改透明度及按鈕位置，便手持裝置使用者操作。

圖片在點擊當下出現藍色閃爍，" outline: none; "明顯無效。

換角度思考，改變背景顏色解決藍色背景問題。

加入進度條，在沒有金烏的況下，使用者也能明白網頁在Loading。

結合不同的Swiper Demos，修改Thumbs，使用者在觸控操作下能輕易點選觀看不同卷軸。

在手機上使用時，習慣將手指放在螢幕上的人，容易喚醒圖片的長按動作反饋。

Nav選項在:hover時，觸發其他選項的透明度問題。

Nav選單在手機閱讀不易，關閉按鈕錯位與難觸及。

圖片在點擊當下出現藍色閃爍，" outline: none; "明顯無效。

感謝您的參閱

北經殘卷於此告一段落。從無到有的這過程中，我遇上許多困難與挫折，也盡最大努力一一克服，為目標堅持到底。當然，在程式語言使用上不夠精練，也一定有更好的寫法可以使北經殘卷更加完善。我很喜歡這部作品，希望你也喜歡，謝謝。

-- Thank you --