INFO3315 Human-Computer Interaction ở Đại học Sydney (University of Sydney) nằm trong một khoa mà tính đúng thường rạch ròi. Mã hoặc biên dịch được hoặc không, một kiểm thử hoặc qua hoặc trượt. Rồi tới một môn mà câu hỏi trung tâm là giao diện này có chạy được với con người hay không, và những thói quen đã cõng một sinh viên khoa học máy tính qua trọn 2 năm môn lập trình bỗng lặng lẽ hết tác dụng. Điều người chấm hay viết nhất lên báo cáo UX của INFO3315 không phải là thiết kế dở. Điều họ viết là lời khẳng định về thiết kế ấy chẳng có gì làm căn cứ ngoài phản ứng của chính người viết khi nhìn nó.
Tác giả: Ban biên tập MAAS · Hiệu đính bởi mentor chuyên môn của MAAS
Cập nhật: 20/08/2026
Chuyên mục: it-data
INFO3315 là môn gì và nằm ở đâu?
Trả lời trực tiếp: 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, môn nhập môn tương tác người và máy. 50% điểm nằm ở bài thi cuối kỳ kèm ngưỡng sàn bắt buộc, điều nhiều sinh viên không ngờ ở môn có đồ án. Môn đòi các môn lập trình bậc thấp và bậc cao thuộc Bảng A ngành máy tính nâng cao làm điều kiện tiên quyết.
Bằng chứng: Chính cấu trúc điều kiện tiên quyết ấy đã là bản thu nhỏ của toàn bộ 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ứ đượ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ở, mà kỷ luật này rút từ tâm lý học cả về lý thuyết lẫn về phương pháp nghiên cứu người dùng, đúng phạm vi mà Dix và cộng sự (2004) đóng khung cho cả ngành tương tác người và máy.
Ví dụ: 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 mô tả môn này với mentor MAAS là "môn mềm". Tới tuần thứ năm bạn có một bản mẫu UI chạy được cùng một báo cáo không đỡ nổi lấy một câu hỏi về việc vì sao mọi thứ lại được sắp đặt như thế. Phần dựng chưa bao giờ là phần khó của môn này, mà 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 và một cột điểm ở khoảng giữa.
Môn thực chất yêu cầu bạn tạo ra cái gì?
Trả lời trực tiếp: Những kết luận dựa trên bằng chứng về UX (trải nghiệm người dùng) của một giao diện, ít nhất là ngang với bản thân giao diện, tức phần UI (giao diện người dùng). Trong tám chuẩn đầu ra công bố, hai chuẩn nói về việc làm ra sản phẩm, đó là 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ề chọn kỹ thuật để xác định nhóm người dùng cùng 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ác phương pháp thiết kế và đánh giá chính, nắm được 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, và nó là hoạt động sinh viên dồn sức quá tay.
| Sinh viên dồn sức vào | Chuẩn đầu ra thật sự tưởng thưởng | Hậu quả lúc chấm |
|---|---|---|
| Bản mẫu chạy được, bóng bẩy | Bản mẫu thô nhưng trả lời được một câu hỏi | Công sức đổ vào chỗ không có điểm |
| Thiết kế mà chính mình thấy dễ dùng | Thiết kế truy được về một nhóm người dùng đã xác định | Câu "cái này làm cho ai" bỏ trống |
| Danh sách tính năng thật dài | Yêu cầu sử dụng có nguồn gốc | Yêu cầu từ đâu rơi xuống |
| Một khuyến nghị dứt khoát | Một kết luận có bằng chứng đi kèm | Khẳng định bị đọc thành ý kiến cá nhân |
Bằng chứng: 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 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, mà chính điều đó làm nó dùng được như một công cụ kiểm định ý tưởng. Một bản mẫu bóng bẩy thì mời gọi người làm ra nó đi bảo vệ nó, còn môn học đang cố rèn cho bạn phản xạ ngược lại.
Ví dụ: Hai nhóm 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. 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 tệ hơn ở mọi ảnh chụp màn hình và được điểm cao hơn hẳn, bởi báo cáo của họ có điều để nói.
Đánh giá rút gọn khác đánh giá có người dùng ở chỗ nào?
Trả lời trực tiếp: Chúng 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ộ mười nguyên tắc 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.
Bằng chứng: 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, công bố tại hội nghị CHI của Association for Computing Machinery, dựa trên lập luận rằng một phương pháp rẻ 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 (Nielsen, 1994). Cách đặt vấn đề đó quan trọng với báo cáo của bạn, vì phương pháp rút gọn đứng vững được chính nhờ chỗ nó chấp nhận đánh đổi, cò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 là đã mô tả sai chính bằng chứng của mình.
Ví dụ: Báo cáo của một nhóm 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. Nó cũng được rút hoàn toàn từ một lượt soi theo nguyên tắc do chính nhóm tự chạy, 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.
Xác định nhóm người dùng thế nào để không phải là tự nghĩ ra?
Trả lời trực tiếp: Hãy dựa nó 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 người dùng được định nghĩa là "sinh viên đại học từ 18 tới 25 tuổi và bận rộn" thì không phải một phát hiện, nó 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 những đặ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ả.
Bằng chứng: Môn xếp việc nhận diện nhóm người dùng và yêu cầu sử dụng thành chuẩn đầu ra thứ nhất, đứng trước cả thiết kế lẫn đánh giá, đúng 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à trật tự đó phản ánh trật tự trong thực hành. Norman đưa nguyên tắc ấy về một định nghĩa cụ thể cho khái niệm affordance, nền tảng của cách tiếp cận lấy con người làm trung tâm: "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, mà một yêu cầu không bác bỏ được thì không đánh giá đối chiếu vào đâu, và điều đó âm thầm phá vỡ mọi khâu phía sau của báo cáo.
Ví dụ: Một nhóm đị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à nhận ra 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.
Đồ án nhóm ở môn này hay hỏng vì đâu?
Trả lời trực tiếp: 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), thì 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 dựa trên 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ế sang bằng chứng.
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, và 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, mà đó là một khẳng định về quy trình chứ không phải về chủ đề. Đâ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. Một 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.
Ví dụ: Ở một nhóm làm INFO3315, mục QA 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, và 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.
Viết phần kết quả thế nào để nó đọc lên như bằng chứng?
Trả lời trực tiếp: Nêu phương pháp, người tham gia, điều quan sát đượ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, viết tắt của 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 bạn khi vẫn còn kịp sửa.
Bằng chứng: Trình bày một thiết kế kèm kết luận dựa trên 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, đúng khuôn báo cáo mà Preece và cộng sự (2019) trình bày cho ngành, và 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, 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, và 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.
Ví dụ: Một bạn 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 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 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.
Sinh viên Việt Nam nên xử lý phần công nghệ mới nổi thế nào?
Trả lời trực tiếp: Hãy coi nó 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 tự nhiên như AR, như VR, 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, tức là nhóm người dùng là ai, những yếu tố con người nào đang bị 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ì không chứa lập luận nào. Một đoạn nói cái gì ở nó sẽ khó đánh giá thì có.
Bằng chứng: Chuẩn đầu ra của INFO3315 liên quan yêu cầu sinh viên phân tích các dạng giao diện mới nổi như AR, VR, mà phân tích trong ngữ cảnh này nghĩa là định vị 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).
Ví dụ: Khi được yêu cầu bàn về tính toán khắp nơi, một bạn viết bốn đoạn mô tả và 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. 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.
Bài thi nằm ở đâu, và vì sao nó làm đổi cách bạn lên kế hoạch?
Trả lời trực tiếp: Ở 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% và bài kiểm tra ngoài lớp chiếm thêm 5%. 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, đạt tổng từ 50 trở lên, và vượt thêm một ngưỡng sàn không mang điểm nào cả, đó là sổ nhật ký nhóm ghi biên bản họp hằng tuần, tuy 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 hãy lên kế hoạch trên giả định rằng phần đồ án không cõng nổi bạn.
Bằng chứng: 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ó nằm 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ỳ.
Ví dụ: Một nhóm có phần đồ án thật sự tốt đã 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.
Câu hỏi thường gặp
Không có nền thiết kế thì học INFO3315 được không?
Được. Điều kiện tiên quyết của University of Sydney, cấp độ 7 trong Australian Qualifications Framework, là các môn lập trình và môn ngành máy tính nâng cao chứ không phải môn thiết kế, và môn dạy phương pháp thiết kế UX từ đầu. Thứ làm đa số sinh viên bất ngờ không phải phần thiết kế mà là bước chuyển từ tính đúng chứng minh được sang bằng chứng và phán đoán.
Bản mẫu có cần chạy được không?
Môn chỉ định bản mẫu độ trung thực thấp, gần với khái niệm MVP hơn là một sản phẩm hoàn chỉnh, và một bản mẫu thô kiểm được một câu hỏi thì đáng giá hơn một bản bóng bẩy chẳng kiểm gì. Hãy đọc đề bài của chính lớp mình để biết yêu cầu, nhưng đừng mặc định rằng dựng càng nhiều thì điểm càng cao.
Nghiên cứu người dùng ở cấp này cần bao nhiêu người tham gia?
Ít hơn sinh viên vẫn tưởng, và thứ quan trọng hơn nhiều là bạn tường thuật trung thực điều mình đã làm. Nielsen (2000) lập luận rằng khoảng 5 người dùng đã phát hiện được phần lớn vấn đề sử dụng nghiêm trọng trong một lượt kiểm thử. Một nghiên cứu 5 người được mô tả chính xác thì mạnh hơn một nghiên cứu 20 người được mô tả mơ hồ.
Mình tự đánh giá giao diện của mình được không?
Bạn soi được nó theo bộ nguyên tắc sử dụng như ISO 9241 hay bộ mười nguyên tắc của Nielsen và Molich (1990), và đó là một phương pháp rút gọn chính đáng, nhưng bạn không được lấy nó thay cho đánh giá có người dùng và tuyệt đối không được mô tả kết quả tự soi như hành vi của người dùng. Chính sự phân biệt giữa hai thứ đó cũng nằm trong phần bị hỏi.
MAAS có hỗ trợ INFO3315 không?
Có. Dịch vụ hỗ trợ học thuật của MAAS đồng hành cùng bạn theo mô hình Outline → Draft → Final, gồm xác định nhóm người dùng, chọn phương pháp đánh giá UX khớp với câu hỏi của bạn, và phản hồi phần viết cùng mentor có nền tảng HCI. Chúng tôi hướng dẫn bài của bạn, không viết hộ bạn.
Sẵn sàng làm cho các khẳng định trong bài INFO3315 đứng vững?
Nếu bản mẫu của bạn tốt mà báo cáo vẫn bị phê là thiếu cơ sở, thì khoảng cách nằm giữa điều bạn biết và điều bạn đã trưng ra, mà khoảng cách đó thì khép lại được. Hỗ trợ học thuật của MAAS làm việc bên cạnh bạn theo trình tự Outline → Draft → Final để phần thiết kế vẫn là của bạn còn bằng chứng phía sau nó thì hiện ra rõ ràng. Mỗi lượt đồng hành đều đi kèm mục tiêu điểm ba mức (Pass / Merit / Distinction) và 90 ngày hỗ trợ sau khi nộp bài.
Bạn gửi đề đồ án UX của INFO3315 và bên mình ghép bạn với mentor mảng thiết kế tương tác, 23% trong hơn 100 chuyên gia của MAAS có bằng Tiến sĩ, trong vòng 48 giờ.
Đặt lịch tư vấn miễn phí 20 phút về INFO3315 cùng MAAS →
Bài liên quan
- Hướng dẫn bài INFO5995 Introduction to Cybersecurity: một môn máy tính khác ở Sydney nơi lập luận quan trọng ngang kỹ thuật
- Hướng dẫn bài 7COM1025 Programming for Software Engineers: môn máy tính chấm bằng phán đoán kỹ thuật chứ không chỉ bằng mã chạy được
- Hướng dẫn bài ISYS90026 Concepts of Information Systems: tư duy hệ thống ở chỗ con người gặp công nghệ
- Dịch vụ Đồng hành học thuật MAAS: kèm 1:1 cùng mentor trình độ Tiến sĩ đúng chuyên ngành
- Đồng hành bài tập theo mã môn: bài trụ về cách xử lý bài tập của bất kỳ môn nào cùng mentor MAAS
References
- Brooke, J. (1996). SUS: A "quick and dirty" usability scale. In P. W. Jordan, B. Thomas, B. A. Weerdmeester, & A. L. McClelland (Eds.), Usability evaluation in industry (pp. 189–194). Taylor & Francis.
- Card, S. K., Moran, T. P., & Newell, A. (1983). The psychology of human-computer interaction. Lawrence Erlbaum Associates.
- Cooper, A. (1999). The inmates are running the asylum: Why high-tech products drive us crazy and how to restore the sanity. Sams Publishing.
- Design Council. (2005). The double diamond: A universally accepted depiction of the design process. https://www.designcouncil.org.uk/our-resources/the-double-diamond/
- Dix, A., Finlay, J., Abowd, G. D., & Beale, R. (2004). Human-computer interaction (3rd ed.). Pearson Prentice Hall.
- Nielsen, J. (1994). Usability inspection methods. In Conference companion on human factors in computing systems (pp. 413–414). Association for Computing Machinery. https://doi.org/10.1145/259963.260531
- Nielsen, J. (2000). Why you only need to test with 5 users. Nielsen Norman Group. https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
- Nielsen, J., & Molich, R. (1990). Heuristic evaluation of user interfaces. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (pp. 249–256). Association for Computing Machinery. https://doi.org/10.1145/97243.97281
- Norman, D. A. (2013). The design of everyday things (Rev. ed.). Basic Books.
- Polson, P. G., Lewis, C., Rieman, J., & Wharton, C. (1992). Cognitive walkthroughs: A method for theory-based evaluation of user interfaces. International Journal of Man-Machine Studies, 36(5), 741–773.
- Preece, J., Sharp, H., & Rogers, Y. (2019). Interaction design: Beyond human-computer interaction (5th ed.). Wiley.
- Weiser, M. (1991). The computer for the 21st century. Scientific American, 265(3), 94–104.
- World Wide Web Consortium. (2018). Web Content Accessibility Guidelines (WCAG) 2.1. https://www.w3.org/TR/WCAG21/
Tools & resources
- The University of Sydney. (n.d.). INFO3315 Human-Computer Interaction. Truy cập ngày 20 tháng 8, 2026, từ https://www.sydney.edu.au/units/INFO3315
- The University of Sydney Library. (n.d.). Referencing and citation styles. Truy cập ngày 20 tháng 8, 2026, từ https://www.library.sydney.edu.au/support/referencing
Bài viết thuộc chuyên mục MAAS Journal dành cho du học sinh Việt Nam. hỗ trợ học thuật của MAAS là đối tác cố vấn, đồng hành cùng sinh viên theo mô hình Outline → Draft → Final với phản hồi phát triển từ mentor trình độ Tiến sĩ. Chúng tôi không viết hộ hay nộp bài thay sinh viên.