{/* Trang này được tạo tự động từ SKILL.md của kỹ năng bởi website/scripts/generate-skill-docs.py. Chỉnh sửa nguồn SKILL.md, không phải trang này. */}

Thử nghiệm Ux đối nghịch

Đóng vai người dùng khó tính nhất, kháng công nghệ nhất đối với sản phẩm của bạn. Duyệt ứng dụng với tư cách là nhân vật đó, tìm mọi điểm yếu của UX, sau đó lọc các khiếu nại thông qua lớp chủ nghĩa thực dụng để tách các vấn đề thực sự khỏi tiếng ồn. Chỉ tạo các yêu cầu có thể xử lý được từ các vấn đề thực sự.

Siêu dữ liệu kỹ năng

Nguồn	Tùy chọn — cài đặt với
`Hermes skills install official/dogfood/adversarial-ux-test
`
Đường dẫn

optional-skills/dogfood/adversarial-ux-test ` | | Phiên bản |

1.0.0 ` | | Tác giả | Omni @ Comelse | | Giấy phép | MIT | | Nền tảng | Linux, macOS, Windows | | Thẻ |

qa

, `ux

, `testing

, `adversarial

, `dogfood

, `personas

, user-testing | | Kỹ năng liên quan | XPROTECTX12XPROTECTX |

Tham khảo: đầy đủ SKILL.md

thông tin

Sau đây là định nghĩa kỹ năng đầy đủ mà Hermes tải khi kỹ năng này được kích hoạt. Đây là những gì tác nhân coi là hướng dẫn khi kỹ năng được kích hoạt.

Thử nghiệm UX đối nghịch

Đóng vai người dùng trong trường hợp xấu nhất đối với sản phẩm của bạn - người ghét công nghệ, không muốn phần mềm của bạn và sẽ tìm mọi lý do để phàn nàn. Sau đó lọc phản hồi của họ thông qua lớp chủ nghĩa thực dụng để tách các vấn đề UX thực sự khỏi tiếng ồn "Tôi ghét máy tính".

Hãy coi đó như một "bài kiểm tra mẹ" tự động - nhưng tức giận.

Tại sao điều này lại hiệu quả

Hầu hết QA đều tìm thấy lỗi. Điều này phát hiện ma sát. Một ứng dụng đúng về mặt kỹ thuật vẫn có thể không sử dụng được cho người thật. Tính cách đối lập bắt:

• Thuật ngữ khó hiểu có ý nghĩa đối với nhà phát triển chứ không phải người dùng
• Quá nhiều bước để hoàn thành nhiệm vụ cơ bản
• Thiếu khoảnh khắc làm quen hoặc "aha"
• Các vấn đề về khả năng truy cập (cỡ chữ, độ tương phản, mục tiêu nhấp chuột)
• Sự cố khởi động nguội (trạng thái trống, không có nội dung demo)
• Rào cản giữa tường phí/đăng ký làm mất chuyển đổi`Bộ lọc chủ nghĩa thực dụng (Giai đoạn 3) là yếu tố khiến điều này trở nên hữu ích thay vì chỉ mang tính giải trí. Nếu không có nó, bạn sẽ thêm nút "in trang này" vào mọi màn hình vì Ông nội không thể tìm ra các tệp PDF.

Cách sử dụng

Hãy nói với người đại diện:

`

"Run an adversarial UX test on [URL]" "Be a grumpy [persona type] and test [app name]" "Do an aSSHole user test on my staging site"

` ``Bạn có thể cung cấp một nhân cách hoặc để đại lý tạo một nhân cách dựa trên đối tượng mục tiêu của sản phẩm của bạn.

Bước 1: Xác định Persona

Nếu không có cá tính nào được cung cấp, hãy tạo một cá tính bằng cách trả lời:

1. Ai là người dùng CỨNG NHẤT đối với sản phẩm này? (trên 50 tuổi, vai trò phi kỹ thuật, hàng chục năm kinh nghiệm làm việc đó "theo cách cũ")
2. Mức độ thoải mái về công nghệ của họ là gì? (càng thấp càng tốt - sổ tay giấy, chỉ dành cho WhatsApp, vợ đã thiết lập email cho họ)
3. MỘT điều họ cần hoàn thành là gì? (công việc cốt lõi của họ, không phải danh sách tính năng của bạn)
4. Điều gì sẽ khiến họ bỏ cuộc? (quá nhiều cú nhấp chuột, biệt ngữ, chậm, khó hiểu)
5. Họ nói chuyện thế nào khi bực bội? (thẳng thừng, chửi thề, xua đuổi, thở dài)

Ví dụ về Persona Tốt

"Big Mick" McAllister — huấn luyện viên S&C 58 tuổi. Sử dụng WhatsApp và thế là xong. "Bảng tính" của anh ấy là một cuốn sổ tay bằng giấy. "Nếu tôi không thể tìm ra nó trong 10 giây thì tôi sẽ quay lại cuốn sổ tay của mình." Cần ghi lại kết quả phiên của 25 người chơi. Ghét văn bản nhỏ, biệt ngữ và mật khẩu.

Ví dụ về tính cách xấu

"Người dùng không thích ứng dụng" — quá mơ hồ, không ràng buộc, không có tiếng nói.

Tính cách này phải đủ cụ thể để giữ nguyên tính cách trong 20 phút thử nghiệm.

Bước 2: Trở thành ASSHole (Duyệt với tư cách Persona)

1. Đọc mọi tài liệu dự án có sẵn về ngữ cảnh và URL của ứng dụng
2. Hoàn toàn thể hiện tính cách — những nỗi thất vọng, hạn chế, mục tiêu của họ
3. Điều hướng đến ứng dụng bằng công cụ trình duyệt
4. Thực hiện NHIỆM VỤ THỰC TẾ của nhân vật (không phải chuyến tham quan đặc sắc):
   • Họ có thể làm được việc họ đến để làm không?
   • Có bao nhiêu lần nhấp chuột/màn hình để thực hiện nó?
   • Điều gì khiến họ bối rối vậy?
   • Điều gì khiến họ tức giận?
   • Họ lạc ở đâu?
   • Điều gì đã khiến họ bỏ cuộc và quay lại con đường cũ?
5. Kiểm tra các loại ma sát này:
   • Ấn tượng đầu tiên — liệu họ có bận tâm đến trang đích không?
   • Quy trình làm việc cốt lõi — MỘT điều họ cần làm thường xuyên nhất
   • Khôi phục lỗi — điều gì xảy ra khi họ làm sai điều gì đó?
   • Khả năng đọc — kích thước văn bản, độ tương phản, mật độ thông tin
   • Tốc độ — phương pháp này có nhanh hơn phương pháp hiện tại của họ không?
   • Thuật ngữ — bất kỳ biệt ngữ nào họ không hiểu?
   • Điều hướng — họ có thể tìm đường quay lại không? họ có biết họ ở đâu không?
6. Chụp ảnh màn hình mọi điểm yếu
7. Kiểm tra bảng điều khiển trình duyệt để tìm lỗi JS trên mỗi trang## Bước 3: Rant (Viết phản hồi bằng ký tự)

Viết phản hồi NHƯ CON NGƯỜI - bằng giọng nói của họ, với sự thất vọng của họ. Đây không phải là một báo cáo lỗi. Đây là một sự trút giận thực sự của con người.

` [PERSONA NAME]'s Review of [PRODUCT]

Overall: [Would they keep using it? Yes/No/Maybe with conditions]

THE GOOD (grudging admission):

• [things even they have to admit work]

THE BAD (legitimate UX issues):

• [real problems that would stop them from using the product]

THE UGLY (showstoppers):

• [things that would make them uninstall/cancel immediately]

SPECIFIC COMPLAINTS:

1. [Page/feature]: "[quote in persona voice]" — [what happened, expected]
2. ...

VERDICT: "[one-line persona quote summarizing their experience]"

`

Bước 4: Bộ lọc chủ nghĩa thực dụng (Quan trọng - Không bỏ qua)

Bước RA KHỎI cá tính. Đánh giá từng khiếu nại với tư cách là người sản phẩm:

• ĐỎ: LỖI UX THỰC SỰ — Bất kỳ người dùng nào cũng sẽ gặp phải vấn đề này, không chỉ những người khó tính. Sửa nó đi.
• MÀU VÀNG: HỢP LỆ NHƯNG ƯU TIÊN THẤP — Vấn đề thực sự nhưng chỉ dành cho người dùng cực đoan. Lưu ý nó.
• TRẮNG: TIẾNG ỒN CÁ NHÂN — Việc nói "Tôi ghét máy tính", không phải vấn đề về sản phẩm. Bỏ qua nó.
• XANH: YÊU CẦU TÍNH NĂNG — Ý tưởng hay ẩn trong đơn khiếu nại. Hãy xem xét nó.

Tiêu chí lọc

1. Liệu một người dùng 35 tuổi có năng lực nhưng bận rộn có phàn nàn như vậy không? → ĐỎ
2. Đây có phải là sự cố thực sự về khả năng truy cập (cỡ chữ, độ tương phản, mục tiêu nhấp chuột) không? → ĐỎ
3. Đây có phải là sự phản kháng "Tôi muốn nó hoạt động như tờ giấy" đối với kỹ thuật số? → TRẮNG
4. Đây có phải là sự kém hiệu quả thực sự của quy trình làm việc mà nhân vật đó gặp phải? → VÀNG hoặc ĐỎ
5. Việc sửa lỗi này có làm tăng thêm sự phức tạp cho 80% số người ổn không? → TRẮNG
6. Khiếu nại có tiết lộ khoảnh khắc làm quen bị thiếu không? → XANH`Bộ lọc này là BẮT BUỘC. Không bao giờ gửi khiếu nại cá nhân thô dưới dạng phiếu yêu cầu.

Bước 5: Tạo Ticket

Chỉ dành cho các mặt hàng ĐỎ và XANH:

• Tiêu đề rõ ràng, dễ thực hiện
• Bao gồm trích dẫn nguyên văn của nhân vật (giải trí + đáng nhớ)
• Vấn đề UX thực sự bên dưới (khách quan)
• Một bản sửa lỗi được đề xuất (có thể thực hiện được)
• Thẻ/nhãn: "ux-review"

Đối với mặt hàng VÀNG: một vé trọn gói có đầy đủ ghi chú.

Các mục TRẮNG chỉ xuất hiện trong báo cáo. Không có vé.

Tối đa 10 vé mỗi phiên — tập trung vào những vấn đề tồi tệ nhất.

Bước 6: Báo cáo

Cung cấp:

1. Lời nói cá nhân (Bước 3) - mang tính giải trí và mang tính nội tạng
2. Đánh giá được lọc (Bước 4) - thực tế và có thể hành động
3. Đã tạo vé (Bước 5) — có liên kết
4. Ảnh chụp màn hình các vấn đề chính

Mẹo

• Mỗi phiên một người. Không trộn lẫn các quan điểm.
• Giữ nguyên nhân vật trong Bước 2-3. Chỉ ngắt nhân vật ở Bước 4.
• Kiểm tra QUY TRÌNH CỐT LÕI trước. Đừng để bị phân tâm bởi các trang cài đặt.
• Trạng thái trống rỗng là vàng. Trải nghiệm người dùng mới bộc lộ nhiều khó khăn nhất.
• Phát hiện tốt nhất là những vật phẩm ĐỎ mà nhân vật vô tình tìm thấy khi đang cố gắng làm việc khác.
• Nếu người đó không có lời phàn nàn nào thì người đó quá hiểu biết về công nghệ. Hãy khiến họ già đi, ít kiên nhẫn hơn và cứng rắn hơn theo cách của họ.
• Chạy phần mềm này trước khi giới thiệu, ra mắt hoặc sau khi cung cấp một loạt tính năng.
• Đăng ký làm người dùng MỚI khi có thể. Không sử dụng tài khoản quản trị viên được cài sẵn — trải nghiệm khởi đầu nguội là nơi xảy ra nhiều xích mích nhất.
• Các mục KHÔNG TRẮNG là một tín hiệu, không phải là lỗi. Nếu bộ lọc chủ nghĩa thực dụng không phát hiện thấy nhiễu thì sản phẩm của bạn thực sự có vấn đề về trải nghiệm người dùng chứ không chỉ là một người khó tính.
• Kiểm tra các vấn đề đã biết trong tài liệu dự án SAU khi thử nghiệm. Nếu người đó tìm thấy một lỗi đã có trong danh sách các vấn đề đã biết, thì đó thực sự là phát hiện tai hại nhất — điều đó có nghĩa là nhóm đã biết về lỗi đó nhưng chưa bao giờ cảm thấy phiền toái cho người dùng.
• Thử nghiệm đăng ký/tường phí là rất quan trọng. Thử nghiệm với các tài khoản đã hết hạn, không chỉ các tài khoản đang hoạt động. Trải nghiệm "điều gì xảy ra khi bạn không thể thanh toán" cho biết sản phẩm có tôn trọng người dùng hay giữ dữ liệu của họ làm con tin hay không.
• Đếm số lần nhấp để hoàn thành MỘT nhiệm vụ của cá nhân. Nếu nhiều hơn 5, đó hầu như luôn là phát hiện ĐỎ bất kể trình độ công nghệ của cá nhân.

Ví dụ về Personas theo ngành

Đây là những điểm bắt đầu - tùy chỉnh cho sản phẩm cụ thể của bạn:

Loại sản phẩm	Nhân cách	Tuổi	Đặc điểm chính
CRM	Giám đốc nhà hưu trí	68	Tủ hồ sơ là CRM hiện hành
Nhiếp ảnh SaaS	Nhiếp ảnh gia đám cưới nông thôn	62	Ghi sổ khách hàng qua điện thoại, hóa đơn trên giấy
Công cụ AI/ML	Người mua cửa hàng bách hóa	55	Bị đốt cháy bởi 3 startup công nghệ thất bại
Ứng dụng thể hình	Huấn luyện viên thể dục trường học cũ	58	Sổ tay giấy, ngón tay dày, mắt xấu
Kế toán	Gia đình chủ tiệm bánh	64	Hộp đựng hóa đơn, ghét đăng ký
Thương mại điện tử	Nhà cung cấp gian hàng ở chợ	60	Chỉ tiền mặt, điện thoại thông minh dành cho cuộc gọi
Chăm sóc sức khỏe	GP cao cấp	63	Đọc ghi chú, y tá xử lý máy tính
Giáo dục	Giáo viên kỳ cựu	57	Phấn và nói, bảng tính đựng trong bìa cứng

Quy tắc- Giữ nguyên nhân vật trong Bước 2-3

• Hãy thực sự xấu tính nhưng công bằng - tìm ra những vấn đề thực sự chứ không phải những vấn đề được tạo ra
• Bộ lọc chủ nghĩa thực dụng (Bước 4) là BẮT BUỘC
• Cần có ảnh chụp màn hình cho mọi khiếu nại
• Tối đa 10 vé/buổi
• Thử nghiệm trên ứng dụng dàn dựng/triển khai, không phải nhà phát triển cục bộ
• Một cá nhân, một phiên họp, một báo cáo