Bỏ qua

P4.1 — Mental model, affordance và nguyên lý usability

Module: P4 - UX và Product Design

Mục tiêu đọc

Sau chương này, người đọc có thể:

  • Phân tích giao diện bằng usability (khả năng sử dụng), không bằng sở thích cá nhân.
  • Chẩn đoán khoảng cách giữa mental model (mô hình nhận thức) của người dùng và conceptual model (mô hình khái niệm) của đội sản phẩm.
  • Dùng affordance (khả năng hành động), signifier (dấu hiệu chỉ dẫn), mapping (ánh xạ), feedback (phản hồi) và constraint (ràng buộc) để sửa luồng tương tác.
  • Phân biệt lỗi thực thi với lỗi lập kế hoạch; thiết kế khả năng phòng ngừa và phục hồi.
  • Áp dụng các quy luật tâm lý như quy tắc định hướng, không như luật tuyệt đối.
  • Thiết lập quyền quyết định, bằng chứng và ngưỡng chất lượng cho usability (khả năng sử dụng) và accessibility (khả năng tiếp cận).

Nguồn tổng hợp: The Design of Everyday Things, Don't Make Me Think, Laws of UX

Giới hạn của chương: Đọc chương này giúp người đọc nhận diện đúng khái niệm và áp dụng quy tắc chẩn đoán. Nó không thay thế kinh nghiệm chạy usability testing (kiểm thử khả năng sử dụng) thật, quan sát người dùng thật, hoặc chịu trách nhiệm về một quyết định thiết kế có hậu quả kinh doanh. Năng lực senior trong lĩnh vực này đến từ việc lặp lại chẩn đoán trên sản phẩm thật, chịu áp lực deadline và bảo vệ quyết định trước stakeholder — không đến từ việc đọc.

Mental model — người dùng không tương tác với ý định của đội

Intuition

Hãy tưởng tượng một người vừa mở một ứng dụng lần đầu. Họ không đọc tài liệu thiết kế, không biết đội kỹ thuật đã tranh luận gì về kiến trúc, không biết PM đã đánh đổi điều gì để kịp deadline. Họ chỉ nhìn thấy những gì hiện trên màn hình, và từ đó họ tự suy luận ra "sản phẩm này hoạt động như thế nào". Nếu suy luận đó sai, hậu quả xảy ra ngay — không phải vì người dùng kém, mà vì cái họ nhìn thấy không truyền tải đúng cái đội định làm.

Định nghĩa chính xác

Ba thành phần tạo thành chuỗi giao tiếp thiết kế:

  1. Designer's model (mô hình của nhà thiết kế): cách đội tin hệ thống hoạt động.
  2. System image (hình ảnh hệ thống): mọi thứ người dùng cảm nhận được, gồm cấu trúc, nhãn, giao diện, âm thanh, hướng dẫn, tài liệu và thông điệp truyền thông.
  3. User's model (mô hình của người dùng), còn gọi là mental model (mô hình nhận thức): cách người dùng tin hệ thống hoạt động.

P4.1 - Mental model, affordance và nguyên lý usability — diagram 1

Source mermaid — có thể chỉnh sửa 
flowchart TB
    D["Designer's model<br/>(Mô hình của nhà thiết kế)"]
    S["System image<br/>(Hình ảnh hệ thống)"]
    U["User's model<br/>(Mô hình của người dùng)"]

    D --> S
    S --> U

Vì sao mô hình này tồn tại

Mô hình này tồn tại để chỉ ra một sự thật thường bị bỏ qua: đội sản phẩm không giao tiếp trực tiếp với người dùng qua ý định, mà chỉ giao tiếp qua system image (hình ảnh hệ thống). Nếu nhãn, luồng, trạng thái và thông điệp không nhất quán, người dùng hình thành mental model (mô hình nhận thức) sai dù tài liệu nội bộ hoàn hảo. Không có cách nào "giải thích thêm bằng lời" để bù cho một system image mâu thuẫn — người dùng không đọc tài liệu nội bộ.

Ví dụ minh hoạ tối thiểu

Một nút có nhãn "Xóa" nhưng hành vi thực tế là "chuyển vào thùng rác, có thể khôi phục trong 30 ngày". Nếu system image chỉ hiển thị nhãn "Xóa" mà không có dấu hiệu nào về khả năng khôi phục, người dùng sẽ hình thành mental model rằng dữ liệu mất vĩnh viễn. Họ có thể hoảng sợ, liên hệ hỗ trợ, hoặc tránh dùng tính năng — dù hệ thống thực ra an toàn hơn họ nghĩ.

Ứng dụng thực tế

Một mental model (mô hình nhận thức) sai vẫn có thể giúp người dùng hoàn thành tác vụ. Người dùng có thể đi vòng, đoán, dùng nút quay lại hoặc vô tình chọn đúng. Vì vậy, task completion (hoàn thành tác vụ) không tự chứng minh thiết kế tốt — một tỷ lệ hoàn thành cao có thể đang che giấu một mô hình nhận thức sai mà người dùng may mắn vượt qua được.

Hai đặc tính đầu tiên của thiết kế tốt

  • Discoverability (khả năng khám phá): người dùng nhận ra hành động nào khả thi và bắt đầu ở đâu.
  • Understanding (sự thấu hiểu): người dùng hiểu sản phẩm làm gì, trạng thái hiện tại nghĩa gì và hành động sẽ tạo kết quả nào.

Một màn hình có thể đẹp nhưng thiếu discoverability (khả năng khám phá). Một luồng có thể hoàn thành được nhưng thiếu understanding (sự thấu hiểu). Cả hai đều là lỗi thiết kế.

Failure mode — người dùng thật không hành xử như người dùng lý tưởng

Trên giao diện số, người dùng thường:

  • Scan (quét nhanh) thay vì đọc toàn bộ.
  • Satisfice (chọn phương án đầu tiên đủ tốt) thay vì so sánh mọi phương án.
  • Muddle through (tự mò để hoàn thành việc) thay vì học hệ thống.

Đây không phải thiếu thông minh. Đây là chiến lược hợp lý khi người dùng bận, mức quan tâm thấp hoặc chi phí thử sai nhỏ.

Quy tắc thiết kế: Không cố sửa các hành vi này bằng thêm hướng dẫn. Thiết kế cho việc quét nhanh, lựa chọn đủ rõ và đường phục hồi an toàn.

Core — mô hình tương tác nền tảng

Affordance và signifier không phải một thứ

Affordance

Intuition: Một cái ghế "mời" người ta ngồi lên, không phải vì nó có chữ "Ngồi" mà vì hình dạng của nó phù hợp với cơ thể người. Đó là bản chất của affordance — nó nằm trong quan hệ giữa vật và người, không nằm trong nhãn dán trên vật.

Định nghĩa: Affordance (khả năng hành động) là quan hệ giữa thuộc tính của đối tượng và khả năng của tác nhân.

Ghế tạo affordance (khả năng hành động) ngồi đối với người có thể ngồi. Trường nhập văn bản tạo affordance (khả năng hành động) nhập liệu đối với người có thiết bị và cách tương tác phù hợp.

Vì sao khái niệm này quan trọng: Nó buộc người thiết kế phân biệt giữa "hành động về mặt kỹ thuật có thể thực hiện" và "hành động người dùng nhận ra được". Một sản phẩm có thể hỗ trợ đầy đủ affordance nhưng vẫn thất bại vì không ai nhận ra.

Affordance (khả năng hành động) không đồng nghĩa với usability (khả năng sử dụng). Một hành động có thể thực hiện được nhưng khó khám phá, khó hiểu hoặc dễ gây lỗi.

Anti-affordance (khả năng ngăn hành động) chặn một hành động, như tấm kính ngăn người đi xuyên qua hoặc quyền truy cập ngăn người không đủ thẩm quyền mở dữ liệu.

Signifier

Định nghĩa: Signifier (dấu hiệu chỉ dẫn) truyền đạt nơi và cách thực hiện hành động.

Ví dụ trong đời thường và trong sản phẩm số:

  • Nhãn "Đẩy" trên cửa.
  • Tay nắm cho biết vị trí tương tác.
  • Chữ gạch chân cho biết liên kết.
  • Nhãn trường biểu mẫu cho biết dữ liệu cần nhập.
  • Âm báo phù hợp cho biết trạng thái đã thay đổi.

Ứng dụng thực tế: Đối với người làm sản phẩm, signifier (dấu hiệu chỉ dẫn) thường quan trọng hơn affordance (khả năng hành động). Hệ thống có thể hỗ trợ hành động, nhưng người dùng không thể dùng thứ họ không nhận ra.

Tín hiệu cảnh báo: Sản phẩm cần giấy ghi chú, hướng dẫn viết tay, tooltip dày đặc hoặc đào tạo riêng để giải thích thao tác cơ bản. System image (hình ảnh hệ thống) đang thất bại.

Âm thanh cũng là signifier (dấu hiệu chỉ dẫn). Âm thanh tốt truyền trạng thái hoặc mức khẩn cấp. Một tiếng bíp không rõ nghĩa chỉ tạo nhiễu.

Mapping, feedback và constraints

Mapping

Định nghĩa: Mapping (ánh xạ) là quan hệ giữa bộ điều khiển và kết quả.

Natural mapping (ánh xạ tự nhiên) dùng quan hệ không gian hoặc quy ước quen thuộc để giảm suy luận. Ví dụ, bốn nút điều khiển bếp được bố trí giống vị trí bốn vùng nấu.

Ứng dụng trong giao diện:

  • Nút gửi đặt ngay dưới trường cuối.
  • Điều khiển phát video đặt gần video.
  • Nhãn gắn trực tiếp với trường tương ứng.
  • Nút tăng và giảm nằm cạnh giá trị chúng thay đổi.

Boundary: "Tự nhiên" không hoàn toàn phổ quát. Văn hóa, hướng đọc và quy ước đã học có thể thay đổi cách người dùng hiểu mapping (ánh xạ). Một mapping "tự nhiên" với người dùng phương Tây có thể không tự nhiên với người dùng ở văn hóa khác.

Feedback

Định nghĩa: Feedback (phản hồi) cho biết hệ thống đã nhận hành động, đang xử lý hay đã hoàn thành.

Feedback (phản hồi) tốt phải:

  • Đúng lúc.
  • Đúng mức.
  • Nêu trạng thái hữu ích.
  • Cho biết bước tiếp theo khi có lỗi.
  • Không che khuất tác vụ khác.

Một nút đổi trạng thái khi được nhấn xác nhận hệ thống đã nhận thao tác. Thanh tiến trình cho biết tác vụ dài vẫn đang chạy. Lỗi tại trường cho biết dữ liệu nào cần sửa.

Anti-pattern (mẫu phản tác dụng): Quá nhiều thông báo, tiếng bíp không rõ nghĩa hoặc hoạt ảnh kéo dài. Feedback (phản hồi) dư thừa có thể tệ hơn thiếu phản hồi.

Constraints

Định nghĩa: Constraints (ràng buộc) thu hẹp hành động khả thi và hướng người dùng tới hành động đúng.

Bốn loại chính:

Loại Nghĩa Ví dụ
Physical constraint (ràng buộc vật lý) Hình dạng vật lý ngăn hành động sai Chi tiết lớn không vừa khe nhỏ
Cultural constraint (ràng buộc văn hóa) Quy ước xã hội đã học Màu đỏ biểu thị nguy hiểm
Semantic constraint (ràng buộc ngữ nghĩa) Ý nghĩa tình huống giới hạn lựa chọn Kính chắn gió nằm trước người lái
Logical constraint (ràng buộc logic) Suy luận loại trừ phương án sai Còn thừa linh kiện nghĩa là lắp chưa xong

Failure mode: Trong sản phẩm số, constraint (ràng buộc) nên ngăn lỗi mà không che lý do hoặc giam người dùng. Nút bị vô hiệu hóa nhưng không giải thích điều kiện còn thiếu là constraint (ràng buộc) yếu — nó ngăn được hành động sai nhưng tạo ra một Gulf of Execution mới: người dùng không biết phải làm gì để nút khả dụng.

Forcing functions

Forcing function (hàm ép buộc) là dạng constraint (ràng buộc) mạnh:

  • Interlock (khóa liên động): buộc hành động đúng thứ tự.
  • Lock-in (khóa trong): ngăn kết thúc quá sớm, như cảnh báo còn thay đổi chưa lưu.
  • Lockout (khóa ngoài): ngăn truy cập vùng nguy hiểm hoặc không đủ quyền.

Standardization (tiêu chuẩn hóa) là cultural constraint (ràng buộc văn hóa) dùng khi không thể tạo thiết kế tự hiểu. Người dùng học một lần rồi tái sử dụng kiến thức. Đổi lại, standardization (tiêu chuẩn hóa) có thể cản đổi mới.

Skeuomorphism (thiết kế mô phỏng vật quen thuộc) dùng dấu hiệu từ công nghệ cũ để hỗ trợ chuyển đổi sang công nghệ mới. Dùng khi ẩn dụ cũ giúp hiểu; bỏ khi nó giữ lại giới hạn không còn cần thiết.

Hai vực thẳm và Bảy giai đoạn hành động

Intuition: Khi một người dùng muốn làm gì đó với sản phẩm, họ phải vượt qua hai "khoảng trống" nhận thức: một khoảng trống trước khi hành động (họ không biết cách làm), và một khoảng trống sau khi hành động (họ không biết chuyện gì vừa xảy ra). Cả hai khoảng trống này đều là nơi lỗi thiết kế ẩn náu.

Định nghĩa:

  • Gulf of Execution (vực thẳm thực thi): khoảng cách giữa mục tiêu và hành động khả thi. Câu hỏi: "Làm thế nào để làm việc này?"
  • Gulf of Evaluation (vực thẳm đánh giá): khoảng cách giữa trạng thái hệ thống và khả năng diễn giải. Câu hỏi: "Điều gì vừa xảy ra?"

Signifier (dấu hiệu chỉ dẫn), mapping (ánh xạ) và constraint (ràng buộc) chủ yếu thu hẹp Gulf of Execution (vực thẳm thực thi). Feedback (phản hồi) và conceptual model (mô hình khái niệm) rõ chủ yếu thu hẹp Gulf of Evaluation (vực thẳm đánh giá).

Seven Stages of Action

Vì sao mô hình này tồn tại: Khi một luồng thất bại, câu hỏi "cái gì sai" quá mơ hồ để hành động. Seven Stages of Action (Bảy giai đoạn hành động) chia nhỏ hành trình thành các bước có thể kiểm tra riêng, giúp định vị chính xác nơi luồng gãy.

P4.1 - Mental model, affordance và nguyên lý usability — diagram 2

Source mermaid — có thể chỉnh sửa 
flowchart TB
    G["1. Goal<br/>(Hình thành mục tiêu)"]
    P["2. Plan<br/>(Lập kế hoạch)"]
    S["3. Specify<br/>(Chỉ định chuỗi hành động)"]
    A["4. Perform<br/>(Thực hiện hành động)"]
    W["Trạng thái hệ thống"]
    PE["5. Perceive<br/>(Cảm nhận trạng thái mới)"]
    I["6. Interpret<br/>(Diễn giải trạng thái)"]
    C["7. Compare<br/>(So sánh với mục tiêu)"]

    G --> P
    P --> S
    S --> A
    A --> W
    W --> PE
    PE --> I
    I --> C
    C --> G
Giai đoạn Câu hỏi chẩn đoán
Goal (mục tiêu) Người dùng thật sự muốn đạt kết quả nào?
Plan (lập kế hoạch) Họ tin con đường nào sẽ đạt mục tiêu?
Specify (chỉ định) Họ có xác định được thao tác cụ thể không?
Perform (thực hiện) Mục tiêu tương tác có đủ lớn, gần và khả dụng không?
Perceive (cảm nhận) Họ có thấy trạng thái thay đổi không?
Interpret (diễn giải) Họ có hiểu trạng thái đó nghĩa gì không?
Compare (so sánh) Họ có biết mục tiêu đã đạt chưa?

Boundary: Khi mục tiêu bề mặt không giải thích được hành vi, dùng kỹ thuật Five Whys (Hỏi Tại sao năm lần) để tìm mục tiêu gốc. Không tối ưu thao tác trước khi xác nhận đúng mục tiêu — tối ưu sai mục tiêu chỉ làm luồng sai nhanh hơn.

Kiến thức trong đầu và kiến thức trong thế giới

Intuition: Con người không cần nhớ mọi thứ nếu môi trường xung quanh nhắc cho họ. Một cuốn lịch trên tường thay thế việc phải nhớ ngày. Nguyên lý này áp dụng trực tiếp vào giao diện số.

Định nghĩa:

  • Knowledge in the head (kiến thức trong đầu): điều đã học và ghi nhớ.
  • Knowledge in the world (kiến thức trong thế giới): nhãn, cấu trúc, ví dụ, trạng thái, lịch sử và chỉ dẫn hiện diện trong môi trường.
Tiêu chí Kiến thức trong đầu Kiến thức trong thế giới
Chi phí học Cao Thấp
Tốc độ với chuyên gia Nhanh Có thể chậm hơn
Hỗ trợ người mới Kém hơn Tốt hơn
Độ gọn giao diện Có thể cao Có thể tạo thêm chi tiết
Rủi ro Quên, nhầm chế độ Nhiễu, phụ thuộc ngữ cảnh

Vì sao cần phân biệt: Đội thiết kế thường mắc lỗi giả định người dùng sẽ "nhớ" thông tin đã hiện ở bước trước. Working memory (bộ nhớ làm việc) rất hạn chế, thường chỉ giữ khoảng 3–5 đơn vị trong điều kiện thực tế. Không bắt người dùng nhớ mã, giá trị hoặc lựa chọn giữa các màn hình. Đưa thông tin cần thiết vào đúng ngữ cảnh.

Long-term memory (trí nhớ dài hạn) giữ thông tin có ý nghĩa và cấu trúc tốt hơn dữ liệu tùy tiện. Conceptual model (mô hình khái niệm) tốt giúp tính năng có cấu trúc, dễ học và dễ nhớ.

Anti-pattern (mẫu phản tác dụng): Chính sách mật khẩu buộc tạo chuỗi phức tạp, thay đổi thường xuyên nhưng không hỗ trợ trình quản lý mật khẩu. Người dùng chuyển sang knowledge in the world (kiến thức trong thế giới) không an toàn như ghi mật khẩu ra giấy.

Ba cấp độ xử lý và vai trò của cảm xúc

Một sản phẩm được xử lý đồng thời ở ba cấp độ:

  1. Visceral level (cấp độ bản năng) — Phản ứng nhanh về vẻ ngoài, âm thanh, chuyển động và cảm giác an toàn.
  2. Behavioral level (cấp độ hành vi) — Khả năng hoàn thành việc, hiệu suất, kiểm soát và chất lượng feedback (phản hồi).
  3. Reflective level (cấp độ phản tư) — Ý nghĩa, ký ức, hình ảnh bản thân, niềm tin và giá trị thương hiệu.

Boundary quan trọng cho senior: Thiết kế đẹp không đối lập với usability (khả năng sử dụng). Vẻ đẹp tạo ấn tượng bản năng và có thể tăng khoan dung với lỗi nhỏ. Nhưng nó cũng có thể che lỗi hành vi — đây là lý do một sản phẩm được khen "đẹp" trong khảo sát vẫn có thể thất bại tác vụ trong usability testing.

Trong usability testing (kiểm thử khả năng sử dụng), quan sát người dùng làm gì. Không dùng lời khen màu sắc hoặc phong cách làm bằng chứng rằng luồng hoạt động tốt.

Các quy luật usability — công cụ phá thế hòa

Các quy luật dưới đây là heuristics (quy tắc thực nghiệm). Chúng hỗ trợ phán đoán và giải thích hành vi; không thay nghiên cứu người dùng.

Ba định luật của Krug

1. Don't Make Me Think

Krug's First Law of Usability (Định luật khả năng sử dụng thứ nhất của Krug): không bắt người dùng suy nghĩ về thứ không phục vụ nhiệm vụ.

Mỗi dấu hỏi nhận thức tiêu hao chú ý:

  • Đây là gì?
  • Tôi bắt đầu ở đâu?
  • Thứ này có bấm được không?
  • Hai nhãn này khác nhau thế nào?
  • Vì sao họ dùng từ này?

Quy tắc quyết định:

  1. Ưu tiên self-evident interface (giao diện tự hiển nhiên).
  2. Nếu sản phẩm mới hoặc phức tạp, dùng self-explanatory interface (giao diện tự giải thích).
  3. Không chấp nhận giao diện buộc người dùng tự suy luận mô hình vận hành.

2. Mức suy nghĩ quan trọng hơn số lần bấm

Krug's Second Law of Usability (Định luật khả năng sử dụng thứ hai của Krug): số lần bấm không quan trọng bằng mức suy nghĩ và bất định của mỗi lần bấm.

Ba lần bấm rõ có thể tốt hơn một lần bấm mơ hồ. Số lần bấm quan trọng hơn khi thao tác lặp thường xuyên, tải chậm hoặc mỗi bước có chi phí cao.

Đánh giá đường đi theo:

  • Mức suy nghĩ cần thiết.
  • Mức bất định.
  • Information scent (dấu hiệu đường đi đúng).
  • Tần suất lặp.
  • Chi phí tải và phục hồi.

Không áp dụng máy móc three-click rule (quy tắc ba lần bấm).

3. Omit Needless Words

Krug's Third Law of Usability (Định luật khả năng sử dụng thứ ba của Krug): bỏ từ không thay đổi quyết định, hành động hoặc mức hiểu.

Cắt trước:

  • Happy talk (lời chào và tự quảng bá không mang thông tin).
  • Hướng dẫn giải thích điều giao diện nên tự thể hiện.
  • Thuật ngữ nội bộ.
  • Nội dung xuất hiện sai thời điểm.

Boundary: Không cắt thông tin ảnh hưởng đến sự đồng thuận, giá, rủi ro, kỳ vọng thời gian hoặc khả năng phục hồi. "Ngắn gọn" không phải mục tiêu tuyệt đối — mục tiêu là loại bỏ thứ không phục vụ quyết định.

Mười quy luật UX thường dùng

Quy luật Ý nghĩa Cách dùng Cảnh báo
Jakob's Law (Quy luật Jakob) Người dùng mong sản phẩm vận hành giống sản phẩm quen thuộc Dùng quy ước cho tìm kiếm, điều hướng, thanh toán Chỉ phá quy ước khi lợi ích vượt chi phí học và đã kiểm thử
Fitts's Law (Quy luật Fitts) Mục tiêu lớn và gần dễ chọn hơn Tăng kích thước, khoảng cách và khả năng tiếp cận Nút nguy hiểm đặt sát nút an toàn làm tăng chọn nhầm
Miller's Law (Quy luật Miller) Bộ nhớ làm việc có giới hạn Dùng chunking (phân cụm) và đưa thông tin vào ngữ cảnh Không giới hạn menu ở bảy mục một cách máy móc
Hick's Law (Quy luật Hick) Quyết định chậm khi lựa chọn nhiều hoặc phức tạp Nhóm, xếp ưu tiên, tiết lộ dần Cắt lựa chọn quá mức có thể tạo biểu tượng và nhãn khó hiểu
Postel's Law (Quy luật Postel) Đầu ra nhất quán; đầu vào bao dung Chuẩn hóa số điện thoại, hỗ trợ thiết bị và mạng khác nhau Bao dung đầu vào không được làm yếu bảo mật hoặc tính đúng
Peak–End Rule (Quy luật Đỉnh–Cuối) Ký ức chịu ảnh hưởng mạnh bởi đỉnh cảm xúc và kết thúc Giảm điểm đau lớn, tạo kết thúc rõ và tích cực Không dùng khoảnh khắc vui để che hành trình tệ
Aesthetic–Usability Effect (Hiệu ứng Thẩm mỹ–Khả dụng) Thiết kế đẹp thường được cảm nhận là dễ dùng hơn Dùng chất lượng thị giác để tăng tin cậy Thẩm mỹ có thể che lỗi nghiêm trọng
Von Restorff Effect (Hiệu ứng Von Restorff) Thành phần khác biệt dễ được chú ý và nhớ Làm nổi hành động chính Quá nhiều điểm nhấn triệt tiêu nhau; không chỉ dùng màu
Tesler's Law (Định luật Tesler) Độ phức tạp cố hữu phải do hệ thống hoặc người dùng gánh Chuyển xử lý lặp và tính toán sang hệ thống Đừng giấu độ phức tạp cần thiết tới mức mất kiểm soát
Doherty Threshold (Ngưỡng Doherty) Phản hồi nhanh giữ người dùng trong dòng tác vụ Phản hồi dưới 400 mili giây khi khả thi; quản lý hiệu suất cảm nhận Optimistic UI (giao diện lạc quan) cần phục hồi khi máy chủ từ chối

Quy tắc kích thước mục tiêu

Mốc tham khảo:

  • Apple: 44 × 44 pt.
  • Google Material Design: 48 × 48 dp.
  • WCAG: 44 × 44 CSS px.
  • Khoảng cách tham khảo giữa mục tiêu: 8 dp.

Boundary: Không dùng con số để thay kiểm thử trên thiết bị, tư thế và nhóm người dùng thật. Các mốc này là điểm khởi đầu, không phải bằng chứng đủ.

Progressive disclosure và độ phức tạp

Progressive disclosure (tiết lộ lũy tiến) chỉ hiển thị lựa chọn chính trước, đưa lựa chọn nâng cao ra khi cần. Kỹ thuật này quản lý cognitive load (tải nhận thức) nhưng không xóa độ phức tạp cố hữu.

Dùng khi:

  • Phần lớn người dùng chỉ cần tập chức năng nhỏ.
  • Tùy chọn nâng cao có ngữ cảnh rõ.
  • Người dùng vẫn tìm được chức năng bị ẩn.

Failure mode: Không dùng để chôn giá, rủi ro, điều khoản hoặc chức năng phục hồi. Đây là ranh giới giữa "quản lý tải nhận thức hợp lý" và "che giấu thông tin quan trọng".

Thiết kế cho lỗi, không đổ lỗi cho người dùng

Intuition: Khi nhiều người dùng cùng mắc "lỗi" tại cùng một điểm, đó không còn là lỗi cá nhân — đó là tín hiệu hệ thống có thiết kế kém.

Slips và mistakes

Loại Nghĩa Ví dụ Hướng thiết kế
Slip (lỗi trượt) Mục tiêu đúng, thực thi sai Bấm nhầm "Xóa" thay vì "Lưu" Tách mục tiêu, tăng khác biệt, hỗ trợ hoàn tác
Mistake (lỗi nhầm lẫn) Mục tiêu hoặc kế hoạch sai Hiểu sai "Hủy" là hủy hộp thoại thay vì hủy đơn Sửa nhãn, mô hình khái niệm và giải thích hệ quả

Các dạng slip (lỗi trượt) thường gặp:

  • Bị thói quen cũ kéo sang hành động quen thuộc.
  • Chọn nhầm đối tượng tương tự.
  • Quên một bước.
  • Nhầm mode (chế độ) hiện tại.

Các dạng mistake (lỗi nhầm lẫn) thường gặp:

  • Áp dụng sai quy tắc.
  • Thiếu kiến thức để chẩn đoán.
  • Quên mục tiêu sau khi bị gián đoạn.

Vì sao phân biệt này quan trọng: Hộp thoại "Bạn có chắc không?" thường không sửa được mistake (lỗi nhầm lẫn) vì người dùng tin họ đang làm đúng — họ sẽ bấm "Có" ngay vì họ không nghĩ mình đang sai. Cách tốt hơn:

  • Nêu đối tượng và hệ quả cụ thể.
  • Cho xem trước tác động.
  • Dùng Undo (hoàn tác).
  • Trì hoãn xóa vĩnh viễn.
  • Cung cấp lịch sử hoặc phiên bản.

Swiss Cheese Model

Swiss Cheese Model (Mô hình Lát phô mai Thụy Sĩ) xem sự cố nghiêm trọng là kết quả của nhiều lớp phòng vệ cùng hở, không phải một cá nhân duy nhất sai.

Các lớp có thể gồm:

  • Chính sách.
  • Quy trình.
  • Phân quyền.
  • Giao diện.
  • Kiểm tra tự động.
  • Đào tạo.
  • Phê duyệt.
  • Khả năng phục hồi.

Resilience engineering (kỹ thuật phục hồi) tập trung vào khả năng phát hiện, cô lập, phục hồi và học từ sự cố; không chỉ cố ngăn mọi lỗi.

Billboard design — thiết kế cho việc quét nhanh

Một màn hình hỗ trợ scan (quét nhanh) cần:

  1. Visual hierarchy (phân cấp thị giác) rõ.
  2. Quy ước quen thuộc.
  3. Vùng chức năng tách biệt.
  4. Thành phần tương tác dễ nhận biết.
  5. Ít visual noise (nhiễu thị giác).

Visual hierarchy

Visual hierarchy (phân cấp thị giác) phải phản ánh quan hệ logic:

  • Nội dung quan trọng nổi hơn.
  • Nội dung liên quan được nhóm.
  • Quan hệ cha–con thể hiện bằng vị trí, khoảng trắng và kiểu chữ.
  • Hành động chính khác hành động phụ.

Nếu mọi thành phần cùng nổi, không thành phần nào nổi.

Visual noise

Visual noise (nhiễu thị giác) gồm:

  • Quá nhiều thành phần tranh chú ý.
  • Chi tiết nền nhỏ nhưng cộng dồn.
  • Quảng bá trông giống hành động chính.
  • Liên kết và chữ tĩnh dùng cùng kiểu.

Quy tắc kinh nghiệm: Xem mỗi thành phần là nhiễu cho tới khi chứng minh nó hỗ trợ hiểu, quyết định hoặc hành động.

Navigation (điều hướng) phải giúp người dùng trả lời:

  • Đây là sản phẩm nào?
  • Đây là trang nào?
  • Tôi đang ở đâu?
  • Khu vực chính là gì?
  • Lựa chọn cấp hiện tại là gì?
  • Tìm kiếm ở đâu?

Trunk test (kiểm tra định hướng khi vào trang sâu) kiểm tra sáu câu trên tại trang người dùng có thể vào trực tiếp từ tìm kiếm, email hoặc liên kết ngoài. Nếu chỉ hiểu sau vài phút suy luận, điều hướng chưa đạt.

Applied — tình huống đăng ký ứng dụng học trực tuyến

Lưu ý: Tình huống dưới đây là mô phỏng minh họa (simulated), dùng để luyện tập chẩn đoán và ra quyết định. Số liệu và tên sản phẩm không phải trường hợp thật.

Bối cảnh (Facts)

Một ứng dụng học trực tuyến có tỷ lệ bỏ màn hình đăng ký cao. Đội tăng quảng cáo nhưng số tài khoản kích hoạt không tăng tương ứng.

Màn hình hiện tại yêu cầu: Họ, Tên, Tên người dùng, Email, Mật khẩu, Nhập lại mật khẩu, Ngày sinh, Số điện thoại, Lĩnh vực quan tâm, Mã giới thiệu.

Tất cả trường bắt buộc. Nút "Đăng ký" màu xám nhạt. Khi dữ liệu sai, trang tải lại và hiện "Đã có lỗi xảy ra" ở đầu trang.

Current behavior (hành vi hiện tại)

Người dùng vào màn hình, thấy 10 trường bắt buộc, điền một phần, gặp lỗi không rõ nguyên nhân sau khi bấm nút mờ, và phần lớn rời trang tại đây. Quảng cáo đưa thêm lưu lượng vào cùng một điểm nghẽn, nên chi phí thu hút tăng nhưng số tài khoản kích hoạt không tăng tương ứng.

Underlying need (nhu cầu thật)

Người dùng muốn bắt đầu học ngay, không muốn khai báo thông tin cá nhân trước khi thấy giá trị sản phẩm. Marketing muốn dữ liệu phân khúc để nhắm quảng cáo và cá nhân hóa. Hai nhu cầu này bị ép chung vào một thời điểm — thời điểm người dùng có ít động lực nhất để cung cấp thông tin (chưa thấy giá trị gì).

Chẩn đoán theo mô hình

1. Mục tiêu kinh doanh và mục tiêu người dùng không khớp

Gulf of Execution (vực thẳm thực thi) lớn vì người dùng không biết vì sao phải cung cấp ngày sinh, số điện thoại và lĩnh vực quan tâm trước khi thấy giá trị.

2. System image truyền sai trạng thái

Nút màu xám thường biểu thị trạng thái không khả dụng. Nếu nút vẫn bấm được, signifier (dấu hiệu chỉ dẫn) sai. Nếu nút không bấm được nhưng không nói điều kiện thiếu, constraint (ràng buộc) không đủ thông tin.

3. Feedback không hỗ trợ phục hồi

"Đã có lỗi xảy ra" chỉ báo thất bại, không chỉ nguyên nhân, vị trí hoặc cách sửa. Người dùng phải quét lại toàn bộ biểu mẫu. Gulf of Evaluation (vực thẳm đánh giá) lớn.

4. Hệ thống chuyển độ phức tạp sang người dùng

Yêu cầu định dạng số điện thoại cứng nhắc vi phạm Postel's Law (Quy luật Postel). Nhập lại mật khẩu bắt người dùng làm công việc hệ thống có thể thay bằng chức năng hiện mật khẩu.

5. Rủi ro dữ liệu giả

Trường không cần cho giao dịch hiện tại làm giảm hoàn thành, giảm thiện cảm và tăng dữ liệu giả. Nhiều trường tùy chọn vẫn tạo cảm giác công việc dài.

Options (phương án)

Phương án Mô tả Ưu điểm Nhược điểm
A. Giữ nguyên, tăng ngân sách quảng cáo Không đổi form, đổ thêm traffic Không tốn công thiết kế lại Chi phí thu hút tăng, tỷ lệ kích hoạt không cải thiện, lãng phí ngân sách
B. Rút gọn form về tối thiểu (email + mật khẩu) Chỉ giữ trường cần cho giao dịch hiện tại Giảm mạnh rào cản, tăng tỷ lệ hoàn thành dự kiến Mất dữ liệu phân khúc sớm; cần thiết kế lại luồng hỏi thông tin sau
C. Giữ toàn bộ trường nhưng thêm giải thích lý do từng trường Không đổi cấu trúc, chỉ thêm nội dung Không đổi kiến trúc, ít việc engineering Không giải quyết gốc rễ — vẫn là công việc dài trước khi thấy giá trị

Decision criteria (tiêu chí quyết định)

  • Trường có cần cho giao dịch hiện tại (tạo tài khoản, xác thực) không.
  • Giá trị đổi lại cho người dùng nếu cung cấp trường đó ngay.
  • Khả năng hỏi lại thông tin đó sau, sau khi người dùng đã thấy giá trị.
  • Yêu cầu pháp lý bắt buộc (ví dụ xác minh tuổi khi luật yêu cầu).
  • Tác động lên tỷ lệ hoàn thành và tỷ lệ dữ liệu giả.

Decision (quyết định)

Chọn phương án B — rút gọn form về mức tối thiểu, chuyển các trường không bắt buộc sang hỏi sau bằng progressive disclosure.

Form data justification (bảng biện minh dữ liệu biểu mẫu):

Trường Cần cho giao dịch hiện tại Giá trị cho người dùng Quyết định
Email Có Tạo và phục hồi tài khoản Giữ
Mật khẩu Có nếu không dùng đăng nhập liên kết Bảo vệ tài khoản Giữ
Họ và tên Không Cá nhân hóa hạn chế Hỏi sau
Số điện thoại Không Chưa có giá trị trực tiếp Xóa
Ngày sinh Chỉ cần nếu có yêu cầu tuổi Bảo vệ trẻ vị thành niên Chỉ hỏi khi pháp lý yêu cầu
Lĩnh vực quan tâm Không Cải thiện gợi ý Hỏi sau khi người dùng thấy giá trị
Mã giới thiệu Không Nhận ưu đãi Giữ tùy chọn, thu gọn

Authority (quyền quyết định)

Product Manager quyết định phạm vi dữ liệu bắt buộc, với sự tham gia bắt buộc của Legal (yêu cầu tuổi, quyền riêng tư) và Data owner (tác động lên phân khúc marketing). Design chịu trách nhiệm về mapping, feedback và progressive disclosure. Engineering xác nhận tính khả thi của việc hỏi thông tin sau khi tài khoản đã tạo.

Artifact

Form data justification (bảng trên) và Stakeholder design decision brief gửi cho Marketing để giải thích lý do bỏ thu thập số điện thoại và lĩnh vực quan tâm ngay từ đầu, kèm kế hoạch thu thập lại sau khi kích hoạt.

Consequence if wrong (hệ quả nếu quyết định sai)

Nếu rút gọn quá mức và bỏ luôn các trường pháp lý bắt buộc (như xác minh tuổi khi luật yêu cầu), sản phẩm có thể vi phạm quy định bảo vệ trẻ vị thành niên. Nếu không thiết kế lại luồng hỏi thông tin sau, Marketing mất hoàn toàn dữ liệu phân khúc và không thể bù lại — đây là lý do quyết định cần Legal và Data owner tham gia trước khi chốt, không phải sau khi phát hành.

Thiết kế sửa

  • Màn hình đầu chỉ yêu cầu email và mật khẩu.
  • Đăng nhập liên kết được cung cấp khi phù hợp với mô hình rủi ro và nền tảng.
  • Yêu cầu mật khẩu hiện đúng lúc, không hiện như đoạn hướng dẫn dài.
  • Hệ thống chấp nhận khoảng trắng quanh email và chuẩn hóa đầu vào an toàn.
  • Chức năng hiện mật khẩu thay việc nhập lại mật khẩu.
  • Lỗi hiển thị cạnh trường, nêu nguyên nhân và cách sửa.
  • Email đã tồn tại dẫn thẳng tới đăng nhập hoặc phục hồi tài khoản.
  • Nút chính có độ tương phản, kích thước và nhãn rõ.
  • Khi xử lý, nút chuyển trạng thái và ngăn gửi lặp.
  • Nếu máy chủ từ chối, dữ liệu không nhạy cảm được giữ để người dùng không nhập lại.
  • Thông tin sở thích được hỏi sau bằng progressive disclosure (tiết lộ lũy tiến).

Không tối ưu mù quáng

Đội không tuyên bố thiết kế mới "chắc chắn tăng mạnh chuyển đổi". Đội kiểm chứng bằng:

  • Tỷ lệ bắt đầu và hoàn thành đăng ký.
  • Thời gian hoàn thành.
  • Lỗi theo trường.
  • Tỷ lệ tự phục hồi.
  • Tỷ lệ dữ liệu giả.
  • Tỷ lệ kích hoạt học tập.
  • Phản hồi định tính về niềm tin.

Một vòng usability testing (kiểm thử khả năng sử dụng) nhỏ được chạy trước phát hành. Ba đến bốn người thực hiện tác vụ, nói thành tiếng suy nghĩ. Đội quan sát hành vi, rút kinh nghiệm cùng ngày, sửa rồi kiểm thử lại.

Senior Lens — governance, trade-off và quyền quyết định

Quyền quyết định

Nguyên tắc tâm lý không tự giải quyết tranh chấp. Mỗi quyết định cần chủ sở hữu rõ:

Phạm vi Người chịu trách nhiệm chính Bên bắt buộc tham gia
Mục tiêu người dùng và kết quả kinh doanh Product Manager Design, Engineering, Data
Mô hình tương tác và phân cấp Product Designer Product Manager, Research
Tính khả thi và trạng thái hệ thống Engineering Design, Product Manager
Nội dung, nhãn và giọng điệu Content Design hoặc Design Product Manager, Legal
Accessibility (khả năng tiếp cận) Chủ sản phẩm chịu trách nhiệm cuối Design, Engineering, QA
Dữ liệu bắt buộc Product Manager Legal, Security, Data owner
Phát hành thay đổi rủi ro cao Người có quyền phát hành Product, Design, Engineering, Risk

Testing cung cấp bằng chứng; testing không thay quyền quyết định. Người có quyền quyết định phải ghi rõ:

  • Mục tiêu.
  • Rủi ro.
  • Bằng chứng.
  • Đánh đổi.
  • Điều kiện giữ, sửa hoặc bỏ.
  • Phần cần kiểm thử lại.

Artifact quản trị quyết định

Stakeholder design decision brief (bản tóm tắt quyết định thiết kế cho bên liên quan) nên gồm:

  1. Ý định kinh doanh.
  2. Nhiệm vụ người dùng bị ảnh hưởng.
  3. Phương án đề xuất.
  4. Rủi ro về usability (khả năng sử dụng), thiện cảm, thương hiệu và tiếp cận.
  5. Phương án ít hại hơn.
  6. Điều kiện chấp nhận.
  7. Kế hoạch kiểm thử.
  8. Chỉ số giữ, sửa hoặc bỏ.
  9. Người có quyền quyết định.
  10. Ngày xem lại.

Khi nào tuân thủ và khi nào phá quy ước

Jakob's Law (Quy luật Jakob) không yêu cầu mọi sản phẩm giống nhau.

Nên giữ quy ước cho:

  • Tìm kiếm.
  • Điều hướng.
  • Biểu mẫu.
  • Thanh toán.
  • Phục hồi tài khoản.
  • Hành động nguy hiểm.
  • Thành phần phục vụ tiếp cận.

Có thể đổi mới khi:

  • Giá trị cốt lõi thật sự được cải thiện.
  • Cách mới rõ ngay hoặc có cơ chế chuyển đổi.
  • Lợi ích vượt chi phí học và chi phí chuyển đổi.
  • Đội đã kiểm thử nghiêm ngặt.
  • Có đường quay lại hoặc triển khai theo giai đoạn khi rủi ro cao.

Legacy problem (vấn đề di sản) xuất hiện khi lượng người dùng lớn đã học cách cũ. Thiết kế mới không chỉ cần tốt hơn; nó phải tốt hơn đủ nhiều để bù chi phí chuyển đổi.

Human-Centered Design (thiết kế lấy con người làm trung tâm) mạnh với đổi mới tiệm tiến. Nó không tự tạo đổi mới đột phá. Đổi mới đột phá thường cần công nghệ mới, nhiều thất bại và thời gian dài để hình thành quy ước.

Ma sát có chủ đích

Giảm friction (ma sát) không phải mục tiêu tuyệt đối.

Thêm friction (ma sát) khi cần:

  • Ngăn chuyển tiền sai.
  • Ngăn xóa dữ liệu khó phục hồi.
  • Buộc xem hệ quả pháp lý.
  • Xác nhận thay đổi quyền truy cập.
  • Tăng bảo mật.
  • Chuyển người dùng từ phản ứng nhanh sang cân nhắc có ý thức.

Không dùng hộp thoại xác nhận chung chung. Ưu tiên:

  1. Nêu đối tượng cụ thể.
  2. Nêu hệ quả.
  3. Tách hành động nguy hiểm khỏi hành động thường.
  4. Yêu cầu xác nhận tương xứng với rủi ro.
  5. Cung cấp Undo (hoàn tác) nếu khả thi.

Boundary: Cố ý thêm độ trễ để tạo cảm giác hệ thống "đang làm việc" dễ trở thành thao túng. Chỉ dùng khi nó tăng hiểu trạng thái hoặc ngăn hành động rủi ro, không để giả hiệu suất.

Accessibility là quality bar

Accessibility (khả năng tiếp cận) không phải lớp kiểm tra cuối. Sản phẩm không thể được xem là dễ dùng nếu loại bỏ người có nhu cầu tiếp cận.

Ngưỡng tối thiểu:

  • Hoạt động bằng bàn phím.
  • Thứ tự đọc hợp lý.
  • Nhãn biểu mẫu liên kết đúng với trường.
  • Hình có văn bản thay thế phù hợp.
  • Chữ phóng to không làm vỡ bố cục.
  • Không dùng màu làm tín hiệu duy nhất.
  • Độ tương phản văn bản thông thường đạt ít nhất 4.5:1 khi tiêu chuẩn áp dụng.
  • Chuyển động tôn trọng thiết lập giảm chuyển động.
  • Thông báo lỗi được công nghệ hỗ trợ đọc màn hình nhận biết.
  • Từ phân biệt được đặt sớm trong liên kết và tiêu đề.

Boundary: Công cụ tự động chỉ tìm một phần lỗi. Đạt kiểm tra tự động không chứng minh sản phẩm tiếp cận được. Cần kiểm thử bằng bàn phím, trình đọc màn hình và người dùng thật khi rủi ro đủ cao.

Anti-patterns và tín hiệu cảnh báo

Featuritis — Featuritis (bệnh nghiện tính năng) là việc liên tục thêm tính năng để cạnh tranh hoặc thúc đẩy nâng cấp, làm sản phẩm phức tạp và khó dùng.

Quy tắc: Củng cố điểm mạnh độc nhất. Giữ phần khác ở mức đủ tốt. Không sao chép mọi tính năng của đối thủ.

Learned helplessness — Learned helplessness (sự bất lực tập nhiễm) xuất hiện khi người dùng gặp khó lặp lại rồi tin lỗi nằm ở họ. Họ không báo cáo; họ chịu đựng, dùng đường vòng hoặc rời đi.

Không chỉ dựa vào phiếu hỗ trợ. Quan sát hành vi, lỗi lặp, thao tác quay lại và thời gian dừng.

Aesthetic masking — Giao diện đẹp có thể che lỗi. Người dùng nói "đẹp" nhưng không hiểu giá trị, chọn sai nhãn hoặc thất bại tác vụ.

Quan sát: điểm họ dừng, thứ họ bấm, lý do họ nêu, cách họ tự phục hồi.

Oversimplification — Đơn giản hóa quá mức tạo biểu tượng không nhãn, cấu trúc ẩn và điều khiển khó khám phá.

Xóa trước. Nếu vẫn phức tạp, nhóm và ưu tiên. Không thay chữ rõ bằng biểu tượng mơ hồ để giao diện trông sạch.

Confirmation dialog everywhere — Hộp thoại xác nhận xuất hiện quá thường xuyên tạo thói quen bấm qua. Nó không sửa mistake (lỗi nhầm lẫn) và còn làm cảnh báo quan trọng mất hiệu lực.

Measurement trap — Measurement trap (bẫy đo lường) xuất hiện khi đội tối ưu chỉ số tương tác như thời gian sử dụng hoặc số lần mở ứng dụng mà bỏ qua mục tiêu và sức khỏe người dùng.

Intermittent variable rewards (phần thưởng biến đổi không liên tục) có thể tăng hành vi lặp nhưng cũng tạo cơ chế gây nghiện.

Product Leader phải cân bằng: giá trị kinh doanh, mục tiêu người dùng, niềm tin, khả năng quay lại lành mạnh, hậu quả dài hạn, nhóm dễ bị tổn thương.

Usability testing — phá tranh luận bằng hành vi

Focus group (nhóm thảo luận) thu ý kiến và cảm nhận. Nó không cho biết giao diện có dùng được không.

Usability testing (kiểm thử khả năng sử dụng) quan sát từng người dùng sản phẩm, mẫu thử hoặc bản phác thảo để hiểu:

  • Họ có hiểu sản phẩm không?
  • Họ chọn đường nào?
  • Họ thất bại ở đâu?
  • Họ có tự phục hồi không?
  • Nhãn và mô hình có khớp không?

Nhịp tối thiểu:

  1. Chọn câu hỏi thiết kế cụ thể.
  2. Chuẩn bị phiên bản nhỏ nhất đủ kiểm tra.
  3. Kiểm thử với ba hoặc bốn người.
  4. Quan sát, không chỉ đường.
  5. Rút kinh nghiệm cùng ngày.
  6. Chọn lỗi nghiêm trọng và thay đổi ít nhất đủ kiểm tra.
  7. Kiểm thử lại.

Nhiều vòng nhỏ sớm thường có giá trị hơn một vòng lớn muộn.

Quy tắc ưu tiên lỗi: Ưu tiên lỗi gây không hiểu đề xuất giá trị, thất bại tác vụ chính, chọn sai nhưng tin rằng đang đúng, mất định hướng, không thể phục hồi, friction (ma sát) lặp lại, hoặc rủi ro an toàn, bảo mật, tiếp cận.

Một lỗi có thể chưa sửa ngay nếu người dùng nhận ra nhanh, tự phục hồi và không chịu chi phí đáng kể. Mọi thay đổi vẫn cần đánh giá regression risk (rủi ro làm hỏng hành vi đang tốt).

Artifacts dùng trong thực tế

Artifact Nội dung tối thiểu Khi dùng
Usability issue log (nhật ký vấn đề khả năng sử dụng) Thành phần, suy nghĩ bị kích hoạt, tác vụ bị gián đoạn, bằng chứng, mức nghiêm trọng, hướng sửa Đánh giá giao diện
Page hierarchy spec (đặc tả phân cấp trang) Mức ưu tiên, nhóm logic, quan hệ cha–con, vùng chức năng, trạng thái tương tác Thiết kế màn hình
Click-path review (đánh giá đường thao tác) Nhãn, lựa chọn cạnh tranh, bất định, dấu hiệu đường đi đúng, chi phí phục hồi Kiến trúc thông tin
Trunk test worksheet (phiếu kiểm tra định hướng trang sâu) Nhận diện sản phẩm, tên trang, khu vực, vị trí, điều hướng cục bộ, tìm kiếm Điều hướng
Form data justification (bảng biện minh dữ liệu biểu mẫu) Trường, bắt buộc, lý do hiện tại, giá trị đổi lại, chủ sở hữu, khả năng hỏi sau Biểu mẫu
Journey map (bản đồ hành trình người dùng) Bối cảnh, giai đoạn, hành động, suy nghĩ, cảm xúc, đỉnh, đáy, cơ hội Hành trình dài
Goodwill audit (kiểm toán thiện cảm) Thông tin bị giấu, bước thừa, dữ liệu thừa, lỗi thiếu phục hồi, điểm bù niềm tin Thanh toán, hỗ trợ, sự cố
Same-day debrief (biên bản rút kinh nghiệm cùng ngày) Lỗi, bằng chứng, tác động, quyết định, người phụ trách, phần kiểm thử lại Sau kiểm thử
Stakeholder design decision brief (bản tóm tắt quyết định thiết kế cho bên liên quan) Ý định, rủi ro, phương án, điều kiện chấp nhận, quyền quyết định Tranh chấp liên phòng ban

Quick reference

Câu hỏi Nguyên tắc
Người dùng có hiểu đây là gì trong vài giây không? System image (hình ảnh hệ thống), Don't Make Me Think (Đừng bắt tôi suy nghĩ)
Hành động khả thi có dễ nhận ra không? Discoverability (khả năng khám phá), signifier (dấu hiệu chỉ dẫn)
Nhãn có dùng từ người dùng hiểu không? Mental model (mô hình nhận thức), information scent (dấu hiệu đường đi đúng)
Điều khiển có quan hệ rõ với kết quả không? Mapping (ánh xạ)
Hệ thống có xác nhận trạng thái đúng lúc không? Feedback (phản hồi), Doherty Threshold (Ngưỡng Doherty)
Người dùng có phải nhớ dữ liệu giữa các bước không? Knowledge in the world (kiến thức trong thế giới), working memory (bộ nhớ làm việc)
Có quá nhiều lựa chọn hoặc lựa chọn quá phức tạp không? Hick's Law (Quy luật Hick)
Thông tin có được nhóm theo nghĩa không? Miller's Law (Quy luật Miller), chunking (phân cụm)
Mục tiêu tương tác có đủ lớn và cách nhau đủ xa không? Fitts's Law (Quy luật Fitts)
Đầu vào có được chuẩn hóa thay vì phạt định dạng không? Postel's Law (Quy luật Postel)
Độ phức tạp có bị đẩy sang người dùng không? Tesler's Law (Định luật Tesler)
Hành động nguy hiểm có hệ quả rõ và khả năng phục hồi không? Forcing function (hàm ép buộc), Undo (hoàn tác)
Giao diện có hoạt động bằng bàn phím và trình đọc màn hình không? Accessibility (khả năng tiếp cận)
Quyết định dựa trên hành vi hay sở thích? Usability testing (kiểm thử khả năng sử dụng)
Chỉ số tăng có làm giảm niềm tin hoặc sức khỏe người dùng không? Measurement trap (bẫy đo lường)

Thuật ngữ sử dụng trong chương

Thuật ngữ Giải nghĩa
Usability (khả năng sử dụng) Mức người dùng có thể đạt mục tiêu hiệu quả, ít lỗi và không chịu thất vọng nghiêm trọng
Mental model (mô hình nhận thức) Cách người dùng tin hệ thống hoạt động
Conceptual model (mô hình khái niệm) Cách đơn giản hóa để giải thích hệ thống hoạt động
System image (hình ảnh hệ thống) Toàn bộ thông tin người dùng có thể cảm nhận từ sản phẩm
Affordance (khả năng hành động) Quan hệ cho biết hành động nào khả thi với đối tượng
Signifier (dấu hiệu chỉ dẫn) Tín hiệu cho biết nơi và cách hành động
Mapping (ánh xạ) Quan hệ giữa điều khiển và kết quả
Feedback (phản hồi) Thông tin về kết quả hoặc trạng thái sau hành động
Constraint (ràng buộc) Giới hạn giúp thu hẹp hành động khả thi
Discoverability (khả năng khám phá) Khả năng nhận ra hành động và điểm bắt đầu
Understanding (sự thấu hiểu) Khả năng hiểu ý nghĩa và cơ chế của sản phẩm
Cognitive load (tải nhận thức) Nỗ lực tinh thần cần để hiểu hoặc dùng sản phẩm
Chunking (phân cụm) Nhóm thông tin thành đơn vị có nghĩa
Friction (ma sát) Chi phí cản người dùng hoàn thành mục tiêu
Accessibility (khả năng tiếp cận) Khả năng sản phẩm phục vụ người có năng lực và cách tương tác đa dạng
Anti-pattern (mẫu phản tác dụng) Cách làm phổ biến nhưng tạo kết quả xấu lặp lại
Human-Centered Design (thiết kế lấy con người làm trung tâm) Quy trình bắt đầu từ nhu cầu, khả năng và hành vi con người
Progressive disclosure (tiết lộ lũy tiến) Chỉ hiện độ phức tạp khi người dùng cần
Undo (hoàn tác) Khả năng đảo ngược hành động
Goodwill (thiện cảm) Lượng kiên nhẫn, tin tưởng và thiện chí người dùng dành cho sản phẩm

Nguồn và giới hạn

The Design of Everyday Things

Nguồn mạnh về tâm lý hành động, mental model (mô hình nhận thức), affordance (khả năng hành động), signifier (dấu hiệu chỉ dẫn), lỗi và thiết kế phục hồi. Các ví dụ công nghệ có thể cũ; nguyên tắc nền tảng vẫn bền.

Don't Make Me Think

Nguồn mạnh về hành vi quét nhanh, lựa chọn đủ tốt, tự mò, điều hướng, biên tập nội dung, thiện cảm và usability testing (kiểm thử khả năng sử dụng) tinh gọn. Phạm vi nghiêng về website thông tin và thương mại điện tử; không bao phủ đầy đủ ứng dụng phức tạp hoặc mô hình kinh doanh.

Laws of UX

Nguồn mạnh về bộ quy tắc tâm lý cô đọng và ngôn ngữ chung cho quyết định thiết kế. Các quy luật là heuristics (quy tắc thực nghiệm), không phải quan hệ vật lý hay bằng chứng đủ để bỏ nghiên cứu người dùng.

Giới hạn áp dụng

Không có thiết kế duy nhất luôn đúng. Bối cảnh gồm:

  • Mục tiêu người dùng.
  • Tần suất tác vụ.
  • Mức chuyên môn.
  • Rủi ro lỗi.
  • Thiết bị.
  • Văn hóa.
  • Khả năng tiếp cận.
  • Chi phí kỹ thuật.
  • Lịch phát hành.
  • Mô hình kinh doanh.

Dùng nguyên tắc để tạo giả thuyết và phá thế hòa. Dùng quan sát để kiểm chứng. Dùng quyền quyết định rõ để chốt đánh đổi.

Giới hạn của việc đọc chương này: Hiểu các quy luật và mô hình trong chương giúp người đọc chẩn đoán đúng và đặt câu hỏi đúng. Nó không tạo ra năng lực chạy một buổi usability testing thật với người dùng thật, xử lý phản ứng bất ngờ của stakeholder khi kết quả kiểm thử mâu thuẫn với ý kiến cá nhân của họ, hoặc chịu trách nhiệm khi một quyết định thiết kế gây thiệt hại kinh doanh. Năng lực đó chỉ hình thành qua thực hành lặp lại trên sản phẩm thật.