Smart Building Operations Platform

Xây mới hệ thống nền tảng vận hành toà nhà thông minh theo góc nhìn UX/Product Delivery quy mô enterprise (doanh nghiệp lớn), B2B2C, phục vụ quản lý danh mục bất động sản quy mô lớn thay vì một tòa nhà đơn lẻ.

1. PRODUCT CONTEXT (Bối cảnh sản phẩm)

Giai đoạn này giúp xác định sản phẩm là gì, phục vụ ai, quy mô vận hành ra sao và bài toán kinh doanh nào đang cần giải quyết, trước khi đi vào nghiên cứu UX chi tiết.

1.1 Product Context Overview (Tổng quan sản phẩm)

Mục tiêu:

Xác định bức tranh tổng thể của sản phẩm trước khi đi vào nghiên cứu UX, nhằm giúp toàn team thống nhất chính xác sản phẩm đang xây là gì, phục vụ ai, vận hành ở quy mô nào và hệ sinh thái chức năng bao gồm những gì.

Định hướng sản phẩm cấp business (kinh doanh)
Phạm vi giải pháp mà tổ chức muốn xây
Mô hình khách hàng B2B2C
Logic vận hành bất động sản enterprise đa site

Dữ liệu

Product scope (phạm vi sản phẩm)
Primary B2B customers (khách hàng doanh nghiệp chính)
End users (người dùng cuối)
Operational users (người dùng vận hành)
Delivery Surfaces (Các nền tảng triển khai)
Product Ecosystem Architecture (Kiến trúc hệ sinh thái sản phẩm)
System Integrations (Tích hợp hệ thống)

Kết quả

D1 – Product Context Overview (Tổng quan sản phẩm) [Notion / Figma]

Tài liệu này định nghĩa bối cảnh sản phẩm ở cấp hệ thống, làm foundation (nền tảng) cho toàn bộ các bước tiếp theo.

1.2 Business Problem Statement (Mô tả vấn đề kinh doanh)

Mục tiêu

Chuyển bối cảnh sản phẩm từ D1 — Product Context Overview (Tổng quan sản phẩm) thành một bài toán UX/Product rõ ràng bằng cách xác định những friction points (điểm vướng mắc), operational inefficiencies (hiệu quả vận hành thấp) và business risks (các rủi ro kinh doanh) có khả năng xuất hiện trong mô hình vận hành này.

Phạm vi hệ thống đã được xác định ở D1 – Tổng quan sản phẩm
Mức độ phức tạp của workflow đa vai trò
Các pain hypotheses (giả thuyết điểm đau) phổ biến trong vận hành bất động sản enterprise
Kỳ vọng business về khả năng mở rộng, hiệu suất SLA, độ trưởng thành quản trị vận hành và chất lượng trải nghiệm khách hàng

Dữ liệu

Operational pain points (Điểm đau vận hành)
Customer experience pain points (Điểm đau trải nghiệm khách hàng)
Business impact (Tác động kinh doanh)
Operational Metrics (Chỉ số vận hành)
Experience Metrics (Chỉ số trải nghiệm)
Business Metrics (Chỉ số kinh doanh)

Kết quả

D2 – Business Problem Statement (Mô tả vấn đề kinh doanh) [Notion / Figma]

Tài liệu này định nghĩa bài toán kinh doanh và vận hành ở cấp hệ thống, làm nền cho toàn bộ giai đoạn Discovery và UX / Service Design

2. DISCOVERY (Khám phá vấn đề)

Giai đoạn này tập trung kiểm chứng giả thuyết bằng dữ liệu thực tế từ stakeholder (các bên liên quan), người dùng và workflow hiện trạng, nhằm xác định chính xác các friction points (điểm ma sát), operational bottlenecks (nút thắt vận hành) và cơ hội cải thiện trước khi thiết kế giải pháp.

Đây là giai đoạn chuyển từ problem assumptions (giả định vấn đề) sang evidence-based insights (insight dựa trên dữ liệu thực tế).

2.1 Stakeholder Interviews (Phỏng vấn stakeholder)

Mục tiêu

Chuyển bài toán kinh doanh từ D2 — Business Problem Statement (Mô tả vấn đề kinh doanh) thành góc nhìn thực tế từ các bên liên quan đang sở hữu, vận hành hoặc quyết định sản phẩm. Bước này giúp kiểm tra xem các giả thuyết về pain points (điểm đau), rủi ro vận hành và kỳ vọng kinh doanh có đúng với thực tế tổ chức hay không.

Các operational pain points (điểm đau vận hành) đã xác định ở D2
Customer experience risks (rủi ro trải nghiệm khách hàng)
Business expectations (kỳ vọng kinh doanh) về SLA, scalability và operational efficiency

Mục tiêu cuối cùng là thu thập stakeholder perspectives (góc nhìn stakeholder) để tránh thiết kế dựa trên assumption (giả định) một chiều.

Dữ liệu

Resident (Cư Dân)
Dispatcher (Điều Phối Viên)
Technician (Kỹ Thuật Viên)
Chief Experience Officer (Giám đốc trải nghiệm khách hàng)
Head Of Operations (Giám đốc vận hành)
Product Director (Giám đốc sản phẩm)
Regional Operations Manager (Quản lý vận hành khu vực)

Kết quả

D3 – Stakeholder Interview Summary (Tóm tắt phỏng vấn stakeholder) [Notion / FigJam]

Tài liệu này tổng hợp insight chiến lược và vận hành từ các nhóm ra quyết định hoặc trực tiếp tham gia vận hành sản phẩm.

2.2 User Feedback Synthesis (Tổng hợp phản hồi người dùng)

Mục tiêu

Bổ sung góc nhìn thực tế từ end users (người dùng cuối) và operational users (người dùng vận hành) để đối chiếu với stakeholder assumptions (giả định của stakeholder).

Các pain hypotheses (giả thuyết điểm đau) từ D2
Stakeholder concerns (mối quan tâm stakeholder) từ D3
Các hành vi thường thấy trong hệ thống vận hành bất động sản quy mô lớn

Bước này giúp team hiểu bài toán không chỉ ở cấp business, mà còn ở cấp trải nghiệm sử dụng thực tế. Mục tiêu cuối cùng là tìm recurring patterns (mẫu lặp lại) từ trải nghiệm người dùng thật.

Dữ liệu

Feedback Sources (Nguồn phản hồi)
Recurring Feedback Themes (Chủ đề lặp lại)

Kết qủa

D4 – User Feedback Synthesis (Tổng hợp phản hồi người dùng) [FigJam / Notion]

Tài liệu này tổng hợp feedback patterns (mẫu phản hồi) từ nhiều nhóm người dùng.

2.3 Existing Workflow Audit (Đánh giá workflow hiện tại)

Mục tiêu

Xác định current-state workflows (workflow hiện trạng) trong hệ thống vận hành truyền thống hoặc fragmented operations (vận hành phân mảnh) mà sản phẩm mới cần thay thế hoặc tối ưu.

Pain points từ D2
Stakeholder insights từ D3
User feedback patterns từ D4

Mục tiêu cuối cùng là nhìn rõ workflow bottlenecks (nút thắt workflow), manual dependencies (phụ thuộc thủ công) và broken handoffs (bàn giao đứt gãy).

Dữ liệu

Current Incident Handling Workflow (Workflow xử lý sự cố hiện tại)
Observed Operational Issues (Vấn đề quan sát được)

Kết quả

D5 — Existing Workflow Audit (Đánh giá workflow hiện tại) [Miro / Figma]

Tài liệu này mô tả current operational workflows (workflow vận hành hiện tại) trước khi tối ưu.

2.4 Affinity Map (Sơ đồ nhóm insight)

Mục tiêu

Tổng hợp toàn bộ dữ liệu từ stakeholder interviews (phỏng vấn stakeholder), user feedback (phản hồi người dùng) và workflow audit (đánh giá workflow) thành structured insights (insight có cấu trúc).

D3 — Stakeholder Interview Summary
D4 — User Feedback Synthesis
D5 — Existing Workflow Audit

Bước này giúp chuyển dữ liệu thô thành decision-ready themes (nhóm chủ đề sẵn sàng ra quyết định) cho giai đoạn 3. UX/Service Design. Mục tiêu cuối cùng là gom các vấn đề rời rạc thành nhóm insight có ý nghĩa thiết kế.

Dữ liệu

Insight Clusters (Nhóm insight)

Kết quả

D6 – Affinity Map (Sơ đồ nhóm insight) [FigJam / Miro]

Tài liệu này là synthesis artifact (tài liệu tổng hợp insight) quan trọng nhất của Discovery.

3. UX / SERVICE DESIGN

Sau khi tổng hợp đủ insight từ business, người dùng và workflow hiện trạng, giai đoạn này tập trung chuyển dữ liệu nghiên cứu thành service architecture (kiến trúc dịch vụ) và UX workflows để có thể định nghĩa logic vận hành chuẩn cho toàn hệ thống và triển khai thiết kế.

Đây là giai đoạn quan trọng nhất vì sản phẩm không chỉ cần giao diện đẹp, mà phải phản ánh đúng operational reality (thực tế vận hành), role ownership (phân quyền trách nhiệm), SLA logic và exception handling (xử lý ngoại lệ) trong môi trường enterprise đa site.

3.1 Role Matrix (Ma trận vai trò)

Mục tiêu

Chuyển các insight từ giai đoạn Discovery (Khám phá vấn đề) thành cấu trúc ownership (phân quyền trách nhiệm) rõ ràng giữa các nhóm người dùng trong hệ thống, để thiết kế không chỉ dựa trên nhu cầu trải nghiệm mà còn phản ánh đúng mô hình vận hành enterprise thực tế.

D6 – Affinity Map (Sơ đồ nhóm insight) để hiểu các friction points (điểm ma sát), handoff issues (vấn đề bàn giao) và operational bottlenecks (nút thắt vận hành)
D1 – Product context (Bối cảnh sản phẩm) đã xác định từ giai đoạn 1 về mô hình enterprise B2B2C đa vai trò
Operational governance assumptions (Giả định quản trị vận hành) về ownership, SLA accountability và escalation responsibilities

Mục tiêu cuối cùng là xác định rõ: Ai làm gì, chịu trách nhiệm gì, có quyền gì và tương tác với hệ thống như thế nào.

Dữ liệu

Core Roles (Vai Trò Cốt Lõi)
Resident (Cư Dân)
Dispatcher (Điều Phối Viên)
Technician (Kỹ Thuật Viên)
Vendor Technician (Kỹ Thuật Viên Nhà Cung Cấp)
Facility Manager (Quản Lý Vận Hành)
Regional Operations Manager (Quản Lý Vận Hành Khu Vực)
Executive Stakeholders (Nhóm Điều Hành)

Output:

D7 – Role Matrix (Ma trận vai trò) [Figma / FigJam]

Tài liệu này định nghĩa quyền hạn, trách nhiệm và ownership của từng nhóm người dùng.

3.2 Persona Snapshot (Chân dung người dùng rút gọn)

Mục tiêu

Chuyển role definitions (định nghĩa vai trò) thành hành vi người dùng thực tế để thiết kế không chỉ dựa trên business roles (vai trò nghiệp vụ), mà còn dựa trên actual usage patterns (mẫu hành vi sử dụng thực tế).

D6 — Affinity Map (Sơ đồ nhóm insight) để hiểu pain points (điểm đau), frustrations (điểm khó chịu) và behavior signals (tín hiệu hành vi)
D7 — Role Matrix (Ma trận vai trò) để hiểu quyền hạn, trách nhiệm và phạm vi tương tác của từng vai trò
Operational behavior assumptions (Giả định hành vi vận hành) về cách các nhóm người dùng thực tế xử lý công việc trong môi trường áp lực cao

Mục tiêu cuối cùng là hiểu mỗi vai trò: không chỉ “làm gì”, mà còn “làm theo cách nào”, “ra quyết định như thế nào” và “gặp vướng mắc ở đâu”.

Dữ liệu

Role-asymmetric system (hệ thống có vai trò bất đối xứng)

Role	Ảnh hưởng UX	Tần suất tương tác
Resident (cư dân)	Cao	Thấp
Dispatcher (điều phối viên)	Rất cao	Rất cao
Technician (kỹ thuật viên)	Cao	Cao
Facility Manager (quản lý vận hành)	Trung bình	Trung bình

Kết quả

D8 – Persona Snapshot (Chân dung người dùng rút gọn) [Figma]

3.3 Customer Journey Map (Bản đồ hành trình khách hàng)

Mục tiêu

Mô hình hóa end-to-end resident experience (trải nghiệm cư dân đầu-cuối) để nhìn hệ thống từ góc nhìn người dùng cuối thay vì chỉ từ logic vận hành nội bộ.

D6 — Affinity Map (Sơ đồ nhóm insight) để hiểu recurring pain points (các điểm đau lặp lại)
D8 — Persona Snapshot (Chân dung người dùng rút gọn) để hiểu hành vi, kỳ vọng và emotional patterns (mẫu cảm xúc)
Existing resident service assumptions (Giả định trải nghiệm dịch vụ cư dân) trong các hệ thống quản lý bất động sản hiện tại

Mục tiêu cuối cùng là xác định rõ: người dùng đi qua những touchpoints (điểm chạm) nào, cảm thấy gì ở từng giai đoạn, gặp ma sát ở đâu và cơ hội cải thiện trải nghiệm nằm ở đâu.

Dữ liệu

Journey Stages (Các Giai Đoạn)
Pain Points (Điểm Đau)

Kết quả

D9 – Customer Journey Map (Bản đồ hành trình khách hàng) [Figma / Miro]

3.4 Service Blueprint (Bản đồ vận hành dịch vụ)

Mục tiêu

Chuyển hành trình trải nghiệm người dùng thành operational service delivery model (mô hình vận hành cung cấp dịch vụ thực tế) để thiết kế không chỉ đúng UX logic, mà còn đúng thực tế vận hành đa vai trò, đa thiết bị, đa hệ thống).

D7 — Role Matrix (Ma trận vai trò) để hiểu ownership (phân quyền trách nhiệm), access scope (phạm vi truy cập) và role handoffs (bàn giao giữa vai trò)
D8 — Persona Snapshot (Chân dung người dùng rút gọn) để hiểu usage context (ngữ cảnh sử dụng) theo từng thiết bị
D9 — Customer Journey Map (Bản đồ hành trình khách hàng) để hiểu user-facing experience (trải nghiệm phía cư dân)
Platform ecosystem assumptions (Giả định hệ sinh thái nền tảng)
System integration assumptions (Giả định tích hợp hệ thống)

Mục tiêu cuối cùng là xác định rõ: Ai xử lý bước nào, trên thiết bị nào, giao tiếp với ai, thông qua hệ thống nào và exception handling (xử lý ngoại lệ) xảy ra ở đâu.

Dữ liệu

Resident Actions (Hành Động Cư Dân)
Resident-facing Touchpoints (Điểm Chạm Với Cư Dân)
Operations Frontstage (Vận Hành Tuyến Đầu)
Field Operations (Vận Hành Hiện Trường)
Management Oversight (Giám Sát Quản Lý)
Vendor Operations (Vận Hành Nhà Cung Cấp)
Communication Layer (Lớp Giao Tiếp Hệ Thống)
Core Platform Services (Dịch Vụ Nền Tảng)
Enterprise Integrations (Tích Hợp Enterprise) </aside>

Kết quả

D10 – Service Blueprint (Bản đồ vận hành dịch vụ) [Figma / Miro]

3.5 Scenario Mapping (Kịch bản nghiệp vụ)

Mục tiêu

Thiết kế operational exception logic (logic xử lý ngoại lệ vận hành), vì hệ thống enterprise thực tế không chỉ chạy theo happy path (luồng lý tưởng), mà phải xử lý hàng loạt tình huống bất thường.

D10 — Service Blueprint (Bản đồ vận hành dịch vụ) để hiểu luồng vận hành chuẩn
Operational risk assumptions (Giả định rủi ro vận hành) về SLA breaches, unavailable resources, incomplete requests và escalations
Enterprise workflow complexity assumptions (Giả định độ phức tạp workflow enterprise) </aside>

Mục tiêu cuối cùng là xác định rõ: Khi workflow không diễn ra như kỳ vọng, hệ thống và con người phải phản ứng như thế nào.

Dữ liệu

Scenarios (Kịch Bản)

Kết quả

D11 – Scenario Mapping (Kịch bản nghiệp vụ) [Miro / Figma]

3.6 Optimized User Flow (Luồng người dùng tối ưu)

Mục tiêu

Tổng hợp toàn bộ UX logic, service logic, role ownership (phân quyền trách nhiệm) và logic xử lý ngoại lệ thành luồng người dùng mục tiêu đa thiết bị, dùng trực tiếp cho thiết kế và prototype.

D8 — Persona Snapshot (Chân dung người dùng rút gọn) để hiểu usage context (ngữ cảnh sử dụng) theo từng thiết bị
D9 — Customer Journey Map (Bản đồ hành trình khách hàng) để giữ đúng góc nhìn trải nghiệm cư dân
D10 — Service Blueprint (Bản đồ vận hành dịch vụ) để phản ánh đúng operational handoffs (bàn giao vận hành), communication model (mô hình giao tiếp) và supporting systems (hệ thống hỗ trợ)
D11 — Scenario Mapping (Kịch bản nghiệp vụ) để tích hợp exception handling logic (logic xử lý ngoại lệ)
Product ecosystem assumptions (Giả định hệ sinh thái sản phẩm)

Mục tiêu cuối cùng là tạo ra: Một target UX workflow (luồng UX mục tiêu) cân bằng giữa trải nghiệm người dùng, hiệu quả vận hành, khả năng mở rộng enterprise và khả năng triển khai thực tế.

Dữ liệu

Primary Flow

Kết quả

D12 – Optimized User Flow (Luồng người dùng tối ưu) [Figma]

4. DESIGN EXECUTION (Triển khai thiết kế)

Sau khi xác định rõ logic trải nghiệm, vai trò vận hành, service workflows (luồng dịch vụ) và exception scenarios (kịch bản ngoại lệ), giai đoạn này tập trung chuyển toàn bộ solution logic (logic giải pháp) thành thiết kế có thể handoff (bàn giao) cho development team (đội phát triển).

Mục tiêu của giai đoạn này không chỉ là tạo UI đẹp, mà là chuẩn hóa information structure (cấu trúc thông tin), interaction logic (logic tương tác), component consistency (tính nhất quán thành phần giao diện) và UX communication (giao tiếp UX) để đảm bảo khả năng scale của sản phẩm enterprise.

4.1 IA (Kiến trúc thông tin)

Mục tiêu:

Chuyển workflow architecture (kiến trúc workflow), service dependencies (phụ thuộc dịch vụ) và platform ecosystem structure (cấu trúc hệ sinh thái nền tảng) thành conceptual information architecture (kiến trúc thông tin khái niệm), nhằm xác định dữ liệu, chức năng và information domains được tổ chức như thế nào trên toàn ecosystem.

D10 — Service Blueprint (Bản đồ vận hành dịch vụ) để hiểu operational dependencies (phụ thuộc vận hành), system touchpoints (điểm chạm hệ thống) và integrations
D12 — Optimized User Flow (Luồng người dùng tối ưu) để hiểu workflow logic (logic workflow)
D7 — Role Matrix (Ma trận vai trò) để hiểu access scope (phạm vi truy cập) theo vai trò
Product ecosystem assumptions (Giả định hệ sinh thái sản phẩm)

Mục tiêu cuối cùng là xác định: Thông tin nào thuộc domain nào, domain nào dùng chung, domain nào dành riêng cho từng nhóm người dùng và cấu trúc dữ liệu nào sẽ hỗ trợ khả năng scale enterprise.

Dữ liệu

Core Information Domains (Nhóm thông tin cốt lõi)

Kết quả

D13 — IA (Kiến trúc thông tin) [Figma]

4.2 Sitemap (Sơ đồ cấu trúc)

Mục tiêu

Chuyển IA (kiến trúc thông tin) thành screen-level navigation structure (cấu trúc điều hướng cấp màn hình) cho MVP operational surface (bề mặt vận hành MVP), nhằm xác định cách người dùng vận hành chính di chuyển giữa các khu vực chức năng trong hệ thống.

D13 — IA (Kiến trúc thông tin) để hiểu information domains (miền thông tin)
D12 — Optimized User Flow (Luồng người dùng tối ưu) để hiểu workflow transitions (chuyển tiếp workflow)
D7 — Role Matrix (Ma trận vai trò) để xác định primary operational user (người dùng vận hành chính)
MVP scope assumptions (Giả định phạm vi MVP)

Mục tiêu cuối cùng là tạo ra: Một screen hierarchy (cấu trúc màn hình) rõ ràng cho Dispatcher Console (Bảng điều phối), phục vụ wireframe và prototype design.

Dữ liệu

Dispatcher Console Sitemap (Sơ Đồ Cấu Trúc Bảng Điều Phối)

Kết quả

D14 — Sitemap (Sơ đồ cấu trúc) [Figma]

4.3 Wireframe Definition (Định nghĩa wireframe)

Mục tiêu

Chuyển screen hierarchy (cấu trúc màn hình) và workflow logic của MVP operational surface (bề mặt vận hành MVP) thành structural screen layouts (bố cục cấu trúc màn hình), nhằm kiểm tra information density (mật độ thông tin), action placement (vị trí hành động) và workflow efficiency (hiệu quả workflow) trước khi đi vào thiết kế giao diện chi tiết.

D14 — Sitemap (Sơ đồ cấu trúc) để xác định screen hierarchy (cấu trúc màn hình)
D12 — Optimized User Flow (Luồng người dùng tối ưu) để giữ đúng workflow transitions (chuyển tiếp workflow)
D13 — IA (Kiến trúc thông tin) để xác định information grouping (nhóm thông tin)
D8 — Persona Snapshot (Chân dung người dùng rút gọn) để hiểu dispatcher usage context (ngữ cảnh sử dụng của điều phối viên)
MVP scope assumptions (Giả định phạm vi MVP)

Mục tiêu cuối cùng là tạo ra: Một bộ low-fidelity operational wireframes (wireframe vận hành độ trung thực thấp) cho Dispatcher Console, tối ưu cho high-frequency operational workflows (workflow vận hành tần suất cao).

Dữ liệu

Screen 1 — Dispatcher Dashboard
Screen 2 — Incident Queue
Screen 3 — Incident Detail
Screen 4 — Assignment Workspace
Screen 5 — Escalation View
Screen 6 — SLA Monitoring View

Kết quả

D15 — Wireframe Definition (Định nghĩa wireframe) [Figma]

4.4 Prototype Structure (Cấu trúc nguyên mẫu)

Mục tiêu

Chuyển structural wireframes (bố cục wireframe) thành interactive prototype (nguyên mẫu tương tác) và kiểm thử usability (khả năng sử dụng) với representative users (người dùng đại diện), nhằm xác thực interaction logic (logic tương tác), workflow efficiency (hiệu quả workflow) và decision-making clarity (độ rõ hỗ trợ ra quyết định) trước khi business validation và triển khai.

D15 — Wireframe Definition (Định nghĩa wireframe) để kế thừa screen structures (cấu trúc màn hình)
D14 — Sitemap (Sơ đồ cấu trúc) để giữ navigation architecture (kiến trúc điều hướng)
D12 — Optimized User Flow (Luồng người dùng tối ưu) để giữ workflow transitions (chuyển tiếp workflow)
D8 — Persona Snapshot (Chân dung người dùng rút gọn) để phản ánh dispatcher behavioral patterns (mẫu hành vi điều phối viên)

Mục tiêu cuối cùng là tạo ra: Một interactive prototype (nguyên mẫu tương tác) đã được usability validation (kiểm thử usability) đủ thực tế để giảm UX risk trước UAT.

Dữ liệu

Prototype Flows (Luồng nguyên mẫu)
Usability Testing Scope (Phạm vi kiểm tra khả năng sử dụng)

Kết quả

D16 — Prototype Structure (Cấu trúc nguyên mẫu) [Figma Prototype]

4.5 UI Kit / Design System Mini (Bộ giao diện)

Mục tiêu

Chuẩn hóa reusable UI patterns (mẫu giao diện tái sử dụng), interaction rules (quy tắc tương tác) và visual consistency (tính nhất quán hình ảnh) trên toàn bộ ecosystem đa nền tảng, để đảm bảo tốc độ delivery (triển khai), khả năng scale enterprise và consistency giữa mobile + desktop products.

D15 — Wireframe Definition (Định nghĩa wireframe) để hiểu layout requirements (yêu cầu bố cục)
D16 — Prototype Structure (Cấu trúc nguyên mẫu) để hiểu interaction behaviors (hành vi tương tác)
D10 — Service Blueprint (Bản đồ vận hành dịch vụ) để hiểu service states (trạng thái dịch vụ), SLA logic và operational communication needs (nhu cầu giao tiếp vận hành)
Platform ecosystem assumptions (Giả định hệ sinh thái nền tảng)
Existing brand guidelines (Giả định guideline thương hiệu)

Mục tiêu cuối cùng là tạo ra: Một UI foundation (nền tảng giao diện) đủ mạnh để hỗ trợ nhiều products, nhiều roles, nhiều devices trong cùng hệ sinh thái enterprise.

Dữ liệu

Design Tokens (Token Thiết Kế)

Output:

D17 – UI Kit (Bộ giao diện) [Figma]

4.6 UX Writing Spec (Đặc tả nội dung UX)

Mục tiêu

Chuẩn hóa system communication (giao tiếp hệ thống), operational messaging (thông điệp vận hành) và user-facing content behaviors (hành vi nội dung hướng người dùng) trên toàn bộ ecosystem đa nền tảng, nhằm đảm bảo tính rõ ràng, nhất quán và hỗ trợ workflow execution (thực thi workflow) trong môi trường vận hành enterprise.

D10 — Service Blueprint (Bản đồ vận hành dịch vụ) để hiểu communication channels (kênh giao tiếp) và service state transitions (chuyển trạng thái dịch vụ)
D12 — Optimized User Flow (Luồng người dùng tối ưu) để hiểu workflow messaging triggers (điểm kích hoạt thông điệp)
D17 — UI Kit (Bộ giao diện) để đồng bộ component states (trạng thái thành phần giao diện)
D8 — Persona Snapshot (Chân dung người dùng rút gọn) để điều chỉnh tone theo usage context (ngữ cảnh sử dụng)

Mục tiêu cuối cùng là tạo ra: Một communication specification (đặc tả giao tiếp) đủ rõ để nhiều roles, nhiều devices và nhiều channels cùng hoạt động nhất quán trong hệ thống enterprise.

Dữ liệu

Resident-facing Messaging (Thông điệp cho cư dân)
Technician Messaging (Thông Điệp Kỹ Thuật Viên)
Dispatcher Messaging (Thông Điệp Điều Phối)
Management Messaging (Thông Điệp Quản Lý)
System State Messages (Thông Điệp Trạng Thái Hệ Thống)

Kết quả

D18 — UX Writing Spec (Đặc tả nội dung UX) [Notion / Figma]

5. VALIDATION + PRODUCT (Kiểm thử + cải tiến)

Sau khi MVP operational workflows (workflow vận hành MVP) được thiết kế và prototype hóa, giai đoạn này tập trung kiểm chứng khả năng vận hành thực tế, tính usable (dễ sử dụng), độ ổn định workflow và mức độ đáp ứng KPI vận hành trước khi mở rộng product ecosystem (hệ sinh thái sản phẩm).

5.1 UAT Checklist (Danh sách kiểm thử chấp nhận người dùng)

Mục tiêu

Kiểm tra khả năng vận hành thực tế của MVP workflows (workflow MVP) dưới góc nhìn người dùng nghiệp vụ chính, nhằm xác nhận hệ thống hỗ trợ đúng operational execution (thực thi vận hành) trước khi rollout (triển khai).

D14 — Dispatcher Console Sitemap (Sơ đồ cấu trúc bảng điều phối)
D15 — Dispatcher MVP Wireframes (Wireframe MVP điều phối)
D16 — Dispatcher MVP Interactive Prototype (Nguyên mẫu MVP tương tác)
D12 — Optimized User Flow (Luồng người dùng tối ưu)

Mục tiêu cuối cùng là xác nhận: Core workflows có thực thi được trong môi trường vận hành thật hay không.

Validation Scope (Phạm Vi Kiểm Thử)

Dispatcher Workflows
Technician Touchpoints
Resident Confirmation Flow

Output:

D19 — UAT Checklist (Danh sách kiểm thử chấp nhận người dùng)

5.2 UX QA Checklist (Danh sách kiểm UX)

Mục tiêu

Đánh giá usability quality (chất lượng dễ sử dụng), interaction consistency (tính nhất quán tương tác) và communication clarity (độ rõ nội dung UX) trước khi triển khai thực tế.

D16 — Prototype Structure (Cấu trúc nguyên mẫu)
D17 — UI Kit (Bộ giao diện)
D18 — UX Writing Spec (Đặc tả nội dung UX)

Mục tiêu cuối cùng là xác nhận: Trải nghiệm có đủ rõ ràng, dễ thao tác và phù hợp ngữ cảnh vận hành thực tế hay không.

QA Scope

Desktop UX
Mobile UX
Communication UX

Kết quả

D20 — UX QA Checklist (Danh sách kiểm UX)

5.3 Feedback Log (Nhật ký phản hồi)

Mục tiêu

Ghi nhận validation findings (phát hiện kiểm thử), usability issues (vấn đề usability), operational friction (điểm nghẽn vận hành) và communication breakdowns (đứt gãy giao tiếp) theo cấu trúc có thể hành động.

D19
D20
Pilot feedback assumptions (Giả định pilot feedback)

Mục tiêu cuối cùng: Biến raw feedback thành product action items.

Log Structure

Source
User Role
Device
Workflow
Issue
Severity
Recommendation
Status

Kết quả

D21 — Feedback Log (Nhật ký phản hồi)

5.4 Insight Summary (Tóm tắt insight)

Mục tiêu

Tổng hợp recurring patterns (mẫu lặp lại), high-impact UX findings (phát hiện UX ảnh hưởng cao) và operational opportunities (cơ hội cải tiến vận hành) thành product insights.

D21 Feedback Log
Validation observations
KPI assumptions

Mục tiêu cuối cùng: Biến feedback rời rạc thành strategic insights.

Kết quả

D22 — Insight Summary (Tóm tắt insight)

5.5 UX Backlog (Danh sách cải tiến UX)

Mục tiêu

Chuyển insights thành prioritized product improvements (danh sách cải tiến ưu tiên) để product roadmap (lộ trình sản phẩm) có thể thực thi.

D22
Business priorities
MVP constraints

Mục tiêu cuối cùng: Biến insight thành execution backlog.

Backlog Structure

Problem
Proposed Fix
Priority
Impact
Effort
Owner

Kết quả

D23 — UX Backlog (Danh sách cải tiến UX)

5.6 KPI Tracker (Theo dõi KPI)

Mục tiêu

Theo dõi post-validation product performance (hiệu suất sản phẩm sau kiểm thử) để xác nhận MVP có đạt business outcomes (kết quả kinh doanh) và operational outcomes (kết quả vận hành) mong muốn hay không.