INFO3315 HCI: vì sao ý kiến về giao diện chưa là bằng chứng?

Trả lời thẳng: INFO3315 Human-Computer Interaction là môn cử nhân 6 tín chỉ do Khoa Kỹ thuật (Faculty of Engineering) của Đại học Sydney giảng dạy, đóng vai trò môn nhập môn về tương tác người và máy. 50% điểm nằm ở bài thi cuối kỳ có ngưỡng sàn bắt buộc, điều nhiều sinh viên không ngờ tới ở một môn có đồ án. Điều kiện tiên quyết là các môn lập trình và các môn máy tính nâng cao.

Cấu trúc điều kiện tiên quyết ấy cho thấy gần như toàn bộ cách thiết kế môn học. Khoa không dạy bạn lập trình, vì bạn tới đây đã biết rồi. Thứ môn học thêm vào là một kỷ luật để quyết định nên dựng cái gì và để chứng minh quyết định đó có cơ sở, và kỷ luật này lấy từ tâm lý học, cả phần lý thuyết lẫn phần phương pháp nghiên cứu người dùng. Cách này gần với việc Dix và cộng sự (2004) coi con người và máy tính là hai chủ đề nối nhau trước khi bàn tới thiết kế tương tác.

Một bạn nam người Việt học nhánh khoa học máy tính nâng cao tại INFO3315 từng mô tả môn này với mentor MAAS là "môn mềm". Tới tuần thứ năm bạn ấy đã có một bản mẫu giao diện (UI) chạy được, nhưng báo cáo thì không trả lời nổi dù chỉ một câu hỏi về lý do mọi thứ được sắp xếp như vậy. Phần dựng chưa bao giờ là phần khó của môn này, và coi nó là phần khó chính là cách sinh viên kết thúc kỳ với một sản phẩm bóng bẩy cùng một cột điểm ở khoảng giữa.

---

Trả lời thẳng: Môn yêu cầu những kết luận có bằng chứng về trải nghiệm người dùng (UX) của một giao diện, và phần này có trọng lượng ít nhất ngang với bản thân giao diện (UI). Trong tám chuẩn đầu ra công bố, chỉ hai chuẩn nói về việc làm ra sản phẩm: vận dụng các cách tiếp cận thiết kế UX chuẩn mực và dùng công cụ dựng bản mẫu UI độ trung thực thấp.

Sáu chuẩn còn lại nói về việc chọn kỹ thuật để xác định nhóm người dùng và yêu cầu của họ, đánh giá giao diện bằng cả phương pháp rút gọn lẫn phương pháp có người dùng, giải thích cách các yếu tố con người tác động tới thiết kế, nắm các phương pháp thiết kế và đánh giá chính, nắm dải rộng các loại giao diện, và trình bày phần thiết kế cùng phần đánh giá của một bản mẫu. Tỷ lệ ấy mới là điều đáng chú ý, vì dựng sản phẩm chỉ là một hoạt động trong nhiều hoạt động, trong khi đó lại là hoạt động sinh viên dồn sức quá tay.

Bản mẫu độ trung thực thấp, gần với low-fidelity prototype trong khung của Preece và cộng sự (2019), được môn chỉ định có chủ đích chứ không phải một sự nhân nhượng vì thiếu thời gian. Một bản mẫu thô đủ rẻ để vứt đi, và chính điều đó khiến nó dùng được như một công cụ kiểm định ý tưởng. Bản mẫu bóng bẩy thì mời người làm ra nó đi bảo vệ nó, trong khi môn học đang cố rèn cho bạn phản xạ ngược lại.

Hai nhóm từng nộp bài trên cùng một đề. Một nhóm dành 3 tuần dựng một giao diện chạy được rồi đánh giá đúng một lần vào cuối kỳ. Nhóm kia dựng ba bản thô, đem từng bản thử với vài người, rồi nộp bản thứ ba kèm phần thuật lại hai bản đầu đã sai ở đâu. Sản phẩm của nhóm sau trông kém hơn ở mọi ảnh chụp màn hình nhưng được điểm cao hơn hẳn, bởi báo cáo của họ có điều để nói.

---

Trả lời thẳng: Hai loại trả lời hai câu hỏi khác nhau, đúng như Preece và cộng sự (2019) tách bạch trong giáo trình chuẩn của ngành, và lấy loại này đi trả lời câu hỏi của loại kia là cách chắc chắn nhất để mất điểm ở môn này. Phương pháp rút gọn, chẳng hạn chuyên gia soi giao diện theo một bộ nguyên tắc sử dụng như ISO 9241 hay bộ nguyên tắc heuristic mà Nielsen và Molich (1990) đưa ra, hoặc quy trình cognitive walkthrough mà Polson và cộng sự (1992) đề xuất, thì nhanh và rẻ, và nó cho biết giao diện nhiều khả năng vi phạm thông lệ tốt ở chỗ nào, cùng họ với các mô hình phân tích thao tác như GOMS mà Card, Moran và Newell (1983) đề xuất. Phương pháp có người dùng thì đặt người thật trước sản phẩm, thường kèm một bảng hỏi chuẩn hoá như SUS (System Usability Scale) mà Brooke (1996) giới thiệu, và cho biết chuyện gì thực sự xảy ra. Một lượt soi của chuyên gia không thể nói cho bạn rằng người dùng chưa bao giờ nhìn thấy cái nút đó, chỉ người dùng mới nói được. Ngược lại một nghiên cứu người dùng không phải cách hiệu quả để phát hiện thông báo lỗi của bạn vi phạm một nguyên tắc đã được thiết lập vững, việc đó thuộc về lượt soi.

Truyền thống đánh giá rút gọn ra đời như một thoả hiệp kỹ thuật có tuyên bố rõ ràng. Nielsen (1994) trình bày lập trường này thẳng thắn tại hội nghị CHI của Association for Computing Machinery, với lập luận rằng một phương pháp rẻ mà tìm ra phần lớn vấn đề nghiêm trọng vẫn hơn một phương pháp chặt chẽ nhưng đắt tới mức không bao giờ được chạy. Cách đặt vấn đề đó quan trọng với báo cáo của bạn. Phương pháp rút gọn đứng vững được chính nhờ chỗ nó chấp nhận đánh đổi, nên một báo cáo trình bày kết quả soi như thể đó là hành vi quan sát được của người dùng đã mô tả sai chính bằng chứng của mình.

Báo cáo của một nhóm từng khẳng định phần điều hướng gây rối cho người dùng lần đầu, dựa trên đúng kiểu soi theo nguyên tắc mà Nielsen (1994) mô tả. Khẳng định đó tình cờ đúng, nhưng nó được rút hoàn toàn từ một lượt soi do chính nhóm tự chạy, và không có người dùng lần đầu nào tham gia ở bất kỳ khâu nào. Gắn lại nhãn cho phát hiện ấy thành một vấn đề dự báo, kèm hai câu về cách nhóm sẽ kiểm chứng nó, không tốn gì cả và biến một lời nói quá thành một khẳng định đúng tầm.

---

Trả lời thẳng: Hãy dựa nhóm người dùng vào một thứ nằm ngoài đầu bạn, gần với kỹ thuật dựng persona mà Cooper (1999) khởi xướng và Dix và cộng sự (2004) mô tả lại trong giáo trình chuẩn. Một nhóm được định nghĩa là "sinh viên đại học từ 18 tới 25 tuổi và bận rộn" thì chưa phải một phát hiện, vì đó chỉ là bản mô tả những người tình cờ đang ngồi trong nhóm đồ án.

Một nhóm người dùng bảo vệ được thì đi kèm các đặc điểm có ảnh hưởng tới giao diện, một lý do để tin các đặc điểm ấy đúng, và phần trình bày hệ quả kéo theo cho thiết kế. Nếu chẳng có gì trong thiết kế của bạn thay đổi khi bạn định nghĩa nhóm khác đi, thì định nghĩa ấy không có tác dụng gì cả.

Môn xếp việc nhận diện nhóm người dùng và yêu cầu sử dụng làm chuẩn đầu ra thứ nhất, đứng trước cả thiết kế lẫn đánh giá. Thứ tự đó đúng với nguyên tắc lấy con người làm trung tâm mà Norman (2013) lập luận trong The Design of Everyday Things, và cũng phản ánh trật tự trong thực hành. Trong cùng cuốn sách, Norman định nghĩa chính xác khái niệm affordance, tức đặc tính của một vật gợi ra cách dùng nó: "An affordance is a relationship between the properties of an object and the capabilities of the agent that determine just how the object could possibly be used" (Norman, 2013, p. 10). Một yêu cầu không truy ngược được về một nhóm dân số đã mô tả thì không bác bỏ được. Yêu cầu không bác bỏ được thì không có gì để đối chiếu khi đánh giá, và điều đó âm thầm phá vỡ mọi khâu phía sau của báo cáo.

Một nhóm từng định nghĩa người dùng của mình là những người ít tự tin về công nghệ, rồi thiết kế giao diện lấy một thao tác vuốt ẩn làm cách điều hướng chính. Không ai trong nhóm nhận ra mâu thuẫn cho tới khi một mentor đọc hai mục ấy cạnh nhau. Cách sửa không phải làm thêm việc, mà là hiểu rằng định nghĩa nhóm người dùng là một ràng buộc bạn tự đặt lên mình chứ không phải một đoạn văn để ở đầu bài.

---

Trả lời thẳng: Đồ án hay hỏng vì chia việc theo mục UX, UI, QA thay vì chia theo câu hỏi. Khi một người ôm phần nghiên cứu người dùng (UX), một người ôm bản mẫu (UI) và người thứ ba ôm phần đánh giá (QA), ba phần thôi tham chiếu lẫn nhau, và báo cáo giống ba tài liệu bị dập ghim vào nhau.

Phần đánh giá rốt cuộc đi kiểm những thứ mà phần yêu cầu chưa bao giờ hỏi tới, còn bản mẫu thì hiện thân cho những quyết định mà phần nghiên cứu chưa bao giờ đỡ. Tiêu chí chấm vốn tưởng thưởng kết luận có bằng chứng sẽ trừng phạt kiểu làm này rất nặng, bởi thứ bị đứt chính là chuỗi nối từ nhóm người dùng sang yêu cầu, sang thiết kế, rồi sang bằng chứng.

Đồ án được mô tả là lấy con người làm trung tâm, đúng khái niệm human-centred design mà Norman (2013) và Preece cùng cộng sự (2019) đều đặt ở trung tâm giáo trình. Đó cũng là nguyên tắc cốt lõi của chuẩn quốc tế ISO 9241, phần 210, ban hành năm 2019, và nó là một khẳng định về quy trình chứ không phải về chủ đề. Cách làm này gần với mô hình double diamond mà Design Council của Anh công bố (Design Council, 2005). Một quy trình lấy con người làm trung tâm thì tự thân đã lặp, vì thứ bạn học được khi đánh giá bản này sẽ làm đổi bản sau. Cách chia việc giao phần đánh giá cho một người vào lúc cuối là đã bỏ mất vòng lặp trong khi vẫn giữ cái tên.

Ở một nhóm làm INFO3315, mục QA từng báo cáo một vấn đề sử dụng nằm trong tính năng UI đã bị cắt khỏi bản mẫu từ 2 tuần trước. Không ai nói dối và không ai lười. Các mục chỉ đơn giản được viết song song bởi những người đã thôi trao đổi với nhau, nên bản báo cáo ghi lại một phiên bản hệ thống không còn tồn tại.

---

Trả lời thẳng: Hãy nêu phương pháp, người tham gia và điều quan sát được trước, rồi mới tới điều bạn kết luận, gần với khuôn báo cáo khoa học IMRaD (Introduction, Methods, Results and Discussion), và giữ cho kết luận hẹp hơn phần quan sát. Phần lớn bài viết yếu đảo ngược thứ tự này, mở bằng một khẳng định dứt khoát rồi nhắc tới phương pháp phía sau như phần nền.

Chính sự đảo ngược ấy nghe như một ý kiến đang đi tìm chỗ dựa. Giữ đúng thứ tự bốn thành phần còn làm cho phần nói quá của chính bạn hiện ra trước mắt khi bạn vẫn còn kịp sửa.

Trình bày một thiết kế kèm kết luận có bằng chứng về điểm mạnh điểm yếu là một chuẩn đầu ra được gọi tên của môn, khớp với chu trình thiết lập yêu cầu, thiết kế phương án, dựng bản mẫu rồi đánh giá mà Preece và cộng sự (2019) trình bày. Cụm từ ấy mang hai yêu cầu chứ không phải một: kết luận phải tồn tại, và chúng phải gắn với bằng chứng. Một báo cáo đầy quan sát mà không có kết luận thì trượt yêu cầu thứ nhất, còn một báo cáo đầy kết luận mà không có quan sát thì trượt yêu cầu thứ hai. Trường hợp thứ hai phổ biến hơn nhiều ở một lứa sinh viên được rèn cho ăn nói dứt khoát.

Một bạn từng viết rằng biểu mẫu sau khi thiết kế lại đã cải thiện tỷ lệ hoàn thành một cách có ý nghĩa thống kê. Khi được hỏi cụm đó nghĩa là gì ở đây, bạn ấy giải thích rằng bốn trên năm người thử làm xong nhanh hơn. Đó là một kết quả thật và đáng báo cáo, nhưng nó không phải ý nghĩa thống kê theo bất kỳ nghĩa kỹ thuật nào, và dùng cụm từ ấy đã mời tới một chất vấn mà dữ liệu của bạn ấy không đỡ nổi. Viết đúng điều đã xảy ra, bằng lời thường, vừa trung thực hơn vừa được đón nhận tốt hơn.

---

Trả lời thẳng: Hãy coi phần này là một bài phân tích chứ không phải một bài điểm danh. Môn có nói tới các dạng giao diện mới hơn, gồm giao diện xã hội, giao diện người dùng tự nhiên (NUI), giao diện nhận biết cảm xúc và tính toán khắp nơi theo khái niệm ubiquitous computing mà Weiser (1991) đặt ra, và cám dỗ là mô tả lần lượt từng loại.

Thứ kiếm được điểm là đem đúng bộ công cụ phân tích bạn đã dùng cho đồ án của mình áp lên chúng: nhóm người dùng là ai, những yếu tố con người nào đang được huy động, bạn sẽ đánh giá nó ra sao, và nó hỏng ở đâu. Một đoạn nói giao diện nhận biết cảm xúc là gì thì chưa chứa lập luận nào, còn một đoạn nói điều gì ở nó sẽ khó đánh giá thì có.

Chuẩn đầu ra liên quan của INFO3315 yêu cầu sinh viên phân tích các dạng giao diện mới nổi, và phân tích trong ngữ cảnh này nghĩa là chỉ ra các mâu thuẫn trong thiết kế chứ không phải liệt kê tính năng. Các mô hình tương tác mới hơn thường làm nảy sinh đúng những khó khăn mà các phần trước của môn đã rèn cho bạn nhận ra, nhất là quanh chuyện xin phép người dùng, khôi phục sau lỗi, mức độ hiển thị trạng thái hệ thống, và khả năng tiếp cận theo tinh thần WCAG (Web Content Accessibility Guidelines) phiên bản 2.1 (World Wide Web Consortium, 2018).

Khi được yêu cầu bàn về tính toán khắp nơi, một bạn từng viết bốn đoạn mô tả và chỉ một câu đánh giá. Đảo ngược tỷ lệ ấy không cần đọc thêm tài liệu nào, vì câu hỏi duy nhất mở được nút thắt là làm sao người dùng biết được một tương tác đã thất bại khi giao diện không hề có màn hình.

---

Trả lời thẳng: Ở học kỳ 2 năm 2026, đồ án nhóm chiếm tổng cộng 40%, chia thành báo cáo yêu cầu 10%, buổi trình diễn bản mẫu kèm áp phích 15% và báo cáo cuối 15%. Bài kiểm tra ngắn trên lớp chiếm 5%, bài kiểm tra ngoài lớp chiếm thêm 5%, còn bài thi cuối kỳ chiếm 50%.

Muốn qua môn, bạn phải đạt tối thiểu 40% ở bài thi ấy và đạt tổng từ 50 trở lên. Ngoài ra còn một ngưỡng sàn không mang điểm nào, đó là sổ nhật ký nhóm ghi biên bản họp hằng tuần: nó tính 0% nhưng vẫn bắt buộc phải làm. Hãy xác nhận cấu trúc trong đề cương của lớp mình, nhưng nên lên kế hoạch trên giả định rằng phần đồ án không cõng nổi bạn.

Một ngưỡng sàn ở INFO3315 làm đổi phép tính theo cách mà riêng trọng số không làm được. Một sinh viên điểm tốt ở mọi phần đồ án nhưng chỉ đạt 35% bài thi thì không qua môn, bất kể tổng điểm là bao nhiêu. Điều đó biến việc ôn thi thành một điều kiện tiên quyết chứ không phải một đầu vào ngang hàng với các đầu vào khác, và nó khá chỏi với cách phần đồ án hút hết sự chú ý vào những tuần cuối học kỳ.

Một nhóm có phần đồ án thật sự tốt từng dành 2 tuần cuối để mài giũa báo cáo cuối, với lý lẽ rằng đó là phần họ còn kịp cải thiện. Phần đó đáng 15%. Bài thi mà họ không ôn thì đáng 50% và có ngưỡng sàn, và một thành viên của nhóm ấy phải học lại môn.

---