Nên thử những gì trước khi duyệt thiết kế lại ứng dụng doanh nghiệp?

Các màn hình mới trông có vẻ ổn. Nhà cung cấp hướng dẫn bạn tìm một đơn hàng, sửa thông tin rồi lưu lại. Giờ họ muốn bạn duyệt thiết kế lại để đội phát triển có thể bắt đầu.

Trước khi đồng ý, hãy để một người sẽ dùng ứng dụng thử thực hiện một công việc quan trọng. Cho họ biết tình huống và kết quả cần đạt, rồi quan sát cách họ làm. Người xem thuyết trình có người chỉ đường. Người xử lý yêu cầu của khách hàng phải tự tìm cách thực hiện.

Bắt đầu với công việc quan trọng

Hãy chọn công việc mọi người thường làm hoặc một sai sót có thể gây rắc rối. Nếu một tình huống ngoại lệ khiến người dùng phải làm khác đi, hãy đưa tình huống đó vào. Phạm vi phù hợp tùy thuộc vào ứng dụng và quyết định bạn cần đưa ra.

Hãy xem một ví dụ giả định. Một nhân viên xử lý đơn hàng nhận được yêu cầu đổi địa chỉ giao hàng của khách trước khi đơn được chuyển đi. Nhân viên cần tìm đúng đơn, sửa địa chỉ và biết thay đổi đã được áp dụng hay chưa.

Hãy tạo các đơn hàng mẫu với thông tin khách hàng bịa đặt. Đưa cho nhân viên một tin nhắn khách hàng nghe hợp lý và đủ thông tin để xác định đơn hàng. Đừng đưa dữ liệu khách hàng hay doanh nghiệp thật vào nguyên mẫu chưa được thiết kế để bảo vệ những dữ liệu đó.

Sau đó, hãy yêu cầu họ xử lý đề nghị này. Tránh hướng dẫn kiểu “mở Đơn hàng, chọn Sửa rồi nhấn Lưu”. Những bước đó tiết lộ chính câu trả lời bạn đang muốn tìm hiểu.

Hướng dẫn ngày 12 tháng 1 năm 2014 của Marieke McCloskey về tình huống tác vụ giải thích sự khác biệt này: hãy cho người dùng bối cảnh có ý nghĩa và mục tiêu cần đạt, nhưng đừng chỉ cho họ đường đi qua giao diện.

Để người có khả năng sẽ dùng ứng dụng thử

Hãy chọn người đang làm công việc này hoặc có khả năng sẽ làm. Nếu nhân viên xử lý việc sửa đơn, người quản lý đã biết các màn hình dự kiến không thể thay họ thử. Hãy mời thêm những vai trò khác nếu công việc của họ đặt ra câu hỏi khác.

Hãy dùng điều kiện phù hợp với công việc. Nhân viên ngồi bàn cả ngày có thể chủ yếu dùng bàn phím. Người kiểm tra đơn trên điện thoại sẽ gặp màn hình và cách nhập liệu khác. Nếu mọi người dùng công nghệ hỗ trợ, hãy chuẩn bị cấu hình liên quan và kiểm tra xem nguyên mẫu có hỗ trợ hay không.

Hướng dẫn của GOV.UK về kiểm thử khả năng sử dụng có điều phối mô tả cách quan sát người dùng thực tế hoặc người dùng dự kiến thực hiện các tác vụ gần với thực tế. Bạn có thể áp dụng nguyên tắc đó cho công việc cụ thể cần xem xét mà không cần làm lại cả một chương trình nghiên cứu của chính phủ.

Hãy quan sát nhân viên nhìn vào đâu, lúc nào họ do dự, đi nhầm hướng hoặc bỏ sót thông tin. Lắng nghe cách họ hiểu điều vừa xảy ra. Nếu bạn phải giúp, hãy ghi lại bạn đã giúp ở đâu và như thế nào. Hoàn thành sau khi được chỉ dẫn cho bạn biết điều khác với tự hoàn thành.

“Tôi thích cách bố trí này” là phản hồi hữu ích về sở thích của một người. “Tôi tưởng địa chỉ đã được lưu, nhưng màn hình vẫn ở chế độ chỉnh sửa” nêu ra một vấn đề cụ thể cần tìm hiểu.

Giờ hãy giả sử đơn hàng đã được chuyển đi giao

Trong cùng ví dụ giả định, khách hàng yêu cầu đổi địa chỉ quá muộn để xử lý theo cách thông thường. Nhân viên có hiểu trạng thái hiện tại của đơn hàng và biết nên làm gì tiếp theo không? Có thể họ cần người quản lý phê duyệt hoặc phải liên hệ với bộ phận giao hàng.

Hãy thống nhất bước tiếp theo trong doanh nghiệp của bạn, rồi để nhân viên thử thực hiện. Nếu nguyên mẫu hỗ trợ, hãy đưa vào các màn hình và lựa chọn liên quan. Hãy tìm một kết quả rõ ràng: nhân viên có biết địa chỉ đã đổi chưa, có cần người khác xử lý không và có thể trả lời khách hàng thế nào không?

Cảnh báo mô phỏng có thể cho thấy nội dung có dễ hiểu hay không. Nó không chứng minh ứng dụng đang hoạt động sẽ ngăn được thay đổi trái phép hoặc gửi thông báo cho bộ phận giao hàng. Hãy dành những câu hỏi đó cho các bước kiểm tra có thể trả lời chúng.

Chọn nguyên mẫu có thể trả lời câu hỏi của bạn

Bản phác thảo có thể giúp bạn trao đổi xem màn hình cần có gì và ý tưởng được đề xuất có hợp lý không. Nguyên mẫu có thể tương tác cho phép người dùng tìm đơn hàng, chuyển giữa các màn hình và hiểu thông báo xác nhận, nếu những phần đó đã được xây dựng. Hãy nói rõ với mọi người phần nào hoạt động và phần nào chỉ là mô phỏng.

Nếu muốn biết nhân viên có tìm được cách sửa đơn không, hãy để họ thử cách đó. Nếu bạn đang xem cảnh báo có dễ hiểu không, hãy cho họ xem trong đúng tình huống cảnh báo sẽ xuất hiện. Hỏi một người liệu họ nghĩ mình có dùng được màn hình không sẽ cho bạn biết dự đoán của họ; quan sát họ thử sẽ cho bạn biết họ thực sự làm gì.

Trong bài viết ngày 27 tháng 8 năm 2014 về việc dùng nguyên mẫu tại GDS, Katherine Alsop mô tả sự khác biệt giữa bản trình diễn ổn định cho các bên liên quan và nguyên mẫu được thay đổi trong quá trình nghiên cứu. Bà cũng lưu ý rằng nghiên cứu trên dịch vụ đang hoạt động có thể phát hiện vấn đề về thời gian phản hồi và xử lý lỗi mà nguyên mẫu không thể hiện.

Điều này có ý nghĩa khi bạn duyệt công việc. Thông báo “Đã lưu” có thể giúp kiểm tra xem nhân viên có hiểu kết quả không. Để biết dữ liệu chính xác đã được lưu chưa, các yêu cầu lặp lại có được xử lý an toàn không và hệ thống kết nối đã nhận thay đổi chưa, cần có các bước kiểm tra phù hợp trên phần mềm đã triển khai. Bảo mật, quyền được hệ thống thực thi và tốc độ cũng cần được kiểm tra trên những phần liên quan của ứng dụng đang hoạt động.

Quan sát mọi người sử dụng cấu hình hỗ trợ quen thuộc có thể phát hiện trở ngại thực tế. Như hướng dẫn của W3C về việc mời người dùng tham gia đánh giá khả năng tiếp cận giải thích, việc này cần đi cùng đánh giá theo các tiêu chuẩn về khả năng tiếp cận. Hoàn thành các tác vụ này không chứng minh ứng dụng đáp ứng các tiêu chuẩn đó. Nếu nguyên mẫu không hỗ trợ cấu hình cần thiết, hãy ghi lại giới hạn này và sắp xếp bước kiểm tra phù hợp sau đó.

Rời cuộc họp với quyết định mà bạn có thể giải thích

Hãy ghi lại những gì bạn quan sát được khi mọi thứ còn mới. Ghi ngắn gọn, thiết thực:

• Ai đã thử việc gì: vai trò của người thử, tác vụ, thiết bị và cách nhập liệu, cùng những phần nguyên mẫu hỗ trợ.
• Điều gì đã xảy ra: họ có đạt kết quả mong muốn không, gặp khó ở đâu và cần được giúp thế nào. Tách điều quan sát được khỏi phỏng đoán về nguyên nhân.
• Cần sửa gì và thử lại: nêu nhãn khó hiểu, thông tin còn thiếu hoặc bước tiếp theo chưa rõ. Sau khi sửa, hãy để ai đó thử lại phần công việc bị ảnh hưởng.
• Việc gì vẫn cần ứng dụng đang hoạt động: ghi lại câu hỏi còn bỏ ngỏ, ai sẽ kiểm tra và khi nào. Trong ví dụ này, có thể cần xác định ai được duyệt yêu cầu đổi địa chỉ muộn và bộ phận giao hàng nhận thông tin bằng cách nào.

Sau đó, bạn có thể duyệt hướng thiết kế được các lần thử ủng hộ, yêu cầu sửa phần khiến người dùng gặp khó hoặc để dành một quyết định cho đến khi có đủ bằng chứng cần thiết. Bạn có thể làm cả ba việc với những phần khác nhau của thiết kế lại. Duyệt màn hình đơn hàng không có nghĩa là chấp nhận một tích hợp với bộ phận giao hàng chưa được kiểm tra.

Nếu bạn đang chuẩn bị thiết kế lại ứng dụng doanh nghiệp, dịch vụ thiết kế của chúng tôi có thể là điểm bắt đầu để trao đổi về ai sử dụng ứng dụng, họ cần làm gì và bạn cần đưa ra những quyết định nào.