Tất cả câu hỏi

Đáp án đúng: "False". Phát biểu "chỉ cần thiết kế thông tin người dùng nhập rõ ràng" là sai, nên chọn "False" chứ không chọn "True". Đầu vào của hệ thống gồm cả đầu vào tường minh (explicit input) như gõ tên, chọn ngày, và đầu vào ngầm (implicit input) mà hệ thống tự thu được từ hành vi và bối cảnh: vị trí GPS, thời gian trong ngày, lịch sử bấm, hướng xoay điện thoại hay cảm biến bước chân. Người thiết kế UX phải quyết định hệ thống thu những tín hiệu nào, dùng chúng ra sao và báo cho người dùng biết thế nào, vì chúng định hình trải nghiệm không kém gì biểu mẫu. Ví dụ ứng dụng bản đồ tự đổi sang chế độ tối vào ban đêm hay ứng dụng gọi xe tự điền điểm đón theo vị trí hiện tại đều là thiết kế dựa trên đầu vào ngầm, và làm sai sẽ gây khó chịu hoặc lo ngại về quyền riêng tư.

Đáp án đúng: "Current values of all system inputs and variables, and rules for operating on those values". Trong thiết kế tương tác, system state (trạng thái hệ thống) là ảnh chụp toàn bộ tại một thời điểm: giá trị hiện có của mọi đầu vào và biến, cùng các quy tắc xử lý những giá trị đó để quyết định hệ thống phản ứng thế nào; ví dụ một máy điều hòa có nhiệt độ đặt, nhiệt độ phòng, chế độ đang chạy và quy tắc bật tắt máy nén. "Information about the user’s current location" chỉ là một đầu vào riêng lẻ, chỉ là một phần nhỏ của trạng thái chứ không phải toàn bộ. "User profile information" cũng vậy, hồ sơ người dùng chỉ là một nhóm biến trong hệ thống. "Rules for providing feedback to the user" chỉ là một phần quy tắc, thiếu hẳn các giá trị hiện tại của biến nên không mô tả được trạng thái.

Đáp án đúng: "Is the color scheme visually appealing?". Wireframe (khung dây) cố ý bỏ màu sắc, hình ảnh và kiểu chữ hoàn chỉnh, thường chỉ dùng hộp xám và chữ giữ chỗ, để mọi người tập trung vào cấu trúc; vì không có màu nên nó không thể trả lời bảng màu có đẹp hay không, câu hỏi đó thuộc về mockup hay bản thiết kế độ trung thực cao. "Does the overall layout make sense?" đúng là việc của wireframe: nó cho thấy bố cục tổng thể và vị trí các vùng nội dung để kiểm tra có hợp lý không. "Are proper navigation elements provided?" cũng trả lời được, vì wireframe thể hiện menu, nút quay lại, thanh tab và các đường dẫn chính. "Which components should appear on the screen?" là mục đích cơ bản của wireframe: quyết định màn hình gồm những thành phần nào trước khi tô vẽ.

Đáp án đúng: "The standards used to evaluate different design options". Khung Questions, Options, Criteria (câu hỏi, phương án, tiêu chí) giúp ghi lại lý lẽ đằng sau quyết định thiết kế: Questions là các vấn đề thiết kế cần quyết định, Options là các cách giải quyết khả dĩ cho từng vấn đề, còn Criteria là các thước đo dùng để so sánh và chọn giữa các phương án, ví dụ dễ học, thao tác nhanh, chi phí triển khai thấp. "The possible solutions to a design problem" là định nghĩa của Options chứ không phải Criteria. "The questions that need answers" là phần Questions của khung. "The tools used in prototyping" không thuộc khung này; công cụ làm mẫu thử như Figma là chuyện thực hiện thiết kế, không phải tiêu chí để đánh giá phương án.

Đáp án đúng: "It has no single clear solution". Khái niệm wicked problem (bài toán rối) do Rittel và Webber nêu ra chỉ những vấn đề không thể định nghĩa trọn vẹn, có nhiều bên liên quan với mục tiêu xung đột, không có lời giải đúng hay sai tuyệt đối mà chỉ có lời giải tốt hơn hoặc kém hơn, và cách hiểu vấn đề thay đổi ngay khi ta thử giải nó, ví dụ thiết kế ứng dụng giúp người dân giảm dùng xe máy trong thành phố. "It relates to app performance issues" sai vì lỗi hiệu năng thường xác định rõ và đo được, đúng kiểu bài toán thuần (tame problem). "It requires coding expertise" sai vì tính rối nằm ở bản chất vấn đề, không phụ thuộc kỹ năng lập trình của người giải. "It is solved through visual design" sai vì bài toán rối không có lời giải dứt điểm, càng không thể giải chỉ bằng một khía cạnh như hình thức thị giác.

Đáp án đúng: "To identify areas where users encounter difficulties". Kiểm thử người dùng (user testing) là quan sát người thật làm các nhiệm vụ trên sản phẩm, nên khi phân tích dữ liệu, mục tiêu chính là tìm ra chỗ họ vấp: bấm nhầm, lạc đường, mất nhiều thời gian hay bỏ dở nhiệm vụ, rồi xếp mức độ nghiêm trọng để ưu tiên sửa. Ví dụ năm trên tám người không tìm thấy nút đổi mật khẩu là một vấn đề rõ ràng cần xử lý. "To confirm that the design meets business objectives" sai vì mục tiêu kinh doanh được đo bằng chỉ số doanh thu, chuyển đổi, không phải trọng tâm của phân tích kiểm thử khả dụng. "To validate the technical feasibility of the design" sai vì tính khả thi kỹ thuật do đội phát triển đánh giá, người dùng thử không cho biết điều đó. "To assess the aesthetic appeal of the interface" sai vì cảm nhận thẩm mỹ có thể được ghi lại nhưng kiểm thử khả dụng tập trung vào việc dùng được, không phải đẹp hay không.

Đáp án đúng: "Behavioral". Khi tuyển người tham gia nghiên cứu, tiêu chí behavioral (hành vi) lọc theo những gì người đó thực sự đã làm, thường hỏi tần suất hay lượng thời gian trong một khoảng gần đây; câu hỏi số giờ học trên edX trong tuần qua đo đúng một hành vi đã xảy ra. "Expertise" (chuyên môn) lọc theo trình độ hay kinh nghiệm trong một lĩnh vực, như số năm làm lập trình hay mức thành thạo một phần mềm, chứ không hỏi đã làm gì trong tuần. "Characteristic" (đặc điểm) lọc theo thuộc tính nhân khẩu như tuổi, giới tính, nghề nghiệp hay nơi sống. "Attitudinal" (thái độ) lọc theo quan điểm, niềm tin hay cảm nhận, ví dụ hỏi người đó thích hay ngại học trực tuyến. Câu hỏi trong đề không hỏi cảm nghĩ hay đặc điểm cá nhân mà hỏi việc đã làm, nên thuộc nhóm hành vi.

Đáp án đúng: "Prompt the participant with clarifying questions to understand the issue better". Moderator (người điều phối) trong kiểm thử người dùng phải giữ trung lập: mục tiêu là hiểu vì sao giao diện gây bối rối, nên khi người tham gia lúng túng, cách đúng là hỏi mở để làm rõ, chẳng hạn bạn đang mong thấy điều gì ở chỗ này, để họ nói ra mô hình suy nghĩ của mình theo kiểu think-aloud (nói to suy nghĩ). "Ignore the confusion and continue with the tasks" bỏ lỡ đúng dữ liệu quý nhất của buổi thử, vì chỗ bối rối chính là dấu hiệu của vấn đề khả dụng. "Provide the participant with answers to solve the problem" làm sai lệch kết quả: người dùng thật không có ai chỉ bài, và lời gợi ý che mất vấn đề cần phát hiện. "Encourage the participant to skip the task" khiến tác vụ không được quan sát trọn vẹn; chỉ nên cho bỏ qua khi người tham gia quá căng thẳng hoặc hết thời gian, không phải phản ứng đầu tiên trước sự bối rối.

Đáp án đúng: "Reword it to avoid interface-specific terms". Khi viết nhiệm vụ kiểm thử, nếu dùng đúng nhãn đang hiện trên giao diện như Shopping Cart thì người tham gia chỉ cần dò tìm chữ khớp với chữ trong nhiệm vụ, buổi kiểm thử không còn đo được việc họ có hiểu nhãn và cấu trúc của giao diện hay không; cách đúng là diễn đạt theo mục tiêu đời thường của người dùng, ví dụ xem lại những món mình đã chọn mua trước khi thanh toán. "Leave it as is" giữ nguyên chính lỗi vừa nêu, biến nhiệm vụ thành trò dò chữ. "Add more technical jargon" làm nhiệm vụ khó hiểu hơn và còn gợi ý thêm cho người tham gia. "Ask users to guess the meaning" đẩy người tham gia vào chỗ đoán mò; nhiệm vụ phải rõ ràng về mục tiêu dù không được chỉ đường.

Đáp án đúng: "Declining to provide a recommendation, admitting you have no good ideas". Câu hỏi tìm điều KHÔNG nên làm khi đề xuất cách xử lý một vấn đề khả năng sử dụng. Báo cáo nghiên cứu có giá trị khi mỗi vấn đề đi kèm một hướng hành động; ngay cả khi chưa có giải pháp chắc chắn, người nghiên cứu vẫn có thể chỉ ra bước tiếp theo, nên từ chối đề xuất là bỏ dở trách nhiệm. Ba hướng kia đều là cách đề xuất hợp lệ nên không được chọn. "Identifying best practices from competitors’ products" đúng vì xem sản phẩm khác đã giải bài toán tương tự ra sao là nguồn ý tưởng nhanh và có kiểm chứng. "Suggesting further research to better characterize the problem" đúng khi vấn đề chưa rõ nguyên nhân, cần thêm dữ liệu trước khi sửa. "Recommending an iterative design process to find the best solution" đúng khi vấn đề phức tạp, cần thử vài phương án và kiểm thử lại để chọn cái tốt nhất.

Đáp án đúng: "The range of alternative ways that a design solution can work". Design space (không gian thiết kế) là một khái niệm trừu tượng: tập hợp mọi lời giải khả dĩ cho một bài toán, khác nhau ở cách hoạt động, hình thức và tương tác. Người thiết kế được khuyên khám phá rộng không gian này, phác nhiều phương hướng khác nhau trước khi thu hẹp, thay vì bám ngay ý tưởng đầu tiên. Ví dụ chức năng nhắc uống thuốc có thể là thông báo đẩy, hộp thuốc phát sáng hay tin nhắn cho người nhà. "Physical space (like a design studio) where design activities take place" sai vì đó là nơi làm việc, không phải tập các lời giải. "Space into which the design has to fit (e.g., the size of the screen of a mobile phone)" chỉ là một ràng buộc giới hạn không gian thiết kế chứ không phải chính nó. "Properties of the space (e.g., location, shape of the room) where the design will be used" là bối cảnh sử dụng, thông tin quan trọng cho thiết kế nhưng không phải phạm vi các phương hướng giải quyết.

Đáp án đúng: "To write a business plan for selling the technology designers created". Câu hỏi tìm thứ KHÔNG phải kỹ năng thiết kế cốt lõi. Viết kế hoạch kinh doanh để bán sản phẩm là việc của quản lý sản phẩm hay kinh doanh, không thuộc chu trình thiết kế lấy người dùng làm trung tâm, nên đây là đáp án. Các phương án kia đều là kỹ năng cốt lõi nên không được chọn: "To frame or reframe a design problem" là xác định đúng vấn đề, ví dụ chuyển từ "làm nút đẹp hơn" sang "vì sao người dùng bỏ giỏ hàng"; "To generate a large number of alternative solutions" là tư duy phân kỳ, tạo nhiều phương án trước khi chọn; "To evaluate tradeoffs of different alternatives" là cân nhắc được mất giữa các phương án, như đơn giản đổi lấy ít tùy chọn; "To create and test with potential users a functioning prototype" là dựng nguyên mẫu và kiểm thử với người dùng tiềm năng để kiểm chứng giải pháp.

Đáp án đúng: "Benchmark Testing". Benchmark testing (kiểm thử đối sánh chuẩn) đo hệ thống theo các chỉ tiêu hiệu năng định trước như thời gian hoàn thành tác vụ, tỷ lệ lỗi hay tỷ lệ thành công, để xác minh sản phẩm có đạt mục tiêu đề ra hay không, ví dụ người dùng mới phải đặt được vé trong dưới hai phút. "Formative Testing" là kiểm thử hình thành, làm sớm và lặp lại trong quá trình thiết kế để tìm vấn đề và cải tiến, không nhằm xác minh chỉ tiêu. "Problem Identification Testing" tập trung phát hiện và mô tả các vấn đề khả dụng người dùng gặp phải, chứ không so với ngưỡng hiệu năng. "Comparative Testing" đặt hai hay nhiều phương án thiết kế hoặc sản phẩm cạnh nhau để xem cái nào tốt hơn, không phải kiểm một hệ thống có đạt mục tiêu của chính nó hay không.

Đáp án đúng: "You should not know who the test participants are, and they should not know who you are.". Trong user testing (kiểm thử với người dùng), người điều phối biết rõ người tham gia: họ được tuyển theo tiêu chí, ký đồng thuận, được chào đón và hướng dẫn, còn nghiên cứu viên cũng tự giới thiệu mình. Ẩn danh cả hai chiều không phải là yêu cầu; điều cần làm là bảo mật thông tin cá nhân khi lưu và báo cáo dữ liệu, nên phát biểu này là phát biểu sai cần chọn. "You should observe test participants using the system directly." đúng vì giá trị của kiểm thử nằm ở việc nhìn thấy hành vi thật, chỗ ngập ngừng, chỗ bấm nhầm. "You should recruit test participants who are representative of your target users." đúng vì người tham gia phải giống người dùng mục tiêu thì những lỗi tìm được mới có ý nghĩa. "You should give test participants specific tasks to carry out using the system." đúng vì nhiệm vụ cụ thể giúp buổi quan sát có trọng tâm và so sánh được giữa những người tham gia.

Đáp án đúng: "Critical incidents". Formative test (kiểm thử định hình) được làm trong lúc thiết kế với mục đích tìm vấn đề để sửa, nên dữ liệu quý nhất là critical incidents (sự cố then chốt): những thời điểm người dùng bối rối, mắc lỗi, đi sai đường hoặc bỏ cuộc, ví dụ bấm nhầm vào biểu tượng giỏ hàng khi muốn lưu sản phẩm. Mỗi sự cố chỉ ra đúng chỗ thiết kế cần chỉnh. "Perceived usability" như điểm SUS hữu ích cho đánh giá tổng kết hoặc so sánh phiên bản, nhưng một con số cảm nhận không cho biết vấn đề nằm ở màn hình nào. "Suggested improvements" có thể tham khảo, song người tham gia không phải nhà thiết kế và lời gợi ý của họ kém tin cậy hơn hành vi quan sát được. "Participant demographics" dùng để mô tả mẫu và đối chiếu kết quả, bản thân nó không phát hiện vấn đề nào của giao diện.

Đáp án đúng: "Qualitative research focuses on understanding in-depth user behavior and experiences, while quantitative research focuses on numerical data". Nghiên cứu định tính (qualitative) như phỏng vấn sâu hay quan sát tại chỗ trả lời câu hỏi "vì sao" và "như thế nào" qua lời kể và hành vi của ít người, còn nghiên cứu định lượng (quantitative) như khảo sát diện rộng hay số liệu phân tích trả lời "bao nhiêu" bằng con số có thể thống kê. Ví dụ analytics cho biết 40 phần trăm người bỏ giỏ hàng, phỏng vấn mới cho biết họ bỏ vì phí ship hiện quá muộn. "Qualitative research provides statistical data, while quantitative research focuses on user behavior" đảo ngược vai trò của hai loại. "Quantitative research is more subjective than qualitative research" sai vì định lượng dựa trên số đo chuẩn hoá nên ít phụ thuộc diễn giải hơn, chính định tính mới cần người nghiên cứu diễn giải nhiều. "Qualitative research involves automated data analysis" sai vì dữ liệu định tính thường được mã hoá và gom nhóm thủ công, ví dụ bằng affinity wall.

Đáp án đúng: "To summarize the common theme or issue represented by the notes in the cluster". Affinity wall (tường quan hệ) là kỹ thuật dán từng quan sát lên giấy nhớ, gom các tờ có ý giống nhau thành cụm rồi đặt nhãn cho cụm; nhãn phải nói lên chủ đề hay vấn đề chung mà các tờ cùng phản ánh, ví dụ "Người dùng không tìm thấy nút hủy đơn", để từ đó nhìn ra mẫu hình trong dữ liệu. "To create catchy titles for each cluster" sai vì nhãn cần chính xác và mô tả được nội dung, không cần kêu hay hấp dẫn. "To provide a detailed breakdown of each user's feedback" sai vì cụm vốn gộp ý từ nhiều người theo chủ đề, không tách lại theo từng người dùng. "To list all the observations without organizing them" đi ngược mục đích của cả phương pháp, vốn sinh ra để tổ chức và tổng hợp quan sát rời rạc.

Đáp án đúng: "Socio-technical extraction.". Câu phủ định: cần tìm tên không dùng cho phương pháp nghiên cứu định tính đã học, tức đi tới nơi người dùng sống và làm việc, quan sát và phỏng vấn họ trong bối cảnh thật để hiểu nhu cầu. "Socio-technical extraction." không phải tên của phương pháp nào; cụm socio-technical (xã hội và kỹ thuật) chỉ một cách nhìn hệ thống, còn extraction gợi việc khai thác dữ liệu, nên đây là đáp án. "Ethnographic research." là tên đúng: nghiên cứu dân tộc học, người nghiên cứu hoà vào môi trường của người dùng để quan sát hành vi tự nhiên. "Contextual inquiry." cũng đúng: điều tra theo ngữ cảnh, vừa quan sát người dùng làm việc thật vừa hỏi họ theo kiểu thầy và người học việc. "User needs assessment." đúng nốt: đánh giá nhu cầu người dùng là tên gọi tổng quát cho chính quy trình thu thập và phân tích nhu cầu ấy.

Đáp án đúng: "Participants behaving unnaturally due to being observed". In-situ observation (quan sát tại chỗ) là theo dõi người dùng làm việc trong môi trường thật của họ; thách thức nổi bật là hiệu ứng người quan sát, còn gọi là hiệu ứng Hawthorne: người được quan sát biết mình bị nhìn nên làm cẩn thận hơn, theo quy trình chuẩn hơn ngày thường, khiến dữ liệu lệch khỏi thực tế. Nhà nghiên cứu giảm điều này bằng cách quan sát đủ lâu để người dùng quen và giữ thái độ không phán xét. "Difficulty in accessing the user's environment" có xảy ra, như khi xin vào bệnh viện hay nhà máy, nhưng đó là khâu chuẩn bị trước buổi quan sát chứ không phải thách thức đặc trưng khi tiến hành. "Collecting too much quantitative data" sai vì quan sát tại chỗ chủ yếu cho dữ liệu định tính như ghi chú, mô tả hành vi. "Lack of visual data" sai vì đây chính là lúc dễ chụp ảnh môi trường và công cụ thật của người dùng nhất.

Đáp án đúng gồm hai ý: "User interviews" và "Surveys". Thu thập nhu cầu người dùng là tìm hiểu trực tiếp từ chính những người sẽ dùng sản phẩm. Phỏng vấn người dùng cho dữ liệu định tính sâu: ta hỏi về mục tiêu, thói quen, khó khăn và có thể hỏi thêm để hiểu lý do. Khảo sát cho dữ liệu trên nhiều người hơn, giúp ước lượng một nhu cầu phổ biến tới đâu; hai phương pháp thường bổ sung cho nhau, phỏng vấn để phát hiện, khảo sát để kiểm tra độ rộng. "Ignoring negative feedback" sai vì phản hồi tiêu cực thường chỉ thẳng vào chỗ sản phẩm chưa đáp ứng nhu cầu, bỏ qua nó là tự đánh mất thông tin quý nhất. "Copying competitors' features" sai vì phân tích đối thủ có thể gợi ý tưởng, nhưng sao chép tính năng chỉ phản ánh lựa chọn của người khác chứ không cho biết nhu cầu thật của người dùng mình.