Những quy tắc vàng của thiết kế giao diện (2013)
(cs.umd.edu)- 8 nguyên tắc thiết kế giao diện của Ben Shneiderman là các tiêu chí thực tiễn có thể áp dụng cho hầu hết hệ thống tương tác, nhưng cần được kiểm chứng và điều chỉnh tùy theo từng lĩnh vực thiết kế
- Thuật ngữ và hành vi nhất quán, khả năng sử dụng phổ quát, cùng phản hồi giàu thông tin là những điều kiện cơ bản giúp người dùng dự đoán và hiểu được thay đổi trạng thái
- Luồng công việc nên được nhóm thành các đơn vị có điểm bắt đầu, phần giữa và điểm kết thúc; khi hoàn tất cần cung cấp xác nhận rõ ràng để người dùng dễ chuyển sang hành động tiếp theo
- Với lỗi, ưu tiên hàng đầu là phòng ngừa; khi lỗi xảy ra, cần giảm lo lắng cho người dùng bằng hướng dẫn khôi phục cụ thể và khả năng hoàn tác dễ dàng
- Khi đặt cảm giác kiểm soát và giảm gánh nặng ghi nhớ làm trọng tâm, có thể nâng cao năng suất và cảm giác thành thạo trên giao diện di động, desktop và web
Tính chất của các nguyên tắc và phạm vi áp dụng
- Ben Shneiderman đã cô đọng khối kiến thức rộng lớn về thiết kế giao diện người dùng thành một số Golden Rules, tạo thành bộ hướng dẫn có thể áp dụng cho hầu hết hệ thống tương tác
- Các nguyên tắc này xuất phát từ kinh nghiệm và đã được tinh chỉnh trong hơn 30 năm, nhưng trong một số lĩnh vực thiết kế cụ thể vẫn cần kiểm chứng và điều chỉnh riêng
- Danh sách ban đầu năm 1985 cũng được sinh viên và nhà thiết kế xem là hướng dẫn hữu ích; Jakob Nielsen, Jeff Johnson và những người khác đã bổ sung các biến thể và mở rộng
- Phiên bản này là nội dung trong mục 3.3.4 của Designing the User Interface: Strategies for Effective Human-Computer Interaction: Sixth Edition
8 quy tắc vàng trong thiết kế giao diện
-
Theo đuổi sự nhất quán
- Trong các tình huống tương tự, cần có trình tự hành động nhất quán
- Nên dùng cùng một thuật ngữ trong lời nhắc, menu và màn hình trợ giúp
- Màu sắc, bố cục, cách dùng chữ hoa và phông chữ cũng cần nhất quán trên toàn bộ giao diện
- Các ngoại lệ như xác nhận lệnh xóa hoặc không hiển thị khi nhập mật khẩu phải dễ hiểu và có giới hạn
-
Theo đuổi khả năng sử dụng phổ quát
- Cần nhận diện nhu cầu của nhiều nhóm người dùng và thiết kế linh hoạt để dễ chuyển đổi nội dung
- Khác biệt giữa người mới và chuyên gia, nhóm tuổi, khuyết tật, khác biệt quốc tế và sự đa dạng công nghệ làm mở rộng phạm vi yêu cầu
- Phần giải thích cho người mới, phím tắt và chức năng thao tác nhanh cho chuyên gia giúp nâng cao nhận thức về chất lượng giao diện
-
Cung cấp phản hồi giàu thông tin
- Mọi hành động của người dùng đều nên đi kèm phản hồi từ giao diện
- Với các hành động nhỏ thường xuyên xảy ra, phản hồi đơn giản là đủ; nhưng với các hành động hiếm và quan trọng, cần phản hồi thực chất hơn
- Việc trình bày trực quan đối tượng đang được quan tâm giúp dễ thể hiện rõ các thay đổi
-
Thiết kế luồng đối thoại tạo cảm giác hoàn tất
- Trình tự công việc nên được tổ chức thành các nhóm có điểm bắt đầu, phần giữa và điểm kết thúc
- Phản hồi giàu thông tin khi một nhóm công việc kết thúc mang lại cảm giác đạt được, yên tâm và tín hiệu sẵn sàng cho công việc tiếp theo
- Trên website thương mại điện tử, ví dụ là luồng đi từ chọn sản phẩm sang thanh toán và kết thúc giao dịch bằng một trang xác nhận rõ ràng
-
Phòng ngừa lỗi
- Cần thiết kế giao diện sao cho, trong khả năng có thể, người dùng không thể tạo ra lỗi nghiêm trọng
- Ví dụ gồm vô hiệu hóa các mục menu không phù hợp hoặc không cho phép nhập ký tự chữ cái vào trường nhập số
- Khi lỗi xảy ra, cần cung cấp hướng dẫn khôi phục đơn giản, mang tính xây dựng và cụ thể
- Không nên bắt người dùng nhập lại toàn bộ biểu mẫu tên và địa chỉ chỉ vì một mã bưu chính sai; hãy hướng dẫn họ chỉ sửa phần sai
- Hành động sai không nên làm thay đổi trạng thái giao diện, hoặc phải cung cấp kèm cách khôi phục trạng thái
-
Cho phép hoàn tác dễ dàng
- Trong khả năng có thể, các hành động nên có thể hoàn tác
- Hoàn tác giúp giảm lo lắng bằng cách tạo cho người dùng niềm tin rằng họ có thể hủy lỗi, đồng thời khuyến khích họ khám phá cả những lựa chọn chưa quen
- Đơn vị hoàn tác có thể là một hành động đơn lẻ, một tác vụ nhập dữ liệu, hoặc một nhóm công việc như khối tên và địa chỉ
-
Duy trì quyền kiểm soát cho người dùng
- Người dùng thành thạo rất muốn cảm thấy rằng họ đang kiểm soát giao diện và giao diện phản ứng với hành động của họ
- Những thay đổi bất ngờ, thay đổi trong thao tác quen thuộc, nhập dữ liệu nhàm chán, khó lấy thông tin cần thiết, hoặc không thể tạo ra kết quả mong muốn đều khiến người dùng khó chịu
-
Giảm gánh nặng cho trí nhớ ngắn hạn
- Khả năng xử lý thông tin của trí nhớ ngắn hạn ở con người là có giới hạn; theo kinh nghiệm, con người có thể nhớ khoảng “7±2 chunks”
- Nên tránh các giao diện buộc người dùng phải ghi nhớ thông tin ở một màn hình rồi dùng lại ở màn hình khác
- Điện thoại di động không nên yêu cầu nhập lại số điện thoại, vị trí trên website phải luôn được hiển thị, và các biểu mẫu dài nên được nén để vừa trong một màn hình
Tiêu chí thực tiễn dành cho nhà thiết kế
- Các nguyên tắc này cần được diễn giải, tinh chỉnh và mở rộng cho phù hợp với từng môi trường
- Dù có giới hạn, chúng là điểm khởi đầu tốt cho nhà thiết kế giao diện di động, desktop và web
- Nhập dữ liệu được đơn giản hóa, hiển thị dễ hiểu, cùng phản hồi nhanh và giàu thông tin tập trung vào việc nâng cao năng suất của người dùng
- Một giao diện tốt nên giúp người dùng cảm thấy có năng lực, thành thạo và kiểm soát được hệ thống
1 bình luận
Ý kiến trên Hacker News
Dù thường không được xem là phần bắt buộc của "thiết kế" UI, hiệu năng cũng hay bị bỏ qua
Một UI chậm chạp thì coi như vi phạm toàn bộ các quy tắc thiết kế này. Smart TV Sony Android của tôi nhìn thì rất đẹp nhưng UI quá chậm, gần như không thể dùng nổi
Một UI thiếu ổn định, cứ liên tục thay đổi, cũng đi ngược lại hầu hết các nguyên tắc. Smart TV đặc biệt tệ ở điểm này nữa, khi bố cục màn hình chính và vị trí biểu tượng ứng dụng thường xuyên thay đổi mà chẳng có lý do rõ ràng
Thêm một nỗi bực bội cá nhân ngày càng lớn của tôi là icon không có nhãn. Nhiều khi còn chẳng có tooltip, và nếu phải lên Google tài liệu chỉ để biết tên một nút thì đó là UI tệ
Người trẻ đổ xô vào những giao diện khó dùng, và chính sự khó hiểu đó hoạt động như một đặc quyền nội bộ để loại trừ thế hệ cha mẹ
Nhà thiết kế giỏi sẽ trao đổi với lập trình viên về việc UI mà họ đề xuất ảnh hưởng thế nào đến hiệu năng, và giúp cân bằng khi phía kỹ thuật phải đưa ra các quyết định mà người dùng có thể cảm nhận được
Không chỉ có hàng trăm icon nhỏ trong UI, mà tài liệu hướng dẫn cũng dùng y nguyên các icon đó. Kiểu như manual viết "đầu tiên bấm vào [], tiếp theo nhấn [], cuối cùng vào [] rồi làm []"
Đây là chuyện từ những phiên bản rất đầu của V5 nên cũng lâu rồi, hy vọng giờ đã khá hơn
Còn lại hầu như đều gần với chuyện coding
Mỗi sáng tôi đều nghe hai podcast tin tức giống nhau, nhưng các mục gợi ý trong app cứ bị xáo trộn vô cớ vào mỗi sáng
Điều còn khó chịu hơn là lúc khởi động app, nó thoáng hiện bố cục của hôm qua, rồi đứng khựng khoảng 1 giây để tải, sau đó sắp xếp lại các mục. Khoảnh khắc các mục di chuyển đó khiến tôi liên tục bấm nhầm, cực kỳ bực bội
Một nhà thiết kế tôi từng làm việc cùng vài năm trước đã giải thích rất hay vì sao tính nhất quán lại quan trọng
Không phải chuyện bảng màu bị giới hạn hay chọn font mà chẳng ai để ý. Nếu cứ chăm chăm theo các quy tắc chi tiết đó thì sẽ tạo ra phần mềm khủng khiếp. Có người lầm tưởng rằng UI càng ít đa dạng thì càng nhất quán
Cốt lõi là giúp người dùng trở thành chuyên gia của phần mềm đó
Nhà thiết kế ấy lấy Microsoft Office làm ví dụ. Mọi người tự hào rằng mình "biết" Microsoft Office, và cảm nhận được quán tính của "Office", nên có thể chuyển qua lại giữa các ứng dụng một cách tự nhiên. Tôi cũng có cảm giác y như vậy với Vim. Tôi просто biết thứ gì nên hoạt động như thế nào, và plugin mới được làm tốt thường tôn trọng các mẫu đó
Office và (Neo)Vim không hẳn là ví dụ về UI xuất sắc, nhưng chúng đặc biệt ổn định
Ví dụ, khi đưa ra bốn lựa chọn, bạn có thể dùng combobox các mục có thể tìm kiếm từ [Insert UI Library] với theme thương hiệu, hoặc chỉ đơn giản hiển thị radio button hay checkbox thường có gắn nhãn. Cách sau tốt hơn về mọi mặt
Người dùng chỉ cần nhìn hình tròn và hình vuông là biết đây là chọn một hay chọn nhiều, họ thấy được cả bốn lựa chọn, bàn phím di động cũng không tự bật lên để "tìm kiếm" rồi che thêm màn hình nhỏ, và khả năng truy cập gần như lúc nào cũng sát 100%
Nhưng lựa chọn đó lại thua ở tiêu chí "trông dễ thương với design system của chúng ta", nên designer thường chọn cách đầu tiên, tệ hơn nữa là chuẩn hóa nó đến mức dùng widget thông thường bị xem như một "bug"
Kết cục là quá nhiều "UX designer" tôn thờ thẩm mỹ và branding rồi hy sinh mọi thứ khác. UI widget không phải nơi để thể hiện thương hiệu hay sự sáng tạo, cũng giống như việc bạn không nên tạo một font riêng buộc mọi ký tự phải trông như logo. Khách hàng quan tâm đến việc họ có hoàn thành công việc được hay không hơn là thương hiệu
Nó phá hỏng nghiêm trọng khả năng tìm ra tính năng cần dùng
Lúc nào cũng đặc biệt khi nhìn một người không nghĩ mình giỏi công nghệ lại thao tác cực nhanh trong Excel
Các quy tắc thiết kế UI của Microsoft khá đáng nể. Nhờ nhiều năm nhất quán, người ta vẫn có thể tiếp tục dùng phần mềm kể cả khi chỉ nâng cấp mỗi 1-2 năm một lần. Tôi không nói vậy vì là fan Microsoft
Cốt lõi của nâng cấp là thay đổi dần dần để cải thiện UX. Tuy nhiên tôi không hiểu vì sao khi Win 95 đưa vào khái niệm "nhấp chuột phải ở bất cứ đâu để xem thuộc tính và cài đặt sâu hơn/thông tin chi tiết", đội thiết kế lại không phản đối. Vì đó là một tính năng vô hình, không hề cho người dùng biết chỗ nào có thể nhấp chuột phải. Có vẻ như trong vài lần đầu dùng Win 95, hầu như chẳng ai hiểu chuyện nhấp chuột phải
Tôi đồng ý rằng độ thành thạo có liên quan, nhưng có lẽ cần nối rõ hơn vì sao tính nhất quán lại dẫn đến độ thành thạo
Tính nhất quán là việc những gì người dùng đã biết về hệ thống sẽ được mở rộng theo kiểu lãi kép sang các phần khác của hệ thống. Nếu hệ thống nhất quán, công sức học X và Y sẽ giúp họ hiểu luôn cả Z và W, vì chúng sẽ hoạt động theo cùng một cách. Với hệ thống thiếu nhất quán, giá trị thu được từ khoản đầu tư học trước đó giảm đi rất nhiều
Ít nhất về lâu dài thì Office không hề ổn định. Ribbon tai tiếng là một bước lệch buồn từ UI Word vốn ổn định và hiệu quả, và sự thụt lùi khó hiểu của Microsoft trên toàn bộ nền tảng Windows còn làm vấn đề tệ hơn. Ví dụ như việc loại bỏ thanh menu khỏi ứng dụng. Tôi thật sự không hiểu tại sao họ lại làm vậy
Một “quy tắc” nữa nên được thêm vào là bộc lộ mô hình khái niệm cho người dùng
Nếu không hiểu mô hình khái niệm của sản phẩm, thì dù nhãn biểu tượng có được đặt tốt đến đâu, người dùng vẫn sẽ luôn bối rối. Ví dụ, hãy tưởng tượng một sản phẩm có lệnh "New Configuration"; trước hết đã không rõ "Configuration" là gì. Đó là một mẫu để định nghĩa đối tượng khác sao? Một cách để chuyển nhanh giữa nhiều nhóm tùy chọn sao? Hay là một vùng chứa kiểu thư mục?
UI nên được thiết kế để người dùng có thể suy ra mô hình khái niệm chỉ bằng cách khám phá giao diện. Điều này không phải lúc nào cũng dễ
Phần nói rằng "ví dụ khi người dùng nhập sai mã bưu chính, đừng bắt họ nhập lại toàn bộ biểu mẫu tên-địa chỉ, mà hãy hướng dẫn họ chỉ sửa phần sai" là điểm gây khó chịu lớn nhất, và đến giờ vẫn rất hay gặp
Nguyên tắc này cũng phải được giữ trong các biểu mẫu nhiều trang khi di chuyển qua lại giữa các bước
Câu "một thao tác sai không được làm thay đổi trạng thái giao diện, và nếu đã thay đổi thì phải chỉ cho người dùng cách khôi phục trạng thái ban đầu" cũng rất quan trọng
Trên các màn hình nhỏ như điện thoại và đồng hồ, các nhà thiết kế ngày càng phụ thuộc nhiều hơn vào biểu tượng để tiết kiệm không gian. Nhưng nhiều biểu tượng thì xa lạ hoặc khó diễn giải, đôi khi chỉ có bấm thử mới biết. Với những biểu tượng như vậy, nhất định phải có cách quay lại trạng thái ban đầu nếu lỡ thao tác sai
Việc này đã phiền rồi khi đăng nhập bằng địa chỉ email và mật khẩu, nhưng nếu tôi đã bấm "quên mật khẩu" thì đừng đưa tôi tới một biểu mẫu bắt nhập lại chính địa chỉ email tôi vừa gõ
Câu "hãy làm mờ các mục menu không phù hợp" có điều kiện đi kèm
Nếu lý do bị làm mờ không rõ ràng thì không nên làm vậy. Hãy cứ để lệnh ở trạng thái khả dụng, và nếu khi bấm vào nó hiện tại chưa dùng được thì hãy giải thích bằng thông báo lỗi vì sao chưa dùng được. Bắt người dùng tự tìm ra tại sao lệnh bị vô hiệu hóa là điều rất bực bội
Ngoại lệ là khi nhiều khả năng người dùng sẽ phải lãng phí rất nhiều thời gian đến tận cuối mới bị báo là không thể dùng
Bài liên quan để đọc thêm: https://medium.com/@vedranio/james-bond-and-the-design-of-di...
Cách đó có vẻ như lấy được ưu điểm của cả hai bên
Có một ứng dụng việc cần làm làm thế này. Các lệnh premium không khác biệt gì về mặt hình ảnh so với lệnh miễn phí, nên tôi cứ hay bấm vào, và mỗi lần như vậy lại hiện một hộp thoại mời đăng ký làm đứt quãng toàn bộ luồng thao tác
Theo tôi đó là một lỗi UI nghiêm trọng
Những UI chỉ vô hiệu hóa một hành động nào đó mà không cho biết lý do thì lúc nào cũng làm tôi bực mình
10 heuristic về khả năng sử dụng của Nielsen là một ngôi sao Bắc Cực rất tốt
https://www.nngroup.com/articles/ten-usability-heuristics/
Trang NN giúp tiếp thu thông tin dễ hơn nhiều, ngắn gọn hơn, và bố cục trang cũng tốt hơn hẳn
Cả hai bài đều chứa thông tin và định hướng đáng để lắng nghe, nhưng thật mỉa mai khi trang gốc lại áp dụng kiểu quy ước cũ mà trang NN đã bỏ đi như cỡ chữ đồng nhất và cách chia đoạn văn
Tôi cũng thấy bực khi Hacker News không làm theo một phần thông tin này. Khi sửa một bài đăng hiện có, sau khi bấm nút "update" thì phản hồi không đủ rõ ràng. Có lẽ nó chỉ redraw lại màn hình
Cần chấm dứt kiểu UI khiến người dùng bấm nhầm bằng cách chèn thứ khác đúng vào chỗ họ sắp chọn
Có thể đây là chuyện vi phạm hoặc có thể giảm nhẹ bằng một số quy tắc ở trên, nhưng cá nhân tôi thấy nó thật sự phát điên, và là một lỗi đặc biệt nghiêm trọng
Có một quy tắc quan trọng bị thiếu. Nó từng có vẻ quá hiển nhiên, đó là phải phân biệt thông tin tĩnh với yếu tố có thể thao tác
Ngoài ra, các yếu tố thao tác không áp dụng được thì không nên ẩn đi mà nên làm mờ. Như vậy người dùng sẽ biết tính năng đó tồn tại, nó ở đâu, và cần đáp ứng điều kiện gì để dùng được
Liên quan đến đó, tuyệt đối không được phụ thuộc vào kiểu UI trốn tìm chỉ hiện ra thứ gì đó khi người dùng tình cờ rê con trỏ qua. Người ta đang cố hoàn thành công việc, chứ không phải đi khám phá một Advent calendar
Một quy tắc vàng mà tôi học được là sau khi giao diện đã được vẽ xong thì các yếu tố không được di chuyển ngoài dự kiến
Google đặc biệt tệ ở chuyện nút di chuyển trong khoảng từ lúc bạn giơ ngón tay cái lên đến lúc chạm vào màn hình, nhưng không chỉ mình Google như vậy
Nếu mục tiêu mới xuất hiện trong vòng khoảng 0,25 giây trước khi bị chạm, thì không nên tạo sự kiện chạm. Vì xét theo tốc độ phản ứng của con người, không thể nào nhắm và bấm một nút nhanh đến thế được đâu
Đây rõ ràng là những quy tắc vàng của một thế giới không tưởng
Hầu hết mọi người sẽ không phản đối các quy tắc này
Thế nhưng, đa số lập trình viên hẳn đã từng làm việc với các giao diện thường xuyên vi phạm những quy tắc đó. Không phải vì họ không hiểu hoặc không muốn, mà vì chi phí tại thời điểm ấy quá lớn
Ví dụ, có thể hoàn tác là điều rất khó, và chỉ khả thi khi cấu trúc dữ liệu bên dưới ứng dụng ngay từ đầu đã được xây dựng với điều đó trong đầu. Việc phòng ngừa lỗi cũng tương tự: bản thân việc biết chính xác thế nào là lỗi đã khó và tốn kém, còn việc cung cấp phản hồi hoàn hảo bằng ngôn ngữ của người dùng thì còn phức tạp hơn nhiều