Usability Testing - Kiểm thử tính hữu dụng của phần mềm ( Phần 2 )

6. Sử dụng Usability testing như thế nào?

6.2. Tuyển dụng các bên tham gia Usability Test

– Nó là quan trọng để tuyển dụng người tham gia người mà tương tự như người sử dụng trang web của bạn cho Usabily Testing. Tùy thuộc vào các trang web hoặc sản phẩm, bạn có thể có nhiều nhóm người dùng tiềm năng. Hãy thử bao gồm đại diện của tất cả các nhóm hoặc tùy chọn, thực hiện kiểm tra với từng nhóm riêng biệt nếu bạn thực sự muốn tập trung vào thông tin dựa trên vai trò hoặc chức năng.

– Hãy nhớ rằng bạn không phải là người dùng của bạn. Sử dụng nhân viên nội bộ của bạn như là bên tham gia chỉ khi

• Họ đã không có sự tham gia vào việc thiết kế hoặc phát triển của các trang web hoặc sản phẩm
• Họ đại diện cho một đối tượng mục tiêu

– Nhân viên nội bộ có thể được sử dụng cho pilot testing khi bạn kiểm thử các công nghệ và luồng của kiểm thử và dữ liệu không được tính vào các kết quả cuối cùng.

– Nhân viên nội bộ không bao giờ nên được sử dụng để bổ sung trong quá trình test. Nó không chỉ là bất kỳ bên tham gia nào mà bạn cần; mà đó là bên tham gia từ các đối tượng đúng.

6.2.1. Bao nhiêu bên tham gia là đủ?

– Nielsen chỉ ra số lượng người tham gia mà bạn cần dựa trên một số trường hợp nghiên cứu:

• Usability tests: kiểm tra với 5 người dùng cho phép bạn tìm thấy hầu như nhiều vấn đề về usability như khi bạn muốn tìm cách sử dụng nhiều người tham gia hơn nữa.
• Nghiên cứu định lượng (nhằm thống kê, không hiểu biết): kiểm tra ít nhất 20 người để có được con số ý nghĩa thống kê; khoảng tin cậy chặt chẽ đòi hỏi nhiều người dùng hơn.
• Card sorting: thử nghiệm ít nhất 15 người.
• Eye tracking: thử nghiệm với 39 người sử dụng nếu bạn muốn 1 lược đồ nóng và ổn định.

– Nếu bạn đang thử nghiệm trong không gian liên bang, xin vui lòng xem lại nguyên tắc OMB liên quan đến các thủ tục giấy tờ Paperwork Reduction Act cho usability testing. Để chẩn đoán usability testing, sáu đến tám người dùng của một đối tượng mục tiêu đưa ra thường đủ để phát hiện ra những vấn đề lớn trong một sản phẩm.

– Lưu ý: Nếu bạn có kế hoạch để làm lặp (lặp đi lặp lại) kiểm tra khả năng sử dụng trong quá trình phát triển trang web, bạn cần phải tuyển dụng một nhóm mới cho mỗi lần test. Bạn sẽ cần đến yếu tố đó vào kế hoạch của bạn, tuyển dụng, và ngân sách.

6.2.2. Sàng lọc bên tham gia

– Participant screeners bao gồm các câu hỏi sẽ giúp đỡ những người tuyển dụng cho các bài test với điều lệ riêng hoặc loại bỏ những tranh cãi. Nó có thể được đơn giản như giới tính và tuổi tác hoặc phức tạp như những chỉ dẫn cho đối tượng mục tiêu của bạn. Đối với ví dụ, xin vui lòng xem mẫu screener của chúng tôi.

6.2.3. Chi phí tuyển dụng

– Nhà tuyển dụng thường thu phí cho mỗi người tham gia “thành công” tuyển dụng. Một tuyển dụng thành công là cái mà đáp ứng các tiêu chí, xuất hiện cho testing và có thể hoàn thành các bài test. Một nhà tuyển dụng tốt sẽ thông báo, schedule và nhắc nhở những người tham gia về nhiệm vụ kiểm thử của họ để đảm bảo tất cả các ứng viên của họ là thành công.

– Nếu có nhu cầu, bạn cũng có thể tham gia vào các nhà tuyển dụng để xử lý các nhiệm vụ hành chính bổ sung như quản lý ưu đãi cho người tham gia (quà tặng ý nghĩa hoặc tiền), và trong một số trường hợp chi phí đi lại / đậu xe. Sẽ có một khoản phí cho các dịch vụ bổ sung nên nó sẽ là tốt nhất để thảo luận về bất kỳ dịch vụ bổ sung cần thiết cho team của mình trong các cuộc thảo luận ban đầu của bạn với nhà tuyển dụng.

6.2.4. Làm việc với nhà tuyển dụng

– Nếu nhóm có khả năng là người dùng đại diện bạn có thể tuyển dụng các cá nhân đó. Nếu nhóm không có khả năng là người dùng đại diện, bạn sẽ phải thuê một công ty tuyển dụng thương mại. Hầu hết các công ty tuyển dụng yêu cầu 2-3 tuần để tìm và sắp xếp số lượng cần thiết và loại người tham gia. Dưới đây là những thông tin cơ bản bạn nên có sẵn khi bạn nói chuyện với một nhà tuyển dụng hoặc yêu cầu báo giá cho dịch vụ của họ:

• Có bao nhiêu người tham gia mà bạn cần; các nhóm được chỉ ra
• Địa điểm, ngày tháng và thời gian để test. Đó là hữu ích để cung cấp một bản draft về screeners của bạn ((government-focused template and non-government template), một schedule chi tiết và một bản đồ hoặc định hướng công ty của bạn nếu có thể.
• Mỗi phiên sẽ mất bao lâu
• Nếu bạn sẽ được bồi thường cho test, bao nhiêu ( và trong những format; tiền mặt, séc hoặc thẻ quà tặng hoặc giấy chứng nhận), và nếu bất cứ điều gì khác, bạn sẽ được cung cấp (ví dụ: du lịch hoặc đỗ xe).

– Một ví dụ thông cáo với nhà tuyển dụng: Chi tiết:

• Thời gian: Friday, July 19th and Monday, July 22nd – Friday, July 26th. (schedule có khoảng thời gian cụ thể vào những ngày này, chúng tôi đang tìm kiếm để điền vào.)
• Location: On-site: (Map attached)
• Thời gian của mỗi session: 1-hour usability test sessions
• Bồi thường cho người tham gia: $$ cho phiên làm việc (Chúng tôi sẽ không phải bồi thường thêm cho du lịch hoặc đậu xe.)

– As to the participants – Total (18):

• Non-smokers/Non-tobacco users with smokers in the house (5 participants)
• Non-smokers/Non-tobacco users without smokers in the house (4 participants)
• Current smoker or tobacco user (4 participants)
• Former smoker or tobacco user (5 participants)
• Một kết hợp của giới tính
• Một sự pha trộn của các dân tộc
• Một kết hợp của nền giáo dục
• Tôi muốn các lứa tuổi sau đây được đại diện trong từng phân khúc đối tượng:
  • 18-30
  • 31-50
  • 50 +

6.2.5. Bồi thường cho người tham gia

– Khi xác định như thế nào và bao nhiêu người tham gia để bù cho thời gian của họ là rất quan trọng để xác định những phương pháp và các khoản đã được sử dụng trước đó. Tuyển dụng của bạn có thể hữu ích trong việc học những gì là điển hình cho các bài test mà họ đã tuyển dụng. Các đồng nghiệp của bạn cũng có thể hữu ích, nếu họ đã hoặc tiến hành hoặc tham gia testing.

– Một số điều cần xem xét khi bồi thường tham gia:

• Nếu tham gia của bạn là nhân viên liên bang, bạn không thể trả chi phí cho thời gian của họ.
• Nếu tham gia của bạn là nhân viên không liên bang, chế độ bồi thường phải ở trong nhu cầu của người tham gia tiềm năng. Tiền dưới mọi hình thức nói chung là chấp nhận được nhưng nó có thể được thuận tiện hơn để cung cấp thẻ quà tặng hoặc giấy chứng nhận cho các nhà cung cấp trực tuyến hoặc local vendors. Hãy nhớ rằng mua hàng từ một nhà cung cấp trực tuyến sẽ thường thu phí tham gia của bạn để vận chuyển. Bạn có thể muốn điều chỉnh bồi thường cho phù hợp.
• Nếu bạn đang làm test từ xa, bạn có thể muốn xem xét một electronic mode của bồi thường như e-Certificate cho một nhà cung cấp trực tuyến.
• Hãy nhớ để cung cấp một biên nhận cho tham gia của bạn (một cho người lớn và trẻ vị thành niên được đưa vào phần mẫu) để đăng ký cho các mục đích:
  • Cho thấy rằng họ đã nhận được bồi thường
  • Cung cấp tài liệu cho bộ phận kế toán hoặc nhân viên của bạn.

6.3. Chạy một Usability Testing

– Khi bạn đã lên kế hoạch kiểm thử và tuyển dụng người gia, đó là thời gian để tổ chức kiểm thử. Để làm điều này, bạn cần phải nghĩ về một kỹ thuật phù hợp với kiểm thử của bạn, thiết lập không gian và trang thiết bị, và đảm bảo rằng bạn đã thực hiện một kiểm thử thử nghiệm trước quá trình kiểm thử với những người tham gia thực.

– Chọn Moderating Technique

– Trong một bài viết về Moderation Usability Tests, Jen Romano Bergstorm đã ghi lại rằng, việc lựa chọn một moderation technique tốt nhất cho kiểm thử của bạn, phụ thuộc vào các mục tiêu session. Một số moderation techniques thông dụng sau:

• Concurrent Think Aloud (CTA) được sử dụng để hiểu suy nghĩ của những người tham gia khi họ tương tác với sản phẩm, bằng cách đưa ra suy nghĩ của họ trong quá trình làm việc. Mục tiêu là khuyến khích khách hàng tiếp tục luồng công việc của mình.
• Trong Retrospective Think Aloud (RTA), người điều tiết (moderator) hỏi những người giam gia để vẽ lại các bước của họ khi session kết thúc. Thường người tham gia sẽ xem lại video của họ, có thể hoặc không thể đủ tầm mắt.
• Concurrent Probing (CP) đòi hỏi thực hiện khi những người tham gia đang làm việc với công việc của họ – Khi họ nói ra những thứ làm cho họ thú vị hay những thứ dị thường nào đó, người nghiên cứu (researcher) hỏi các câu hỏi tiếp theo.
• Retrospective Probing (RP) cần chờ cho đến khi session kết thúc và sau đó đưa ra các câu hỏi về suy nghĩ và hành động của những người tham gia – khi người tham gia tạo ra các bình luận và hoạt động, người nghiên cứu (researcher) sẽ ghi chú và theo dõi với các câu hỏi thêm vào ở cuối session.

6.3.1. Pilot Testing

– Trước khi thực hiện một usability test, đảm bảo toàn bộ các vật liệu (materials), sự đồng thuận (consents) và văn bản (documentation) đã được chuẩn bị và kiểm tra. Tạo ra một kiểm thử thí điểm (pilot test) với thiết bị và vật liệu với một người tham gia tình nguyện thực sự quan trọng. Chạy thí điểm 1-2 ngày trước session kiểm thử đầu tiên, bạn sẽ có thời gian để giải quyết bất kỳ vấn đề kỹ thuật nào (technical issues), hoặc thay đổi lại kịch bản hay vật liệu khác nếu cần thiết.

– Pilot test cho phép bạn:

• Kiểm thử thiết bị
• Cung cấp thực hành cho người điều phối (facilitator) và người ghi chép (note-takers)
• Nhận được cảm tình tốt từ người tham gia khi các câu hỏi và kịch bản của bạn hoàn toàn rõ ràng.
• Thực hiện bất cứ điều chỉnh nào vào phút cuối.

6.3.2. Các thực hành tốt nhất

• Hãy đối xử với người tham gia với sự tôn trọng và làm cho họ cảm thấy thoải mái.
• Hãy nhớ rằng bạn đang kiểm tra các trang web không phải là người sử dụng. Giúp họ hiểu rằng họ đang giúp chúng ta kiểm tra các mẫu thử nghiệm hoặc Web site.
• Duy trì trung lập – bạn đang có để nghe và xem. Nếu người tham gia đặt câu hỏi, trả lời với “bạn nghĩ gì?” Hay “Tôi quan tâm tới những gì bạn sẽ làm gì.”
• Đừng nhảy vào và giúp đỡ người tham gia ngay lập tức và không dẫn người tham gia. Nếu người tham gia bỏ và yêu cầu giúp đỡ, bạn phải quyết định xem có nên kết thúc kịch bản, đưa ra một gợi ý, hoặc cung cấp sự giúp đỡ nhiều hơn đáng kể.
• Nhóm nghiên cứu nên quyết định bao nhiêu là một gợi ý bạn sẽ cung cấp và bao lâu bạn sẽ cho phép những người tham gia làm việc trên một kịch bản khi chúng được rõ ràng đi xuống một con đường không hiệu quả.
• Hãy ghi chú tốt. Lưu ý-takers nên nắm bắt những gì mà người tham gia đã làm trong nhiều chi tiết càng tốt cũng như những gì họ nói (trong lời nói của họ). Các tốt hơn các nốt được thực hiện trong phiên giao dịch, dễ dàng hơn việc phân tích sẽ được.
• Đo hiệu suất và chủ quan (ưu tiên) số liệu. hiệu suất của nhân dân và sở thích không luôn luôn phù hợp. Thông thường người dùng sẽ hoạt động kém nhưng đánh giá chủ quan của họ là rất cao. Ngược lại, họ có thể thực hiện tốt nhưng đánh giá chủ quan là rất thấp.
• Đo đạc hiệu năng bao gồm: success, time, errors, …
• Đo đạc chủ quan: báo cáo của người dùng về tỷ lệ hài lòng và thoải mái.

6.3.3. Ví dụ về Usability Test Session

– Dưới đây là một ví dụ thử nghiệm.

1. Người điều phối chào mừng người tham gia và giải thích test session, hỏi người tham gia để ký vào release form, và đưa ra bất kỳ pre-test hay câu hỏi nào.
2. Người điều phối giải thích suy nghĩ và hỏi xem người tham gia có bất kỳ câu hỏi nào thêm không. Người điều phối giải thích sẽ bắt đầu từ đâu.
3. Người tham gia đọc kịch bản công việc và bắt đầu làm việc với scenario trong suy nghĩ của họ.
4. Người ghi chú sẽ ghi lại toàn bộ hành vi, bình luận, lỗi và việc hoàn thành (thành công hoặc thất bại) của công việc.
5. Session làm việc cho đến khi toàn bộ scenarios hoàn thành hoặc thời gian đã hết.
6. Người điều tiết đưa ra các câu hỏi chủ quan vào cuối session hoặc gửi chúng vào một online survey, cảm ơn những người tham gia. Sau đó người điều tiết thiết lập lại toàn bộ vật chất và thiết bị; nói ngắn gọn với người quan sát và đợi cho đến khi người tham gia tiếp theo

6.4. Báo cáo các kết quả Usability Test

– Khi báo cáo kết quả từ một thử nghiệm khả năng sử dụng, bạn nên tập trung chủ yếu vào việc phát hiện và kiến nghị của bạn được phân biệt theo mức độ nghiêm trọng. Bao gồm các thông tin cần thiết từ các kế hoạch kiểm tra và hiện chi tiết chỉ đủ để phương pháp này là xác định được. Giữ các phần ngắn, sử dụng bảng để hiển thị các số liệu, và sử dụng các ví dụ trực quan để chứng minh vấn đề khu vực, khi có thể.

6.4.1. Phân tích dữ liệu

– Vào cuối của thử nghiệm khả năng sử dụng, bạn sẽ thu thập được một số loại dữ liệu dựa trên các số liệu bạn đã xác định trong kế hoạch kiểm tra của bạn. Khi phân tích các dữ liệu bạn đã thu thập được, đọc qua các ghi chú cẩn thận tìm kiếm các mô hình và chắc chắn để thêm một mô tả về từng vấn đề. Trông cho các xu hướng và giữ một số vấn đề đã xảy ra trên những người tham gia.

– Quantitative Data

• Chuyển dữ liệu vào một spreadsheet từ dữ liệu ghi được, tạo ra sự tính toán như :
  • Success rates
  • Task time
  • Error rates
  • Satisfaction questionnaire ratings
• Bạn có thể muốn thêm vào dữ liệu demographic của người tham gia, do vậy bạn có thể sắp xếp theo demographic để thấy nếu có bất kỳ dữ liệu nào cần lọc theo giá trị demographic.
• Đảm bảo bạn xác định các task scenarios cho mỗi metrics.
• Record data liên quan đến:
  • Observations about pathways participants took
  • Problems experienced
  • Comments / recommendations
  • Answers to open-ended questions
• Đảm bảo các trạng thái vấn đề của bạn chính xác và ngắn ngọn. Ví dụ:
  • Good problem statement: Đã nhấp vào liên kết để Research thay thế Clinical Trials.
  • Poor problem statement: Đã nhấp vào liên kết sai.
  • Poor problem statement: Đã nhầm lẫn về các liên kết.

6.4.2. Báo cáo các mực độ nghiêm trọng của vấn đề

– Khi bạn đang xem xét các dữ liệu, xem xét toàn bộ vấn đề qua site như thế nào và vấn đề nghiêm trọng như thế nào. Phát hiện của bạn có thể có ý nghĩa đối với các trang khác trong trang (toàn cầu). Ví dụ, bạn có thể thấy rằng những người tham gia không thể tìm thấy những gì họ cần vào trang do mật độ văn bản. Bạn có thể nói rằng trang cần phải được fix, nhưng bạn cũng nên xem xét có bao nhiêu trang còn lại cũng rất dày đặc với văn bản.

– Một số vấn đề được đóng góp từ những người tham gia không thể hoàn thành các scenarios nhiều hơn những cái khác. Để phân biệt, bạn nên ghi lại mức độ nghiêm trọng của vấn đề trên 3 hoặc 4 điểm. Ví dụ :

• Critical: Nếu chúng ta không sửa lỗi này, người dùng sẽ không thể hoàn thành kịch bản.
• Serious: Nhiều người dùng sẽ thất vọng nếu chúng ta không sửa lỗi này; họ có thể từ bỏ.
• Minor: Người dùng đang khó chịu, nhưng điều này không giữ cho chúng khỏi hoàn thành kịch bản. Điều này cần được xem xét lại sau.

6.4.3. Viết báo cáo Usability Test

– Nói chung, báo cáo nên gồm 1 bản tóm lược, phương pháp, các kết quả kiểm thử, các phát hiện và các kiến nghị.

• Background Summary: Bao gồm một bản tóm tắt ngắn gọn bao gồm cả những gì bạn đã thử nghiệm, ở đâu và khi nào, thông tin thiết bị, những gì bạn đã làm trong thời gian thử nghiệm (bao gồm toàn bộ vật liệu kiểm thử như một phụ lục), nhóm nghiên cứu thử nghiệm, và một mô tả ngắn gọn trong những vấn đề gặp phải cũng như những gì đã làm việc tốt.
• Methodology: Bao gồm các phương pháp thử nghiệm có thể tái tạo các kiểm thử. Giải thích làm thế nào bạn tiến hành các thử nghiệm bằng cách mô tả các test sessions, các loại hình giao diện được kiểm thử, số liệu thu thập được, và tổng quan về kịch bản. Mô tả những người tham gia và cung cấp bảng tóm tắt câu hỏi background/demographic (ví dụ, tuổi, nghề nghiệp, việc sử dụng Internet, site visited, …). Cung cấp bản tóm tắt ngắn gọn về các dữ liệu demographic, nhưng không bao gồm đầy đủ tên của những người tham gia.
• Test Results: Bao gồm một phân tích về những người điều phối và dữ liệu được ghi lại. Mô tả các tasks có tỷ lệ hoàn thành cao nhất và thấp nhất. Cung cấp bản mô tả cho tỷ lệ hoàn thành của các task thành công, tỷ lệ task và thành công cung bình bởi task và dữ liệu được hiển thị trong bảng. Thực hiện mô hình chung cho toàn bộ metrics. Phụ thuộc vào các metrics mà bạn đã tập hợp:
  • Số lượng và phần trăm người tham gia hoàn thành mỗi scenario, và toàn bộ scenarios (một bản đồ thì được khuyến thích)
  • Thời gian trung bình cần hoàn thành mỗi scenarios cho những người hoàn thành scenarios
  • Các kết quả hài lòng
  • Participant comments can be included if they are illustrative.
  • Các ý kiến của người tham gia có thể được gộp vào nếu chúng là minh họa.
• Findings and Recommendations: Danh sách các phát hiện và khuyến nghị sử dụng toàn bộ dữ liệu của bạn. Mỗi phát hiện cần phải có cơ sở trong dữ liệu – cái mà bạn thực sự nhìn thấy và nghe thấy. Bạn có thể chỉ có một danh sách tổng thể các phát hiện và khuyến nghị hoặc bạn có thể muốn có những phát hiện và khiến nghị từ kịch bản này sang kịch bản khác, hoặc bạn có thể muốn cả hai nhưng cắt qua các kịch bản như báo cáo scenario này đến scenario khác. Hãy ghi nhớ:
  • Mặc dù hầu hết các báo cáo usability test đều tập trung vào problems, nó cũng hữu dụng để báo cáo các phát hiện.
  • Một báo cáo hoàn toàn tiêu cực có thể làm chán nản; nó giúp nhóm biết website cần thực hiện tốt hơn.
  • Mỗi phát hiện nên càng cụ thể tình hình càng tốt.
  • Mỗi phát hiện (hoặc nhóm những phát hiện liên quan) nên gộp cả những khuyến nghị cần làm.

6.4.4. Các kết hợp để minh họa các điểm đặc trưng

– Bạn có thể làm báo cáo cả thông tin mới hơn và thú vị hơn bằng cách bao gồm nội dung trực quan. Bạn có thể xem xét bao gồm: * Chụp màn hình để người đọc hình dung những thứ mà bạn kiểm thử: Bao gồm các phần của màn hình để minh họa các khu vực cụ thể đang làm việc đặc biệt tốt hoặc đang gây ra vấn đề cho người dùng. * Những video clips ngắn để minh họa các điểm đặc trưng: Nếu bạn đang trình bày báo cáo điện tử và người đọc báo cáo có công nghệ như xem video clips. Những người không quan sát test session thực hết thường thuyết phục các vấn đề và yêu cầu sửa chúng bằng cách xem và nghe một vài video clips liên quan.

6.4.5. Hoàn thành và kiểm thử lại

– Đối với một usability test có một số giá trị, bạn nên sử dụng những cái mà bạn học để cải tiến site. Bạn có thể không hoàn thành toàn bộ khuyến nghị. Phát triển một số sản phẩm là loạt các thỏa hiệp mà bạn cân bằng tiến độ, ngân sách, khả năng con người, và những thay đổi cần thiết. Nếu bạn không hoàn thành toàn bộ khuyến nghị, phát triển theo thứ tự ưu tiên dựa vào việc sửa chữa các vấn đề cục bộ nhất và nghiêm trọng nhất. Như bạn đánh thứ tự ưu tiên, đẩy lên để thu được những thay đổi mà người dùng cần.

– Hãy nhớ rằng các chi phí hỗ trợ người dùng của một trang thiết kế nghèo nàn thì lớn hơn nhiều so với chi phí sửa chữa site trong khi nó vẫn đang phát triển.

7. Tham khảo

https://www.usability.gov