State-Based Design trong UI (thiết kế giao diện theo trạng thái) là cách quy định giao diện hiển thị và hoạt động thế nào khi người dùng thao tác hoặc hệ thống có thay đổi. Ví dụ, biểu mẫu tư vấn có lúc đang nhập, báo thiếu thông tin, đang gửi, đã tiếp nhận hoặc gửi thất bại. Mỗi trạng thái cần có thông báo và hành động phù hợp.
Chủ doanh nghiệp cần nhớ: Nút “Gửi” đẹp chưa đủ. Phải biết khách nhập sai sẽ thấy gì, khi chờ có bấm gửi trùng được không, mất mạng có mất dữ liệu không và khi nào hệ thống thực sự xác nhận đã nhận yêu cầu. Hãy nghiệm thu cả tình huống gặp lỗi, không chỉ trường hợp mọi thứ diễn ra bình thường.
Ví dụ dễ hiểu: Một biểu mẫu tư vấn có những trạng thái nào?
Ví dụ giả định để giải thích quy trình, không phải kết quả kiểm thử trên websitehcm.com: Khách mở trang dịch vụ, điền tên và số điện thoại rồi gửi yêu cầu. Chỉ cần một hành động này đã có nhiều tình huống cần thiết kế:
- Đang nhập: nhãn trường và nút gửi dễ hiểu, dữ liệu đang nhập được giữ lại.
- Thiếu hoặc sai thông tin: chỉ rõ trường cần sửa bằng chữ, không chỉ đổi màu đỏ.
- Đang gửi: hiển thị “Đang gửi…”, hạn chế gửi lặp và cho biết hệ thống vẫn xử lý.
- Đã tiếp nhận: chỉ báo thành công khi máy chủ xác nhận đã lưu hoặc tiếp nhận hợp lệ; có thể nêu bước tiếp theo.
- Gửi không thành công: nêu rõ chưa hoàn tất, giữ dữ liệu phù hợp và cho thử lại hoặc liên hệ bằng cách khác.
- Kết quả chưa rõ: khi mất mạng sau khi gửi, có thể chưa biết máy chủ đã nhận hay chưa; đừng tự hiển thị thất bại tuyệt đối hoặc gửi lại vô hạn gây trùng.
Đặc biệt, khách bấm nút không có nghĩa doanh nghiệp đã nhận yêu cầu. Khi kết nối gián đoạn, cần có cách kiểm tra trạng thái hoặc mã tham chiếu nếu hệ thống hỗ trợ. Việc tránh tạo hai yêu cầu trùng phải được kiểm soát phù hợp ở hệ thống phía sau, không chỉ khóa nút trên màn hình.
Trạng thái, sự kiện và chuyển đổi là gì?
Có thể mô tả một giao diện bằng chuỗi: đang ở trạng thái nào → điều gì xảy ra → có đủ điều kiện không → chuyển sang trạng thái nào → thông báo và khắc phục ra sao. Đây là cách trình bày các khái niệm state, event, guard và transition bằng tiếng Việt.
- Trạng thái (state): tình huống hiện tại của giao diện hoặc quy trình, như “đang nhập”, “đang gửi”, “thành công”.
- Sự kiện (event): điều vừa xảy ra, như khách bấm gửi, máy chủ phản hồi hoặc kết nối bị mất.
- Điều kiện (guard): quy tắc phải đúng mới được chuyển, ví dụ dữ liệu hợp lệ và chưa có yêu cầu cùng loại đang xử lý.
- Chuyển trạng thái (transition): đi từ tình huống trước sang tình huống sau khi một sự kiện được xử lý.
- Dữ liệu và hành động: nội dung khách đã nhập, việc gửi lên hệ thống, lưu nháp hay cập nhật thông báo.
- Cách khắc phục: sửa dữ liệu, thử lại, đăng nhập lại hoặc liên hệ hỗ trợ.
Đội kỹ thuật có thể dùng sơ đồ hoặc bảng để mô tả. Tài liệu Stately về trạng thái và chuyển đổi giải thích cách mô hình hóa này. Với biểu mẫu đơn giản, mô tả rõ bằng vài bước cũng được; không bắt buộc mua thêm phần mềm.
Các nhóm trạng thái thường gặp trong website và ứng dụng
- Tương tác: nút bình thường, được chọn, đang có tiêu điểm bàn phím (focus), được bấm hoặc không thể sử dụng.
- Kiểm tra dữ liệu: chưa nhập, hợp lệ, thiếu thông tin hoặc cần sửa lỗi.
- Chờ hệ thống: đang tải lần đầu, đang làm mới, đã có kết quả hoặc yêu cầu bị lỗi.
- Dữ liệu: chưa có bản ghi, không có kết quả phù hợp, có dữ liệu hoặc dữ liệu cũ chưa được làm mới.
- Quyền truy cập: chưa đăng nhập, chỉ được xem, đủ quyền thực hiện hoặc hết phiên đăng nhập.
- Kết nối và công việc: mất mạng, đang nối lại, bản nháp, chờ duyệt, hoàn tất hoặc bị từ chối.
Các nhóm có thể diễn ra đồng thời. Chẳng hạn biểu mẫu đang nhập dở mà điện thoại mất mạng. Không nhất thiết vẽ một màn hình riêng cho mọi tổ hợp; cần chỉ rõ những tổ hợp ảnh hưởng đến việc khách có thể làm gì và thông báo nào phải xuất hiện.
Hover, Active và Focus khác nhau thế nào?
- Hover: hiệu ứng khi con trỏ chuột đi qua; điện thoại không nên phải dựa vào hover mới thao tác được.
- Active/pressed: phản hồi trong lúc người dùng nhấn; không đồng nghĩa giao dịch đã hoàn tất.
- Focus: vị trí đang nhận thao tác bằng bàn phím. Dấu hiệu focus phải thấy được để biết đang ở nút, liên kết hay ô nhập nào.
- Disabled: thành phần tạm không thực hiện được hành động. Khi người dùng cần biết lý do, nên giải thích điều kiện; không chỉ làm nút mờ.
Theo tiêu chí Focus Visible của W3C, người dùng bàn phím cần biết phần tử nào đang được chọn. Không được xóa dấu hiệu focus chỉ vì không hợp màu giao diện. Khi làm nút liên hệ, tham khảo cách thiết kế nút kêu gọi hành động để đồng bộ trạng thái với hành động thực tế.
Cách lập bảng chuyển trạng thái cho biểu mẫu tư vấn
Đội thiết kế và lập trình nên thống nhất trước mỗi tình huống: đang ở đâu, điều gì xảy ra, điều kiện cần có, kết quả thật của hệ thống và lời thông báo cho khách. Ví dụ:
- Khách bấm gửi nhưng thiếu số điện thoại: từ “đang nhập” sang “cần sửa”; nêu “Vui lòng nhập số điện thoại”, giữ các dữ liệu còn lại.
- Dữ liệu hợp lệ và khách gửi: sang “đang xử lý”; hiển thị chờ, hạn chế thao tác lặp và chuyển yêu cầu cho máy chủ.
- Máy chủ xác nhận tiếp nhận: sang “thành công”; hiển thị thông báo đúng phạm vi đã tiếp nhận và bước tiếp theo.
- Máy chủ từ chối hoặc báo lỗi: sang “chưa hoàn tất”; nêu lỗi có ích, giữ dữ liệu có thể giữ và hướng dẫn thử lại.
- Mất mạng khi gửi: xử lý “chưa xác định được kết quả” nếu chưa biết máy chủ đã nhận hay chưa; ưu tiên đối chiếu mã yêu cầu hoặc xác minh trên hệ thống trước khi gửi lại.
- Phiên đăng nhập hết hạn: không hứa tác vụ đã xong; chỉ dẫn đăng nhập lại và bảo toàn bản nháp khi hệ thống cho phép.
Ví dụ trên là mẫu chuyển trạng thái, không phải bằng chứng website đã hoạt động đúng. Các thông báo phải khớp phản hồi từ máy chủ. Nếu hệ thống cần tránh trùng đơn hoặc yêu cầu, đội kỹ thuật phải kiểm tra ở cả phía máy chủ và quy trình gửi lại.
Loading, Empty và Error: đừng để khách phải đoán
Khi đang tải hoặc đang gửi
Cần cho biết đang xử lý công việc gì. Nếu có thể xác định tiến độ thật thì hiển thị tiến độ; nếu chưa biết, chỉ nên báo đang xử lý. Không dùng thanh phần trăm tùy ý khiến khách tưởng sắp hoàn tất. Khi làm mới dữ liệu, có thể giữ nội dung cũ và ghi rõ đang cập nhật nếu phù hợp.
Khi không có dữ liệu
“Bạn chưa có đơn hàng nào” khác với “Không tìm thấy sản phẩm theo bộ lọc” hoặc “Không tải được dữ liệu”. Mỗi tình huống nên giải thích vì sao trống và việc có thể làm tiếp, tránh biến lỗi mạng thành thông báo không có dữ liệu.
Khi có lỗi
Thông báo nên nêu chỗ gặp vấn đề và cách sửa, không chỉ hiện “Có lỗi” hoặc tô đỏ. Theo tiêu chí nhận diện lỗi 3.3.1 của W3C, nếu hệ thống tự phát hiện lỗi nhập, trường có lỗi và vấn đề phải được mô tả bằng văn bản. Đề xuất cách sửa khi biết rõ còn liên quan đến tiêu chí 3.3.3.
Nếu nội dung thay đổi thành thông báo “Đang xử lý” hoặc “Đã lưu” mà không chuyển vị trí đang thao tác, công nghệ hỗ trợ cũng cần nhận biết thông báo trạng thái theo WCAG 4.1.3. Không phải thông báo nào cũng cần giành vị trí focus của người dùng.
Liên hệ Design System và cách bàn giao cho lập trình
Một nút hoặc biểu mẫu dùng lại ở nhiều trang nên có bộ trạng thái thống nhất: bình thường, đang chờ, lỗi, thành công theo nhu cầu, và hướng dẫn tương ứng. Bản thiết kế cần ghi rõ trạng thái nào có thật, phản hồi mong đợi và khi nào không thể bấm.
Figma có thể dùng các kiểu biến thể của thành phần (variants), theo tài liệu Figma. Nhưng file thiết kế không thay thế được quy tắc xử lý ở hệ thống. Xem cách chọn công cụ UX/UI; với hành trình khách mới, cần kết hợp hướng dẫn người dùng mới để không bỏ sót trạng thái bắt đầu sử dụng.
Kiểm thử tình huống khó trước khi nghiệm thu
Ngoài thao tác bình thường, nên thử những việc có thể gây mất dữ liệu, tạo đơn trùng hoặc khiến khách không biết hành động đã hoàn thành hay chưa.
- Bấm gửi hai lần: kiểm tra có tạo hai bản ghi trùng không; không chỉ dựa vào nút đang bị khóa.
- Phản hồi tới sai thứ tự: nếu khách tìm kiếm A rồi B, kết quả A tới sau không được ghi đè kết quả B đang hiển thị.
- Mất mạng hoặc gửi quá lâu: trạng thái có rõ ràng, dữ liệu đã nhập có được giữ an toàn và có đường phục hồi không?
- Đổi quyền hoặc hết phiên: thông báo đúng quyền; không để giao diện báo thành công khi máy chủ từ chối.
- Đóng hộp thoại bằng bàn phím: vị trí đang chọn cần trở về nơi hợp lý nếu phù hợp với loại hộp thoại.
- Khách dùng thiết bị nhỏ: thông báo lỗi, biểu mẫu và nút thử lại không bị che bởi bàn phím ảo.
Kiểm thử an toàn: dùng dữ liệu thử, tài khoản được phép và môi trường phù hợp; với thanh toán cần chế độ thử do hệ thống hỗ trợ. Không tự gửi thông tin khách thật hay tạo giao dịch thật chỉ để kiểm tra minh họa. Những chức năng không có trong hợp đồng được ghi là “Không áp dụng”.
Checklist nghiệm thu State-Based Design
- Xác định hành động quan trọng: liên hệ, thanh toán hoặc đặt lịch tùy dự án.
- Liệt kê các trạng thái: chưa nhập, chờ, lỗi, thành công, hết phiên hoặc mất mạng khi có liên quan.
- Chốt điều kiện chuyển: sự kiện nào hợp lệ, hệ thống xác nhận bằng cách nào, khi nào không được thực hiện.
- Thử cả trường hợp lỗi: nhập thiếu, bấm lặp, mất kết nối, phản hồi chậm và thử lại.
- Kiểm tra khả năng sử dụng: chữ thông báo, focus bàn phím, điện thoại và trạng thái nhận biết được bằng công nghệ hỗ trợ.
- Đối chiếu kết quả hệ thống: thông báo thành công phải khớp dữ liệu thực sự tiếp nhận; ghi bằng chứng hợp lệ.
- Ghi biên bản: URL, thiết bị, bước thử, kết quả mong đợi/thực tế, người sửa, hạn kiểm tra lại và Đạt/Chưa đạt/Không áp dụng.
Đây là checklist dành cho các chức năng có trong phạm vi dự án, không bắt mọi website phải có toàn bộ trường hợp của ứng dụng lớn. Có thể đưa vào checklist bàn giao website để người nhận biết mình đã thử những gì.
Khi nào website doanh nghiệp nên ưu tiên sửa trạng thái?
Nếu khách phản ánh không gửi được tư vấn, biểu mẫu báo lỗi khó hiểu, đặt hàng trùng hoặc trang không rõ đã lưu thông tin chưa, nên kiểm tra trạng thái và hành vi hệ thống trước khi chỉ chỉnh màu nút. Với trang đích và website đang có khách nhưng ít yêu cầu, có thể xem cách tìm nguyên nhân website đẹp nhưng chưa hiệu quả; không được mặc định sửa trạng thái sẽ bảo đảm tăng doanh thu.
Các website đơn giản nên bắt đầu từ nút liên hệ, biểu mẫu, menu và thông báo chính; hệ thống phức tạp như tài khoản khách hàng hoặc thanh toán cần mô hình chuyển đổi chi tiết hơn. Có thể trao đổi phạm vi với đơn vị thiết kế website; số điện thoại liên hệ hiện sử dụng là 0902 711 308.
Câu hỏi thường gặp
State-Based Design khác Interaction Design thế nào?
Interaction Design giải thích cách người dùng và giao diện tương tác. State-Based Design tập trung mô tả hệ thống đang ở trạng thái nào, điều gì làm nó thay đổi và cách xử lý cả tình huống lỗi.
Có phải mọi nút đều cần thiết kế hàng chục trạng thái?
Không. Chỉ xây trạng thái có ý nghĩa với hành động và phạm vi cần hỗ trợ. Nút liên kết đơn giản khác biểu mẫu gửi dữ liệu hay quy trình thanh toán.
Focus có bắt buộc phải nhìn thấy không?
Các thành phần vận hành bằng bàn phím cần có chế độ hiển thị dấu hiệu focus theo tiêu chí WCAG 2.4.7. Không nên tắt dấu hiệu chỉ để giao diện trông đẹp.
Gửi yêu cầu xong có nên hiện thành công ngay không?
Không chỉ vì khách đã bấm gửi. Thông báo phải phản ánh kết quả tiếp nhận thực tế. Nếu kết nối gián đoạn khiến chưa xác minh được kết quả, cần nêu tình trạng chưa rõ và cho cách xử lý phù hợp.
Không có dữ liệu với không tải được dữ liệu có giống nhau không?
Không. Không có dữ liệu có thể là kết quả hợp lệ; không tải được dữ liệu là lỗi cần thông báo và hướng xử lý khác.
Kết luận
Thiết kế giao diện theo trạng thái giúp doanh nghiệp không bỏ sót những tình huống sau khi khách bấm nút: đang chờ, nhập sai, thành công, mất mạng hay hết quyền. Giá trị của nó là người dùng hiểu chuyện gì đang xảy ra, đội lập trình biết xử lý đúng và người nghiệm thu có tiêu chí thử rõ ràng.
Hãy bắt đầu bằng một hành động quan trọng trên website, thống nhất trạng thái và cách xác minh kết quả rồi thử cả khi gặp lỗi. Một bản thiết kế đẹp chỉ thực sự hữu ích khi hệ thống hoạt động đáng tin và khách biết phải làm gì tiếp.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.