Nhờ AI làm bản mẫu phần mềm rồi thử với người dùng

Khách bấm nút đặt lịch, màn hình hiện dấu tích xanh. Bạn thiết kế thở phào: luồng chạy mượt rồi. Nhưng khi được hỏi sẽ làm gì tiếp theo, khách nói sáng mai cứ mang máy đến cửa hàng. Trong khi đó, cửa hàng vẫn phải gọi lại mới xác nhận được giờ nhận máy. Một dấu tích đẹp vừa tạo ra hai cách hiểu.

Đó là tình huống giả định của nhóm Linh khi thử mẫu giao diện đặt lịch sửa thiết bị. AI giúp nhóm dựng màn hình khá nhanh, nhưng buổi thử mới lộ ra điều quan trọng. Prototype có ích khi giúp trả lời một câu hỏi thực tế. Ở đây, câu hỏi là khách có hiểu mình mới gửi yêu cầu hay đã có lịch chắc chắn.

Biến yêu cầu chung thành một việc cụ thể

Yêu cầu đầu tiên là “làm trang đặt lịch hiện đại, dễ dùng”. Linh thấy câu này chưa đủ để chọn màn hình cần dựng. Cô hỏi cửa hàng đang mất thời gian ở đâu. Hóa ra khách thường gửi thiếu loại thiết bị, rồi nghĩ cửa hàng đã giữ giờ dù nhân viên chưa kiểm tra khả năng tiếp nhận.

Nhóm đổi mục tiêu thành một việc cụ thể: khách gửi đủ thông tin ban đầu và biết cần chờ xác nhận. Người thử sẽ đóng vai người muốn sửa một chiếc máy vào chiều thứ bảy. Nhóm chưa cần dựng trang giới thiệu dài hoặc hệ thống tích điểm. Những phần đó không giúp trả lời câu hỏi đang vướng.

Linh viết yêu cầu cho AI gồm tình huống sử dụng, thông tin phải thu thập và trạng thái sau khi gửi. Cô cũng nói rõ dữ liệu chỉ là mẫu, chưa gửi tới cửa hàng thật. Bản nháp có thể thay đổi, nhưng ý nghĩa của thao tác phải nhất quán để buổi thử không đánh giá nhầm một luồng.

Vẽ luồng trước khi chăm từng chiếc nút

Nhóm phác bốn bước: chọn nhu cầu, nhập thông tin liên hệ, xem lại rồi gửi yêu cầu. Sau đó họ thêm nhánh khách chưa biết tên model thiết bị. Nếu bắt buộc nhập đúng model ngay, nhiều người sẽ đứng hình ở bước đầu. Nhóm cho phép mô tả ngắn và ghi chú rằng cửa hàng sẽ hỏi thêm khi liên hệ.

Linh đọc từng bước như một cuộc hội thoại. Màn hình này đang hỏi gì? Người dùng lấy thông tin ở đâu? Bấm xong thì chuyện gì xảy ra? Cách đọc ấy giúp bỏ những ô không cần thiết. Một biểu mẫu ngắn hơn không phải lúc nào cũng tốt hơn; nó cần thu được thông tin đủ cho bước xử lý tiếp.

Nhóm kiểm tra cả đường quay lại sửa thông tin. Nếu khách đổi ngày, màn hình xem lại phải hiện ngày mới. Những tương tác chưa làm được cần được ghi rõ cho người điều phối buổi thử. Không nên để lỗi của bản mẫu khiến nhóm kết luận rằng người dùng không hiểu một thiết kế vốn chưa hoạt động.

Dữ liệu giả nên giống cấu trúc, không giống hồ sơ thật

Linh tạo vài tình huống mẫu: tên thiết bị dài, mô tả lỗi nhiều dòng và người chưa chọn được giờ. Các dữ liệu này giúp nhìn thấy chỗ giao diện bị chật hoặc câu hướng dẫn thiếu rõ ràng. Cô không lấy nguyên hồ sơ sửa máy của khách rồi đổi mỗi tên ở đầu.

Thông tin liên hệ dùng trong bản mẫu phải được chuẩn bị để không vô tình gọi hay gửi tin cho người thật. Nếu công cụ có tính năng gửi thông báo, nhóm kiểm tra nó trước buổi thử. Dữ liệu demo nhìn hợp lý là đủ; không cần đánh đổi sự riêng tư để làm màn hình trông chân thật hơn.

Thử bằng nhiệm vụ, không hỏi “bạn thấy sao?”

Linh đưa nhiệm vụ: bạn muốn mang thiết bị đến vào chiều thứ bảy, hãy làm điều bạn thường làm để gửi yêu cầu. Cô không chỉ nút và không đọc hướng dẫn hộ. Khi người thử dừng lại, cô ghi vị trí cùng điều họ đang tìm. Việc này cho thấy vấn đề cụ thể hơn một lời nhận xét “giao diện hơi khó”.

Sau khi người thử hoàn thành, Linh hỏi họ nghĩ bước tiếp theo là gì. Câu trả lời về việc mang máy đến ngay khiến nhóm chú ý. Cô hỏi thêm chi tiết nào trên màn hình dẫn đến cách hiểu đó. Người thử chỉ vào dòng “đặt lịch thành công” cùng giờ đã chọn, không nhắc tới đoạn chú thích ở dưới.

Nhóm sửa thông báo thành “đã nhận yêu cầu đặt lịch” và giải thích cửa hàng sẽ liên hệ để xác nhận. Họ không chỉ đổi màu nút rồi gọi là xong. Trong lần thử tiếp theo, câu hỏi vẫn giữ nguyên để xem cách hiểu có thay đổi không. Đây là kiểm tra một giả thuyết cụ thể, chưa phải bằng chứng đại diện cho mọi khách hàng.

Chuẩn bị buổi thử trước khi mời người dùng

Trước buổi thử, một thành viên đi hết luồng trên thiết bị dự định sử dụng. Nhóm kiểm tra các nút, nội dung mẫu và đường quay về điểm đầu. Người điều phối cũng chuẩn bị cách xử lý khi prototype đứng ở một màn hình. Mất vài phút sửa lỗi ngay trước mặt người thử dễ làm cuộc trao đổi chệch hướng.

Nhóm nói rõ đang thử bản thiết kế, không chấm điểm người tham gia. Nếu muốn ghi âm hoặc ghi hình, cần hỏi và thống nhất trước. Ghi chú tập trung vào thao tác cùng lời giải thích liên quan. Một buổi thử hữu ích không cần thu thập thêm thông tin riêng tư không phục vụ việc đánh giá.

Khả năng tiếp cận nên có từ đầu

Linh kiểm tra nhãn của các ô nhập, chữ có dễ đọc không và người dùng có nhận ra lỗi mà không chỉ dựa vào màu. Với bản mẫu có tương tác phù hợp, nhóm thử di chuyển bằng bàn phím. Những kiểm tra ban đầu này giúp phát hiện vấn đề sớm, trước khi thiết kế được bàn giao thành nhiều màn hình thật.

Bộ kiểm tra sơ bộ của W3C WAI cung cấp các điểm bắt đầu để xem xét khả năng tiếp cận. Đây chưa phải đánh giá đầy đủ. Nhóm cần ghi lại những phần prototype không mô phỏng được để kiểm tra tiếp trên sản phẩm thực tế, thay vì tuyên bố đã đạt chuẩn chỉ sau vài thao tác.

Prototype để trả lời một câu hỏi

Sau buổi thử, nhóm không chọn thiết kế theo số người khen đẹp. Họ xem lại câu hỏi ban đầu: khách có phân biệt gửi yêu cầu với xác nhận lịch không? Những chỗ người thử hiểu sai được ưu tiên sửa. Ý tưởng thêm hiệu ứng chuyển màn hình được lưu lại, vì lúc này nó chưa giải quyết vấn đề chính.

Mỗi lần sửa nên có lý do để so sánh. Nếu thay đồng thời nội dung, thứ tự bước và cách chọn giờ, nhóm khó biết điều gì đã giúp người dùng hiểu hơn. Linh giữ ghi chú ngắn về thay đổi và điều cần quan sát ở lần thử kế tiếp. Như vậy, prototype trở thành công cụ học, không chỉ là màn demo.

Bàn giao cả điều đã học và phần chưa làm thật

Khi chuyển cho lập trình viên, Linh gửi thiết kế cùng luồng, trạng thái lỗi và kết quả quan sát. Cô đánh dấu phần nào đang dùng dữ liệu giả, phần nào chưa kết nối dịch vụ. Tài liệu bàn giao để người khác tiếp tục cần giúp người nhận hiểu cả quyết định lẫn giới hạn của bản mẫu.

Nhóm đã biết phải nói rõ trạng thái chờ xác nhận. Họ vẫn cần kiểm tra luồng vận hành thật cùng cửa hàng. Tách rõ hai điều ấy giúp tránh mang một màn hình đẹp đi triển khai quá sớm. AI đã giúp dựng nhanh; câu chuyện của người dùng mới giúp nhóm biết nên xây thứ gì tiếp theo.