Kiểm tra khả năng sử dụng từng bước hoặc đánh giá thiết kế HCD. Kiểm tra khả năng sử dụng

Có nhiều cách để nhanh chóng đánh giá khả năng sử dụng của một trang web. Bạn có thể thử những điều sau: Kiểm tra khả năng sử dụng trong 5 giây, Kiểm tra nhấp chuột, Kiểm tra câu hỏi kết thúc mở, Kiểm tra điều hướng, Kiểm tra ưu tiên, Survey Monkey, Kiểm tra hành lang (thử trực tiếp hoặc qua bản trình bày Skype, Google Hangouts)

Ghi chú của tác giả: Các dịch vụ trong nước để kiểm tra khả năng sử dụng: https://uxcrowd.ru, http://sitepolice.ru/, https://www.userpoint.ru/, Webvisor

5 ví dụ về thu thập phản hồi

2. Đảm bảo bạn có được đúng người dùng. Bạn cần biết khách hàng lý tưởng của mình là ai. Chẳng ích gì khi tối ưu hóa trang web của bạn cho những người sẽ không bao giờ mua hàng của bạn.

3. Chuẩn bị bài phát biểu của bạn. Với tư cách là người điều hành, bạn phải đặt ra quan điểm cho việc kiểm tra. Cấu trúc các câu hỏi để đối tượng của bạn nói về những gì họ đánh giá cao và những gì họ cần.

4. Đặt những câu hỏi mở. Nói chuyện với người trả lời.

5. Sử dụng phân khúc. Phân khúc người dùng của bạn dựa trên số liệu LTV (giá trị trọn đời của khách hàng) của họ.

6. Lập kế hoạch hành động mà người trả lời cần thực hiện.. Những điều này phải dựa trên các chức năng chính, phụ và cấp ba của sản phẩm của bạn.

Công cụ ghi lại người dùng cho phép bạn phân khúc đối tượng của mình dựa trên nguồn lưu lượng truy cập, nhân khẩu học, hành vi và hành động. Về ngữ cảnh, tốt nhất bạn nên nhóm các phiên đã ghi lại thành các nhóm cá nhân quen thuộc của bạn.

7. Tránh gây ảnh hưởng tới ý kiến ​​của người trả lời. Đối với bài kiểm tra thể chất, hãy cố gắng hết sức để trở thành người điều hành khách quan.

8. Sử dụng đồng hồ hẹn giờ. Bạn cũng nên xác định các điểm khó khăn bằng cách xác định và ghi lại những khoảnh khắc gây bất tiện nhất cho người dùng: tạm dừng, cuộn dài, nhấp chuột lạ.

9. Người dùng biết họ đang bị theo dõi sẽ cố gắng làm mọi thứ “quá đúng”. Họ đã biết họ cần gì và điều này có thể làm hỏng dữ liệu của bạn và làm sai lệch những con số cuối cùng. Để có kết quả tốt nhất, hãy cố gắng hết sức để mô phỏng một môi trường tự nhiên, thoải mái để tương tác với sản phẩm của bạn.

Nếu bạn sử dụng những lời khuyên này, bạn sẽ yêu thích công việc thử nghiệm giống như chúng tôi.

Phân tích kết quả

“Tổng biên tập blog GetGoodRank, nhà phân tích web, blogger.
Hướng dẫn từng bước về cách tự mình thực hiện kiểm tra khả năng sử dụng với mức đầu tư tối thiểu. Làm thế nào để phân tích kết quả và có những lựa chọn thay thế nào.”

Kiểm tra khả năng sử dụng xác định các vấn đề không rõ ràng, phi kỹ thuật của trang web, ứng dụng hoặc giao diện cản trở việc chuyển đổi khách truy cập thành khách hàng. Và vì vậy, công ty mất thu nhập. Lỗi khả năng sử dụng dẫn đến sự suy giảm các yếu tố hành vi, ảnh hưởng đến thứ hạng của trang web trong tìm kiếm và dẫn đến giảm vị trí. Trong bài đánh giá này, chúng tôi sẽ hướng dẫn bạn cách tự mình tiến hành kiểm tra khả năng sử dụng.

Tại sao phải tiến hành kiểm tra khả năng sử dụng?

Giao diện được sắp xếp hợp lý, thân thiện với người dùng sẽ tạo ấn tượng tích cực đầu tiên.

Cấu trúc chính xác, đơn giản của trang web cho phép khách hàng nhanh chóng tìm thấy thông tin cần thiết, đặt mua sản phẩm, làm quen với dịch vụ và liên hệ với công ty.

Các trang web được tối ưu hóa giúp người dùng đưa ra quyết định mua hàng và đặt hàng cuối cùng dễ dàng hơn.

Một trang web thân thiện với người dùng sẽ truyền cảm hứng cho sự tin tưởng và tăng lòng trung thành với thương hiệu.

Làm thế nào để tự mình tiến hành kiểm tra khả năng sử dụng?

Ai sẽ kiểm tra trang web và tìm người dùng để kiểm tra ở đâu?

Lý tưởng nhất là trang web của bạn nên được thử nghiệm bởi những người dùng gần với đối tượng mục tiêu của bạn. Sự trùng khớp càng chính xác thì kết quả kiểm tra sẽ càng mang tính đại diện. Ai có thể trở thành người thử nghiệm:

Khách hàng/khách truy cập trang web thực tế- bạn có thể mời khách truy cập trang web tham gia vào một nghiên cứu/khảo sát/kiểm tra ngắn để cải thiện trang web. Khiếu nại có thể được đưa ra thông qua khối thông tin đầu cuối, cửa sổ bật lên ở lối ra khỏi trang web hoặc tin nhắn e-mail cá nhân đến cơ sở người đăng ký/khách hàng.

Thuận lợi: sự tương ứng tối đa giữa người thử nghiệm và người dùng mục tiêu.
Sai sót: người dùng đã quen thuộc với trang web và đã biết cách vượt qua “những trở ngại”.

Trao đổi tự do, mạng xã hội- một số công ty đang cố gắng thu hút người dùng mới tham gia thử nghiệm bằng cách đăng một ưu đãi lên mạng xã hội hoặc trên các sàn giao dịch việc làm tự do. Theo quy định, một dịch vụ như vậy không tốn kém, nhưng phản hồi của người dùng không đặc biệt tích cực.

Thuận lợi:Đây là những người dùng mới chưa quen với dịch vụ, website, ứng dụng, công ty, dịch vụ, sản phẩm.

Sai sót:đòi hỏi phải đầu tư. Không phải lúc nào cũng có thể đạt được kết quả hợp lý. Thái độ của nhân viên đối với nhiệm vụ có thể là vô trách nhiệm. Không phải lúc nào cũng có thể tìm được người dùng gần đúng với đối tượng mục tiêu để thử nghiệm.

Các công ty chuyên ngành- bằng cách chọn tùy chọn thử nghiệm trả phí, bạn có thể liên hệ với đại lý sẽ cung cấp đối tượng mục tiêu mong muốn cho thử nghiệm.

Thuận lợi: một cách nhanh chóng để có đủ người dùng mục tiêu cho các cuộc thử nghiệm.

Sai sót: thường có chi phí cao.

Làm thế nào để tiến hành kiểm tra khả năng sử dụng?

Có hai loại thử nghiệm:

Kiểm duyệt hoặc kiểm soát- Bạn trực tiếp tham gia thi, hướng dẫn thí sinh, đặt câu hỏi, ghi chép. Để tiến hành kiểm tra khả năng sử dụng có kiểm soát, bạn sẽ cần bất kỳ ứng dụng nào hỗ trợ cuộc gọi video và quyền truy cập chung vào giao diện trang web (Skype, Google Hangouts). Để có thể ghi lại bài kiểm tra, bạn sẽ cần các công cụ trả phí như GoToMeeting hoặc Zoom.

Thử nghiệm không được kiểm duyệt hoặc không được kiểm soát- người dùng kiểm tra trang web hoặc ứng dụng theo hướng dẫn được cung cấp. Thử nghiệm như vậy càng gần với việc sử dụng thực tế của trang web càng tốt, vì người dùng chỉ dựa vào chính mình và không có nơi nào để mong đợi sự trợ giúp hoặc gợi ý từ bất cứ đâu. Bạn có thể tạo một nhiệm vụ kiểm tra bằng nhiều dịch vụ trực tuyến miễn phí và trả phí khác nhau.

Kiểm tra không được kiểm duyệt sẽ cung cấp kết quả chính xác hơn so với kiểm tra được kiểm duyệt. Ngoài ra, bạn sẽ không có cơ hội hoặc cám dỗ để can thiệp vào bài kiểm tra.

Cách viết kịch bản thử nghiệm

Bất kể loại thử nghiệm nào được chọn để kiểm tra trang web, bạn sẽ cần một tập lệnh hướng dẫn người dùng thông qua trang web và chỉ ra những phần và chức năng nào của trang web cần được kiểm tra.

Thông thường, đây là một chuỗi nhiệm vụ dẫn người dùng từ làm quen với công ty đến đưa ra lời đề nghị, lựa chọn, đưa ra quyết định và đặt hàng.

Các quy tắc cơ bản cho kịch bản xác minh trang web:

1. Bài kiểm tra phải mô phỏng lộ trình thực sự của người dùng quan tâm đến sản phẩm/dịch vụ. Để làm điều này, bạn có thể sử dụng dữ liệu từ hệ thống phân tích.

2. Bài thi phải rõ ràng, logic, dễ thực hiện.

3. Bài kiểm tra phải cung cấp cho người dùng thông tin cơ bản: ai, cái gì, khi nào, tại sao, tại sao.

4. Bài kiểm tra phải bao gồm các mục tiêu và không đưa ra hướng dẫn về cách đạt được mục tiêu này. Ví dụ: nhiệm vụ kiểm tra là mua một chiếc váy màu đỏ cỡ 42, thay vì mở danh mục, phần “váy mùa hè”, đặt bộ lọc theo kích cỡ và màu sắc, chọn một chiếc váy màu đỏ, trên trang sản phẩm cho biết kích thước, màu sắc. và nhấp vào thêm vào giỏ hàng (đây là dấu “cộng” bên cạnh hình ảnh sản phẩm).

5. Không sử dụng các thuật ngữ và biệt ngữ để đặt mục tiêu. Chúng phải đơn giản và rõ ràng.

Dữ liệu nào cần thu thập

Khi tiến hành kiểm tra khả năng sử dụng, điều quan trọng là phải có được hai bản ghi:

• quay video màn hình của người tham gia để xem đường đi, chuyển động của con trỏ và hiểu logic của hành động.
• giọng nói của người kiểm tra - trong quá trình kiểm tra, người dùng nhận xét về nhiệm vụ và những gì đang diễn ra trên màn hình, cho biết rằng anh ta không hiểu, những gì anh ta không thể tìm thấy, những gì anh ta không thể hoàn thành.

Từ những bản ghi này, bạn sẽ hiểu lý do tại sao người dùng nhấp vào nút cụ thể này hoặc đi đến phần cụ thể này, tại sao người dùng lại bị kẹt ở giai đoạn cụ thể này.

Dữ liệu hữu ích khác mà bạn có thể trích xuất từ ​​bản ghi:

• thời gian để hoàn thành nhiệm vụ
• số lượng người dùng đã hoàn thành nhiệm vụ
• số lần nhấp chuột cần thiết để hoàn thành nhiệm vụ

Có bao nhiêu bài kiểm tra để thực hiện

Các chuyên gia của NNGroup chỉ ra rằng chỉ cần thu hút 5 người dùng tiến hành thử nghiệm là đủ. Điều này sẽ đủ để xác định tới 80% lỗi về khả năng sử dụng trang web hoặc ứng dụng. Để có được mẫu dữ liệu định lượng chính xác hơn, thử nghiệm sẽ cần tới 20 người dùng.

Trong một số trường hợp, khi thử nghiệm các tùy chọn trang web riêng lẻ, 3 người dùng có thể là đủ.

Cách phân tích kết quả của bạn

Sau khi nhận được kết quả kiểm tra, điều quan trọng là phải xác định xem tầm nhìn của người dùng và cách sử dụng thực tế các chức năng và công cụ của trang web khác với cách sử dụng chức năng ban đầu.

Chia kịch bản kiểm tra thành các tiểu mục theo chủ đề: trang chủ, danh mục, tìm kiếm trang web, thẻ sản phẩm, giỏ hàng, danh bạ, v.v. Ghi lại nhận xét của người dùng, lỗi, khó khăn trong quá trình kiểm tra vào các phần thích hợp.

Bạn luôn có thể tiến hành phân tích toàn diện về trang web và đối thủ cạnh tranh tại GetGoodRank. Nó dễ dàng hơn, nhanh hơn và đáng tin cậy hơn. Chúng tôi không chỉ kiểm tra khả năng sử dụng mà còn đánh giá mức độ tin cậy đối với trang web và công ty nói chung, mức độ phù hợp về thông tin và thương mại, đồng thời chỉ ra những lợi thế của trang web của đối thủ cạnh tranh.

Trong một ngành phụ thuộc vào cách mọi người sử dụng sản phẩm, dịch vụ và ứng dụng của chúng tôi, nghiên cứu là điều cần thiết. Chúng tôi đặt câu hỏi. Chúng tôi ghi chép. Chúng tôi cố gắng tìm hiểu mọi thứ có thể về đối tượng mục tiêu của mình và sau đó thử nghiệm tương tác công việc của mình trong quá trình thiết kế.

Nghiên cứu UX (hoặc nghiên cứu thiết kế) có nhiều mục đích tùy thuộc vào giai đoạn của công việc. Chúng giúp chúng ta xác định và sau đó chứng minh hoặc bác bỏ các giả định của mình, tìm ra điểm tương đồng giữa các thành viên của đối tượng mục tiêu và hiểu nhu cầu, mục tiêu cũng như hình mẫu tinh thần của họ. Nghiên cứu cung cấp cho chúng ta dữ liệu cần thiết để thực hiện công việc, cải thiện sự hiểu biết và hỗ trợ các quyết định của chúng ta.

Nghiên cứu UX là gì?

Nghiên cứu UX bao gồm nhiều phương pháp được sử dụng để thu thập thông tin. Nhưng các nhà thiết kế đã không phát minh ra điều gì mới. Nhiều kỹ thuật đã được vay mượn từ các lĩnh vực học thuật, khoa học và tiếp thị. Tuy nhiên, cũng có một số loại nghiên cứu chỉ dành riêng cho thế giới UX.

Chủ yếu mục tiêu nghiên cứu thiết kế – để cung cấp thông tin cho quá trình thiết kế tập trung vào người dùng cuối. Điều này giúp bạn tránh được lỗi thường gặp khi tạo ra một thiết kế chỉ dành cho riêng mình. Chính nghiên cứu giúp chúng tôi hiểu người dùng cuối là ai, họ sẽ sử dụng sản phẩm trong bối cảnh nào và họ cần gì.

Nghiên cứu bao gồm hai phần: thu thập dữ liệu và xử lý dữ liệu để cải thiện khả năng sử dụng. Khi bắt đầu một dự án, nghiên cứu thiết kế tập trung vào việc xác định các yêu cầu của dự án từ ban quản lý cũng như mục tiêu và nhu cầu của người dùng cuối. Điều này bao gồm tiến hành các cuộc phỏng vấn, khảo sát, nghiên cứu người dùng tiềm năng hoặc người dùng hiện tại và phân tích tài liệu và dữ liệu hiện có. Sau đó, nghiên cứu bắt đầu tập trung vào khả năng sử dụng và ý kiến ​​về sản phẩm. Ở giai đoạn này, thử nghiệm A/B được thực hiện, phỏng vấn người dùng về quá trình tương tác và thử nghiệm các giả định có thể cải thiện thiết kế.

Các phương pháp nghiên cứu hiện tại có thể được chia thành hai phe:

• Nghiên cứu định lượng- mọi thứ có thể đo được bằng số. Họ trả lời những câu hỏi như: “Có bao nhiêu người đã nhấp vào nút này?” hoặc “Bao nhiêu phần trăm người dùng có thể tìm thấy lời kêu gọi hành động?” Dữ liệu này hữu ích khi xác định xác suất thống kê và nghiên cứu trên trang web hoặc ứng dụng.
• Nghiên cứu định tính giúp hiểu lý do tại sao người dùng thực hiện một số hành động nhất định. Chúng thường được thực hiện dưới hình thức phỏng vấn hoặc trò chuyện. Những câu hỏi như thế này được sử dụng: “Tại sao mọi người chú ý đến lời kêu gọi hành động?” hoặc “Mọi người còn chú ý điều gì khác trên trang này?”

Một số nhà nghiên cứu có thể chỉ chuyên về một số loại phỏng vấn hoặc bài kiểm tra nhất định, nhưng hầu hết đều sử dụng nhiều kỹ thuật khác nhau trong quá trình thực hành của họ.

Kỹ thuật chung

Tất cả các loại nghiên cứu UX khác nhau, từ phỏng vấn cá nhân đến thử nghiệm A/B, đều dựa trên ba kỹ thuật: quan sát, hiểu biết và phân tích.

Quan sát

Bước đầu tiên trong việc tiến hành nghiên cứu là học cách quan sát. Các chuyên gia mới vào nghề phải học lại cách xem: chú ý các tín hiệu cho biết trạng thái của người dùng đang được phỏng vấn hoặc chú ý đến những chi tiết nhỏ nhất mà sau đó có thể ảnh hưởng đáng kể đến dự án.

Quan sát tưởng chừng như là một kỹ năng rất đơn giản nhưng nó thường bị lu mờ bởi những thành kiến ​​trong tiềm thức. Vì vậy, các nhà nghiên cứu tự rèn luyện khả năng quan sát và ghi chép để sau này có thể tìm ra những điểm tương đồng giữa một nhóm người có vẻ khác nhau.

Hiểu biết

Cũng giống như quan sát, hiểu biết là điều tất cả chúng ta đều làm trong cuộc sống hàng ngày. Chúng tôi cố gắng hiểu đồng nghiệp, thành viên gia đình và bạn bè của mình, lý do dẫn đến những cuộc cãi vã và hành vi bất thường của họ đối với chúng tôi. Hiểu các mô hình tinh thần là trọng tâm của nghiên cứu UX.

Mô hình về tinh thần là sự thể hiện suy nghĩ của mọi người về một cụm từ hoặc tình huống nhất định. Ví dụ, mô hình tư duy về chiếc ô tô của những người sở hữu xe SUV sẽ khác với mô hình tư duy của những người lái xe điện. Mô hình tinh thần ảnh hưởng đến quyết định. Nếu bạn hỏi những người lái xe ô tô: “Mất bao lâu để đi từ Moscow đến St. Petersburg,” thì ngoài tất cả các dữ liệu khác, họ cũng sẽ tập trung vào đặc điểm của chiếc xe của họ.

Các nhà nghiên cứu cần hiểu mô hình tinh thần của những người họ phỏng vấn vì hai lý do:

• Thứ nhất, mọi giao tiếp đều bị giới hạn về mặt thời gian. Các nhà nghiên cứu phải xác định bất kỳ sự rút gọn nào dựa trên mô hình tinh thần của người nói.
• Thứ hai, nếu nhà nghiên cứu có thể xác định rõ ràng mô hình tinh thần của người dùng, điều này sẽ giúp các nhà thiết kế tạo ra một sản phẩm đáp ứng được mong đợi.

Phân tích

Bản thân nghiên cứu có thể có giá trị, nhưng để sử dụng những phát hiện trong thiết kế, chúng cần được phân tích và trình bày cho các thành viên khác trong nhóm. Phân tích là quá trình xác định cấu trúc của nghiên cứu, xây dựng các cơ sở lý luận hoặc các giải pháp khả thi và các khuyến nghị.

Một số kỹ thuật phân tích liên quan đến việc tạo ra các cá tính và tập lệnh để mô tả các mô hình hoặc bảng và biểu đồ tinh thần phản ánh số liệu thống kê và hành vi của người dùng. Điều quan trọng cần nhớ là kết quả nghiên cứu phải được chia sẻ.

Các loại nghiên cứu

Mỗi dự án UX đều khác nhau nên danh sách nhiệm vụ có thể khác nhau đáng kể. Các hình thức nghiên cứu phổ biến nhất: phỏng vấn, khảo sát và bảng câu hỏi, phân loại thẻ, kiểm tra khả năng sử dụng, kiểm tra thứ bậc và kiểm tra A/B.

Phỏng vấn

Phỏng vấn cá nhân là một phương pháp giao tiếp đã được thử nghiệm và chứng minh giữa nhà nghiên cứu và người sử dụng hoặc người quản lý. Có ba loại phỏng vấn chính, mỗi loại có mục đích khác nhau:

• Phỏng vấn tiêu chuẩn- loại phổ biến nhất. Đây là những cuộc phỏng vấn hỏi đáp điển hình trong đó nhà nghiên cứu đặt những câu hỏi cụ thể. Nó có thể hữu ích khi giao tiếp với số lượng lớn người dùng khi bạn cần so sánh và đối chiếu các câu trả lời.
• Phỏng vấn miễn phí là một cách tuyệt vời để hiểu rõ hơn về người dùng hoặc người quản lý. Nhà nghiên cứu đặt ra những ranh giới nhất định và bắt đầu cuộc trò chuyện. Trong cuộc phỏng vấn, người sử dụng (hoặc người quản lý) phải là người nói chủ yếu, người trình bày chỉ có thể yêu cầu giải thích điều gì đó hoặc nói chi tiết hơn.
• Phỏng vấn dân tộc học cho phép bạn tìm hiểu thói quen của mọi người và hiểu hành vi điển hình của họ. Người dùng cho biết cách anh ta thực hiện hành động này hoặc hành động đó. Một cuộc phỏng vấn như vậy cho phép bạn đánh giá khoảng cách giữa những gì mọi người nói và những gì họ làm.

Khảo sát và bảng câu hỏi

Chuẩn bị, phỏng vấn và thu thập dữ liệu

Để đánh dấu

Natalia Sprogis, người đứng đầu nghiên cứu UX tại Mail.Ru Group, đã phát biểu trên blog của công ty trên Habrahabr về việc chuẩn bị và tiến hành kiểm tra khả năng sử dụng: những gì cần đưa vào tập lệnh kiểm tra, cách chọn phương pháp thu thập dữ liệu, tạo nhiệm vụ và thu thập ấn tượng của người trả lời .

Một mặt, kế hoạch thử nghiệm là một tập hợp các nhiệm vụ, câu hỏi và bảng câu hỏi mà bạn đưa ra cho từng người trả lời, mặt khác, nó là cơ sở phương pháp luận của nghiên cứu: các số liệu và giả thuyết mà bạn kiểm tra và ghi lại, các công cụ đã chọn.

Việc kiểm tra có thực sự cần thiết?

Đầu tiên, bạn phải chắc chắn rằng ở giai đoạn này dự án cần kiểm tra khả năng sử dụng. Do đó, hãy làm rõ mục đích mà nhóm dự án liên hệ với bạn. Kiểm tra khả năng sử dụng không phải là toàn năng và ngay từ đầu, bạn cần hiểu nó có thể mang lại những gì cho sản phẩm. Hãy chuẩn bị ngay cho nhóm dự án của bạn để biết câu hỏi nào bạn có thể trả lời và câu hỏi nào bạn không thể trả lời. Đã có những trường hợp chúng tôi cung cấp cho khách hàng một phương pháp khác (ví dụ: phỏng vấn sâu hoặc nghiên cứu nhật ký hiện tốt hơn) hoặc đề nghị họ từ bỏ hoàn toàn nghiên cứu và thay vào đó thực hiện một bài kiểm tra phân tách.

Ví dụ: chúng tôi không bao giờ kiểm tra “độ hấp dẫn” của một tính năng hoặc phương án thiết kế trong nghiên cứu định tính. Chúng tôi có thể thu thập phản hồi từ người dùng, nhưng có nguy cơ rất lớn là phản hồi của họ sẽ bị ảnh hưởng bởi mong muốn của xã hội. Mọi người luôn có xu hướng nói rằng họ sẽ sử dụng ngay cả những gì họ sẽ không sử dụng. Và cỡ mẫu nhỏ không cho phép chúng ta tin tưởng vào những câu trả lời như vậy. Ví dụ: chúng tôi đã có trải nghiệm không thành công khi thử nghiệm trang đích trò chơi: trang đích được chọn là hấp dẫn nhất trong thử nghiệm hoạt động kém hơn nhiều trong quá trình thử nghiệm A/B.

Việc thử nghiệm các nguyên mẫu và khái niệm cũng có một số hạn chế. Khi lập kế hoạch, bạn phải hiểu những gì bạn thực sự có thể đạt được từ bài kiểm tra này. Thật tuyệt vời khi một dự án có cơ hội thử nghiệm nguyên mẫu hoặc thiết kế trước khi triển khai. Tuy nhiên, nguyên mẫu càng ít chi tiết và hoạt động tốt thì mức độ trừu tượng đối với người trả lời càng cao thì dữ liệu thu được từ thử nghiệm càng ít. Tốt nhất nên thử nghiệm các nguyên mẫu để xác định các vấn đề về cách đặt tên và ẩn dụ của các biểu tượng, tức là mọi vấn đề về tính dễ hiểu. Khả năng thử nghiệm bất cứ điều gì ngoài điều này phụ thuộc rất nhiều vào bản chất của dự án và chi tiết của nguyên mẫu.

Cơ sở để viết kịch bản kiểm thử khả năng sử dụng

Lập kế hoạch kiểm tra không bắt đầu bằng việc viết văn bản của các nhiệm vụ mà bằng việc xây dựng chi tiết các mục tiêu và câu hỏi nghiên cứu cùng với nhóm dự án. Đây là cơ sở để lập kế hoạch:

Kịch bản quan trọng.Đây là những kịch bản người dùng (nhiệm vụ hoặc trường hợp sử dụng) ảnh hưởng đến hoạt động kinh doanh hoặc có liên quan đến mục đích thử nghiệm. Ngay cả khi nhóm nghi ngờ có vấn đề trong các lĩnh vực cụ thể, việc kiểm tra các trường hợp cơ bản vẫn thường đáng giá. Trong trường hợp này, các tình huống sau có thể được coi là quan trọng đối với thử nghiệm:

• thường xuyên nhất (ví dụ: gửi tin nhắn trong trình nhắn tin);
• ảnh hưởng đến mục tiêu kinh doanh (ví dụ: làm việc với hình thức thanh toán);
• liên quan đến bản cập nhật (những bản cập nhật bị ảnh hưởng bởi thiết kế lại hoặc giới thiệu chức năng mới).

Sự cố đã biết Thông thường, nghiên cứu phải đưa ra câu trả lời cho nguyên nhân gây ra vấn đề trong kinh doanh dịch vụ. Ví dụ: nhà sản xuất lo ngại về lượng lớn người chơi bỏ đi sau giờ đầu tiên của trò chơi. Và đôi khi nhóm có vấn đề về giao diện đã biết và bạn cần thu thập thông tin chi tiết và thông tin cụ thể. Ví dụ: dịch vụ hỗ trợ thường được liên hệ khi có thắc mắc về hình thức thanh toán.

Câu hỏi. Nhóm cũng có thể có các câu hỏi cần nghiên cứu: ví dụ: người dùng có để ý thấy biểu ngữ quảng cáo các dịch vụ bổ sung không; Một phần nhất định có được đặt tên rõ ràng không?

Giả thuyết.Đây là những vấn đề và câu hỏi đã biết của nhóm được dịch sang. Thật tốt nếu khách hàng đến với bạn với những giả thuyết có sẵn - ví dụ: “Khách hàng của chúng tôi chỉ thanh toán qua điện thoại kèm theo hoa hồng. Người dùng có thể không thấy lựa chọn phương thức thanh toán có lợi hơn.” Nếu không có giả thuyết nào mà chỉ có mong muốn kiểm tra dự án một cách trừu tượng “về khả năng sử dụng”, thì nhiệm vụ của bạn là hình thành các giả thuyết này.

Hãy cùng nhóm dự án suy nghĩ về những nơi mà người dùng không cư xử như mong đợi (nếu có thông tin đó). Tìm hiểu xem có bất kỳ yếu tố thiết kế nào đã được tranh luận nhiều và có thể có vấn đề hay không. Thực hiện kiểm tra sản phẩm của riêng bạn để tìm ra các vấn đề tiềm ẩn cần được kiểm tra đối với người dùng. Tất cả điều này sẽ giúp bạn lập danh sách các yếu tố (nhiệm vụ, câu hỏi, kiểm tra) cần có trong tập lệnh cuối cùng.

Phương pháp thu thập dữ liệu

Điều quan trọng là xem xét cách bạn sẽ thu thập dữ liệu về những gì xảy ra trong quá trình thử nghiệm để phân tích sau này. Các tùy chọn sau đây thường được sử dụng:

Quan sát. Trong khi hoàn thành nhiệm vụ, người trả lời ở một mình với sản phẩm và cư xử theo cách mà anh ta thấy phù hợp. Ý kiến ​​của người trả lời được thu thập thông qua bảng câu hỏi và trao đổi với người điều hành sau bài kiểm tra. Đây là phương pháp “sạch nhất”; nó cung cấp hành vi tự nhiên hơn của người trả lời và khả năng đo lường chính xác một số số liệu (ví dụ: thời gian để hoàn thành một nhiệm vụ).

Tuy nhiên, có rất nhiều dữ liệu định tính hữu ích đằng sau hậu trường. Khi nhìn thấy hành vi này hay hành vi kia của người trả lời, bạn không thể hiểu tại sao anh ta lại hành động như vậy. Tất nhiên, bạn có thể hỏi về điều này khi kết thúc bài kiểm tra, nhưng rất có thể người trả lời sẽ chỉ nhớ rõ nhiệm vụ cuối cùng. Ngoài ra, trong quá trình hoàn thành nhiệm vụ, ý kiến ​​​​của anh ấy về hệ thống có thể thay đổi và bạn sẽ chỉ nhận được bức tranh cuối cùng chứ không phải ấn tượng đầu tiên.

Hãy suy nghĩ thành tiếng (suy nghĩ thành tiếng). Trong một thời gian dài, phương pháp này được sử dụng thường xuyên nhất trong việc kiểm tra khả năng sử dụng. Jakob Nielsen từng gọi nó là công cụ đánh giá khả năng sử dụng chính. Vấn đề là bạn yêu cầu người trả lời nói lên tất cả những suy nghĩ nảy sinh khi làm việc với giao diện và nhận xét về mọi hành động của anh ta. Nó trông giống như thế này: “Bây giờ tôi sẽ thêm mặt hàng này vào giỏ hàng của mình. Nút ở đâu? À, cô ấy đây rồi. Ồ, tôi quên xem nó có màu gì.”

Phương pháp này giúp hiểu lý do tại sao người dùng hành xử theo cách này hay cách khác và những cảm xúc mà tương tác hiện tại gợi lên ở anh ta. Nó rẻ và đơn giản, ngay cả một nhà nghiên cứu thiếu kinh nghiệm cũng có thể xử lý được.

Tuy nhiên, nó có nhược điểm của nó. Đầu tiên, không phải tự nhiên mà mọi người lúc nào cũng “nghĩ lớn tiếng”. Họ thường sẽ im lặng và bạn sẽ phải liên tục nhắc nhở họ tiếp tục nói. Thứ hai, các nhiệm vụ sử dụng phương pháp này sẽ mất nhiều thời gian hơn để hoàn thành so với ngoài đời thực. Ngoài ra, một số người được hỏi bắt đầu sử dụng sản phẩm một cách chu đáo hơn. Bằng cách nêu rõ lý do cho hành động của mình, họ cố gắng hành động hợp lý hơn và đơn giản là họ không muốn trông giống những kẻ ngốc và bạn có thể không nắm bắt được một số khoảnh khắc trực quan về hành vi của họ.

Sự can thiệp của người điều hành tích cực. Phương pháp này lý tưởng để thử nghiệm các khái niệm và nguyên mẫu. Trong khi hoàn thành nhiệm vụ, người điều hành tích cực tương tác với người dùng: vào đúng thời điểm, anh ta tìm ra lý do cho hành vi của mình và đặt những câu hỏi làm rõ. Trong một số trường hợp, người điều hành thậm chí có thể đưa ra các nhiệm vụ ngoài kế hoạch phát sinh từ cuộc đối thoại.

Phương pháp này cho phép bạn thu thập lượng dữ liệu chất lượng tối đa. Tuy nhiên, nó chỉ có thể được sử dụng nếu bạn tin tưởng vào tính chuyên nghiệp của người điều hành. Các câu hỏi được xây dựng không chính xác hoặc được đặt không đúng lúc có thể ảnh hưởng lớn đến hành vi và ấn tượng của người trả lời, thậm chí làm mất hiệu lực của kết quả kiểm tra. Ngoài ra, khi sử dụng phương pháp này, hầu như không đo được số liệu nào.

Hãy suy nghĩ lại quá khứ, RTA (hồi tưởng).Đây là sự kết hợp của hai phương pháp đầu tiên. Trước tiên, người dùng hoàn thành tất cả các nhiệm vụ mà không bị can thiệp, sau đó một video về công việc của anh ta được phát trước mặt anh ta và anh ta nhận xét về hành vi của mình cũng như trả lời các câu hỏi của người điều hành. Nhược điểm chính của phương pháp là thời gian thử nghiệm tăng lên rất nhiều. Tuy nhiên, có những lúc nó là tối ưu.

Ví dụ: một lần chúng tôi phải đối mặt với nhiệm vụ thử nghiệm một số loại mob (quái vật trong trò chơi) trong một game nhập vai. Đương nhiên, chúng tôi không thể đánh lạc hướng người trả lời bằng các câu hỏi cũng như không thể buộc họ bình luận về hành động của họ trong trận chiến. Điều này sẽ khiến cho việc chơi một trận đấu cần sự tập trung để giành chiến thắng là không thể. Mặt khác, người dùng sẽ khó có thể nhớ được sau một loạt cơn co thắt liệu mình có nhận thấy chiếc rìu phát sáng màu đỏ ở con chuột đầu tiên hay không. Vì vậy, trong thử nghiệm này chúng tôi đã sử dụng phương pháp RTA. Với mỗi người dùng, chúng tôi xem lại các trận chiến của anh ấy và thảo luận về tác dụng của quái vật mà anh ấy nhận thấy cũng như cách anh ấy hiểu chúng.

Hãy thử nghĩ cách lấy đủ dữ liệu trong khi vẫn duy trì sự tự nhiên tối đa trong hành vi của người trả lời. Bất chấp sự đơn giản và linh hoạt của phương pháp “nghĩ lớn tiếng”, vốn từ lâu đã trở thành phương pháp phổ biến nhất trong thử nghiệm khả năng sử dụng, chúng tôi đang ngày càng cố gắng thay thế nó bằng quan sát. Nếu người điều hành thấy hành vi thú vị của người trả lời, anh ta sẽ đợi cho đến khi người này hoàn thành nhiệm vụ và đặt câu hỏi sau đó. Ngay sau khi làm nhiệm vụ, nhiều khả năng người trả lời sẽ nhớ lại lý do tại sao mình làm việc đó.

Máy theo dõi mắt giúp ích rất nhiều trong vấn đề này. Bằng cách nhìn thấy trọng tâm chú ý hiện tại của người trả lời, bạn có thể hiểu rõ hơn về hành vi của anh ta mà không cần hỏi những câu hỏi không cần thiết. Nhìn chung, eye track cải thiện đáng kể chất lượng điều độ, và theo tôi, vai trò này không kém phần quan trọng so với khả năng xây dựng hitmap.

Số liệu

Số liệu là các chỉ số định lượng về khả năng sử dụng. Kết quả của quá trình kiểm tra, bạn luôn nhận được một loạt vấn đề được tìm thấy trong giao diện. Các số liệu cho phép bạn hiểu mọi thứ tốt hay xấu như thế nào, đồng thời so sánh nó với một dự án khác hoặc các phiên bản thiết kế trước đó.

Các số liệu là gì?

Theo ISO 9241-11, các đặc điểm chính của khả năng sử dụng là hiệu quả, năng suất và sự hài lòng. Các số liệu khác nhau có thể phù hợp với các dự án khác nhau, nhưng tất cả chúng đều có mối liên hệ nào đó với ba đặc điểm này. Tôi sẽ viết về các chỉ số được sử dụng phổ biến nhất.

Hoàn thành xuất sắc nhiệm vụ. Bạn có thể sử dụng mã nhị phân: đã hoàn thành nhiệm vụ hoặc không thành công. Chúng tôi thường làm theo cách tiếp cận của Nielsen và phân biệt ba loại đánh giá thành công:

• hoàn thành nhiệm vụ mà hầu như không gặp vấn đề gì - 100%;
• gặp khó khăn nhưng hoàn thành nhiệm vụ một cách độc lập - 50%;
• nhiệm vụ thất bại - 0%.

Nếu trong số 12 người trả lời có 4 người hoàn thành nhiệm vụ dễ dàng, 6 người gặp khó khăn và 2 người thất bại thì tỷ lệ thành công trung bình của nhiệm vụ này sẽ là 58%.

Đôi khi bạn sẽ gặp phải tình huống trong đó nhóm giữa bao gồm những người trả lời có mức độ “có vấn đề” rất khác nhau. Ví dụ: một người trả lời gặp khó khăn với mọi trường biểu mẫu, trong khi người kia chỉ mắc một lỗi nhỏ ở cuối. Bạn có thể cho điểm theo ý mình, tùy thuộc vào những gì diễn ra trong bài kiểm tra. Ví dụ: 25% - nếu người trả lời mới bắt đầu hoàn thành nhiệm vụ hoặc 80% - nếu anh ta mắc một lỗi nhỏ.

Để tránh quá chủ quan, hãy cân nhắc thang đánh giá trước thay vì quyết định cho từng người trả lời sau khi kiểm tra. Nó cũng đáng để xem xét phải làm gì với lỗi. Ví dụ: bạn giao nhiệm vụ mua vé xem phim trong dự án Mail.Ru Cinema. Một trong những người được hỏi đã vô tình mua vé không phải cho ngày mai mà cho hôm nay và không để ý. Anh tự tin rằng mình đã hoàn thành nhiệm vụ và có tấm vé trong tay. Nhưng lỗi của anh ấy nghiêm trọng đến mức sẽ không được tham gia vào bộ phim nên tôi sẽ cho “0%”, mặc dù thực tế là vé đã được mua.

Tỷ lệ thành công là một thước đo rất đơn giản và rõ ràng và tôi khuyên bạn nên sử dụng nó nếu nhiệm vụ của bạn có mục tiêu rõ ràng. Nhìn vào biểu đồ thành công của nhiệm vụ cho phép bạn nhanh chóng xác định các khu vực có vấn đề nhất của giao diện.

Thời gian hoàn thành nhiệm vụ. Số liệu này chỉ mang tính biểu thị so sánh. Làm sao để biết người dùng hoàn thành nhiệm vụ trong 30 giây là tốt hay xấu? Nhưng thực tế là thời gian rút ngắn so với phiên bản trước của thiết kế thì đã tốt rồi. Hoặc thực tế là việc đăng ký dự án của chúng tôi mất ít thời gian hơn so với các đối thủ cạnh tranh. Có những giao diện trong đó việc giảm thời gian hoàn thành nhiệm vụ là rất quan trọng - ví dụ: giao diện làm việc của nhân viên trung tâm cuộc gọi.

Tuy nhiên, số liệu này không áp dụng được cho tất cả các nhiệm vụ. Hãy thực hiện nhiệm vụ chọn sản phẩm trong một cửa hàng trực tuyến. Người dùng nên nhanh chóng tìm thấy các bộ lọc và các thành phần giao diện khác liên quan đến việc tìm kiếm sản phẩm, nhưng bản thân quá trình lựa chọn sẽ đưa chúng vào những thời điểm khác nhau và điều này là hoàn toàn bình thường. Khi chọn giày, phụ nữ sẵn sàng xem qua 20 trang kết quả tìm kiếm. Và điều này không nhất thiết có nghĩa là không có bất kỳ sản phẩm nào phù hợp trên các trang đầu tiên hoặc họ không nhìn thấy bộ lọc. Thường thì họ chỉ muốn xem tất cả các lựa chọn.

Tần suất của các vấn đề. Bất kỳ báo cáo kiểm tra khả năng sử dụng nào cũng chứa danh sách các vấn đề mà người trả lời gặp phải. Số lượng người trả lời gặp phải một vấn đề là một chỉ báo về tần suất của vấn đề đó trong bài kiểm tra. Bạn chỉ có thể sử dụng số liệu này nếu người dùng của bạn thực hiện chính xác các tác vụ tương tự.

Nếu có sự khác biệt trong bài kiểm tra hoặc các nhiệm vụ không được xây dựng rõ ràng mà được biên soạn trên cơ sở phỏng vấn thì sẽ khó tính được tần suất. Không chỉ cần đếm những người đã gặp phải vấn đề này mà còn phải ước tính xem có bao nhiêu người trả lời có thể gặp phải vấn đề (thực hiện một nhiệm vụ tương tự, đi đến cùng một phần). Tuy nhiên, đặc điểm này cho phép nhóm hiểu được vấn đề nào cần được khắc phục trước.

Sự hài lòng chủ quan.Đây là đánh giá chủ quan của người dùng về sự thuận tiện hay thoải mái khi làm việc với hệ thống. Nó được tiết lộ bằng cách sử dụng bảng câu hỏi mà người trả lời điền vào trong hoặc sau khi thử nghiệm. Có bảng câu hỏi tiêu chuẩn. Ví dụ: Thang đo khả năng sử dụng hệ thống, Bảng câu hỏi về khả năng sử dụng sau nghiên cứu hoặc Bảng câu hỏi trải nghiệm trò chơi dành cho trò chơi. Hoặc bạn có thể tạo bảng câu hỏi của riêng bạn.

Đây không phải là số liệu duy nhất có thể có. Ví dụ: danh sách 10 số liệu UX mà Jeff Sauro nêu bật. Đối với sản phẩm của bạn, các số liệu có thể khác nhau: ví dụ: người trả lời hiểu luật chơi ở mức độ nào, họ mắc bao nhiêu lỗi khi điền vào các biểu mẫu dài. Hãy nhớ rằng quyết định sử dụng nhiều số liệu đặt ra một số hạn chế trong quá trình thử nghiệm. Người trả lời nên hành động một cách tự nhiên nhất có thể và trong cùng điều kiện. Vì vậy, sẽ tốt hơn nếu cung cấp:

• Điểm khởi đầu chung. Các nhiệm vụ giống nhau cho những người trả lời khác nhau phải bắt đầu từ cùng một điểm giao diện. Sau mỗi nhiệm vụ, bạn có thể yêu cầu người trả lời quay lại trang chính.
• Không có sự can thiệp. Bất kỳ giao tiếp nào với người điều hành đều có thể ảnh hưởng đến số liệu hiệu suất nếu người điều hành vô tình gợi ý điều gì đó cho người trả lời và tăng thời gian cần thiết để hoàn thành nhiệm vụ.
• Thứ tự nhiệm vụ. Để bù đắp cho hiệu quả học tập trong thử nghiệm so sánh, hãy đảm bảo thay đổi thứ tự tiếp xúc với các sản phẩm được so sánh giữa những người trả lời. Hãy bắt đầu một nửa với dự án của bạn và một nửa với dự án cạnh tranh.
• Tiêu chí thành công. Hãy suy nghĩ trước về loại hành vi mà bạn cho là thành công đối với nhiệm vụ: ví dụ: việc người trả lời không sử dụng bộ lọc khi chọn sản phẩm trong cửa hàng trực tuyến có được chấp nhận hay không.

Giải thích các số liệu

Hãy nhớ rằng thử nghiệm khả năng sử dụng cổ điển là một nghiên cứu định tính và các số liệu bạn thu được chủ yếu mang tính minh họa. Chúng cung cấp cái nhìn tổng quan về các tình huống khác nhau trong một sản phẩm, cho phép bạn nhìn thấy những điểm yếu. Ví dụ, việc lập tài khoản gây khó khăn hơn so với việc đăng ký vào hệ thống. Chúng có thể cho thấy động lực của sự thay đổi nếu bạn đo lường chúng thường xuyên. Nghĩa là, các số liệu cho phép chúng tôi hiểu rằng thiết kế mới cho phép chúng tôi hoàn thành nhiệm vụ nhanh hơn. Chính những mối quan hệ này mang tính biểu thị và đáng tin cậy hơn nhiều so với các giá trị tuyệt đối của các số liệu được tìm thấy.

Jeff Sauro, một chuyên gia thống kê trong nghiên cứu UX, khuyên không nên biểu thị các số liệu dưới dạng mức trung bình mà hãy luôn sử dụng khoảng tin cậy. Điều này đúng hơn nhiều, đặc biệt nếu có sự khác biệt trong kết quả của người trả lời. Để làm điều này, bạn có thể sử dụng máy tính trực tuyến miễn phí của anh ấy: để biết thành công và thời gian hoàn thành nhiệm vụ. Bạn không thể làm gì nếu không xử lý thống kê khi so sánh kết quả.

Khi nào cần có số liệu?

Không phải mọi báo cáo kiểm tra khả năng sử dụng đều chứa số liệu. Việc thu thập và phân tích của họ cần có thời gian và đặt ra những hạn chế về phương pháp thử nghiệm. Dưới đây là những trường hợp thực sự cần thiết:

• Chứng minh. Thường cần phải chứng minh rằng cần phải thực hiện những thay đổi đối với sản phẩm, đặc biệt là ở các công ty lớn. Đối với những người ra quyết định, những con số rất trực quan, dễ hiểu và quen thuộc. Khi bạn cho thấy rằng 10 trong số 12 người được hỏi không thể thanh toán cho một mặt hàng hoặc việc đăng ký vào hệ thống mất trung bình gấp đôi so với đối thủ cạnh tranh, điều đó sẽ mang lại kết quả nghiên cứu có giá trị hơn.
• So sánh. Nếu bạn so sánh sản phẩm của mình với sản phẩm khác trên thị trường, bạn cũng cần có số liệu. Nếu không, bạn sẽ thấy những ưu điểm và nhược điểm của các dự án khác nhau, nhưng sẽ không thể đánh giá sản phẩm của bạn đứng ở đâu trong số đó.
• Xem những thay đổi. Số liệu rất hữu ích cho việc thường xuyên kiểm tra cùng một sản phẩm sau khi thực hiện thay đổi. Chúng cho phép bạn xem tiến trình sau khi thiết kế lại và chú ý đến những chỗ chưa được cải tiến. Bạn có thể sử dụng lại các chỉ số này làm cơ sở bằng chứng cho thấy tầm quan trọng của việc đầu tư vào việc thiết kế lại đối với ban quản lý. Hoặc chỉ để hiểu rằng bạn đã đạt được kết quả và đang đi đúng hướng.
• Minh họa, nhấn mạnh. Các con số có tác dụng tốt trong việc minh họa các vấn đề quan trọng. Đôi khi chúng tôi tính chúng cho những khoảnh khắc nổi bật và quan trọng nhất của bài kiểm tra, ngay cả khi chúng tôi không sử dụng số liệu trong tất cả các nhiệm vụ.

Tuy nhiên, chúng tôi không sử dụng số liệu trong mọi thử nghiệm. Bạn có thể làm mà không cần họ nếu nhà nghiên cứu làm việc chặt chẽ với nhóm dự án, có sự tin tưởng nội bộ và nhóm đủ trưởng thành để ưu tiên giải quyết vấn đề một cách chính xác.

Phương pháp ghi dữ liệu

Có vẻ như, có chuyện gì với sổ ghi chú và bút hay chỉ là một tài liệu Word đang mở? Trong thế giới phát triển Agile ngày nay, các nhà nghiên cứu UX phải cố gắng đưa những phát hiện của họ trở lại nhóm càng nhanh càng tốt.

Để tối ưu hóa thời gian phân tích, bạn nên chuẩn bị trước một mẫu để nhập ghi chú trong quá trình kiểm tra. Chúng tôi đã cố gắng thực hiện việc này trong phần mềm chuyên dụng (ví dụ: Noldus Observer hoặc Morae Manager), nhưng trong thực tế, các bảng hóa ra lại linh hoạt và phổ biến nhất. Trước tiên, hãy đánh dấu vào bảng các câu hỏi mà bạn định hỏi, các vị trí để nhập các vấn đề tìm thấy trong nhiệm vụ, cũng như các giả thuyết (đối với mỗi người trả lời, bạn sẽ đánh dấu xem điều đó đã được xác nhận hay chưa). Dấu hiệu của chúng tôi trông như thế này:

Những gì khác bạn có thể sử dụng:

• . Mẫu Excel có thể tùy chỉnh để nhập các quan sát cho từng người trả lời. Có một bộ đếm thời gian tích hợp để đo thời gian cần thiết để hoàn thành các nhiệm vụ và biểu đồ thời gian và thành công được tạo tự động.
• Bảng tính cầu vồng của Tomer Sharon của Google. Một bảng trực quan để cộng tác giữa nhà nghiên cứu và nhóm. Liên kết dẫn đến một bài viết mô tả phương pháp và cũng có một liên kết đến bảng tính Google có mẫu.

Với kinh nghiệm, hầu hết các ghi chú có thể được ghi lại trong quá trình làm bài. Nếu bạn không đến đúng giờ, tốt hơn hết bạn nên viết ra tất cả những gì bạn nhớ được ngay sau bài kiểm tra. Nếu bạn quay lại phân tích sau một vài ngày, rất có thể bạn sẽ phải xem lại video và mất nhiều thời gian hơn.

Chuẩn bị thử nghiệm

Ngoài phương pháp, số liệu và giao thức thử nghiệm, bạn cần quyết định những điều sau:

Hình thức giao tiếp với người điều hành. Người điều hành có thể ở cùng phòng với người tham gia kiểm tra. Trong trường hợp này, anh ấy sẽ dễ dàng đặt câu hỏi đúng lúc. Tuy nhiên, sự hiện diện của người điều hành có thể ảnh hưởng đến người trả lời: anh ta sẽ bắt đầu đặt câu hỏi cho người điều hành, kích động người điều hành nhắc nhở anh ta một cách rõ ràng hoặc ngầm.

Chúng tôi cố gắng để người trả lời một mình với sản phẩm trong ít nhất một phần của bài kiểm tra. Bằng cách này, hành vi của anh ta trở nên thoải mái và tự nhiên hơn. Và để không phải chạy đi chạy lại nếu có sự cố xảy ra, bạn có thể bật bất kỳ tin nhắn nào có kết nối âm thanh để người điều hành có thể liên hệ với người trả lời từ phòng quan sát.

Phương pháp thiết lập nhiệm vụ. Nhiệm vụ có thể được thông báo bởi người điều hành. Nhưng trong trường hợp này, mặc dù có quy trình kiểm tra thống nhất, văn bản của nhiệm vụ có thể được phát âm hơi khác nhau mỗi lần. Điều này đặc biệt đúng nếu bài kiểm tra được thực hiện bởi nhiều người điều hành. Đôi khi ngay cả những khác biệt nhỏ trong cách diễn đạt cũng có thể đặt người trả lời vào những điều kiện bắt đầu khác nhau.

Để tránh điều này, bạn có thể “huấn luyện” người điều hành luôn đọc văn bản của nhiệm vụ hoặc giao nhiệm vụ cho người trả lời trên mảnh giấy hoặc trên màn hình. Sự khác biệt trong cách diễn đạt sẽ không còn là vấn đề nếu bạn sử dụng một kịch bản linh hoạt khi các nhiệm vụ được hình thành trong quá trình kiểm tra, dựa trên cuộc phỏng vấn với người điều hành.

Bạn có thể sử dụng các công cụ sản phẩm để đặt nhiệm vụ. Ví dụ: khi kiểm tra ICQ, người trả lời đã nhận được nhiệm vụ thông qua cửa sổ trò chuyện với người kiểm duyệt và khi kiểm tra Mail.Ru Mail, họ nhận được chúng bằng thư. Cách thiết lập nhiệm vụ này diễn ra tự nhiên nhất có thể đối với các dự án này và chúng tôi cũng đã thử nghiệm các kịch bản tương ứng cơ bản nhiều lần.

Tạo bối cảnh tự nhiên. Ngay cả khi chúng ta đang nói về các thử nghiệm trong phòng thí nghiệm, hãy nghĩ đến cách đưa việc sử dụng sản phẩm trong thử nghiệm đến gần hơn với điều kiện thực tế. Ví dụ: nếu bạn đang thử nghiệm thiết bị di động, người trả lời sẽ cầm chúng như thế nào? Để có hình ảnh đẹp trong video, sẽ tốt hơn khi điện thoại hoặc máy tính bảng được cố định trên giá đỡ hoặc nằm trên bàn. Tuy nhiên, điều này không làm rõ liệu tất cả các khu vực có dễ tiếp cận và thuận tiện khi bấm hay không, vì điện thoại thường được cầm bằng một tay và với máy tính bảng thì chúng nằm trên ghế sofa.

Điều đáng suy nghĩ là môi trường mà sản phẩm sẽ được sử dụng: có điều gì khiến người dùng mất tập trung không, có ồn ào không, có kết nối Internet tốt không. Tất cả điều này có thể được mô phỏng trong phòng thí nghiệm.

Kế hoạch kiểm tra cho khách hàng.Đây cũng là giai đoạn chuẩn bị quan trọng vì nó có sự tham gia của nhóm dự án. Bạn không cần phải nói với khách hàng tất cả các đặc điểm phương pháp luận của bài kiểm tra (cách bạn sẽ giao tiếp với người trả lời, ghi lại dữ liệu, v.v.). Nhưng hãy nhớ cho anh ấy biết nhiệm vụ sẽ là gì và bạn sẽ kiểm tra chúng những gì. Có thể bạn chưa tính đến một số đặc điểm của dự án, hoặc có thể nhóm dự án sẽ có thêm ý tưởng và giả thuyết. Chúng ta thường kết thúc bằng một dấu hiệu như thế này:

Kế hoạch báo cáo.Đương nhiên, báo cáo được viết dựa trên kết quả nghiên cứu. Tuy nhiên, tốt nhất là bạn nên lập một kế hoạch báo cáo trước khi tiến hành các bài kiểm tra, dựa trên mục đích và mục tiêu của nghiên cứu. Với một kế hoạch như vậy trước mắt, bạn có thể kiểm tra tính đầy đủ của tập lệnh của mình cũng như chuẩn bị các biểu mẫu thuận tiện nhất để thu thập dữ liệu cho phân tích tiếp theo. Bạn có thể quyết định rằng không cần báo cáo và chỉ cần một hồ sơ quan sát chung là đủ cho bạn và nhóm. Và nếu bạn thúc đẩy nhóm của mình cùng hoàn thành nó với bạn, điều đó sẽ thực sự tuyệt vời.

Tất nhiên, bạn có thể chỉ cần “cho bạn của mình sử dụng sản phẩm” và xem anh ấy gặp khó khăn gì. Nhưng một kịch bản được viết tốt sẽ giúp bạn không bỏ sót những vấn đề quan trọng và không vô tình đẩy người trả lời đến những câu trả lời bạn cần. Xét cho cùng, kiểm tra khả năng sử dụng là một thử nghiệm được đơn giản hóa và trong bất kỳ thử nghiệm nào, việc chuẩn bị sơ bộ đều quan trọng.

Giao thức cho mọi thử nghiệm khả năng sử dụng bao gồm các phần sau:

• Hướng dẫn hoặc tóm tắt (chào mừng, mô tả sự kiện, ký kết các tài liệu).
• Phỏng vấn giới thiệu (kiểm tra sàng lọc, phỏng vấn ngắn về cách sử dụng sản phẩm, bối cảnh và kịch bản).
• Làm việc với sản phẩm (nhiệm vụ thử nghiệm).
• Thu thập ấn tượng cuối cùng về sản phẩm dựa trên kinh nghiệm thử nghiệm.

Hướng dẫn hoặc tóm tắt

Bất kể chủ đề kiểm tra là gì, bất kỳ nghiên cứu nào cũng bắt đầu theo cùng một cách. Nên làm gì:

Tạo một bầu không khí. Làm quen với người đó, mời anh ta trà, cà phê hoặc nước, chỉ cho anh ta nhà vệ sinh ở đâu. Cố gắng giúp người trả lời thư giãn một chút, vì anh ta có thể lo lắng trước sự kiện. Tìm hiểu xem có dễ tìm thấy bạn không, hỏi xem bạn có khỏe không.

Mô tả quá trình. Hãy cho chúng tôi biết loại sự kiện nào đang chờ đợi người trả lời, nó sẽ kéo dài bao lâu, nó bao gồm những phần nào và bạn sẽ làm gì. Hãy nhớ chỉ ra cho người trả lời biết rằng ý kiến ​​đóng góp của họ sẽ giúp cải thiện sản phẩm và bạn không đang kiểm tra khả năng của một người. Nếu bạn đang quay video, hãy cảnh báo người trả lời về điều này và nói với họ rằng dữ liệu sẽ không xuất hiện trực tuyến. Tôi nói điều gì đó như thế này:

Chúng tôi được đặt tại văn phòng của Mail.Ru Group. Hôm nay chúng ta sẽ nói về dự án XXX. Việc này sẽ mất khoảng một giờ. Đầu tiên chúng ta sẽ nói chuyện một chút, sau đó tôi sẽ yêu cầu bạn thử làm điều gì đó trong dự án và sau đó chúng ta sẽ thảo luận về ấn tượng của bạn. Chúng tôi sẽ quay video những gì đang diễn ra trong phòng và trên màn hình máy tính. Việc đăng ký chỉ cần thiết cho mục đích phân tích; bạn sẽ không nhìn thấy chính mình trên Internet.

Chúng tôi đang tiến hành nghiên cứu để làm cho dự án XXX tốt hơn, để hiểu những gì cần phải khắc phục trong đó và nên phát triển theo hướng nào. Vì vậy, tôi yêu cầu bạn thẳng thắn bày tỏ bất kỳ nhận xét nào: cả tích cực và tiêu cực. Đừng sợ làm mất lòng chúng tôi. Nếu có điều gì đó không suôn sẻ với bạn khi nghiên cứu một dự án, hãy bình tĩnh giải quyết. Điều này có nghĩa là chúng tôi đã tìm thấy một vấn đề mà nhóm dự án cần khắc phục. Điều quan trọng cần nhớ là chúng tôi không kiểm tra bạn, bạn đang kiểm tra sản phẩm. Nếu bạn đã sẵn sàng, tôi khuyên bạn nên bắt đầu.

Để ký các tài liệu. Theo quy định, đây là sự đồng ý xử lý dữ liệu cá nhân và đôi khi cũng là thỏa thuận về việc không tiết lộ thông tin về xét nghiệm. Đối với các thử nghiệm với trẻ vị thành niên, cần có sự đồng ý của phụ huynh để con họ tham gia nghiên cứu. Chúng tôi thường gửi trước cho phụ huynh và yêu cầu họ mang theo. Hãy chắc chắn giải thích lý do tại sao bạn yêu cầu ký vào các tài liệu và cho họ thời gian để xem xét chúng. Ở Nga, người dân cảnh giác với bất kỳ giấy tờ nào bắt buộc phải ký.

Thiết lập thiết bị. Nếu bạn sử dụng tính năng theo dõi bằng mắt, thiết bị sinh trắc học hoặc đơn giản là quay video thì bây giờ là lúc để bật tất cả. Cảnh báo người trả lời khi bạn bắt đầu ghi âm.

Phỏng vấn giới thiệu

Nó giải quyết các vấn đề sau:

Kiểm tra tuyển dụng.Để đảm bảo an toàn, hãy luôn bắt đầu từ đó - ngay cả khi bạn tin tưởng vào cơ quan hoặc người đã tìm thấy bị đơn. Đã hơn một lần trong quá trình thử nghiệm, chúng tôi phát hiện ra rằng người trả lời đã hiểu nhầm câu hỏi và thực tế là đã không sử dụng sản phẩm đúng như chúng tôi cần. Cố gắng tránh hình thức và tránh đặt các câu hỏi từ bảng câu hỏi sàng lọc: người đó có thể đã biết phải trả lời gì.

Các tình huống và bối cảnh sử dụng sản phẩm. Kể cả khi bạn không có nhiều thời gian để làm bài thi thì cũng đừng bỏ qua bước này. Ít nhất nói chung, hãy tìm hiểu từ người trả lời những vấn đề mà anh ta giải quyết với sự trợ giúp của sản phẩm, liệu anh ta có sử dụng các dự án tương tự hay không, anh ta tương tác với chúng trong những điều kiện nào và từ thiết bị nào. Các câu trả lời sẽ giúp bạn hiểu rõ hơn về nguyên nhân dẫn đến hành vi của người trả lời, và nếu bạn đang sử dụng một kịch bản linh hoạt thì sẽ giúp bạn xây dựng các nhiệm vụ phù hợp. Nếu bạn có đủ thời gian, hãy yêu cầu người trả lời cho biết họ thường làm gì và như thế nào. Đây có thể là nguồn của những câu hỏi và hiểu biết sâu sắc hơn.

Kỳ vọng và các mối quan hệ. Bắt đầu thử nghiệm là thời điểm tốt để tìm hiểu xem người trả lời biết gì về sản phẩm, cảm nhận của họ về sản phẩm và những gì họ mong đợi từ nó. Sau bài kiểm tra, bạn sẽ có thể so sánh kỳ vọng của mình với ấn tượng cuối cùng.

Đối với hầu hết các bài kiểm tra, cấu trúc phỏng vấn giới thiệu này sẽ hiệu quả. Nếu bạn đang thử nghiệm một sản phẩm mới, bạn có thể muốn bỏ qua các câu hỏi giới thiệu. Nếu bạn đi quá chi tiết về một chủ đề, nó có thể tạo ra những kỳ vọng nhất định cho người dùng về sản phẩm. Do đó, chỉ để lại một số câu hỏi chung chung để thiết lập liên hệ với người trả lời và ngay lập tức chuyển sang nhiệm vụ, đồng thời tốt hơn là nên thảo luận về các tình huống, mối quan hệ và bối cảnh sau khi người dùng đã nghiên cứu sản phẩm lần đầu.

Làm việc với sản phẩm, viết bài

Các nhiệm vụ là gì?

Hãy tưởng tượng rằng bạn muốn thử nghiệm một cửa hàng trực tuyến. Bạn có các tình huống quan trọng (tìm kiếm và lựa chọn hàng hóa, quy trình đặt hàng), các vấn đề đã biết (các lỗi thường gặp trong hình thức thanh toán) và thậm chí là giả thuyết rằng nhà thiết kế đã làm sai điều gì đó với bộ lọc giá. Làm thế nào để xây dựng nhiệm vụ?

Nhiệm vụ tập trung. Có vẻ hiển nhiên khi làm một việc như thế này: “Hãy chọn một chiếc máy rửa bát rộng 45 cm có chức năng dầm sàn có giá không quá 30 nghìn rúp.” Điều này thúc đẩy người trả lời sử dụng các bộ lọc và so sánh các sản phẩm với nhau. Bạn có thể kiểm tra bộ lọc giá trên tất cả người trả lời và xem xét tình huống chính để chọn sản phẩm. Những nhiệm vụ như vậy có quyền tồn tại và rất tốt cho việc kiểm tra các giả thuyết cụ thể (như với bộ lọc giá).

Tuy nhiên, nếu toàn bộ bài kiểm tra bao gồm chúng, thì bạn sẽ gặp rủi ro như sau:

• Kiểm tra giao diện tại chỗ. Bạn sẽ chỉ tìm thấy các vấn đề liên quan đến chi tiết công việc (lọc theo giá và chiều rộng). Bạn sẽ không gặp các vấn đề khác - chẳng hạn như sắp xếp sản phẩm hoặc các bộ lọc khác - trừ khi bạn cũng chỉ ra chúng. Nhưng bạn khó có thể hoàn thành nhiệm vụ cho tất cả các thành phần của trang web.
• Thiếu sự tham gia. Người dùng thường thực hiện các tác vụ như vậy một cách máy móc. Khi họ nhìn thấy sản phẩm đầu tiên phù hợp với tiêu chí, họ sẽ dừng lại. Có lẽ người trả lời chưa bao giờ chọn máy rửa bát trong đời và cũng không quan tâm “dầm trên sàn” là gì. Nhiệm vụ càng giống với tình huống thực tế và càng cung cấp nhiều ngữ cảnh để người dùng có thể hiểu thì cơ hội thu hút người trả lời sẽ giả vờ thực sự đang chọn sản phẩm càng cao. Và người dùng tương tác sẽ “trải nghiệm” giao diện tốt hơn, để lại nhiều nhận xét hơn, tăng cơ hội tìm ra vấn đề và cung cấp kiến ​​​​thức hữu ích về hành vi cũng như đặc điểm của khán giả.
• Phạm vi hiểu biết bị thu hẹp. Trong cuộc sống thực, người dùng có thể sẽ chọn một sản phẩm hoàn toàn khác. Ví dụ: tôi hoàn toàn không sử dụng các bộ lọc (và ở đây bạn đã chỉ ra chúng). Hoặc tôi sẽ tìm kiếm một sản phẩm dựa trên các tiêu chí không có trên trang web. Bằng cách đưa ra các nhiệm vụ tập trung và cứng nhắc, bạn sẽ không tìm hiểu về bối cảnh thực tế của việc sử dụng sản phẩm, sẽ không tìm thấy các tình huống mà nhóm dự án có thể không lường trước được và sẽ không thu thập dữ liệu về nhu cầu nội dung và chức năng.

Nhiệm vụ với bối cảnh. Một cách để thu hút người dùng tốt hơn là thêm lịch sử và bối cảnh thực tế vào một tác vụ khô khan. Ví dụ: thay vì “Tìm công thức làm bánh mận trên trang web”, hãy gợi ý như sau: “Bạn sẽ có khách sau một giờ nữa. Tìm thứ gì đó để nướng trong thời gian này. Bạn có mọi thứ để làm bánh quy trong tủ lạnh, cũng như một ít mận. Nhưng thật không may là không có bơ.”

Một cách tiếp cận tương tự có thể được sử dụng với một cửa hàng trực tuyến. Ví dụ: “Hãy tưởng tượng bạn đang chọn một món quà cho em gái mình. Máy sấy tóc của cô ấy gần đây bị hỏng và cô ấy sẽ rất vui khi có được một cái mới. Bạn cần phải đáp ứng 7 nghìn rúp ”. Điều quan trọng là người trả lời phải thực sự chọn được người thật mà mình sẽ “mua” quà cho (nếu không có chị gái thì gợi ý người thân, bạn bè khác). Yếu tố then chốt cho những nhiệm vụ như vậy là tính thực tế và rõ ràng của bối cảnh. Thật dễ dàng để tưởng tượng rằng bạn đang chọn một món quà cho gia đình mình, nhưng sẽ khó hơn nhiều khi tưởng tượng rằng bạn là “một kế toán viên đang chuẩn bị báo cáo thường niên”.

Một ví dụ nổi bật của cách tiếp cận này là “phương pháp Bollywood”, được phát minh bởi chuyên gia UX người Ấn Độ Apala Lahiri Chavan. Cô lập luận rằng người Ấn Độ, giống như nhiều người châu Á, cảm thấy khó nói chuyện một cách cởi mở về giao diện. Tuy nhiên, tưởng tượng mình là anh hùng của những tình huống kịch tính hư cấu (như trong những bộ phim yêu thích của họ), họ cởi mở và bắt đầu tích cực tham gia thử nghiệm. Do đó, nhiệm vụ dành cho người Ấn Độ sẽ giống như thế này:

Hãy tưởng tượng rằng cô cháu gái yêu quý của bạn sắp kết hôn. Và sau đó bạn phát hiện ra rằng người chồng tương lai của cô ấy là một kẻ lừa đảo và đã có gia đình. Bạn cần gấp mua hai vé máy bay đến Bangalore cho mình và cho vợ của kẻ lừa dối để phá đám cưới và cứu gia đình khỏi sự xấu hổ. Sự vội vàng!

Nhiệm vụ dựa trên kinh nghiệm của người trả lời. Hãy để chúng tôi nhắc bạn: để thử nghiệm thành công, người trả lời phải tương ứng với đối tượng của dự án. Vì vậy, để kiểm tra cửa hàng trực tuyến đồ gia dụng, chúng tôi tuyển dụng những người đã chọn thiết bị gần đây hoặc đang chọn chúng. Đây chính xác là những gì chúng tôi sẽ sử dụng khi tạo nhiệm vụ dựa trên kinh nghiệm của người trả lời. Có hai lựa chọn để sử dụng phương pháp này:

• Các tham số của người trả lời. Trong trường hợp này, bạn điều chỉnh các nhiệm vụ cố định cho phù hợp với người trả lời. Ví dụ: trong trường hợp cửa hàng thiết bị gia dụng và nhiệm vụ làm việc với các bộ lọc, bạn hỏi người đó chính xác những gì anh ta đã mua gần đây. Tìm hiểu các tiêu chí (giá cả, chức năng) và đề nghị lặp lại việc “mua hàng” trên trang web của bạn.
• Tình huống của người trả lời. Các nhiệm vụ được hình thành hoàn toàn dựa trên kinh nghiệm của người tham gia. Để hiểu những tình huống nào cần kiểm tra, người điều hành sẽ tìm hiểu chính xác cách người đó giải quyết vấn đề trong cuộc sống và đề xuất thực hiện trên trang web. Ví dụ, người mua đã mất nhiều thời gian so sánh nhiều mẫu mã trước khi lựa chọn. Ngay cả khi trang web không có chức năng phù hợp, hãy mời người trả lời so sánh các sản phẩm để hiểu họ sẽ dựa vào thông số nào. Có lẽ bạn sẽ có ý tưởng về chức năng so sánh sẽ trông như thế nào và cũng có thể điều chỉnh trang sản phẩm cho phù hợp với tình huống này.

Những nhiệm vụ như vậy cung cấp nhiều ví dụ thực tế về việc thực hiện các hoạt động cơ bản trong một sản phẩm. Điều này thường dẫn đến nhiều vấn đề và phát hiện ở phạm vi rộng hơn. Ngoài ra, nó cho phép bạn thử nghiệm sản phẩm trên các tình huống mới mà bạn chưa coi là cơ bản hoặc thậm chí chưa nghĩ đến.

Khi chúng tôi thử nghiệm dự án Bất động sản Mail.Ru, chính các nhiệm vụ dựa trên kinh nghiệm của những người được hỏi đã giúp chúng tôi có nhiều khám phá. Chúng tôi thấy rằng khi tìm kiếm một căn hộ ở khu vực Moscow, mọi người chỉ ra các ga tàu điện ngầm cuối cùng trong bộ lọc địa lý, nghĩa là đây là những ga có thể đến được từ khu vực đó. Chúng tôi dự đoán rằng bộ lọc tàu điện ngầm đang tìm kiếm một căn hộ gần nhà ga. Chúng tôi cũng đã tìm hiểu các kịch bản tìm kiếm tòa nhà mới khác với các kịch bản thứ cấp như thế nào, điều này đã giúp chuyển việc tìm kiếm tòa nhà mới sang một phần khác trên trang web - với các bộ lọc riêng và khái niệm mô tả căn hộ riêng. Tôi cũng khuyên bạn nên đọc bài viết xuất sắc của Jared Spool về lợi ích của những nhiệm vụ như vậy.

Bài tập không có bài tập.Đôi khi, tốt hơn hết là bạn không nên cung cấp cho người dùng các nhiệm vụ để làm việc với dự án mà hãy xem bản thân họ bắt đầu làm quen với sản phẩm từ đâu. Giới thiệu cho người trả lời: “Hãy tưởng tượng rằng bạn quyết định dùng thử sản phẩm này. Tôi sẽ rời xa bạn trong vài phút. Hãy làm những gì bạn sẽ làm trong đời thực. Tôi không giao cho bạn bất kỳ nhiệm vụ nào."

Điều quan trọng là người điều hành phải rời khỏi phòng vào lúc này. Nếu không, người dùng sẽ ngay lập tức hỏi điều gì đó để làm rõ: “Tôi có cần đăng ký không? Tôi có thể làm cái này như thế nào?" và như thế.

Loại nhiệm vụ này rất hữu ích cho các sản phẩm hoàn toàn mới. Chúng tôi thường sử dụng nó cho các ứng dụng và trò chơi di động. Đây là cách chúng tôi tìm hiểu xem người dùng có đọc tài liệu đào tạo hay không, chi tiết nào thu hút sự chú ý ngay lập tức, mọi người hiểu gì về khái niệm sản phẩm và sau đó họ mô tả khả năng của sản phẩm như thế nào. Sau nhiệm vụ miễn phí sẽ có các kịch bản cụ thể được lên kế hoạch.

Một lĩnh vực khác của ứng dụng nhận bài tập miễn phí là các dự án nội dung. Nếu bạn muốn hiểu bài viết của mình được đọc như thế nào (họ nán lại lâu ở đâu, họ bỏ qua những gì, họ chú ý đến những yếu tố nào trên trang), thì bạn chỉ cần để người trả lời một mình với dự án trong vài phút. Chỉ khi không có người điều hành nhìn qua vai, người dùng sẽ thư giãn và đọc văn bản như bình thường. Đây là cách chúng tôi thử nghiệm các dự án “Mail.Ru News”, “Mail.Ru Lady” và các dự án khác. Cách tiếp cận này giúp xác định các kiểu hành vi khác nhau trên trang web, các kiểu đọc bài viết khác nhau và hiểu loại tài liệu nào nên được định dạng khác nhau.

Làm bài tốt

Nhiệm vụ đầu tiên rất đơn giản. Bắt đầu thử nghiệm với các nhiệm vụ giới thiệu và đơn giản. Người trả lời cần phải cảm thấy thoải mái với hình thức kiểm tra, đặc biệt nếu bạn đang sử dụng phương pháp suy nghĩ thành tiếng: họ cần làm quen với việc phải diễn đạt suy nghĩ và cảm xúc của mình bằng lời nói. Bạn không nên đổ ngay tất cả nỗi đau và sự đau khổ của giao diện lên đó.

Đừng cho tôi bất kỳ gợi ý nào. Xây dựng nhiệm vụ theo cách không thúc giục người trả lời làm điều đúng đắn. Nếu bạn muốn kiểm tra khả năng thêm sản phẩm vào mục yêu thích trong cửa hàng trực tuyến, hãy thực hiện mà không cần tác vụ “Hãy thêm TV này vào mục yêu thích”, đặc biệt nếu nút được gọi theo cách đó. Người trả lời, sau khi đọc nhiệm vụ, sẽ chỉ tìm thấy một nút trên màn hình có chữ ký mong muốn - có lẽ thậm chí không hiểu chính xác anh ta đang làm gì.

Tốt hơn là giải thích ý nghĩa của nhiệm vụ mà không cần dùng đến các thuật ngữ trong giao diện. Ví dụ: “Trên trang web, bạn có thể lưu các sản phẩm bạn thích và sau đó chọn sản phẩm để đặt hàng. Hãy thử làm điều này với một chiếc TV như vậy.”

Xem thuật ngữ. Không sử dụng các từ và ký hiệu không rõ ràng. Điều này có vẻ hiển nhiên, nhưng chúng ta, khi đã quen với một số thuật ngữ nhất định, thường quên rằng rất ít người ngoài cộng đồng CNTT biết chúng. Ví dụ: khi thử nghiệm chức năng mới của các chuỗi (chuỗi chữ cái) trong Mail.Ru Mail, chúng tôi đã gặp khó khăn. Rốt cuộc, người dùng không quen với chức năng này chỉ đơn giản là không có thuật ngữ nào trong đầu để biểu thị các luồng.

Cuối cùng, chúng tôi không gọi họ là gì cả. Chúng tôi chỉ đơn giản cho người trả lời xem một hộp có các chủ đề được kết nối và thảo luận về tính năng mới này, đồng thời cho phép người dùng chọn từ để biểu thị các chủ đề. Điều này đã giúp chúng tôi sau này sử dụng những văn bản dễ hiểu nhất trong các tài liệu quảng cáo giáo dục.

Theo dõi không chỉ các bài tập mà còn cả các câu hỏi của người điều hành, đặc biệt là những câu hỏi đến từ nhóm trong quá trình kiểm tra. Ví dụ, khi bàn về chức năng, bạn không nên dùng từ “thanh công cụ”: không phải ai cũng quen với nó. Chỉ vài năm trước, không phải tất cả người dùng đều biết đến từ “trình duyệt”. Cách tốt nhất để xây dựng nhiệm vụ phụ thuộc vào đối tượng thử nghiệm. Bạn không nên đi sang thái cực khác, giải thích liên tiếp tất cả các thuật ngữ. Ví dụ: những người chơi có kinh nghiệm không cần phải giải thích “buff”, “frag”, “respawn”, v.v. là gì.

Ít thử nghiệm hơn. Việc tạo một tài khoản thử nghiệm cho người trả lời trong hệ thống và tiến hành thử nghiệm trên đó thường rất hấp dẫn. Rốt cuộc, bạn có thể kiểm tra trước mọi thứ trong tài khoản này, tránh các vấn đề và không lãng phí thời gian đăng ký hoặc ủy quyền cho người trả lời. Về mặt kỹ thuật, việc triển khai một thiết kế mới trên dữ liệu thử nghiệm thường dễ dàng hơn nhiều so với trên dữ liệu thực.

Tuy nhiên, với cách tiếp cận này, bạn có nguy cơ nhận được kết quả kém hữu ích hơn nhiều vì các hoạt động thử nghiệm không có hậu quả thực sự. Tình huống trở nên hoàn toàn giả tạo; người dùng khó có thể chiếu nó vào trải nghiệm thực tế.

Ví dụ: khi làm việc trên tài khoản của chính họ trên mạng xã hội, những người trả lời, cũng như trong đời thực, sẽ cẩn thận làm mọi thứ mà bạn bè của họ có thể nhìn thấy (đăng liên kết, gửi tin nhắn). Khi thiết lập hộp thư riêng, họ sẽ cố gắng không xóa những bức thư quan trọng. Khi thử nghiệm các cửa hàng trực tuyến, đôi khi người ta sử dụng một phương pháp trong đó phần thưởng phải được chi trực tiếp trong quá trình thử nghiệm. Trong trường hợp này, người trả lời sẽ không chọc vào sản phẩm đầu tiên phù hợp với nhiệm vụ mà sẽ chọn ra thứ mình thực sự cần.

Chỉ với dữ liệu thử nghiệm, bạn sẽ chỉ tìm thấy các vấn đề liên quan đến dữ liệu đó, thay vì thử nghiệm chức năng trên các biến thể khác nhau. Ví dụ: khi chúng tôi kiểm tra bảng xã hội của trình duyệt Amigo, một trong những người được hỏi, người đã kết nối tài khoản VKontakte của mình với bảng, ngay lập tức lưu ý rằng việc đọc theo cách này rất bất tiện cho anh ấy. Hầu như toàn bộ nguồn cấp dữ liệu bao gồm đăng ký các nhóm có ảnh khiêu dâm. Và trong khung hẹp của các bức ảnh, đơn giản là không thể nhìn thấy gì.

Một vấn đề khác với dữ liệu thử nghiệm là rất khó hiểu hệ thống vì mọi thứ xung quanh đều không bình thường. Ví dụ: một người dùng mạng xã hội đã quen với việc nhận ra trang của mình bằng ảnh của chính mình. Ngay cả khi thử nghiệm nguyên mẫu, chúng tôi vẫn cố gắng cá nhân hóa chúng nhiều nhất có thể. Ví dụ: khi thử nghiệm các nguyên mẫu có thể nhấp vào trong Odnoklassniki, chúng tôi luôn điều chỉnh chúng cho phù hợp với từng người dùng, chèn tên và ảnh của họ và đôi khi là tin tức mới nhất vào trang.

Đừng bị giới hạn bởi giao diện.Đừng quên rằng sự tương tác với sản phẩm thường không chỉ giới hạn ở giao diện. Nếu có thể, hãy kiểm tra các sản phẩm hoặc dịch vụ liên quan và mối liên hệ giữa chúng. Khi thử nghiệm trò chơi, chúng tôi cố gắng kiểm tra không chỉ trò chơi mà còn cả trang web của trò chơi và các nội dung tải xuống liên quan, đăng ký trong trò chơi và tìm kiếm thông tin trên diễn đàn. Và khi thử nghiệm một cửa hàng trực tuyến, tôi cũng đã kiểm tra cuộc gọi của nhà điều hành sau khi đặt hàng, cuộc gọi này đưa ra đề xuất cho tổng đài.

Hãy suy nghĩ về thời gian.Để có một kịch bản hay, điều quan trọng là phải ưu tiên các nhiệm vụ. Rất có thể, nếu hệ thống lớn và bài kiểm tra có nhiều mục tiêu, bạn sẽ muốn thực hiện nhiều nhiệm vụ. Tuy nhiên, một người trả lời mệt mỏi sẽ không còn hữu ích nữa. Một bài kiểm tra tốt kéo dài không quá một tiếng rưỡi, tối đa là hai. Ngoại lệ có lẽ là trò chơi. Và hãy nhớ rằng mục tiêu của bạn không chỉ là bài tập mà còn là phỏng vấn, bảng câu hỏi, thiết lập thiết bị và ký tài liệu. Tất cả điều này thường mất ít nhất nửa giờ.

Nếu có quá nhiều nhiệm vụ và bạn không muốn từ bỏ một số nhiệm vụ, bạn có thể luân chuyển những nhiệm vụ ít ưu tiên nhất, tức là chỉ hiển thị các phần của người trả lời. Hoặc bắt buộc mọi người phải làm một phần bài kiểm tra và chỉ xem phần còn lại với những người có đủ thời gian. Nhưng đây rất có thể sẽ là những người trả lời thành công nhất.

Đánh giá tính hữu ích của nhiệm vụ. Hãy xem xét liệu nó có thực sự phù hợp với giả thuyết của bạn hay không. Ví dụ: bạn muốn thử nghiệm tính năng đăng ký tin tức trên một trang web. Nhiệm vụ “Đăng ký nhận bản tin” sẽ chỉ kiểm tra xem những người tìm kiếm nó có thể tìm thấy bản tin hay không. Tuy nhiên, mọi người hiếm khi vào trang này để đăng ký nhận tin tức. Nhiệm vụ không áp dụng cho cuộc sống thực. Bạn cần hiểu liệu những người thực hiện các nhiệm vụ hoàn toàn khác nhau có chú ý đến cơ hội đăng ký hay không.

Điều này có thể được kiểm tra theo nhiều cách khác nhau, tùy thuộc vào việc thực hiện chức năng. Nếu một người đang tham gia vào các nhiệm vụ mà anh ta có thể đã thấy tùy chọn đăng ký, hãy hỏi anh ta xem nó có trên trang web hay không. Chỉ cần đảm bảo làm rõ anh ta đã nhìn thấy cơ hội này ở đâu hoặc nó được triển khai như thế nào để đảm bảo rằng người trả lời không chỉ đồng ý với bạn.

Nếu một ưu đãi đăng ký được tích hợp vào quá trình đăng ký hoặc thanh toán, hãy xem liệu người trả lời có tận dụng được ưu đãi đó hay không và thảo luận về nó sau khi thực hiện nhiệm vụ. Có rất ít khả năng trong điều kiện phòng thí nghiệm, mọi người sẽ thực sự đăng ký danh sách gửi thư, nhưng bạn có thể kiểm tra xem một người có chú ý đến cơ hội này hay không, anh ta mong đợi điều gì từ danh sách gửi thư, v.v.

Bộ sưu tập ấn tượng cuối cùng

Mục đích của giai đoạn thử nghiệm cuối cùng là thu thập ấn tượng khi làm việc với sản phẩm, để hiểu người dùng thích gì và điều gì khiến họ khó chịu cũng như đánh giá sự hài lòng chủ quan. Thông thường, phần kiểm tra này sử dụng sự kết hợp giữa phỏng vấn với người điều hành và hoàn thành bảng câu hỏi chính thức.

Phỏng vấn người điều hành

Trong cuộc phỏng vấn cuối cùng, chúng tôi luôn hỏi những người trả lời những câu hỏi giống nhau: “Ấn tượng của bạn là gì?”, “Bạn thích điều gì và điều gì không?”, “Có điều gì có vẻ khó khăn hoặc bất tiện không?”, “Điều gì là còn thiếu?”, “Bạn muốn thay đổi điều gì ở sản phẩm?” Đã đến lúc làm rõ những khía cạnh chưa rõ ràng trong hành vi của người trả lời nếu bạn không làm điều này trong quá trình kiểm tra. Nếu trước khi thử nghiệm, bạn phát hiện ra thái độ của người dùng đối với thương hiệu hoặc sản phẩm cũng như kỳ vọng của họ đối với nó, hãy tìm hiểu xem có điều gì đã thay đổi hay không. Khi phỏng vấn, hãy chú ý những điều sau:

Mong muốn xã hội. Xử lý kết quả phỏng vấn rất cẩn thận. Nếu trong quá trình kiểm tra, bạn thường nghe thấy những nhận xét bốc đồng dưới ảnh hưởng của các vấn đề, thì trong cuộc phỏng vấn cuối cùng, sự khao khát xã hội sẽ phát triển.

Một số người cảm thấy rằng khi nói về các vấn đề của sản phẩm, họ đang thừa nhận sự kém cỏi của mình. Những người khác chỉ đơn giản là không muốn làm phiền người điều hành dễ chịu. Rất thường xuyên, những người được hỏi (đặc biệt là phụ nữ), những người đã trải qua toàn bộ bài kiểm tra, nói rằng về nguyên tắc, mọi thứ đều bình thường. Phản hồi tiêu cực cũng có thể được quyết định bởi mong muốn của xã hội: nếu người trả lời tin rằng mục đích của bài kiểm tra là tìm ra sai sót, thì anh ta sẽ siêng năng cố gắng tìm ra chúng.

Báo giá và ưu tiên. Mặc dù tất cả những lời nói của thí sinh trong buổi phỏng vấn cuối cùng thường phải chia đôi, thậm chí là mười, nhưng điều này không có nghĩa là chúng vô dụng. Dựa trên cách người trả lời tóm tắt ấn tượng của họ, bạn có thể suy ra các ưu tiên. Sản phẩm có phải là “hoàn toàn tào lao” không? Chính xác thì điều gì đã ảnh hưởng đến điều này? Vấn đề nào trong số nhiều vấn đề mà người trả lời nhớ nhất và cho là khó chịu nhất?

Tuy nhiên, hãy chấp nhận thực tế là nhiệm vụ cuối cùng được ghi nhớ tốt nhất. Việc theo dõi những tính từ mà người trả lời sử dụng để mô tả sản phẩm và những gì họ so sánh trải nghiệm của họ cũng rất hữu ích.

Chúng ta đừng quên những điều tốt đẹp. Thông thường, báo cáo kiểm tra khả năng sử dụng là một danh sách dài các vấn đề được tìm thấy trong quá trình kiểm tra. Nhìn chung, việc tìm ra vấn đề là một trong những nhiệm vụ chính của nghiên cứu. Nhưng đừng quên những khía cạnh tích cực của sản phẩm.

Thứ nhất, một báo cáo không có kết quả tích cực chỉ đơn giản là làm mất đi động lực của nhóm. Và thứ hai, sẽ rất hữu ích khi biết người dùng thích gì ở sản phẩm: điều gì sẽ xảy ra nếu trong lần thiết kế lại tiếp theo, họ quyết định loại bỏ tính năng mà mọi người rất thích. Do đó, hãy nhớ hỏi người trả lời về các khía cạnh tích cực của sản phẩm, ngay cả khi họ chỉ trích giao diện trong suốt quá trình thử nghiệm.

Thái độ đối với “mong muốn”. Rất có thể, người được hỏi, ngoài ấn tượng của họ, sẽ bày tỏ mong muốn và ý kiến. Công việc của bạn là hiểu vấn đề đằng sau các đề xuất là gì. Bởi những giải pháp mà người dùng đưa ra rất có thể sẽ không phù hợp với bạn. Suy cho cùng, những người tham gia thử nghiệm không phải là nhà thiết kế; họ không nhận thức được các tính năng và hạn chế của quá trình phát triển. Tuy nhiên, đằng sau bất kỳ yêu cầu nào như vậy đều có một nhu cầu mà bạn phải nắm bắt. Nếu người trả lời nói rằng anh ta thực sự cần một nút lớn màu xanh lá cây ở đây, hãy nhớ hỏi: tại sao?

Đo lường sự hài lòng

Thông thường, theo lời của người trả lời trong cuộc phỏng vấn cuối cùng, thật khó để hiểu liệu anh ta có thích sản phẩm này hay không, và thậm chí còn khó hơn để so sánh thái độ của một số người trả lời đã lưu ý cả ưu điểm và nhược điểm. Ở đây các câu hỏi sẽ hỗ trợ người nghiên cứu. Thứ nhất, khi điền vào bảng câu hỏi (đặc biệt là trước khi nói chuyện với người điều hành), ảnh hưởng của sự khao khát xã hội khét tiếng sẽ ít hơn một chút, mặc dù bạn sẽ không hoàn toàn loại bỏ nó. Thứ hai, bảng câu hỏi cung cấp cho bạn những thông số rõ ràng để so sánh các kịch bản, sản phẩm hoặc giai đoạn dự án.

Biên soạn một bảng câu hỏi tốt là một chủ đề riêng biệt và rất lớn. Ở đây, từ ngữ, thang âm và nhiều thứ khác đều quan trọng. Các câu hỏi được làm sẵn và đã được chứng minh có thể giúp ích rất nhiều: chúng đã được mài giũa và thử nghiệm nhiều lần. Vấn đề duy nhất là hầu như tất cả các bảng câu hỏi này đều không có bản dịch chính thức sang tiếng Nga. Đương nhiên, bạn có thể tự dịch chúng, nhưng từ quan điểm phương pháp luận, các bản dịch cần phải được kiểm tra để kiểm tra tính chính xác của từ ngữ. Tuy nhiên, các bảng câu hỏi có thể đóng vai trò như một hướng dẫn khi tạo bảng câu hỏi của riêng bạn.

Có những bảng câu hỏi được đưa ra sau mỗi nhiệm vụ để đánh giá mức độ hài lòng với các tình huống cụ thể. Ví dụ:

• Sau bảng câu hỏi kịch bản (ASQ). Ba câu hỏi về độ phức tạp, năng suất và gợi ý trong hệ thống.
• Câu hỏi đơn giản (SEQ) . Một câu hỏi về độ phức tạp của kịch bản.

Và có những bảng câu hỏi đã được sử dụng trong giai đoạn thử nghiệm cuối cùng. Dưới đây là một số ví dụ mà chúng tôi sử dụng khi cần thiết:

• Thang đo khả năng sử dụng hệ thống và Bảng câu hỏi về khả năng sử dụng hệ thống sau nghiên cứu. Hai bảng câu hỏi cổ điển và phổ biến được tạo ra cách đây hơn 20 năm. Cả hai đều bao gồm các tuyên bố. Người trả lời phải cho biết mức độ đồng ý của họ với họ. Tất cả những tuyên bố này mô tả khả năng sử dụng của sản phẩm từ các góc độ khác nhau. Ví dụ: “Tôi có thể dễ dàng tìm thấy thông tin mình cần”, “Có thể dễ dàng truy cập các khả năng khác nhau của hệ thống”, v.v.
• . Một bảng câu hỏi thường giúp chúng ta trong quá trình kiểm tra. Người dùng được cung cấp một tập hợp các tính từ để từ đó họ chọn những tính từ có thể mô tả đặc điểm của sản phẩm. Kết quả là bạn sẽ có được một đám mây từ - đặc điểm của dự án của bạn. Thường thì kỹ thuật này mang lại kết quả rất thú vị.
• Bảng câu hỏi trải nghiệm trò chơi. Không thể áp dụng bảng câu hỏi về khả năng sử dụng cổ điển cho trò chơi: việc tham gia vào trò chơi quan trọng hơn nhiều so với khả năng hiểu giao diện. Do đó, bạn phải luôn tạo bảng câu hỏi đặc biệt cho trò chơi hoặc sử dụng Bảng câu hỏi trải nghiệm trò chơi. Bảng câu hỏi chứa một số mô-đun: mô-đun cơ bản, khối trong trò chơi, bảng câu hỏi sau và bảng câu hỏi về khả năng xã hội của trò chơi.
Tài liệu được xuất bản bởi người dùng. Nhấp vào nút “Viết” để chia sẻ ý kiến ​​của bạn hoặc nói về dự án của bạn.