Máy pha cà phê ở văn phòng có bốn nút bạc, cùng kích thước, cùng vẻ tự tin, và gần như không nút nào nói rõ điều gì sẽ xảy ra sau khi bấm. Một nút pha espresso. Một nút cho nước nóng. Một nút bắt đầu vệ sinh máy. Một nút không tạo phản hồi rõ ràng trong vài giây đầu, đủ lâu để một bạn mới vào team bấm thêm lần nữa và tạo ra một sự cố nhỏ trên mặt bàn.
Khoảnh khắc đó đủ đời thường để thấy buồn cười, nhưng cũng là tinh thần của The Design of Everyday Things. Don Norman không chỉ nói về cửa, công tắc hay máy pha cà phê. Ông nói về một giao ước lặng lẽ giữa đồ vật và người đang cố dùng nó: đồ vật nên đưa ra đủ manh mối để một người bình thường có thể đoán được hành động tiếp theo mà không thấy mình ngớ ngẩn.
Bài viết này là reflection cá nhân từ The Design of Everyday Things của Don Norman, bản revised and expanded do Basic Books xuất bản năm 2013. Tác phẩm ban đầu từng được biết với tên The Psychology of Everyday Things. Em dùng cuốn sách như một lăng kính cho công việc software và product, không tóm tắt tuần tự từng chương.
Sản phẩm không nên bắt người dùng đoán
Một từ rất hữu ích trong sách là discoverability: người dùng có thể nhìn vào một thứ và tự khám phá những hành động nào đang có thể làm không? Trong software, friction thường bắt đầu ở đây. Một màn hình có thể hoàn thành về mặt kỹ thuật nhưng lại quá im lặng về hành vi. Button có đó, nhưng state không rõ. Form hợp lệ hay chưa hợp lệ, người dùng không biết. Submit button bị disable, nhưng không ai nói thiếu điều kiện gì. Một setting rất mạnh, nhưng bật lên rồi chuyện gì đổi thì không rõ.
Hãy lấy ví dụ một màn admin để refund đơn hàng. Team có thể nghĩ flow rất rõ: search order, chọn lý do, nhập số tiền, submit. Nhưng một support agent lần đầu nhìn vào màn hình lại có câu hỏi khác. Đây là full refund hay partial refund? Khách hàng có nhận email không? Có hoàn tác được không? Finance có được cập nhật tự động không? Nếu interface không trả lời đúng lúc, người dùng phải dựa vào trí nhớ, tin nhắn Slack hoặc sự liều lĩnh.
Một màn refund rõ hơn nên làm hành vi hiện ra trước cú bấm rủi ro. Primary button có thể ghi “Refund $48.20 về thẻ Visa đuôi 4242”, thay vì chỉ ghi “Submit”. Một khung review nhỏ có thể nói khách hàng có nhận email không, finance có được thông báo không, refund có hủy được không, và audit note nào sẽ được lưu. Ví dụ nhỏ này cho thấy copy, state và layout đều là một phần của độ an toàn hệ thống.
Bài học của Norman nhẹ nhàng nhưng khó tính: nếu người dùng phải đoán quá nhiều, thiết kế đã đẩy phần việc của mình sang họ. Đôi khi expert tool có thể phức tạp, nhưng kể cả expert tool cũng cần cấu trúc nhìn thấy được. Một console chạy database migration có thể phức tạp. Nó không nên bí hiểm.
Signifier là ngôn ngữ của hành vi
Norman tách điều có thể làm khỏi điều giúp người dùng biết là có thể làm. Với đồ vật vật lý, tay nắm gợi ý kéo, tấm phẳng gợi ý đẩy. Trong software, signifier có thể là label, hình dạng button, cursor change, disabled state, placeholder, empty state, cách layout tạo affordance, và cả vị trí của một hành động trên màn hình.
Một lỗi quen thuộc là nhầm visual cleanliness với clarity. Team bỏ label, giấu secondary action sau icon, giảm contrast, làm mọi thứ trông rất nhẹ trong mockup. Nhưng khi màn hình tới tay người dùng thật, sự nhẹ đó biến thành im lặng. Người dùng hover thử, mở menu chỉ để xem bên trong có gì, rồi hỏi support nút thao tác nằm ở đâu.
| Signifier yếu | Người dùng có thể tự hỏi | Cách thiết kế rõ hơn |
|---|---|---|
| Submit button bị disable không lý do | Trang bị lỗi, hay mình còn thiếu field nào? | Hiển thị validation gần field thiếu và nói rõ điều kiện còn thiếu. |
| Icon-only cho hành động nguy hiểm | Nút này xóa, archive, hay chỉ ẩn item? | Dùng label rõ, hierarchy mạnh hơn và có đường khôi phục. |
| Card bấm được nhưng nhìn như nội dung tĩnh | Mình mở được, chọn được, hay chỉ đọc được? | Có hover state, focus state, cursor và vùng action nhìn thấy được. |
| Toggle với copy trừu tượng | Bật lên thì hệ thống đổi điều gì? | Mô tả hành vi cụ thể và hiển thị state mới sau khi đổi. |
Một ví dụ thực tế là setting billing tên “smart retry”. Engineer có thể biết nó nghĩa là payment thất bại sẽ được retry ba lần trong bảy ngày. Khách hàng thì không. Một màn hình tốt hơn nên nói điều gì sẽ xảy ra, khi nào xảy ra, khách hàng có được thông báo không, và người dùng dừng cơ chế đó bằng cách nào. Signifier không phải trang trí. Nó là một phần hành vi của sản phẩm.
Mapping là cách interface giữ lời hứa
Mapping là quan hệ giữa control và kết quả của nó. Một bếp có bốn núm vặn xếp giống vị trí bốn vùng nấu thì dễ dùng hơn, vì layout vật lý dạy người dùng mối quan hệ đó. Software cũng có cùng vấn đề, chỉ là ít hữu hình hơn.
Một dashboard có filter phía trên và chart phía dưới quen thuộc vì mapping theo không gian khá dễ đoán. Đổi filter, chart đổi. Nhưng hãy tưởng tượng một màn permission, checkbox bên trái ảnh hưởng tới một preview bị giấu trong tab bên phải. Control có thể chạy hoàn hảo trong code, nhưng người dùng không xây được cây cầu tinh thần giữa hành động và kết quả.
Mapping tốt làm giảm gánh nặng trí nhớ. Một deployment screen nên làm environment, branch, version và impact liên hệ với nhau một cách nhìn thấy được. Nếu production và staging nhìn gần như giống hệt, slip nhỏ dễ xảy ra hơn. Nếu action production được tách rõ, dùng màu có chừng mực, label rõ và bắt người dùng review đúng version, interface đang nhớ giúp người dùng một phần.
Khi ai đó thay đổi một control, họ có thấy ngay phần nào của hệ thống sẽ đổi, state hiện tại là gì, và nếu thao tác sai thì quay lại bằng cách nào không?
Feedback là sự tôn trọng dành cho sự chú ý
Feedback nói với người dùng rằng hệ thống đã nghe họ. Nó không cần ồn ào. Thật ra feedback quá nhiều lại thành một dạng rối khác. Nhưng không có feedback thì người dùng bị treo giữa hành động và đánh giá, nơi những cú click lặp lại, duplicate submission và ticket support thường bắt đầu.
Một payment form là ví dụ dễ thấy. Sau khi bấm “Pay”, interface tệ nhất trở nên im lặng. Button vẫn nhìn như bấm được, trang không đổi, người dùng không biết payment có đang xử lý không. Interface tốt hơn sẽ disable button, hiển thị tiến trình, nói rõ không nên đóng trang, rồi đưa ra trạng thái cuối cùng rõ ràng. Nếu lỗi xảy ra, error message nên nói điều gì đã xảy ra, tiền đã đi chưa, và hành động an toàn tiếp theo là gì.
Feedback cũng quan trọng trong công cụ nội bộ của team. CI dashboard không nên chỉ nói “failed”. Nó nên chỉ ra stage nào fail, check nào fail, ai có khả năng xử lý và log nào liên quan. Feature flag console không nên chỉ nói “saved”. Nó nên cho biết environment nào đã đổi và state mới có hiệu lực khi nào. Các chi tiết này nghe nhỏ cho tới khi team đang mệt và release đã gần.
Conceptual model định hình niềm tin
Ý mạnh nhất trong sách, với em, là conceptual model. Con người luôn mang trong đầu một cách giải thích hệ thống đang hoạt động như thế nào. Mô hình đó có thể thiếu, nhưng nó hướng dẫn mọi hành động. Nếu mô hình sai, kể cả người dùng cẩn thận cũng có thể ra quyết định sai.
Software thường tạo conceptual model yếu khi chi tiết implementation rò ra interface. Một công cụ sync file có thể hiển thị “syncing” mà không nói file đang local, remote, conflict hay đang chờ mạng. Người dùng buộc phải tự phát minh mô hình: có lẽ file an toàn, có lẽ chưa. Hành động tiếp theo dựa trên phỏng đoán đó.
Product team có thể giúp bằng cách làm system image nhất quán. Tên gọi, state, flow, empty screen, confirmation message và support docs nên kể cùng một câu chuyện. Nếu sản phẩm gọi “workspace” ở một nơi, “organization” ở nơi khác và “team” ở nơi thứ ba, người dùng không chỉ học ba từ. Họ có thể học ba mô hình tinh thần khác nhau và không biết mô hình nào quyết định billing, permission hay ownership dữ liệu.
| Khu vực hệ thống | Conceptual model yếu | Mô hình rõ hơn |
|---|---|---|
| Publish bản nháp | “Saved”, “submitted”, “published” xuất hiện như các label rời. | Cho thấy đường trạng thái đơn giản: draft, in review, scheduled, live, archived. |
| Team permission | Role, seat và billing owner bị trộn trên một màn. | Tách access, billing và ownership, đồng thời chỉ ra chúng liên hệ thế nào. |
| Import dữ liệu | Người dùng upload file rồi chờ mà không biết validation ra sao. | Hiển thị upload, validation, mapping, preview, commit và rollback thành từng bước. |
Đây là lúc design vượt khỏi chuyện đánh bóng bề mặt. Interface đang dạy logic của sản phẩm. Nếu nó dạy một câu chuyện rối, người dùng sẽ hành động từ sự rối đó. Nếu nó dạy một câu chuyện ổn định, người dùng có thể tự tin hơn.
Đặt tri thức vào môi trường, đừng bắt người dùng nhớ hết
Norman phân biệt knowledge in the head và knowledge in the world. Thiết kế tốt không bắt con người nhớ mọi quy tắc. Nó đặt đủ thông tin vào môi trường để hành động tiếp theo dễ suy ra hơn.
Trong software, điều này có thể đơn giản như giữ field requirement luôn nhìn thấy được, đặt ví dụ cạnh input, giữ breadcrumb trong quy trình nhiều bước, hoặc hiển thị activity gần đây bên cạnh một setting rủi ro. Nó cũng có thể là default phản ánh đường đi phổ biến và an toàn nhất. Người dùng không nên phải nhớ từ tháng trước rằng CSV import cần date theo ISO format. Màn hình có thể đưa ví dụ và validate trước khi upload.
Điều này đặc biệt quan trọng với những công cụ được dùng dưới áp lực: incident console, finance workflow, màn healthcare, legal review system, production deploy tool. Người dùng các công cụ này thường bị gián đoạn, mệt, hoặc phải nhảy giữa nhiều việc. Interface tốt nên mang giúp họ một phần trí nhớ.
Những điều đọng lại
- Discoverability là công việc sản phẩm. Một màn hình nên cho thấy hành động nào có thể làm mà không bắt người dùng săn tìm.
- Signifier không phải trang trí. Label, state, vị trí và chuyển động đều đang nói sản phẩm hành xử thế nào.
- Mapping làm nhẹ trí nhớ. Control nên nằm gần kết quả nó tạo ra, nhất là trong workflow rủi ro.
- Feedback ngăn sự lặp lại vì lo lắng. Hệ thống nên xác nhận hành động và làm rõ bước an toàn tiếp theo.
- Conceptual model định hình niềm tin. Naming, state, flow và documentation nên dạy một câu chuyện sản phẩm nhất quán.
- Thiết kế tốt đặt tri thức vào thế giới. Ví dụ, validation, breadcrumb và default an toàn giảm lượng thông tin người dùng phải nhớ.
Điều còn ở lại với em từ The Design of Everyday Things không chỉ là cửa nên nhìn ra được đẩy hay kéo. Nó là sự khiêm tốn rộng hơn phía sau bài học đó. Khi một người chần chừ, bấm nhầm, hoặc hỏi một câu team thấy quá hiển nhiên, phản ứng đầu tiên không nhất thiết là trách. Nó có thể là tò mò. Sản phẩm đã không nói điều gì? Nó đã dạy mô hình nào? Manh mối nào thiếu đúng lúc quan trọng?
Nhiều sản phẩm tốt hơn được xây từ các chỉnh sửa nhỏ như vậy. Một label rõ hơn. Một state tốt hơn. Một mapping an toàn hơn. Một feedback xuất hiện đúng thời điểm. Những thay đổi yên lặng, nhưng chúng làm interface bớt giống bài kiểm tra và giống một nơi con người có thể suy nghĩ rõ ràng hơn.