Sau khi nghiên cứu khả năng sử dụng thì làm gì?

Các vấn đề thường gặp phải

Dưới đây là 1 vài loại vấn đề mà bạn sẽ gặp khá nhiều khi tiến hành Test.

Người dùng chưa hiểu rõ về trang Web. Họ chỉ đơn giản là không hiểu được thôi. Họ nhìn vào 1 trang Web và hoặc là họ không hiểu nó là cái gì, hoặc là họ tưởng là hiểu rồi nhưng hoá ra là hiểu nhầm.
Những từ khoá mà họ đang tìm kiếm không ở đó. Thường thì điều này nghĩa là bạn đã không lường trước được hết những thứ mà người dùng cần tìm, hoặc là các từ khoá bạn dùng để mô tả mọi thứ khác với các từ khoá họ dùng. -
Có nhiều thứ diễn ra quá. Đôi khi những thứ họ đang tìm nằm ngay giữa trang Web, nhưng người dùng lại không nhìn thấy được. Trong trường hợp này, bạn phải giảm đi sự nhiễu loạn thông tin trong thiết kế, hoặc là cố gắng làm nổi bật hơn những thứ mà người dùng đang muốn tìm.

Họp báo cáo: Quyết định xem nên sửa cái gì

Sau mỗi lượt Test, bạn nên sắp xếp thời gian càng sớm càng tốt cho cả team ngồi cùng nhau và chia sẻ về những thứ họ quan sát được, và quyết định xem nên khắc phục vấn đề nào, và khắc phục ra sao.
Tôi gợi ý mọi người tiến hành họp báo cáo ngay trong bữa trưa sau khi cuộc Test kết thúc, với mọi ấn tượng và quan sát còn mới nguyên trong đầu mọi người. (Order pizza thật là ngon, thật là nhiều để khuyến khích mọi người tham gia đầy đủ) Bất cứ khi nào bạn test, hầu như lúc nào bạn cũng sẽ tìm ra 1 vài vấn đề nghiêm trọng về Tính khả dụng. Không may là, không phải lúc nào chúng cũng là thứ được ưu tiên khắc phục. Thường thì sẽ có người nói: “Ừ biết là cái đó cùi rồi, nhưng cả cái tính năng đó sẽ bị đổi sớm thôi, và từ giờ tới đó cứ để nó đấy cũng chả sao". Hoặc là khi phải đối mặt với sự lựa chọn giữa việc sửa 1 vấn đề nghiêm trọng hay sửa nhiều vấn đề đơn giản, thường thì họ sẽ chọn cái nào ít tốn công hơn.
Đây chính 1 lý do tại sao bạn vẫn thường gặp những lỗi cực nghiêm trọng về Tính khả dụng ngay cả ở trên những trang Web lớn, có nền tảng đầu tư dồi dào, và chính vì lẽ đó nên 1 trong những “lẽ sống" của tôi tại Rocket Surgery là:

“Phải tập trung vào các vấn đề nghiêm trọng nhất trước tiên, bất chấp mọi thứ khác"

Sau đây là phương pháp tôi hay dùng để đảm bảo “lẽ sống" này được tuân theo, nhưng với team của bạn thì cứ liệu cơm gắp mắm thôi nhé.

Tạo 1 danh sách chung. Đi 1 vòng, yêu cầu tất cả mọi người nêu ra 3 vấn đề nghiêm trọng nhất mà họ quan sát được sau mỗi vòng Test (ít nhất phải có 9 cái vấn đề, vì đã có 3 vòng Test rồi.). Viết chúng lên bảng. Thường thì sẽ có nhiều người nói “Tôi cũng thấy thế" với 1 vài vấn đề, và bạn có thể track số lượng bằng việc thêm dấu tick ở mỗi vấn đề. ở giai đoạn này thì không có tranh cãi thảo luận gì cả, bạn chỉ cần liệt kê ra các vấn đề thôi. Những thành viên khác trong team phải quan sát và chỉ ra được các vấn đề có thực, đã diễn ra trong các vòng Test.
Chọn 10 vấn đề nghiêm trọng nhất. Bạn có thể tổ chức vote cho dân chủ, nhưng thường thì chỉ cần chọn luôn những vấn đề mà có nhiều dấu tick nhất là được (có nhiều người cho rằng đó là 1 vấn đề nghiêm trọng nhất)
Phân loại và đánh giá các vấn đề. Xếp chúng theo thứ tự từ 1 tới 10, với 1 là vấn đề nghiêm trọng, tồi tệ nhất. Cái top 10 này để riêng ra 1 chỗ.
Tạo danh sách được sắp xếp theo thứ tự. Đi từ trên xuống, viết ra những ý tưởng sơ bộ về việc Làm thế nào để khắc phục vấn đề này trong 1 tháng tới, ai sẽ đảm nhận việc này, và các tài nguyên cần có để việc khắc phục vấn đề này.
Bạn không cần phải khắc phục các vấn đề 1 cách triệt để và hoàn hảo. Bạn chỉ cần cố gắng cải thiện nó là được - tinh chỉnh chau chuốt 1 chút - vừa đủ để đá nó khỏi danh sách “Các vấn đề nghiêm trọng" là đc. Khi bạn cảm thấy mình đã phân bố đủ mọi quỹ thời gian và nhân lực có thể cho việc khắc phục các vấn đề trong nguyên 1 tháng tiếp theo,
DỪNG LẠI NGAY. Bạn đã đạt được mục tiêu. Cả nhóm đã quyết định được cái gì cần phải sửa và có trách nghiệm phải sửa chúng.

Dưới đây là 1 vài tips giúp bạn quyết định nên sửa cái gì - và không nên sửa cái gì.

Tạo 1 danh sách riêng cho các vấn đề nhỏ lẻ. Bạn có thể giữ 1 danh sách các vấn đề không quá nghiêm trọng và cũng khá dễ khắc phục. Ý tôi nói ‘dễ khắc phục' ở đây là 1 người có thể sửa nó trong không quá 1 tiếng, mà không cần phải chờ sự đồng ý cho phép của bất cứ ai không tham gia họp báo cáo.
Tránh sự cám dỗ của việc thêm thắt. Khi mà thấy rõ được là người dùng chắc chắn không hiểu được cái gì đó, phản ứng đầu tiên của đội phát triển sản phẩm thường là cố gắng thêm cái nọ cái kia, kiểu thêm 1 cái phần giải thích hoặc hướng dẫn gì đó. Nhưng thường thì giải pháp đúng đắn chỉ đơn giản là bỏ đi những thứ (hoặc 1 vài thứ) không cần thiết để khiến cho mọi thứ rõ ràng, dễ hiểu hơn, thay vì lại nhét thêm 1 thứ khác gây phân tán sự tập trung.
Hãy cẩn thận và tỉnh táo trước những yêu cầu “thêm tính năng mới". Các ứng viên thường sẽ nói “Nếu có cái tính năng này thì sẽ tiện hơn nhiều". Cứ thật tỉnh táo, đa nghi trước những yêu cầu thêm tính năng mới kiểu này, không thiệt đi đâu được. Tôi phát hiện ra rằng, nếu bạn yêu cầu họ mô tả cái tính năng đó sẽ hoạt động ra sao - trong phần “hỏi thăm dò" ở cuối 1 cuộc Test - thường thì trăm người như một, cho tới khi họ mô tả xong thì chính họ cũng sẽ thú nhận “Giờ nói ra mới thấy, có khi tôi cũng chả dùng cái tính năng này đâu". Các ứng viên tất nhiên không phải Designer, nhưng thi thoảng họ sẽ có các ý tưởng rất hay, và khi họ có thì bạn sẽ biết luôn, vì bạn sẽ tự nhủ “Sao mình không nghĩ ra cái này nhỉ!?”
Kệ các vấn đề kiểu “ thuyền Kayak”. Trong bất cứ cuộc Test nào, khả năng cao bạn sẽ gặp 1 vài trường hợp mà người dùng sẽ đi lạc trong chốc lát nhưng vẫn quay lại đúng hướng được ngay sau đó mà không cần trợ giúp gì cả. Nó cũng như kiểu bạn đi thuyền Kayak ấy, miễn là con thuyền tự chỉnh được sự cân bằng đủ sớm, thì mọi thứ vẫn ổn. Trong thuật ngữ bóng rổ thì cái này gọi là “No harm, No foul" (không gây hại thì cũng không phạm lỗi) Miễn là
a) bất cứ ai gặp phải vấn đề đều tự nhận ra được mình đang đi sai hướng 1 cách nhanh chóng
b) họ có thể tự sửa chữa tình hình mà không cần giúp
c) họ không bị hoảng loạn, bối rối
thì bạn hoàn toàn có thể tự tin bỏ qua các vấn đề này. Nhìn chung, nếu người dùng đoán sai lần đầu mà đoán đúng ở ngay lần 2 thì cũng tính là tạm ổn rồi.