Bản đồ công trìnhTờ này lắp: Giao diện app, Màn hình bếp
Bài nàyĐã họcChưa tớiĐã thay thế
Bạn sẽ học được gì
Tiêu chí nghiệm thu
Vì sao phải phác thảo khi AI đã code nhanh như vậy?
Một kiến trúc sư không xây thử ngôi nhà rồi hỏi chủ nhà có thích không. Họ vẽ bản phác, làm mô hình, để chủ nhà đi “trong tưởng tượng” qua từng phòng. Sửa một đường kẻ trên giấy mất vài giây; dời một bức tường đã xây mất vài tuần.
AI làm cho việc “xây” nhanh hơn, nên nhiều người nghĩ có thể bỏ qua bước phác thảo: cứ để agent làm luôn rồi sửa. Nhưng hãy nhớ phần chi phí thật của phần mềm ở bài 03-0403-04: một giao diện đã xây đi kèm database, logic, test, phân quyền. Khi Hà dùng thử và nói “thứ tự ô này ngược với cách em hỏi khách”, sửa ở bản phác là đổi chỗ hai dòng chữ; sửa ở phần mềm thật là đổi form, đổi validate, đổi test, và có thể đổi cả cấu trúc dữ liệu gửi lên máy chủ.
Phác thảo còn giải một vấn đề khác: người dùng không phản hồi tốt với chữ. Đưa Hà đọc spec 4 trang, Hà gật đầu. Đưa Hà một màn hình bấm được, Hà lập tức nói “ơ, thế em xem đơn này cọc chưa ở đâu?”.
User flow: đường đi của người dùng
User flow (luồng người dùng) mô tả các bước một người đi qua để hoàn thành một nhiệm vụ cụ thể: điểm bắt đầu, các màn hình/hành động, các điểm rẽ nhánh (quyết định), và điểm kết thúc — kể cả khi có lỗi. Nó khác với sơ đồ quy trình as-is/to-be ở bài 03-0203-02: quy trình nghiệp vụ nói về con người và công việc; user flow nói về con người tương tác với phần mềm.
Quy tắc vẽ user flow hữu ích:
- Một flow, một nhiệm vụ, một vai trò. “Hà tạo đơn bánh kem từ tin nhắn Zalo” — không phải “quản lý đơn hàng”.
- Bắt đầu từ ngữ cảnh thật, không bắt đầu từ màn hình. Hà không “mở trang tạo đơn” một cách vô cớ; Hà vừa nhận tin nhắn của khách.
- Vẽ cả nhánh lỗi và nhánh ngoại lệ: khách chưa có, đặt quá gấp, cọc chưa đủ.
- Đánh dấu điểm hệ thống phải “nói” gì — thông báo lỗi, xác nhận, tóm tắt.
User flow: Hà tạo đơn bánh kem từ tin nhắn Zalo
- Khách nhắn Zalo đặt bánh kem
- Tìm thấy khách?
- Đủ 24 giờ và trong 07:00–21:00?
- Khách cọc ngay?
- Lưu thành công?
- Báo lỗi, GIỮ dữ liệu form
Xem sơ đồ gốc (Hình 1)
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Khách nhắn Zalo đặt bánh kem → Hà mở ‘Tạo đơn’
- Hà mở ‘Tạo đơn’ → Nhập số điện thoại
- Nhập số điện thoại → Tìm thấy khách?
- Tìm thấy khách? → Hiện tên + 3 đơn gần nhất (Có)
- Tìm thấy khách? → Form khách mới, SĐT điền sẵn (Không)
- Tìm thấy khách? → Nhập số điện thoại (SĐT sai định dạng)
- Hiện tên + 3 đơn gần nhất → Chọn sản phẩm: Bánh kem tùy chỉnh 20cm
- Form khách mới, SĐT điền sẵn → Chọn sản phẩm: Bánh kem tùy chỉnh 20cm
- Chọn sản phẩm: Bánh kem tùy chỉnh 20cm → Chọn vị, nhập chữ trên bánh, ghi chú bếp
- Chọn vị, nhập chữ trên bánh, ghi chú bếp → Chọn nhận tại tiệm/giao hàng, giờ nhận
- Chọn nhận tại tiệm/giao hàng, giờ nhận → Đủ 24 giờ và trong 07:00–21:00?
- Đủ 24 giờ và trong 07:00–21:00? → Báo lỗi: cần quản lý tạo đơn gấp (Không)
- Báo lỗi: cần quản lý tạo đơn gấp → Hà nhắn quản lý / đổi giờ với khách
- Hà nhắn quản lý / đổi giờ với khách → Chọn nhận tại tiệm/giao hàng, giờ nhận
- Đủ 24 giờ và trong 07:00–21:00? → Khách cọc ngay? (Có)
- Khách cọc ngay? → Ghi số tiền, phương thức, mã giao dịch (Có)
- Khách cọc ngay? → Bỏ qua, trạng thái thanh toán: unpaid (Chưa)
- Ghi số tiền, phương thức, mã giao dịch → Xem tóm tắt: tổng, đã cọc, còn lại
- Bỏ qua, trạng thái thanh toán: unpaid → Xem tóm tắt: tổng, đã cọc, còn lại
- Xem tóm tắt: tổng, đã cọc, còn lại → Bấm ‘Tạo đơn’
- Bấm ‘Tạo đơn’ → Lưu thành công?
- Lưu thành công? → Báo lỗi, GIỮ dữ liệu form (Mất kết nối)
- Báo lỗi, GIỮ dữ liệu form → Bấm ‘Tạo đơn’
- Lưu thành công? → Hiện mã BM-YYMMDD-XXX + ‘Sao chép tóm tắt’ (Thành công)
- Hiện mã BM-YYMMDD-XXX + ‘Sao chép tóm tắt’ → Hà dán tóm tắt gửi khách xác nhận
Vẽ xong, bạn sẽ thấy ngay vài câu hỏi thiết kế mà spec chữ dễ bỏ sót. Ví dụ: ở bước J, Hà “nhắn quản lý” bằng cách nào — ngoài hệ thống? Có nên cho Hà lưu đơn dạng nháp để quản lý duyệt không? Chị Lan quyết định không (đưa vào non-goals của MVP), nhưng giờ đó là quyết định có ý thức chứ không phải điều bị quên.
Sơ đồ màn hình: sản phẩm có những màn hình nào
Nếu user flow là “một chuyến đi”, thì sơ đồ màn hình (screen map, đôi khi gọi là site map) là “bản đồ thành phố”: tất cả các màn hình và đường nối giữa chúng, thường kèm ai được vào đâu. Nó giúp bạn kiểm tra hai điều: không thiếu màn hình nào cho các user story, và không có màn hình “mồ côi” mà không ai tới được.
Vuốt ngang để xem hết sơ đồ
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Đăng nhập → Theo vai trò
- Theo vai trò → Danh sách đơn (lọc ngày, trạng thái) (staff, manager)
- Theo vai trò → Dashboard đơn hôm nay (owner)
- Theo vai trò → Màn hình bếp (theo chuyến xe) (manager bếp)
- Dashboard đơn hôm nay → Danh sách đơn (lọc ngày, trạng thái)
- Danh sách đơn (lọc ngày, trạng thái) → Tạo đơn
- Danh sách đơn (lọc ngày, trạng thái) → Chi tiết đơn
- Tạo đơn → Tạo thành công + tóm tắt
- Tạo thành công + tóm tắt → Chi tiết đơn
- Chi tiết đơn → Sửa đơn
- Chi tiết đơn → Ghi nhận thanh toán
- Chi tiết đơn → Hủy đơn (có lý do)
- Danh sách đơn (lọc ngày, trạng thái) → Khách hàng (tìm theo SĐT)
- Khách hàng (tìm theo SĐT) → Chi tiết khách + lịch sử mua
- Chi tiết khách + lịch sử mua → Tạo đơn
- Màn hình bếp (theo chuyến xe) → Chi tiết đơn
Đối chiếu với 6 user story ở bài 03-0503-05: US-01 → Tạo đơn; US-02 → Tạo đơn và Khách hàng; US-03 → Ghi nhận thanh toán; US-04 → Màn hình bếp; US-05 → Hủy đơn; US-06 → Dashboard. Không thiếu story nào; và có một đường nối đáng giá vừa xuất hiện: từ “Chi tiết khách” sang “Tạo đơn” — chính là “đặt lại như lần trước” mà khách quen hay yêu cầu.
Wireframe: lo-fi và hi-fi
Wireframe (khung màn hình) là bản phác bố cục một màn hình: có những khối nào, nằm ở đâu, thứ tự ra sao — chưa quan tâm màu sắc, font chữ, hình ảnh. Giống bản vẽ mặt bằng căn nhà: phòng khách ở đâu, cửa sổ hướng nào, chứ chưa chọn màu sơn.
| Mức độ | Hình thức | Thời gian | Dùng khi | Rủi ro |
|---|---|---|---|---|
| Lo-fi (độ trung thực thấp) | Giấy bút, bảng trắng, văn bản/ASCII | Vài phút | Khám phá bố cục, thứ tự thông tin; thảo luận với người dùng | Khó hình dung trên thiết bị thật |
| Mid-fi | Công cụ wireframe (Excalidraw, Figma, Balsamiq… tại thời điểm viết), khối xám | Vài giờ | Chốt bố cục nhiều màn hình, chia sẻ với team | Bắt đầu tốn công sửa |
| Hi-fi (độ trung thực cao) | Mockup có màu, font, component thật | Vài giờ đến vài ngày | Kiểm tra cảm nhận thị giác, chuẩn bị cho code | Người xem góp ý màu sắc thay vì luồng |
| Prototype bấm được | HTML tĩnh hoặc công cụ thiết kế có liên kết | Vài giờ với AI | Thử nghiệm với người dùng thật | Bị nhầm là “gần xong” |
Một nguyên tắc dễ nhớ: độ trung thực càng thấp, góp ý càng về cấu trúc; độ trung thực càng cao, góp ý càng về bề mặt. Khi bạn còn đang hỏi “Hà có cần thấy lịch sử mua ngay trên form tạo đơn không?”, đừng mất thời gian chọn màu nút.
Wireframe ASCII: màn hình “Tạo đơn” (laptop ở quầy)
Thứ tự các khối theo đúng mẫu tin nhắn Hà vẫn dùng (phát hiện ở bài 03-02): Khách → Sản phẩm → Nhận hàng → Thanh toán; khối Tóm tắt luôn nằm bên phải.
Điền ô trống rồi sao chép
+--------------------------------------------------------------------------------------+
| MỘC OMS Đơn hàng | Khách hàng | Bếp Hà (staff) · Phú Nhuận ▾ |
+--------------------------------------------------------------------------------------+
| < Danh sách đơn TẠO ĐƠN MỚI |
+----------------------------------------------------------+---------------------------+
| 1. KHÁCH HÀNG | TÓM TẮT |
| SĐT [ 0901 234 567 ] [Tìm] | Khách: Trần Thị B |
| ✓ Trần Thị B · 3 đơn gần nhất: 12/09 BK 20cm socola ... | Kênh: Zalo |
| | ------------------------- |
| 2. SẢN PHẨM | BK tùy chỉnh 20cm 450.000|
| [Bánh kem tùy chỉnh 20cm ▾] SL [1] 450.000đ | Bánh quy hộp x2 240.000|
| Vị [Chanh dây ▾] | ------------------------- |
| Chữ [Mừng sinh nhật Mẹ Ánh ] 21/40 | Tạm tính 690.000 |
| ( ) Không chữ | Phí giao 0 |
| Ghi chú bếp [ít ngọt ] | TỔNG 690.000 |
| [+ Thêm sản phẩm] | Đã cọc 345.000 |
| | CÒN LẠI 345.000 |
| 3. NHẬN HÀNG | |
| (•) Nhận tại tiệm [Phú Nhuận ▾] ( ) Giao hàng | [ TẠO ĐƠN ] |
| Giờ nhận [13/10/2026] [17:00] | |
| Kênh [Zalo ▾] Ghi chú đơn [ ] | |
| | |
| 4. THANH TOÁN (tùy chọn) | |
| Cọc [ 345.000 ] Phương thức [Chuyển khoản ▾] | |
| Mã giao dịch [ FT2610121234 ] | |
+----------------------------------------------------------+---------------------------+Wireframe ASCII: màn hình bếp (máy tính bảng, xoay ngang)
Từ shadowing bếp, chị Lan biết anh Tuấn đứng cách màn hình khoảng một mét, tay thường dính bột: chữ phải to, nút phải lớn, nhóm theo chuyến xe.
Điền ô trống rồi sao chép
+----------------------------------------------------------------------+
| BẾP TRUNG TÂM · Thứ Ba 13/10/2026 Cập nhật 05:42 [Tải lại]|
+----------------------------------------------------------------------+
| CHUYẾN 07:30 (giờ nhận trước 15:00) 3 bánh · 1 đang làm |
|----------------------------------------------------------------------|
| 10:00 Gò Vấp BK 20cm · Chanh dây [ĐANG LÀM] |
| "Mừng sinh nhật Mẹ Ánh" BM-261012-003 |
|----------------------------------------------------------------------|
| 11:30 Thảo Điền BK 16cm · Socola · ít ngọt [BẮT ĐẦU] |
| "Happy Birthday Bin" BM-261012-015 |
|----------------------------------------------------------------------|
| 14:30 Phú Nhuận BK 24cm · Dâu tây [BẮT ĐẦU] |
| (Không chữ) BM-261012-021 |
|----------------------------------------------------------------------|
| ~~12:00 Gò Vấp BK 20cm · Matcha~~ ĐÃ HỦY |
+----------------------------------------------------------------------+
| CHUYẾN 13:00 (giờ nhận từ 15:00) 3 bánh · 0 đang làm |
|----------------------------------------------------------------------|
| 17:00 Phú Nhuận BK 20cm · Chanh dây [BẮT ĐẦU] |
| "Chúc mừng 10 năm ngày cưới" BM-261012-030 |
| ... |
+----------------------------------------------------------------------+Chú ý những quyết định nhỏ đã nằm sẵn trong wireframe: chữ trên bánh đặt trong ngoặc kép trên dòng riêng (để thợ chép đúng từng ký tự), “(Không chữ)” hiển thị tường minh thay vì để trống (để không ai nghĩ là quên), đơn hủy gạch ngang thay vì biến mất (đúng tiêu chí ở US-04). Mỗi quyết định như vậy sẽ được ghi vào spec màn hình bếp.
Prototype nhanh bằng AI
Prototype (bản mẫu) là phiên bản có thể tương tác được — bấm nút, chuyển màn hình, nhập thử — nhưng không có hệ thống thật phía sau. Trước đây, làm prototype bấm được cần designer và công cụ chuyên dụng. Bây giờ, bạn có thể đưa user flow và wireframe ASCII cho AI và nhận về một file HTML tĩnh chạy được trên trình duyệt trong vài phút.
Cách làm gọn:
- Đầu vào: user flow (Mermaid), wireframe ASCII, vài quy tắc chính (chữ tối đa 40 ký tự, đủ 24 giờ), dữ liệu giả.
- Ràng buộc rõ: một file HTML duy nhất, không backend, không đăng nhập, dữ liệu giả cứng trong file, không gọi API ngoài.
- Mục tiêu rõ: đủ để người dùng làm được 3 nhiệm vụ thử nghiệm; không cần đẹp.
- Lưu riêng: đặt trong thư mục
prototypes/hoặc repo riêng, không trongsrc/.
Khi nào dùng công cụ tạo app tự động (app builder) thay vì HTML tĩnh? Khi bạn cần prototype trông rất giống thật, có nhiều màn hình. Bản đồ các loại công cụ ở bài 02-0302-03. Nguyên tắc vứt đi vẫn giữ nguyên.
Thử nghiệm với 3–5 người dùng
Bạn không cần 50 người để tìm ra vấn đề của một màn hình. Các nhà nghiên cứu khả dụng (như Nielsen Norman Group) từ lâu đã khuyến nghị thử với khoảng 5 người mỗi vòng: vài người đầu tiên đã lộ ra phần lớn vấn đề lớn, người thứ 6, thứ 7 chủ yếu lặp lại điều bạn đã thấy. Tốt hơn là thử nhiều vòng nhỏ — sửa — thử lại, thay vì một vòng lớn.
Với phần mềm nội bộ, “5 người” thường là gần như toàn bộ người dùng của một vai trò. Hãy chọn người thật sẽ dùng: Hà, hai nhân viên quầy, anh Tuấn, một thợ bánh.
Kịch bản buổi thử (20–30 phút mỗi người)
Vuốt ngang để xem hết sơ đồ
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Chuẩn bị: 3 nhiệm vụ, dữ liệu giả, phiếu ghi chép → Giới thiệu: ‘Mình thử phần mềm, không thử bạn’
- Giới thiệu: ‘Mình thử phần mềm, không thử bạn’ → Giao từng nhiệm vụ, người dùng nghĩ to thành lời
- Giao từng nhiệm vụ, người dùng nghĩ to thành lời → Quan sát, ghi chép, KHÔNG giúp đỡ
- Quan sát, ghi chép, KHÔNG giúp đỡ → Hỏi sau mỗi nhiệm vụ: chỗ nào khó, bất ngờ?
- Hỏi sau mỗi nhiệm vụ: chỗ nào khó, bất ngờ? → Tổng hợp: vấn đề + mức nghiêm trọng
- Tổng hợp: vấn đề + mức nghiêm trọng → Cập nhật wireframe/spec, thử vòng tiếp
Nhiệm vụ phải giống tình huống thật, không chỉ dẫn từng bước. Đừng nói “bấm nút Thêm sản phẩm rồi chọn vị”. Hãy nói:
- Nhiệm vụ 1: “Khách số 0901 234 567 vừa nhắn: ‘Em đặt bánh 20cm vị chanh dây, ghi Mừng sinh nhật Mẹ Ánh, 5 giờ chiều mai lấy ở Phú Nhuận, chị chuyển cọc 300 nghìn rồi nhé.’ Em ghi đơn này.”
- Nhiệm vụ 2: “Một khách mới gọi điện, đặt bánh cho 8 giờ sáng mai.” (Kiểm tra người dùng hiểu thông báo 24 giờ không.)
- Nhiệm vụ 3 (bếp): “Anh xem sáng nay chuyến 7:30 có bao nhiêu bánh chưa làm.”
Ghi chép theo bảng đơn giản:
| Người | Nhiệm vụ | Hoàn thành? | Thời gian | Chỗ vấp / câu nói nguyên văn | Mức nghiêm trọng |
|---|---|---|---|---|---|
| Hà | 1 | Có | 1 phút 40 giây | “Ô cọc ở cuối, em cứ tìm ở trên” | Vừa |
| Quầy PN | 2 | Có, sau 2 lần thử | 2 phút 10 giây | Không hiểu “đơn gấp” là gì | Cao |
| Anh Tuấn | 3 | Có | 15 giây | “Chữ nhỏ quá, anh phải cúi xuống” | Cao |
Mức nghiêm trọng gợi ý: Cao — chặn nhiệm vụ hoặc dẫn tới sai bánh/sai tiền; Vừa — làm chậm, gây bối rối nhưng vẫn xong; Thấp — khó chịu nhỏ, thẩm mỹ.
Áp dụng vào dự án Bánh Mộc
Nhật ký công trình · Bánh Mộc
BM-261013-029
13.10.2026
- Chị LanChủ chuỗi
- HàBán hàng online
Chị Lan dành một tuần cho bước này, ngay sau khi spec “Tạo đơn hàng” được duyệt.
Ngày 1 — flow và sơ đồ màn hình. Chị vẽ user flow tạo đơn và sơ đồ màn hình bằng Mermaid, nhờ AI rà xem có user story nào chưa có màn hình. AI phát hiện thiếu một lối từ màn hình bếp sang chi tiết đơn (khi thợ cần xem ghi chú dài) — chị thêm vào.
Ngày 2 — wireframe ASCII. Chị phác wireframe “Tạo đơn” và “Màn hình bếp” bằng văn bản ngay trong file spec. Lần đầu tiên, chị cảm thấy mình “thiết kế” được mà không cần biết dùng công cụ đồ họa.
Ngày 3 — prototype. Chị dùng Prompt 2 bên dưới để agent dựng một file prototypes/tao-don.html và prototypes/bep.html với dữ liệu giả. Mất khoảng một giờ, kể cả hai lần sửa.
Ngày 4–5 — thử với 5 người. Kết quả có ba phát hiện mức “Cao”:
- Nhân viên quầy Phú Nhuận không hiểu chữ “đơn gấp” trong thông báo lỗi. Chị đổi thành câu nói rõ hậu quả và cách xử lý: “Bánh kem tùy chỉnh cần đặt trước ít nhất 24 giờ. Liên hệ quản lý để tạo đơn gấp.” — đúng như bản spec 1.1.
- Anh Tuấn phải cúi xuống mới đọc được chữ trên bánh trên máy tính bảng. Spec màn hình bếp thêm yêu cầu: chữ trên bánh hiển thị cỡ lớn, đậm, trong ngoặc kép, đọc được từ khoảng một mét.
- Thợ bánh hỏi: “Bánh xong rồi thì bấm ở đâu?” Prototype chỉ có nút “Bắt đầu”. Chị bổ sung nút “Xong” và trạng thái tương ứng vào câu hỏi mở của spec màn hình bếp, vì nó liên quan tới quy trình chuyển trạng thái
dang_lam→dang_giao.
Phát hiện mức “Vừa”: Hà muốn khối Thanh toán nằm cao hơn vì khách thường nói chuyện cọc ngay từ đầu. Chị quyết định giữ thứ tự nhưng cho khối Tóm tắt bên phải luôn hiển thị “Đã cọc / Còn lại” — một thỏa hiệp được Hà đồng ý ở vòng thử thứ hai.
Sau một tuần, hai file prototype được lưu lại như tài liệu tham khảo, wireframe ASCII nằm trong spec, và không dòng code prototype nào đi vào src/.
Prompt mẫu
Prompt 1 — Từ user story sang user flow và sơ đồ màn hình
Điền ô trống rồi sao chép
Đây là các user story và quy tắc nghiệp vụ của Mộc OMS:
"""[dán US-01…US-06 và bảng QT]"""
1. Vẽ user flow (Mermaid flowchart TD, nhãn tiếng Việt trong ngoặc kép) cho nhiệm vụ:
"Hà tạo đơn bánh kem từ tin nhắn Zalo". Bắt đầu từ ngữ cảnh thật (khách nhắn tin),
có nhánh: khách chưa có, SĐT sai, đặt quá gấp, cọc/không cọc, mất kết nối khi lưu.
2. Vẽ sơ đồ màn hình (Mermaid flowchart LR) cho toàn bộ MVP, ghi vai trò nào vào được màn hình nào.
3. Lập bảng đối chiếu: mỗi user story -> các màn hình liên quan. Chỉ ra story chưa có màn hình
và màn hình không phục vụ story nào.Prompt 2 — Prototype HTML tĩnh để thử với người dùng
Điền ô trống rồi sao chép
Tạo prototype để THỬ NGHIỆM VỚI NGƯỜI DÙNG, không phải sản phẩm thật.
Ràng buộc:
- Một file duy nhất prototypes/tao-don.html; HTML + CSS + JavaScript thuần, không thư viện ngoài, không backend,
không gọi API, không lưu dữ liệu thật. Dữ liệu giả (3 khách, 6 sản phẩm) viết cứng trong file.
- Giao diện tiếng Việt, theo đúng bố cục wireframe ASCII dưới đây.
- Mô phỏng các quy tắc: chữ trên bánh tối đa 40 ký tự có bộ đếm; báo lỗi khi giờ nhận cách hiện tại dưới 24 giờ;
tóm tắt tự tính tổng, đã cọc, còn lại; bấm "Tạo đơn" hiện mã giả dạng BM-YYMMDD-XXX.
- Không cần đẹp; chữ đủ lớn, dùng được trên laptop và máy tính bảng.
Wireframe: """[dán wireframe ASCII]"""
User flow: """[dán Mermaid]"""
Sau khi tạo, liệt kê những gì prototype KHÔNG mô phỏng để tôi biết giới hạn khi thử nghiệm.Prompt 3 — Chuẩn bị và tổng hợp buổi thử nghiệm
Điền ô trống rồi sao chép
Tôi sẽ thử prototype với 5 người: 1 nhân viên bán hàng online, 2 nhân viên quầy, 1 quản lý bếp, 1 thợ bánh.
1. Viết 3 nhiệm vụ cho mỗi vai trò, dạng tình huống thật (không chỉ dẫn từng bước bấm nút).
2. Viết lời giới thiệu 4–5 câu cho đầu buổi, nhấn mạnh "đang thử phần mềm, không thử bạn" và xin phép ghi chép.
3. Sau buổi thử, tôi sẽ dán ghi chép (đã ẩn danh). Khi đó hãy gom thành danh sách vấn đề, mỗi vấn đề có:
mô tả, số người gặp (x/5), trích dẫn nguyên văn, mức nghiêm trọng (Cao/Vừa/Thấp), đề xuất sửa,
và mục nào trong spec cần cập nhật.Sai lầm thường gặp
-
Sự cố 01
Bỏ qua phác thảo vì “AI code nhanh”.
Triệu chứng*
Cách tránh* nhớ rằng sửa giao diện đã xây kéo theo sửa logic, test, dữ liệu; luôn có ít nhất wireframe lo-fi được người dùng xem trước.
-
Sự cố 02
User flow chỉ có luồng suôn sẻ.
Triệu chứng*
Cách tránh* với mỗi điểm quyết định, hỏi “nếu không thì sao?”; vẽ cả nhánh lỗi mạng, thiếu quyền, dữ liệu sai.
-
Sự cố 03
Hi-fi quá sớm.
Triệu chứngNgười dùng góp ý màu sắc thay vì luồng. *
Cách tránh* đi từ lo-fi; chỉ lên hi-fi khi bố cục và luồng đã ổn.
-
Sự cố 04
Biến prototype thành sản phẩm.
Triệu chứng*
Cách tránh* prototype ở thư mục riêng, ghi rõ “để vứt đi”; sản phẩm thật xây lại từ spec theo quy trình chuẩn.
-
Sự cố 05
Giúp người dùng trong buổi thử.
Triệu chứng*
Cách tránh* giao nhiệm vụ dạng tình huống, ngồi im, chỉ hỏi “bạn đang tìm gì?”; giải thích để sau buổi.
-
Sự cố 06
Thử với người không phải người dùng thật.
Triệu chứngHỏi bạn bè, người nhà thay vì nhân viên. *
Cách tránh* với phần mềm nội bộ, luôn thử với người sẽ dùng hằng ngày, trên thiết bị họ sẽ dùng.
Checklist
Bài tập thực hành
-
Bài 1
Cơ bản
User flow có nhánh lỗi
Chọn một nhiệm vụ trong sản phẩm của bạn, vẽ user flow bằng Mermaid với ít nhất 3 điểm quyết định và 2 nhánh lỗi.
Kết quả mong đợi
sơ đồ hiển thị được, bắt đầu từ ngữ cảnh thật, kết thúc ở cả trạng thái thành công lẫn thất bại có hướng xử lý.
-
Bài 2
Cơ bản
Wireframe ASCII
Phác wireframe ASCII cho màn hình quan trọng nhất, rồi phác lại cho thiết bị thứ hai (ví dụ điện thoại).
Kết quả mong đợi
hai bản phác cho thấy rõ những gì được giữ, ẩn hoặc sắp xếp lại trên màn hình nhỏ; các trạng thái quan trọng (rỗng, lỗi) được ghi chú.
-
Bài 3
Nâng cao
Prototype và thử nghiệm
Dùng Prompt 2 dựng prototype, thử với ít nhất 3 người dùng thật bằng nhiệm vụ dạng tình huống.
Kết quả mong đợi
bảng ghi chép theo mẫu, ít nhất 3 vấn đề có mức nghiêm trọng, và spec được cập nhật (tăng phiên bản, ghi lịch sử thay đổi) theo những phát hiện đó.
Thuật ngữ trong bài
- User flow
- Đường đi của người dùng qua các bước và quyết định để hoàn thành một nhiệm vụ.
- Sơ đồ màn hình (screen map)
- Bản đồ tất cả màn hình của sản phẩm và cách đi giữa chúng.
- Wireframe
- Bản phác bố cục một màn hình, chưa có màu sắc, hình ảnh.
- Lo-fi / hi-fi
- Độ trung thực thấp (phác thô) / cao (gần giống sản phẩm thật).
- Mockup
- Bản thiết kế tĩnh có màu, font, gần với giao diện cuối.
- Prototype
- Bản mẫu bấm được, mô phỏng tương tác, không có hệ thống thật phía sau.
- Thử nghiệm khả dụng (usability test)
- Quan sát người dùng thật làm nhiệm vụ trên sản phẩm/bản mẫu để tìm vấn đề.
- Nghĩ to thành lời (think-aloud)
- Người thử nói ra điều họ đang nghĩ khi thao tác.
- Mức nghiêm trọng
- Phân loại vấn đề theo hậu quả: cao, vừa, thấp.
Đọc thêm
Nghiệm thu tờ 03-07
Đọc xong và tự kiểm theo phiếu nghiệm thu, rồi đánh dấu tờ này.
