Khi một công cụ AI đang tạo nội dung, xử lý một tập dữ liệu hoặc chạy một tác vụ tự trị, người dùng cần một cách rõ ràng để dừng lại. Quá nhiều giao diện coi nút dừng khẩn cấp như một phần phụ. Họ chỉ cần đổi nhãn nút từ "Stop" thành "Stopped" và coi như công việc đã xong. Màu sắc có thể chuyển sang màu xám. Hiệu ứng chuyển động có thể trông mượt mà. Tuy nhiên, tác vụ vẫn tiếp tục chạy trên máy chủ, và người dùng không hề biết có điều gì đó đang sai sót. Đối với những người đang sử dụng trình đọc màn hình (screen reader), lỗi này thậm chí còn nghiêm trọng hơn. Họ nghe thấy âm thanh xác nhận rằng quá trình đã kết thúc, trong khi công việc vẫn tiếp tục âm thầm ở chế độ nền. Đó không phải là một lỗi nhỏ. Đó là sự đổ vỡ của niềm tin.

Sự dối trá của một nút dừng im lặng

Một nút dừng tồi tệ đang lừa dối người dùng của bạn. Nó hiển thị chữ "Stopped" trong khi tác vụ vẫn tiếp tục thực thi đâu đó trong một container hoặc trên một worker từ xa. Điều này xảy ra vì các nhà phát triển front-end thường thực hiện cập nhật lạc quan (optimistic update) cho giao diện trước khi máy chủ xác nhận việc dừng lại. Một người dùng bình thường có thể nhận ra sự sai lệch nếu thanh tiến trình vẫn tiếp tục chạy hoặc nhật ký (log) vẫn tiếp tục cuộn, nhưng người dùng trình đọc màn hình không có kênh phụ nào như vậy. Họ phụ thuộc hoàn toàn vào những gì giao diện thông báo. Nếu văn bản trên nút thay đổi quá sớm mà không có phản hồi âm thanh nào làm rõ trạng thái thực tế, người dùng sẽ tin rằng tình huống khẩn cấp đã kết thúc trong khi thực tế không phải vậy. Khả năng tiếp cận (Accessibility) ở đây không phải là một yêu cầu tính năng. Đó là một yêu cầu về an toàn.

Hai trạng thái khác biệt

Một bộ điều khiển khẩn cấp thực sự phải xử lý hai trách nhiệm riêng biệt. Thứ nhất, hệ thống chấp nhận yêu cầu của bạn. Thứ hai, hệ thống chấm dứt quyền thực thi. Đây không phải là cùng một việc. "Chấp nhận" có nghĩa là front-end đã nhận được lệnh của bạn và chuyển tiếp thông điệp đi. "Chấm dứt" có nghĩa là back-end thực sự đã kết thúc tiến trình. Do sự tồn tại của độ trễ mạng, hàng đợi công việc và các lớp điều phối (orchestration layers), khoảng cách giữa hai thời điểm này có thể kéo dài vài giây. Trong khoảng thời gian đó, giao diện của bạn phải nói lên sự thật về việc bạn đang ở giai đoạn nào. Việc gộp cả hai giai đoạn thành một khoảnh khắc duy nhất là giả định về một cơ sở hạ tầng không hề tồn tại. Người dùng của bạn sẽ phải trả giá cho sự lạc quan đó.

Ánh xạ bốn trạng thái vào giao diện của bạn

Hãy xây dựng UI của bạn xoay quanh bốn trạng thái rõ ràng để người dùng luôn biết họ đang ở đâu.

  • Running (Đang chạy): Hiển thị một nút "Stop task" (Dừng tác vụ) được dán nhãn rõ ràng. Hãy giữ nó luôn hiển thị. Đừng giấu nó dưới các tab hoặc các bảng accordion.
  • Requesting (Đang yêu cầu): Vô hiệu hóa nút để người dùng không thể gửi dồn dập các yêu cầu bổ sung. Hiển thị thông báo "Stop requested" (Đã yêu cầu dừng). Sự trung thực này rất quan trọng. Nó cho người dùng biết rằng lệnh của họ đang được xử lý và hệ thống vẫn chưa xác nhận việc hoàn tất.
  • Stopped (Đã dừng): Vô hiệu hóa nút. Hiển thị một mã biên nhận (receipt ID). Điều này cung cấp cho người dùng bằng chứng rằng máy chủ đã phản hồi và việc dừng đã được ghi lại. Nó biến một lời khẳng định thành một hồ sơ thực tế.
  • Failed (Thất bại): Kích hoạt nút "Try stop again" (Thử dừng lại lần nữa). Hiển thị thông báo lỗi cụ thể. Đừng bao giờ để người dùng rơi vào trạng thái lửng lơ trong im lặng. Nếu máy chủ hết thời gian chờ (timeout) hoặc trả về lỗi, hãy nói rõ điều đó.

Các trạng thái này nên dẫn dắt cả phản hồi về mặt thị giác lẫn thính giác. Khi trạng thái thay đổi, trình đọc màn hình phải thông báo nhãn và trạng thái mới thông qua một vùng live (live region) được quản lý đúng cách. Một nút bị vô hiệu hóa kết hợp với thông báo bằng văn bản sẽ ngăn chặn sự nhầm lẫn về việc liệu bộ điều khiển còn hoạt động hay không.

Các quy tắc thiết kế vững vàng dưới áp lực

Các bộ điều khiển khẩn cấp mang một gánh nặng thiết kế khác với các nút thông thường. Người dùng có thể đang lo lắng, vội vã hoặc đang phản ứng với một kết quả không mong muốn. Giao diện của bạn phải duy trì khả năng sử dụng trong sự căng thẳng đó.

Đừng chỉ sử dụng màu sắc làm tín hiệu duy nhất. Một nút chuyển từ màu đỏ sang màu xanh có thể giúp ích cho một số người dùng có thị lực, nhưng người mù màu và người dùng trình đọc màn hình cần các thay đổi về văn bản và cấu trúc. Hãy kết hợp màu sắc với các nhãn rõ ràng, biểu tượng với các văn bản thay thế và các thông báo trạng thái.

Đừng ẩn các bộ điều khiển trong menu khi di chuột (hover menus). Không ai nên phải tìm kiếm qua một menu thả xuống trong tình huống khẩn cấp. Nút dừng phải nằm trong vùng hiển thị chính, luôn có thể tiếp cận được mà không cần các thao tác điều khiển con trỏ chính xác.

Hãy làm cho các nút dễ dàng nhấn bằng con trỏ. Sự căng thẳng làm giảm khả năng kiểm soát vận động tinh. Hãy sử dụng khoảng đệm (padding) rộng rãi và vùng nhấp (hit target) lớn. Nếu người dùng đang run rẩy hoặc đang sử dụng trackpad trên một chuyến tàu đang chuyển động, họ vẫn phải có thể thực hiện được cú nhấp chuột.

Đảm bảo người dùng bàn phím có thể tiếp cận nút một cách nhanh chóng. Thứ tự tab không nên buộc ai đó phải đi qua ba mươi phần tử có thể lấy tiêu điểm (focusable elements) trước khi chạm tới bộ điều khiển khẩn cấp. Hãy cân nhắc sử dụng một liên kết bỏ qua (skip link) hoặc đặt vị trí tiêu điểm (focus placement) hợp lý để đưa hành động dừng vào tầm với ngay lập tức.

Tránh các phím tắt vô tình bị kích hoạt. Các phím tắt toàn cục dùng để dừng một quy trình nên sử dụng các tổ hợp phím khó bị kích hoạt do nhầm lẫn. Nếu một phím tắt lưu hoặc in phổ biến trùng với lệnh dừng của bạn, người dùng sẽ vô tình kích hoạt nó và làm mất dữ liệu đang làm việc.

Không sử dụng xác nhận nhiều bước cho các trường hợp khẩn cấp. Một hộp thoại xác nhận là một bức tường, chứ không phải là thanh chắn an toàn. Vào lúc người dùng đọc được câu hỏi "Bạn có chắc chắn không?" và nhấp chuột lần nữa, kết quả không mong muốn có thể đã được gửi đi rồi. Một hành động quyết đoán là đủ.

Biên lai, Mất kết nối mạng và Những giới hạn trung thực

Một ID biên lai chứng minh rằng máy chủ đã phản hồi. Nó không chứng minh rằng mọi hiệu ứng hạ nguồn đã được đảo ngược. Nhiệm vụ AI của bạn có thể đã kích hoạt các API bên ngoài, ghi tệp hoặc các hàng đợi tin nhắn vào thời điểm lệnh dừng được gửi đến. Việc dừng bộ điều phối (orchestrator) không đảm bảo rằng mỗi tiến trình con sẽ bị hủy ngay lập tức. Hãy trung thực về giới hạn này trong các thông báo và tài liệu hướng dẫn của bạn.

Bạn cũng cần thiết kế cho các chế độ lỗi xảy ra bên ngoài phòng máy chủ của mình. Hãy kiểm tra điều gì sẽ xảy ra khi người dùng mất kết nối mạng ngay sau khi nhấn dừng. Hãy kiểm tra điều gì sẽ xảy ra khi phản hồi mất mười giây thay vì một trăm mili giây. Nếu yêu cầu bị treo, giao diện của bạn nên chuyển sang trạng thái thất bại (timeout) thay vì bị kẹt mãi ở trạng thái "Đang yêu cầu" (Requesting). Người dùng xứng đáng được biết khi kết nối đã bị ngắt.

Cách kiểm thử một cách thực thụ

Việc xác minh không thể là một bước bổ sung sau cùng. Hãy chạy thử giao diện của bạn qua các điều kiện thực tế mà người khuyết tật gặp phải hàng ngày.

Điều hướng chỉ bằng bàn phím. Hãy rút chuột ra. Sử dụng phím Tab để đi qua mọi trạng thái. Đảm bảo rằng bạn có thể tiếp cận nút dừng từ bất kỳ đâu trong quy trình làm việc mà không bị kẹt tiêu điểm (focus) hoặc tạo ra các điểm dừng Tab vô hình.

Phóng to trình duyệt 200%. Phóng to trang web. Kiểm tra xem nút dừng có được sắp xếp lại (reflow) hay bị biến mất không. Người dùng có thị lực kém thường dựa vào việc phóng to, và việc bố cục bị sụp đổ thường làm ẩn đi các nút điều khiển quan trọng.

Cài đặt giảm chuyển động. Trạng thái "Đang yêu cầu" của bạn có thể sử dụng hiệu ứng nhấp nháy hoặc vòng xoay tải dữ liệu. Hãy tôn trọng prefers-reduced-motion. Cung cấp các chỉ báo hình ảnh tĩnh song song với bất kỳ chuyển động nào để những người dùng tắt hiệu ứng hoạt họa vẫn nhận được phản hồi trạng thái rõ ràng.

Thứ tự thông báo của trình đọc màn hình. Sử dụng vùng trực tiếp (live region) để phát các thay đổi trạng thái, nhưng hãy kiểm tra trình tự một cách cẩn thận. Thứ tự thông báo nên khớp với tiến trình logic của các sự kiện. Nếu nút bị vô hiệu hóa trước khi trình đọc màn hình nói "Đã yêu cầu dừng" (Stop requested), hãy kiểm tra xem trình tự đó có gây nhầm lẫn hay không. Những lỗi nhỏ về thời gian trong công nghệ hỗ trợ có thể làm sai lệch thông điệp, vì vậy hãy xác minh bằng trình đọc màn hình thực tế thay vì chỉ giả định rằng mã đánh dấu (markup) là đủ.

Bài học thực sự

Xây dựng một nút dừng khẩn cấp có khả năng tiếp cận có nghĩa là tôn trọng người dùng đủ để nói cho họ biết sự thật. Giao diện nên diễn đạt rõ ràng, chuyển động có thể dự đoán được và không bao giờ giả vờ rằng một yêu cầu cũng giống như một kết quả. Khi áp lực cao và dữ liệu gặp rủi ro, sự rõ ràng không chỉ cứu vãn thời gian mà còn cứu vãn cả niềm tin. Một nút dừng trung thực không chỉ dừng một tác vụ. Nó chứng minh rằng sản phẩm của bạn an toàn để vận hành ngay từ đầu.