UI/UX for Complex Logic

Thiết kế bài giảng chuyên sâu cho BA 1–2 năm kinh nghiệm trong bối cảnh E-com

---

1) Tóm tắt cốt lõi (The Core)

Mục tiêu học tập đo lường được

Sau bài học, người học có thể:

1. Phân rã một bài toán nghiệp vụ phức tạp thành hệ thống trạng thái, điều kiện, vai trò và nhánh xử lý thay vì nhảy ngay vào vẽ màn hình.
2. Thiết kế một Dashboard dữ liệu phức tạp bằng tư duy Information Architecture và Progressive Disclosure, tránh nhồi mọi biểu đồ lên một màn hình.
3. Xây dựng một bộ Advanced Wireframe/Flow thực chiến gồm:
   • luồng chính,
   • luồng rẽ nhánh,
   • trạng thái màn hình,
   • popup/drawer/modal,
   • validation,
   • thông báo lỗi,
   • trạng thái rỗng/loading/permission/error.
4. Kể được câu chuyện logic qua Wireframe để Stakeholder và Dev có thể sign-off rõ ràng, giảm hiểu sai yêu cầu.
5. Hoàn thành một bài thực hành với tiêu chí:
   • bao phủ ít nhất 90% business rules cốt lõi,
   • thể hiện tối thiểu 8–10 state/edge cases,
   • có annotation logic đủ để Dev hiểu cách hệ thống phản hồi.

---

2) Bước tư duy bắt buộc trước khi dạy (The Thinking Stack)

Bước 1 — Làm rõ (Clarification)

Hồ sơ người học

• Vai trò: BA có 1–2 năm kinh nghiệm
• Điểm yếu thường gặp:
  • quen viết requirement theo feature rời rạc,
  • ít va chạm dự án nhiều trạng thái/phân quyền/phụ thuộc dữ liệu,
  • hay “vẽ theo màn hình” thay vì “vẽ theo logic hệ thống”.
• Công cụ hiện tại:
  • Figma
  • Draw.io
• Domain case study:
  • E-commerce

Hệ quả lên thiết kế bài giảng

Bài giảng này không nên bắt đầu bằng UI đẹp.
Nó phải bắt đầu từ:

• State mapping
• Decision table
• Role & permission
• Action availability
• Information hierarchy

Nói thẳng: với nhóm người học này, dạy họ “wireframe đẹp” là sai trọng tâm.
Thứ họ thiếu là tư duy hệ thống trước khi vẽ.

---

Bước 2 — Phá vỡ giả định (Kill Assumptions)

Giả định sai số 1: “Logic phức tạp thì giao diện phải phức tạp”

Sai.

Logic backend có thể phức tạp, nhưng UI vẫn phải đơn giản về mặt nhận thức.
Người học cần học nghệ thuật nén độ phức tạp, không phải phơi bày toàn bộ độ phức tạp.

Cách dạy đúng

Dạy theo 4 lớp hiển thị:

Lớp	Người dùng thấy gì	Mục đích
Layer 1	Tóm tắt/KPI/Status chính	Trả lời nhanh: “Có gì đang xảy ra?”
Layer 2	Danh sách ưu tiên/Exception queue	Trả lời: “Cần xử lý cái gì trước?”
Layer 3	Chi tiết theo ngữ cảnh	Trả lời: “Tại sao nó xảy ra?”
Layer 4	Action + validation + audit trail	Trả lời: “Tôi được phép làm gì, và hậu quả là gì?”

Đây chính là Progressive Disclosure trong hệ thống B2B.

---

Giả định sai số 2: “Stakeholder nhìn Wireframe là tự hiểu”

Sai.

Stakeholder thường không đọc wireframe theo cách Designer nghĩ.
Họ đọc bằng câu hỏi:

• “Use case này chạy thế nào?”
• “Nếu bị lỗi thì sao?”
• “Ai được bấm nút này?”
• “Ở state này có cho refund không?”
• “Nếu 2 team thao tác cùng lúc thì sao?”

Cách dạy đúng

Wireframe phải là công cụ kể chuyện logic, không chỉ là ảnh xám.

Người học phải học cách trình bày theo format:

• Bối cảnh
• Trigger
• Điều kiện
• System response
• UI response
• Next state
• Exception / Edge Cases

Nói cách khác:
Advanced Wireframe = UI + State + Rule + Narrative

---

Bước 3 — Tư duy đa chiều (Multiple Minds)

Nội dung bài học nên được soi qua 3 lăng kính để BA làm việc được với cả User, Business và Dev.

Lăng kính 1 — Người dùng thao tác (Task & Cognitive Load)

Câu hỏi trọng tâm:

• Họ đang cố hoàn thành việc gì?
• Họ cần quyết định nhanh hay phân tích sâu?
• Điều gì cần hiện ngay, điều gì nên ẩn?
• Một màn hình có đang bắt họ “đọc để hiểu” quá nhiều không?

Lăng kính 2 — Business & Operations Control

Câu hỏi trọng tâm:

• Quy trình có bao nhiêu trạng thái?
• Trạng thái nào cần approval?
• Điều kiện nào là rule cứng, điều kiện nào là policy mềm?
• KPI nào dùng để điều hành, KPI nào chỉ để tham khảo?

Lăng kính 3 — Delivery & Engineering Clarity

Câu hỏi trọng tâm:

• Nút nào enable/disable trong state nào?
• Điều kiện hiển thị của block nào?
• Error nào là system error, error nào là business validation?
• Khi action thành công/thất bại thì state chuyển thế nào?

Nếu bài học không ép người học đi qua cả 3 lăng kính này, họ sẽ tạo ra wireframe “trông hợp lý” nhưng không deploy được.

---

Bước 4 — Tư duy bậc hai (Second-Order Thinking)

Nếu người học nhét mọi biểu đồ lên một màn hình Dashboard thì điều gì xảy ra?

Hậu quả cấp 1

• Người dùng bị quá tải.
• Không biết nhìn vào đâu trước.
• Biểu đồ nhiều nhưng không hỗ trợ quyết định.

Hậu quả cấp 2

• Team vận hành bỏ dashboard, quay lại Excel/Slack/manual checks.
• Stakeholder hiểu sai rằng “thiếu dữ liệu” nên yêu cầu thêm biểu đồ.
• Sản phẩm càng ngày càng phình, nhưng không tăng hiệu quả vận hành.

Hậu quả cấp 3

• Designer bị biến thành người “xếp chart”.
• BA không còn kiểm soát logic.
• Dev implement theo cảm tính vì wireframe không chỉ ra hierarchy và action priority.

Cách dạy để tránh sai lầm này

Bắt buộc người học làm Information Architecture trước khi vẽ:

1. Xác định quyết định mà dashboard phải hỗ trợ.
2. Xác định người dùng cần trả lời câu hỏi gì trong 5 giây đầu.
3. Phân loại thông tin thành:
   • Monitor
   • Diagnose
   • Act
4. Chỉ sau đó mới chọn:
   • card,
   • table,
   • chart,
   • filter,
   • drill-down,
   • alert.

Quy tắc thép:
Không chọn chart trước khi biết decision.

---

3) Lộ trình giảng dạy (The Master Roadmap)

Cấu trúc tổng thể

Module	Trọng tâm	Mục tiêu đầu ra	Deliverable
1	Reset tư duy: từ Screen sang System	Hiểu vì sao UI phức tạp phải bắt đầu từ logic	1 sơ đồ “System Thinking vs Screen Thinking”
2	Business Logic Decomposition	Biết bóc tách state, role, rule, trigger, exception	1 State Map + 1 Decision Table
3	Information Architecture cho Dashboard	Biết sắp xếp thông tin theo quyết định, không theo sở thích	1 sơ đồ IA của dashboard
4	Thiết kế Data Visualization cho B2B	Chọn đúng loại hiển thị theo loại quyết định	1 khung dashboard low-fi
5	Multi-branch User Flow	Vẽ được flow có nhánh, điều kiện, rollback, error path	1 flow tổng + 2 flow exception
6	Advanced Wireframe & Annotation	Chuyển flow thành wireframe có logic đủ để sign-off	1 bộ wireframe annotated
7	Visual Storytelling cho Stakeholder/Dev	Trình bày wireframe như một câu chuyện logic	1 script walkthrough 5–7 phút
8	Thực hành tổng hợp	Hoàn thiện case study end-to-end	Bộ bài nộp hoàn chỉnh

---

Module 1 — Reset tư duy: từ “vẽ màn hình” sang “thiết kế hệ thống”

Mục tiêu

Người học hiểu rằng UI/UX cho logic phức tạp không bắt đầu từ component, mà bắt đầu từ:

• trạng thái,
• nhánh xử lý,
• quyền,
• biến số dữ liệu.

Nội dung dạy

• Sự khác nhau giữa:
  • Simple screen design
  • System interaction design
• 5 câu hỏi phải trả lời trước khi vẽ:
  1. User đang ra quyết định gì?
  2. State hiện tại của object là gì?
  3. Ở state này, action nào hợp lệ?
  4. Điều gì có thể fail?
  5. Nếu fail, UI phản hồi ra sao?

Bài tập nhỏ

Cho 1 màn hình order detail đơn giản.
Yêu cầu học viên liệt kê:

• hidden states,
• missing rules,
• action conflicts.

---

Module 2 — Business Logic Decomposition

Mục tiêu

Biến nghiệp vụ phức tạp thành thứ có thể wireframe được.

Nội dung dạy

• Cách bóc tách:
  • Entity
  • State
  • Trigger
  • Condition
  • Action
  • Outcome
• Dùng Draw.io để vẽ:
  • state diagram,
  • role flow,
  • approval branch.
• Dùng bảng để chốt rule thay vì nói miệng.

Framework dạy

Bảng state logic mẫu

State	Ai nhìn thấy	Action hợp lệ	Điều kiện	Next state
Payment Pending	CS, Ops	Retry payment / Cancel order	Chưa capture tiền	Paid / Cancelled
Fraud Review	Risk, Ops Lead	Approve / Reject	Risk score > threshold	Fulfillment Ready / Cancelled
Customs Hold	Ops	Request document / Refund	Cross-border order	In Transit / Refund Review
Refund Review	Finance, Ops Lead	Approve refund / Reject	Refund amount, policy, tax	Refunded / Rejected

Deliverable

• 1 sơ đồ state machine
• 1 decision table cho 8–12 rules cốt lõi

---

Module 3 — Information Architecture cho Dashboard

Mục tiêu

Biết phân loại thông tin trước khi chọn layout.

Nội dung dạy

Dạy dashboard theo 3 lớp nhiệm vụ:

Loại thông tin	Câu hỏi người dùng	UI phù hợp
Monitor	“Tình hình tổng thể ra sao?”	KPI card, alert summary, trend
Diagnose	“Vấn đề nằm ở đâu?”	Filterable table, segmented chart, breakdown
Act	“Tôi cần xử lý đơn nào?”	Queue, priority list, CTA, batch action

Quy tắc thiết kế

• KPI không quá 5–7 items trên vùng nhìn đầu tiên.
• Mọi chart phải trả lời 1 câu hỏi nghiệp vụ cụ thể.
• Bất cứ biểu đồ nào không dẫn đến action hoặc diagnosis thì xem xét loại bỏ.
• Table trong hệ thống B2B thường quan trọng hơn chart.

Bài tập

Cho danh sách 20 metrics/order signals.
Yêu cầu học viên:

• nhóm thành 3 tầng IA,
• quyết định metric nào hiển thị trực tiếp,
• metric nào đưa vào drill-down.

---

Module 4 — Data Visualization cho Dashboard dữ liệu phức tạp

Mục tiêu

Biết chọn cách hiển thị giúp ra quyết định, không phải chỉ để “đẹp”.

Nội dung dạy

• Khi nào dùng:
  • KPI card
  • stacked bar
  • line trend
  • table with conditional highlight
  • status distribution
• Khi không nên dùng chart
• Cách kết hợp chart + filter + exception table

Nguyên tắc khắt khe

• Nếu user cần “tìm đơn cần xử lý”, chart không phải điểm bắt đầu.
• Nếu user cần “phát hiện bất thường”, chart phải được gắn với threshold hoặc benchmark.
• Nếu user cần “xác minh case”, phải có drill-down vào entity detail.

Deliverable

1 wireframe dashboard low-fi gồm:

• header filters,
• summary KPI,
• alert strip,
• exception queue,
• trend snapshot,
• drill-down entry points.

---

Module 5 — Multi-branch User Flow

Mục tiêu

Vẽ được luồng nhiều nhánh mà vẫn đọc được.

Nội dung dạy

• Cách phân tầng flow:
  • Happy path
  • Exception path
  • Approval path
  • Failure path
• Kỹ thuật tách flow để không thành “mì spaghetti”
• Quy ước ký hiệu:
  • decision node,
  • system action,
  • manual action,
  • async wait,
  • retry,
  • terminal state.

Quy tắc

• Không nhét tất cả vào 1 canvas.
• Phải có:
  • 1 flow tổng cấp cao,
  • 2–3 flow con cho nhánh phức tạp.
• Mỗi flow phải ghi rõ:
  • actor,
  • trigger,
  • condition,
  • artifact được tạo ra.

Deliverable

• 1 overview flow
• 1 refund approval flow
• 1 exception resolution flow

---

Module 6 — Advanced Wireframe & Annotation

Mục tiêu

Chuyển logic thành wireframe mà Stakeholder/Dev đọc ra được hành vi hệ thống.

Nội dung dạy

Một bộ Advanced Wireframe phải có đủ 6 lớp:

1. Layout khung
2. State của màn hình
3. Action availability
4. Validation & business rule
5. System feedback
6. Exception / Edge Cases

Cấu trúc annotation khuyến nghị

ID	Trigger	Condition	UI response	System response	Next state
R1	Click “Approve Refund”	Amount < 200 USD & no tax issue	Show confirm modal	Submit refund request	Refunded
R2	Click “Approve Refund”	Amount ≥ 200 USD	Disable direct approval, show escalation note	Route to Finance	Pending Finance Review
R3	Page load	Order locked by another agent	Show warning banner, disable edit	Refresh lock owner	Read-only

Kết luận quan trọng

Wireframe không có annotation logic thì chưa phải Advanced Wireframe.

---

Module 7 — Visual Storytelling để sign-off với Stakeholder

Mục tiêu

Biết trình bày logic qua wireframe để giảm vòng sửa.

Nội dung dạy

Trình bày theo thứ tự:

1. Business goal
2. User role
3. State hiện tại
4. Problem on screen
5. Action available
6. Result after action
7. What happens in exception

Script walkthrough mẫu

“Ở màn hình queue này, user không cần thấy toàn bộ dữ liệu đơn hàng. Họ chỉ cần biết đơn nào cần xử lý trước. Khi click vào order, detail page chuyển sang state-specific layout. Nếu đơn đang ở Customs Hold, block refund và block document request được ưu tiên hiển thị. Nếu refund vượt ngưỡng, CTA đổi từ approve trực tiếp sang escalate. Như vậy UI đang phản ánh rule, không phải chỉ hiển thị dữ liệu.”

Deliverable

• 1 script thuyết trình 5–7 phút
• 1 checklist sign-off

---

Module 8 — Thực hành tổng hợp

Kết quả cuối kỳ

Người học nộp 1 package gồm:

• State map
• Decision table
• Dashboard IA
• Multi-branch flow
• Bộ Advanced Wireframe
• Annotation logic
• 1 script trình bày

---

4) Kịch bản Case Study & Thực hành

Case Study đề xuất:

Cross-Border E-commerce Order Exception & Refund Console

Đây là case đủ “nặng đô” để dạy đúng bản chất UI/UX for Complex Logic nhưng vẫn nằm trong domain E-com.

---

4.1. Bối cảnh nghiệp vụ

Một sàn E-com bán hàng xuyên biên giới.
Order có thể gặp nhiều tình huống:

• thanh toán thất bại,
• bị flag gian lận,
• thiếu tồn kho tại warehouse,
• bị giữ ở khâu customs,
• giao hàng thất bại,
• khách yêu cầu hoàn tiền một phần hoặc toàn phần.

Hệ thống có nhiều vai trò:

• Customer Support Agent
• Operations Lead
• Finance Reviewer
• Warehouse Coordinator

Mỗi vai trò thấy và làm khác nhau.

---

4.2. Business Logic Constraints

Entities chính

• Order
• Payment
• Shipment
• Refund
• Exception Case
• Audit Log

State chính của Order

• New
• Payment Pending
• Paid
• Fraud Review
• Fulfillment Ready
• Split Shipment
• In Transit
• Customs Hold
• Delivery Failed
• Delivered
• Refund Review
• Refunded
• Cancelled
• Closed

Rule cốt lõi

1. Nếu payment chưa capture, order có thể cancel full.
2. Nếu risk score vượt ngưỡng, order chuyển Fraud Review.
3. Nếu một item hết hàng:
   • cho split shipment nếu còn item khác,
   • hoặc cancel item-level nếu policy cho phép.
4. Nếu order cross-border bị Customs Hold, không được auto-refund ngay nếu thiếu chứng từ.
5. Refund trên ngưỡng tiền hoặc có tax adjustment phải qua Finance Reviewer.
6. Refund không được vượt số tiền đã capture.
7. Nếu dùng coupon/order-level promotion, hoàn tiền phải phân bổ lại theo item.
8. Nếu agent khác đang xử lý case, màn hình phải khóa chỉnh sửa.
9. Nếu trạng thái order đổi trong lúc user đang thao tác, phải cảnh báo dữ liệu stale.
10. Mọi action quan trọng phải có audit trail.

---

4.3. Mục tiêu UX của hệ thống

Người dùng trong Ops Console phải trả lời được 3 câu hỏi trong thời gian ngắn:

1. Đơn nào đang có rủi ro hoặc cần xử lý trước?
2. Tại sao đơn này đang bị chặn?
3. Tôi được phép làm gì ở trạng thái hiện tại?

Nếu UI không giúp trả lời đúng 3 câu hỏi này, coi như fail.

---

5) Phác thảo cấu trúc bộ Advanced Wireframe

5.1. Bộ màn hình chính

Màn hình	Mục tiêu	Thành phần chính
1. Operations Dashboard	Monitor & prioritize	KPI, alert summary, exception queue, trend
2. Exception Queue List	Tìm case cần xử lý	Filter, sort, SLA badge, status, assignee
3. Order Detail Overview	Hiểu toàn cảnh order	State ribbon, order summary, customer/payment/shipment blocks
4. Timeline & Audit Log	Xác minh lịch sử	Timeline, actor, timestamp, state changes
5. Refund Review Screen	Xử lý hoàn tiền	Refund breakdown, eligibility, escalation logic
6. Customs Hold Resolution	Xử lý case hải quan	document request, hold reason, next actions
7. Split Shipment Decision Screen	Chốt xử lý khi thiếu hàng	item status, stock source, split/cancel options
8. Read-only Conflict State	Xử lý concurrent edit	warning banner, lock owner, refresh CTA

---

5.2. Popup / Modal / Drawer bắt buộc

Loại	Dùng khi nào	Logic cần thể hiện
Confirm Refund Modal	Approve refund	số tiền, phí, tax, next approver
Reject Refund Modal	Từ chối refund	reason bắt buộc
Escalate to Finance Modal	Refund vượt ngưỡng	lý do escalate, SLA, assignee
Split Shipment Modal	Thiếu tồn kho cục bộ	item nào ship ngay, item nào hold
Request Customs Doc Drawer	Customs hold	danh sách chứng từ thiếu, deadline
Lock Conflict Modal	Case bị agent khác mở	read-only, refresh, takeover policy
Unsaved Changes Modal	User rời màn hình	save draft / discard
Bulk Action Modal	Chọn nhiều case	validate batch eligibility

---

5.3. Error / Validation / Notification bắt buộc

Error states

• Không đủ quyền để approve refund
• Refund amount vượt captured amount
• Case đã đổi state trong lúc đang thao tác
• API fail khi submit action
• Warehouse data unavailable
• Tax recalculation timeout

Validation states

• Reject reason bắt buộc
• Chứng từ customs bắt buộc trước khi refund
• Không cho partial refund nếu item chưa có delivery outcome
• Không cho split shipment nếu order có item bundle không tách được

Feedback states

• Success toast
• Inline validation
• Warning banner
• Read-only badge
• Loading skeleton
• Empty state
• No search result state

---

6) Bài thực hành chính

Đề bài cho học viên

Nhiệm vụ

Thiết kế một bộ Advanced Wireframe/Flow cho hệ thống
Cross-Border E-commerce Order Exception & Refund Console

Yêu cầu bắt buộc

Học viên phải nộp:

1. State Map

   • ít nhất 10 trạng thái
   • thể hiện 3 nhánh exception

2. Decision Table

   • ít nhất 12 business rules

3. Dashboard IA

   • phân tầng Monitor / Diagnose / Act

4. User Flow

   • 1 happy path
   • 2 exception paths
   • 1 approval path

5. Wireframe

   • tối thiểu 6 màn hình chính
   • tối thiểu 4 popup/drawer
   • đầy đủ loading/empty/error/read-only states

6. Annotation

   • role-based visibility
   • action conditions
   • next state
   • system feedback

---

6.1. Gợi ý bộ màn hình thực hành

Screen set tối thiểu

1. Dashboard Overview
2. Exception Queue
3. Order Detail – Fraud Review state
4. Order Detail – Customs Hold state
5. Refund Review – below threshold
6. Refund Review – finance escalation state
7. Split Shipment Decision
8. Conflict/Locked state
9. Audit Log drawer
10. Error + Empty state variations

---

6.2. Edge Cases bắt buộc phải vẽ

Học viên phải thể hiện ít nhất các Edge Cases sau:

1. Order đổi state khi user đang mở detail screen
2. Refund vượt ngưỡng approval
3. Item-level refund nhưng coupon là order-level
4. Case bị agent khác khóa
5. Cross-border order thiếu customs document
6. Không đủ quyền để thực hiện action
7. API timeout sau khi submit
8. Không có dữ liệu dashboard trong bộ lọc đã chọn

Nếu không có Edge Cases, bài này chưa đạt chuẩn thực chiến.

---

7) Cách dạy Wireframe để “chốt” logic với Stakeholder

7.1. Không trình bày theo màn hình. Trình bày theo câu chuyện

Thứ tự nên là:

Story 1 — Từ Dashboard vào Queue

• User vào dashboard để phát hiện bất thường
• Họ không cần tất cả biểu đồ
• Họ cần thấy:
  • số case đang trễ SLA,
  • số refund pending,
  • số customs hold cần xử lý.

Story 2 — Từ Queue vào Detail

• Click vào case
• Layout detail thay đổi theo state
• Hệ thống ưu tiên thông tin liên quan đến quyết định hiện tại

Story 3 — Từ Detail đến Action

• CTA không cố định
• CTA phụ thuộc state, quyền và điều kiện
• UI phải giải thích vì sao action bị khóa

Story 4 — Nếu có exception

• stale data,
• lock conflict,
• missing documents,
• validation failure
  đều phải được kể thành một luồng rõ ràng.

---

7.2. Công thức trình bày 1 frame

Mỗi frame nên được nói bằng 5 dòng:

1. Frame này dành cho ai
2. Họ đang ở state nào
3. Họ cần quyết định điều gì
4. UI đang ưu tiên thông tin nào
5. Nếu bấm CTA thì hệ thống phản hồi ra sao

Đây là cách biến wireframe từ “ảnh xám” thành “logic story”.

---

8) Checklist “Kill Assumptions”

3 lỗi sai chết người khi chốt logic với Dev/Stakeholder bằng Wireframe

Lỗi sai	Vì sao nguy hiểm	Cách phòng tránh
1. Vẽ màn hình trước, model logic sau	Bỏ sót state, quyền, exception; về sau sửa rất tốn	Luôn làm State Map + Decision Table trước wireframe
2. Nhét toàn bộ dữ liệu lên dashboard	Tăng cognitive load, không hỗ trợ quyết định, Stakeholder càng đòi thêm chart	Bắt buộc làm Information Architecture theo Monitor / Diagnose / Act và áp dụng Progressive Disclosure
3. Wireframe không có annotation logic	Dev hiểu mỗi người một kiểu, Stakeholder sign-off sai, QA không có căn cứ test	Mỗi action quan trọng phải có: condition, validation, system feedback, next state, owner role

---

9) Bộ tiêu chí chấm bài thực hành

Đạt chuẩn khi bài nộp có đủ 5 yếu tố

1. Bao phủ logic

• Có state rõ ràng
• Có nhánh xử lý
• Có exception path

2. Rõ thông tin

• Dashboard có hierarchy
• Không overload
• Có ưu tiên thị giác

3. Rõ hành vi hệ thống

• Nút nào bật/tắt ở state nào
• Khi lỗi thì gì xảy ra
• Khi thành công thì state đổi thế nào

4. Rõ cho Dev

• Annotation dùng được để implement
• Không mơ hồ kiểu “handle by system”

5. Rõ cho Stakeholder

• Có thể walkthrough từ business scenario tới UI outcome
• Đọc xong hiểu được flow, không cần tự đoán

---

10) Kết luận định hướng

Bài học này phải làm được một việc rất rõ:

Chuyển người học từ tư duy “tôi đang vẽ một số màn hình”
sang tư duy
“tôi đang mô hình hóa một hệ thống quyết định và biểu diễn nó bằng UI.”

Đó mới là bản chất của:

• UI/UX for Complex Logic
• Data Visualization trong B2B
• Advanced Wireframe
• Multi-branch User Flow
• và kỹ năng sign-off thực chiến.

Nếu bạn muốn, tôi có thể chuyển ngay nội dung này thành giáo án 90 phút / 1 buổi workshop, hoặc thành slide outline + template bài tập Figma/Draw.io.

Dưới đây là cấu trúc deck thuyết trình dưới 25 slides. Tôi sắp theo logic kể chuyện:
Vấn đề → Tư duy đúng → Framework → Case study → Dashboard → Flow → Wireframe → Sign-off → Thực hành.

---

Deck outline đề xuất: 24 slides

---

Slide 1 — Title Slide

Title

UI/UX for Complex Logic
Từ “simple screens” đến tư duy hệ thống và làm chủ Advanced Wireframe/Flow

Nội dung

• Tên chủ đề
• Subtitle:
  • Thiết kế Dashboard dữ liệu phức tạp
  • Xây dựng User Flow nhiều rẽ nhánh
  • Dùng Advanced Wireframe để chốt logic với Stakeholder/Dev
• Có thể thêm 1 dòng context:
  • Dành cho BA 1–2 năm kinh nghiệm trong bối cảnh E-commerce

Visual gợi ý

• Visual hero dạng sơ đồ từ trái sang phải:
  • Business Logic → Information Architecture → Flow → Wireframe → Sign-off
• Background sạch, thiên hướng enterprise/B2B
• Không cần quá nhiều text ngoài title

---

Slide 2 — The Real Problem

Title

Vấn đề thật không nằm ở UI đẹp — mà ở logic chưa được mô hình hóa

Nội dung

• Nhiều BA/Designer mới thường:
  • nhảy vào vẽ màn hình quá sớm
  • gom mọi dữ liệu lên dashboard
  • thiếu state, rule, error, permission
• Hệ quả:
  • stakeholder không chốt được
  • dev hiểu mỗi người một kiểu
  • QA test thiếu case
  • sản phẩm nhìn “ổn” nhưng không chạy được ngoài thực tế

Visual gợi ý

• 2 cột đối lập:
  • Cột trái: “Screen-first mindset”
  • Cột phải: “System-first mindset”
• Dùng icon nhỏ cho:
  • state
  • rules
  • error
  • roles
• Có thể thêm một mini flow đỏ biểu thị “misalignment”

---

Slide 3 — Learning Objective

Title

Sau buổi này, người học phải làm được gì?

Nội dung

• Sau bài học, học viên phải:
  1. Phân rã được nghiệp vụ phức tạp thành state + condition + action + outcome
  2. Thiết kế dashboard bằng Information Architecture, không bằng cảm tính
  3. Vẽ được multi-branch flow
  4. Tạo được Advanced Wireframe có annotation logic
  5. Trình bày wireframe như một câu chuyện logic để stakeholder sign-off
• Đầu ra mong đợi:
  • 1 state map
  • 1 decision table
  • 1 dashboard IA
  • 1 user flow
  • 1 bộ wireframe annotated

Visual gợi ý

• 5 khối mục tiêu xếp theo chiều ngang hoặc vertical ladder
• Mỗi khối có icon:
  • map
  • chart
  • flow
  • wireframe
  • check/sign-off

---

Slide 4 — Clarification: Who Are We Designing This For?

Title

Người học là ai, và điều đó thay đổi cách dạy như thế nào?

Nội dung

• Hồ sơ người học:
  • BA 1–2 năm kinh nghiệm
  • chưa tham gia nhiều dự án có logic dày
  • công cụ chính: Figma, Draw.io
  • domain: E-commerce
• Họ thường thiếu:
  • tư duy state machine
  • experience với edge cases
  • cách biến business rule thành UI behavior
• Vì vậy bài học phải dạy theo hướng:
  • ít mỹ thuật
  • nhiều hệ thống
  • nhiều mô hình hóa logic
  • nhiều practice hơn theory

Visual gợi ý

• Persona slide:
  • “Junior-to-mid BA”
  • pain points
  • growth goals
• Dùng layout card persona + năng lực cần nâng cấp

---

Slide 5 — Kill Assumption #1

Title

Logic phức tạp ≠ Giao diện phải phức tạp

Nội dung

• Sai lầm phổ biến:
  • nghĩ rằng business logic càng phức tạp thì UI càng phải “show hết”
• Thực tế:
  • backend có thể phức tạp
  • UI phải giảm tải nhận thức
• Nguyên tắc:
  • hiển thị đúng thứ user cần ở đúng thời điểm
  • không phơi bày toàn bộ cấu trúc hệ thống lên màn hình
• Từ khóa cần nhấn mạnh:
  • Progressive Disclosure
  • Contextual Actions
  • Information Priority

Visual gợi ý

• So sánh 2 wireframe:
  • bên trái: dashboard nhồi chart, nhiều box, rối
  • bên phải: dashboard có hierarchy rõ
• Chèn callout: “Complexity in system ≠ complexity in surface”

---

Slide 6 — Kill Assumption #2

Title

Stakeholder không “tự hiểu” Wireframe

Nội dung

• Stakeholder không đọc wireframe như designer
• Họ muốn biết:
  • use case này chạy thế nào?
  • nếu lỗi thì sao?
  • ai được bấm nút gì?
  • rule nào đang chi phối action?
• Vì vậy:
  • wireframe phải kể được câu chuyện logic
  • không chỉ là ảnh xám
• Công thức đúng:
  • UI + State + Rule + Next Step + Exception

Visual gợi ý

• Hình wireframe ở giữa
• Xung quanh là bubble câu hỏi của stakeholder:
  • “What happens next?”
  • “Who can approve?”
  • “What if it fails?”
• Dùng mũi tên trỏ vào các khu vực cần annotation

---

Slide 7 — The Shift in Mindset

Title

Từ “Designing Screens” sang “Designing Decision Systems”

Nội dung

• Màn hình không phải đích đến
• Màn hình là biểu hiện bề mặt của:
  • trạng thái hệ thống
  • quyền người dùng
  • điều kiện nghiệp vụ
  • phản hồi hệ thống
• Câu hỏi phải hỏi trước khi vẽ:
  1. User đang quyết định điều gì?
  2. Object đang ở state nào?
  3. Action nào hợp lệ ở state đó?
  4. Điều gì có thể fail?
  5. Nếu fail, UI phản hồi thế nào?

Visual gợi ý

• Sơ đồ phân lớp:
  • Business rules
  • States
  • Permissions
  • User decisions
  • UI
• UI là layer trên cùng

---

Slide 8 — Teaching Framework

Title

Framework bài học: 4 tầng tư duy bắt buộc

Nội dung

Giới thiệu 4 bước:

1. Clarification
2. Kill Assumptions
3. Multiple Minds
4. Second-Order Thinking

Giải thích ngắn từng bước:

• Clarification: biết mình đang dạy ai
• Kill Assumptions: phá các niềm tin sai
• Multiple Minds: nhìn từ user/business/dev
• Second-Order Thinking: thấy hậu quả của design tệ trước khi vẽ

Visual gợi ý

• 4 block theo chuỗi
• Có thể dùng hình kim tự tháp hoặc staircase
• Mỗi block có 1 câu mô tả ngắn

---

Slide 9 — Multiple Minds

Title

Thiết kế qua 3 lăng kính: User, Business, Engineering

Nội dung

Lăng kính 1 — User / Task

• User cần quyết định gì?
• Cần thao tác nhanh hay phân tích sâu?
• Điều gì cần hiện ngay?

Lăng kính 2 — Business / Operations

• State nào cần approval?
• Rule nào là cứng?
• KPI nào thật sự phục vụ vận hành?

Lăng kính 3 — Engineering / Delivery

• Action nào enable/disable theo state?
• Error nào là business validation?
• State đổi như thế nào sau action?

Visual gợi ý

• 3 vòng tròn hoặc 3 cột
• Ở giữa là “Good B2B UX”
• Có thể dùng Venn diagram nhẹ

---

Slide 10 — Second-Order Thinking

Title

Điều gì xảy ra nếu Dashboard chỉ là nơi “nhét mọi biểu đồ”?

Nội dung

• Hậu quả cấp 1:
  • quá tải thông tin
  • user không biết nhìn gì trước
• Hậu quả cấp 2:
  • dashboard không hỗ trợ quyết định
  • team quay lại Excel/Slack
• Hậu quả cấp 3:
  • stakeholder tiếp tục đòi thêm chart
  • sản phẩm phình to nhưng không hữu ích
• Kết luận:
  • phải làm Information Architecture trước khi vẽ UI

Visual gợi ý

• Cây hậu quả 3 tầng
• Hoặc sơ đồ cause → effect → second-order effect
• Màu sắc nhấn các hậu quả tăng dần

---

Slide 11 — Case Study Introduction

Title

Case Study: Cross-Border E-commerce Order Exception & Refund Console

Nội dung

Giới thiệu bối cảnh:

• Một sàn E-com bán hàng xuyên biên giới
• Đơn hàng có thể gặp:
  • payment failed
  • fraud review
  • out-of-stock
  • customs hold
  • delivery failed
  • refund request
• Mục tiêu hệ thống:
  • cho team vận hành nhìn thấy vấn đề
  • hiểu tại sao đơn bị chặn
  • xử lý đúng action theo state

Visual gợi ý

• Minh họa journey cấp cao:
  • Order placed → Payment → Fulfillment → Shipping → Exception → Resolution
• Có thể dùng timeline ngang

---

Slide 12 — Actors & Entities

Title

Ai tham gia vào hệ thống này, và hệ thống xoay quanh những đối tượng nào?

Nội dung

Actors

• Customer Support Agent
• Operations Lead
• Finance Reviewer
• Warehouse Coordinator
• System

Entities

• Order
• Payment
• Shipment
• Refund
• Exception Case
• Audit Log

Message chính

UI chỉ tốt khi phản ánh đúng:

• ai đang làm
• đang làm với object nào
• ở trạng thái nào

Visual gợi ý

• Bên trái: actor cards
• Bên phải: entity boxes
• Có mũi tên tương tác giữa actors và entities

---

Slide 13 — State Map Overview

Title

Trước khi vẽ UI, phải vẽ State Map

Nội dung

Liệt kê state chính của Order:

• New
• Payment Pending
• Paid
• Fraud Review
• Fulfillment Ready
• Split Shipment
• In Transit
• Customs Hold
• Delivery Failed
• Delivered
• Refund Review
• Refunded
• Cancelled
• Closed

Nhấn mạnh:

• UI không được tách rời state
• mỗi state kéo theo action khác nhau
• cùng một màn hình detail nhưng layout/CTA có thể khác theo state

Visual gợi ý

• State diagram cấp cao
• Có nhánh đặc biệt từ:
  • Fraud Review
  • Customs Hold
  • Refund Review
• Đây nên là visual trung tâm, chiếm nhiều diện tích

---

Slide 14 — Decision Table Thinking

Title

State chưa đủ — phải có Decision Table để chốt rule

Nội dung

Ví dụ rule:

• Nếu payment chưa capture → có thể cancel full
• Nếu risk score > threshold → chuyển Fraud Review
• Nếu refund amount > ngưỡng → escalate Finance
• Nếu order bị lock bởi agent khác → read-only
• Nếu order đổi state khi đang mở → stale data warning

Giải thích:

• State Map cho biết “đang ở đâu”
• Decision Table cho biết “nếu… thì…”

Visual gợi ý

• Một bảng 4–5 dòng mẫu:
  • Condition
  • Action allowed
  • UI response
  • Next state
• Dùng kiểu table enterprise, rõ cột, rõ logic

---

Slide 15 — IA Before UI

Title

Information Architecture phải đi trước Dashboard

Nội dung

Giải thích 3 tầng IA:

1. Monitor — Có gì đang xảy ra?
2. Diagnose — Vấn đề nằm ở đâu?
3. Act — Tôi phải xử lý gì?

Ví dụ áp vào case study:

• Monitor:
  • số đơn đang customs hold
  • số refund pending
  • số case trễ SLA
• Diagnose:
  • breakdown theo quốc gia / warehouse / payment method
• Act:
  • exception queue ưu tiên cao
  • CTA vào detail

Visual gợi ý

• Sơ đồ 3 lớp từ trên xuống dưới
• Có thể làm như funnel ngược:
  • Summary → Analysis → Action
• Màu sắc cấp độ thông tin tăng dần

---

Slide 16 — Dashboard Principles

Title

Nguyên tắc thiết kế Dashboard cho dữ liệu phức tạp

Nội dung

• Dashboard không phải nơi “show tất cả”
• KPI vùng đầu chỉ nên có thông tin quan trọng nhất
• Chart chỉ tồn tại nếu trả lời được câu hỏi nghiệp vụ
• Table rất quan trọng trong B2B
• Mọi summary tốt đều phải dẫn tới:
  • drill-down
  • filter
  • queue
  • detail page

Visual gợi ý

• 5 nguyên tắc trình bày dạng numbered cards
• Có thể thêm 1 mini layout dashboard với callout:
  • KPI strip
  • Alert strip
  • Breakdown chart
  • Exception table

---

Slide 17 — Dashboard Wireframe Anatomy

Title

Anatomy của một Dashboard tốt cho Ops Console

Nội dung

Đề xuất cấu trúc dashboard:

1. Global filters
2. KPI summary
3. Alert / abnormality strip
4. Breakdown visualization
5. Exception queue
6. Drill-down entry points

Mô tả ngắn:

• Filters để đổi góc nhìn
• KPI để monitor
• Alert để ưu tiên
• Breakdown để diagnose
• Queue để act

Visual gợi ý

• 1 wireframe dashboard low-fi chiếm phần lớn slide
• Có đánh số 1–6 trên layout
• Chú thích ngắn từng khu vực

---

Slide 18 — Progressive Disclosure

Title

Dạy người học “nén logic” bằng Progressive Disclosure

Nội dung

Giải thích 4 lớp hiển thị:

• Layer 1: Tóm tắt nhanh
• Layer 2: Danh sách ưu tiên
• Layer 3: Chi tiết theo ngữ cảnh
• Layer 4: Action + validation + audit

Thông điệp:

• không show mọi thứ ngay từ đầu
• user nhìn sâu dần khi thật sự cần
• complexity nằm ở depth, không nằm ở clutter

Visual gợi ý

• 4 lớp dạng step-down
• Hoặc 1 layout zoom-in:
  • dashboard → queue → detail → modal/action
• Đây là slide rất nên có visual rõ ràng

---

Slide 19 — Multi-Branch User Flow

Title

Thiết kế User Flow nhiều rẽ nhánh mà không biến thành “mì spaghetti”

Nội dung

Nguyên tắc vẽ flow:

• tách happy path và exception path
• không vẽ tất cả trên 1 canvas
• luôn phân biệt:
  • manual action
  • system action
  • approval
  • retry
  • terminal state

Khuyến nghị:

• 1 overview flow
• 2–3 flow con cho nhánh phức tạp

Visual gợi ý

• So sánh flow xấu vs flow tốt
• Flow tốt có lane, có decision node, có color semantic nhẹ
• Chỉ ra cách tách nhánh thay vì nhét tất cả vào một sơ đồ

---

Slide 20 — Flow Example from the Case Study

Title

Ví dụ flow: Refund Review với nhiều điều kiện và approval branch

Nội dung

Luồng ví dụ:

1. Agent mở Refund Review
2. Hệ thống kiểm tra eligibility
3. Nếu amount dưới threshold → approve trực tiếp
4. Nếu amount trên threshold → escalate Finance
5. Nếu thiếu customs doc → block action
6. Nếu case locked → read-only
7. Sau submit:
   • success → next state
   • fail → error handling

Visual gợi ý

• Flow chart cụ thể của nhánh refund
• Có 3 decision nodes nổi bật:
  • threshold?
  • missing document?
  • locked by another agent?
• Đây là slide rất quan trọng để nối flow với wireframe

---

Slide 21 — What Makes an Advanced Wireframe

Title

Một Advanced Wireframe phải có gì?

Nội dung

6 lớp bắt buộc:

1. Layout khung
2. State của màn hình
3. Action availability
4. Validation / business rules
5. System feedback
6. Exception / edge cases

Nhấn mạnh:

• wireframe không chỉ trả lời “màn hình trông ra sao”
• mà phải trả lời:
  • “khi nào thấy”
  • “ai thấy”
  • “bấm được khi nào”
  • “bấm xong hệ thống làm gì”

Visual gợi ý

• 1 wireframe detail page ở giữa
• Bao quanh bằng 6 callout tương ứng 6 lớp
• Dạng giải phẫu “anatomy”

---

Slide 22 — Wireframe Set for the Case Study

Title

Bộ màn hình cần có cho case study này

Nội dung

Liệt kê bộ wireframe đề xuất:

• Operations Dashboard
• Exception Queue
• Order Detail Overview
• Refund Review
• Customs Hold Resolution
• Split Shipment Decision
• Audit Log Drawer
• Locked/Read-only State
• Empty/Loading/Error states

Nói rõ:

• đây không phải danh sách “nice to have”
• đây là bộ tối thiểu để chốt logic nghiệp vụ

Visual gợi ý

• Mosaic/tile view 8–9 thumbnail wireframe
• Dạng storyboard hệ thống
• Có nhãn từng frame

---

Slide 23 — Popups, Errors, and Edge Cases

Title

Popup, validation, error state và Edge Cases mới là nơi logic lộ diện

Nội dung

Bắt buộc có:

• Confirm Refund Modal
• Reject Reason Modal
• Escalate to Finance Modal
• Split Shipment Modal
• Lock Conflict Modal
• Unsaved Changes Modal

Error/validation cần thể hiện:

• không đủ quyền
• refund vượt captured amount
• stale data
• API timeout
• thiếu chứng từ
• item bundle không thể tách

Thông điệp:

• màn hình “happy path” thường không đủ để sign-off
• logic thật nằm ở edge cases

Visual gợi ý

• 1 main screen phía sau + các modal chồng lớp
• Kèm cột bên phải liệt kê error states
• Dùng badge đỏ/vàng/xám cho từng loại lỗi/cảnh báo

---

Slide 24 — Annotation & Sign-off

Title

Muốn Stakeholder/Dev chốt được, phải annotate như thế nào?

Nội dung

Giới thiệu cấu trúc annotation:

• ID rule
• Trigger
• Condition
• UI response
• System response
• Next state

Ví dụ:

• R1: refund < threshold → show confirm → submit → Refunded
• R2: refund ≥ threshold → escalate → Pending Finance Review
• R3: locked case → read-only banner → disable action

Kết luận:

• không có annotation logic = chưa đủ để build

Visual gợi ý

• 1 frame wireframe với note numbers
• Bên cạnh là bảng annotation mapping note #1, #2, #3…
• Layout kiểu “wireframe + spec table”

---

Slide 25 — Closing / Assignment

Title

Tổng kết: Từ simple screens đến system thinking

Nội dung

3 takeaways cuối cùng

1. Đừng bắt đầu từ UI — bắt đầu từ state + rule + decision
2. Đừng nhét dữ liệu — hãy làm Information Architecture và Progressive Disclosure
3. Đừng chỉ vẽ frame — hãy tạo Advanced Wireframe đủ để sign-off

Bài tập giao về

Thiết kế 1 package gồm:

• state map
• decision table
• dashboard IA
• flow nhiều nhánh
• bộ wireframe đầy đủ edge cases

Visual gợi ý

• Slide tổng kết dạng “3 nguyên tắc + 1 deliverable package”
• Có thể dùng visual hộp công cụ:
  • State Map
  • Flow
  • Dashboard
  • Wireframe
  • Annotation

---

Gợi ý nhịp thuyết trình của deck

Để deck này nói mạch hơn, bạn nên chia thành 5 chương:

1. Why this matters — Slide 1–4
2. Mindset & framework — Slide 5–10
3. Case study logic — Slide 11–14
4. Dashboard / Flow / Wireframe — Slide 15–24
5. Closing & assignment — Slide 25

---

Nếu muốn, bước tiếp theo tôi có thể làm tiếp một trong 3 hướng sau:

1. Biến outline này thành script thuyết trình cho từng slide
2. Chuyển nó thành nội dung ngắn gọn đúng format đặt vào slide
3. Thiết kế luôn file slide hoàn chỉnh theo phong cách enterprise/B2B