[97 điều lập trình viên nên biết – #03] Bạn không phải người dùng: Hãy quan sát thay vì phỏng đoán

Tóm tắt

Lập trình viên thường cho rằng người dùng sẽ suy nghĩ và thao tác với phần mềm giống mình. Tuy nhiên, người dùng có kiến thức, thói quen và kỳ vọng khác biệt. Quan sát cách họ thực hiện công việc thực tế giúp chúng ta phát hiện những vấn đề về trải nghiệm, kiểm chứng các giả định và thiết kế phần mềm phù hợp hơn với nhu cầu người dùng.

Vì sao lập trình viên thường hiểu sai người dùng?

Chúng ta thường có xu hướng cho rằng người khác suy nghĩ và hành động giống mình. Trong tâm lý học, hiện tượng này được gọi là hiệu ứng đồng thuận giả (False Consensus Effect).

Trong phát triển phần mềm, thiên kiến này có thể khiến lập trình viên thiết kế những giao diện dễ hiểu với bản thân nhưng lại khó sử dụng đối với người dùng.

Lập trình viên dành nhiều thời gian làm việc với máy tính, quen thuộc với các kiểu giao diện và biết cách xử lý khi gặp sự cố.

Trong khi đó, người dùng thông thường không nhất thiết có cùng kinh nghiệm. Họ có thể không hiểu cách phần mềm vận hành bên trong và cũng không có nhu cầu tìm hiểu điều đó. Mục tiêu của họ đơn giản là hoàn thành công việc.

Một nút chức năng có vẻ hiển nhiên với lập trình viên có thể khó nhận biết đối với người dùng.

Khi họ gặp khó khăn, nguyên nhân chưa chắc nằm ở việc thiếu kiến thức, mà có thể do giao diện được thiết kế dựa trên những giả định không phù hợp.

Bài học quan trọng nhất: Bạn không phải người dùng.

Hãy quan sát những gì người dùng thực sự làm

Cách hiệu quả để hiểu người dùng là trực tiếp quan sát cách họ thực hiện những nhiệm vụ gần với công việc thực tế.

Giả sử bạn đang phát triển một ứng dụng bảng tính.

Thay vì yêu cầu:

"Hãy chọn ô này và nhập công thức SUM."

Bạn nên đưa ra một nhiệm vụ tự nhiên hơn:

"Hãy tính tổng số tiền bạn đã chi tiêu trong tháng trước."

Yêu cầu thứ hai chỉ xác định mục tiêu, không chỉ định cách thực hiện. Nhờ đó, bạn có thể quan sát người dùng lựa chọn chức năng nào, gặp khó khăn ở đâu và giải quyết vấn đề như thế nào.

Trong quá trình quan sát, hãy khuyến khích người dùng giải thích suy nghĩ của họ. Tuy nhiên, không nên ngắt lời hoặc trợ giúp quá sớm.

Khi họ gặp khó khăn, hãy tự hỏi:

• Tại sao họ chọn thao tác này?
• Họ mong đợi kết quả gì?
• Vì sao họ không chú ý đến lựa chọn khác?

Những tình huống này giúp chúng ta hiểu cách người dùng nhìn nhận giao diện và phát hiện những điểm thiết kế chưa hợp lý.

Mục đích không phải kiểm tra khả năng sử dụng máy tính của người dùng, mà là tìm hiểu phần mềm có hỗ trợ cách làm việc tự nhiên của họ hay không.

Bốn bài học quan trọng từ việc quan sát người dùng

1. Người dùng thường mắc những lỗi tương tự nhau

Khi nhiều người thực hiện cùng một nhiệm vụ, họ thường có xu hướng thao tác theo trình tự giống nhau và gặp những khó khăn tương tự.

Nếu nhiều người liên tục bỏ qua cùng một nút hoặc hiểu sai một hướng dẫn, vấn đề có thể nằm ở cách thiết kế giao diện.

Đây là lý do việc quan sát hành vi thực tế có giá trị hơn việc chỉ thảo luận về những gì người dùng có thể sẽ làm.

Thay vì bổ sung tính năng dựa trên phỏng đoán, nhóm phát triển nên tập trung giải quyết những khó khăn thường xuyên lặp lại.

2. Khi gặp khó khăn, người dùng thường thu hẹp sự chú ý

Lập trình viên quen với việc thử nhiều cách khác nhau khi gặp sự cố. Tuy nhiên, người dùng thông thường không nhất thiết hành động như vậy.

Khi bối rối, họ thường tập trung vào khu vực đang gặp vấn đề và khó nhận ra giải pháp ở vị trí khác trên màn hình.

Vì vậy, hướng dẫn nên xuất hiện ngay tại nơi xảy ra vấn đề.

Ví dụ, một thông báo lỗi bên cạnh trường nhập dữ liệu sai định dạng thường hữu ích hơn hướng dẫn nằm trong menu trợ giúp riêng biệt.

Tooltip và các thông báo theo ngữ cảnh giúp người dùng tìm được cách xử lý mà không phải rời khỏi công việc đang thực hiện.

3. Người dùng ưu tiên cách làm quen thuộc hơn cách làm hiệu quả

Lập trình viên thường yêu thích phím tắt và những thao tác giúp tiết kiệm thời gian. Nhưng với người dùng, hoàn thành công việc mới là ưu tiên hàng đầu.

Một khi đã tìm được phương pháp hiệu quả với bản thân, họ có xu hướng tiếp tục sử dụng, ngay cả khi tồn tại cách làm nhanh hơn.

Ví dụ, một người có thể liên tục mở menu để sao chép và dán thay vì sử dụng phím tắt.

Vì vậy, thay vì cung cấp quá nhiều cách thao tác, phần mềm nên ưu tiên một phương pháp rõ ràng, dễ nhận biết và dễ thực hiện cho các nhiệm vụ chính.

Những chức năng nâng cao vẫn hữu ích, nhưng không nên thay thế quy trình cơ bản dễ hiểu.

4. Điều người dùng nói có thể khác với điều họ thực sự làm

Phỏng vấn và thu thập yêu cầu là những hoạt động quan trọng trong phát triển phần mềm. Tuy nhiên, lời nói của người dùng không phải lúc nào cũng phản ánh chính xác hành vi thực tế.

Họ có thể mô tả cách mình nghĩ rằng đang làm việc, trong khi thao tác thực tế lại khác.

Chẳng hạn, một người có thể yêu cầu bổ sung tính năng mới nhưng lại hiếm khi sử dụng sau khi tính năng được triển khai.

Điều này không có nghĩa chúng ta nên bỏ qua ý kiến người dùng.

Thay vào đó, cần kết hợp những gì họ chia sẻ với những gì quan sát được. Khi lời nói và hành động không trùng khớp, đó chính là điểm cần tìm hiểu thêm.

Áp dụng quan sát vào thiết kế phần mềm

Quan sát chỉ thực sự có giá trị khi những phát hiện được chuyển thành quyết định thiết kế.

Những bài học này cũng có ý nghĩa trong quá trình phân tích yêu cầu và phát triển phần mềm.

Một chức năng có thể hoạt động hoàn toàn đúng đặc tả nhưng vẫn gây khó khăn cho người sử dụng. Đúng về mặt kỹ thuật không đồng nghĩa với trải nghiệm tốt.

Đối với các nhóm phát triển phần mềm như VAON, nguyên tắc này nhấn mạnh tầm quan trọng của việc hiểu người dùng thực hiện công việc hằng ngày như thế nào, thay vì chỉ tập trung vào những chức năng hệ thống cần có.

Một câu hỏi đáng để đặt ra là:

"Người dùng có thể hoàn thành công việc mà không gặp những khó khăn không cần thiết hay không?"

Quan sát hành vi thực tế giúp chúng ta trả lời câu hỏi này đáng tin cậy hơn so với việc chỉ dựa trên giả định.

Kết luận: Hãy quan sát trước khi phỏng đoán

Lập trình viên và người dùng nhìn nhận phần mềm từ những góc độ khác nhau. Điều hiển nhiên với lập trình viên có thể hoàn toàn xa lạ với người chỉ muốn hoàn thành công việc.

Việc quan sát giúp phát hiện những lỗi thường xuyên lặp lại, những thao tác gây khó hiểu và các hành vi không như dự đoán.

Thay vì dành cả ngày thảo luận về cách người dùng có thể hành động, đôi khi chỉ một giờ quan sát họ thực hiện nhiệm vụ thực tế cũng mang lại nhiều thông tin giá trị.

Phần mềm tốt được thiết kế dựa trên cách người dùng thực sự hành động, không phải cách lập trình viên cho rằng họ sẽ hành động.

Về series "97 điều lập trình viên nên biết"

97 điều lập trình viên nên biết là series chia sẻ những bài học thực tiễn về phát triển phần mềm, tư duy giải quyết vấn đề và cách làm việc của lập trình viên.

Bài viết dựa trên nội dung số #03 –「ユーザが何をするかを観察する（あなたはユーザではない）」, do Giles Colborne viết, trong cuốn sách 『プログラマが知るべき97のこと』.

Nội dung được biên soạn lại nhằm làm rõ những bài học có thể áp dụng trong quá trình phát triển phần mềm, đồng thời giữ nguyên thông điệp cốt lõi của tác giả.

Tìm hiểu thêm về VAON và các dịch vụ phát triển phần mềm.