Hãy khôi phục thiết kế theo quy ước

 (essays.johnloeber.com)
1 điểm bởi GN⁺ 11 ngày trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Quy ước thiết kế mà người dùng có thể hiểu ngay lập tức giúp giảm gánh nặng học tập và cho phép tương tác nhất quán
  • Trong thời đại phần mềm desktop trước đây, nhờ hệ điều hành và các guideline, giao diện như cấu trúc menu hay phím tắt được thống nhất
  • Ngược lại, trong thời đại phần mềm dựa trên trình duyệt, sự lan rộng của framework và các cách triển khai tùy biến đã khiến tính nhất quán của giao diện sụp đổ
  • Apple và Substack cho thấy những ví dụ thành công của quy ước hiện đại thông qua khả năng tùy biến bị giới hạn và hệ thống thiết kế thống nhất
  • Nhà thiết kế sản phẩm nên tuân theo các quy ước sẵn có, ưu tiên sự rõ ràng và nhất quán để hướng tới trải nghiệm người dùng được chuẩn hóa trên toàn web

Quy ước thiết kế

  • Checkbox được nêu như một quy ước thiết kế tiêu biểu mà người dùng có thể hiểu ngay mà không cần học thêm
    • Với câu hỏi có muốn duy trì trạng thái đăng nhập hay không, có thể có nhiều cách nhập khác nhau, nhưng trên thực tế gần như luôn dùng checkbox
    • Đây hoạt động như một mẫu tương tác chuẩn hóa quen thuộc với cả người dùng lẫn nhà phát triển

Giao diện đồng nhất

  • Giao diện là phương tiện để người dùng tương tác với hệ thống, và giao diện càng ít khiến người dùng phải suy nghĩ thì càng tốt
    • Ví dụ, chức năng sao chép bằng phím tắt Command+C phải hoạt động giống nhau ở mọi nơi
  • Tuy nhiên, trong môi trường phần mềm web hiện nay, tính nhất quán của giao diện đã biến mất
    • Ngay cả những chức năng cơ bản như chọn ngày hay nhập số thẻ cũng được triển khai khác nhau ở từng website
    • Phím tắt và cách tương tác khác nhau giữa các ứng dụng, khiến người dùng lần nào cũng phải học lại “bấm ở đâu, làm gì”

Thời đại phần mềm desktop

  • Phần mềm desktop trong giai đoạn Windows 95~7 duy trì mức độ nhất quán giao diện rất cao
    • Cấu trúc menu “File, Edit, View” hiện diện giống nhau trong mọi chương trình
    • Gạch chân dưới các mục menu biểu thị phím tắt bàn phím, có thể thao tác bằng ALT+F, N...
    • Thanh trạng thái (status bar) ở dưới cùng hiển thị rõ trạng thái hiện tại như trang, số từ, chế độ...
    • Giao diện tập trung vào menu dạng văn bản, chỉ dùng biểu tượng khi chúng mang ý nghĩa rõ ràng
  • Những quy ước này được thống nhất không chỉ trong Microsoft Word mà trên toàn bộ hệ sinh thái Windows
    • Ngay cả ở màn hình đăng xuất của Windows XP, mọi nút đều được thể hiện trực quan là nút bấm và có hiển thị phím tắt
  • Sự nhất quán này có được nhờ các ràng buộc của hệ điều hành và thư viện GUI, đồng thời Microsoft phát hành guideline thiết kế dài hàng trăm trang để khuyến khích nhà phát triển tuân theo

Thời đại phần mềm trình duyệt

  • Kỷ nguyên ứng dụng web hiện nay được mô tả là thời đại của giao diện dị biệt
    • Ngay cả những web app xuất sắc như Figma hay Linear cũng không có bộ biểu tượng hay phím tắt chung
    • Mỗi ứng dụng đều được thiết kế tốt theo cách riêng, nhưng lại có mẫu tương tác khác nhau
    • Ngay trong cùng một công ty, trải nghiệm giữa Gmail, GSuite và Google Docs cũng khác nhau
    • Kết quả là người dùng dành thời gian tìm chỗ để thao tác thay vì ở trong trạng thái dòng chảy năng suất (flow)

  • Ảnh hưởng của quá trình chuyển sang mobile

    • Sự xuất hiện của màn hình cảm ứng khiến các mẫu thiết kế xoay quanh chuột và bàn phím phải được phát minh lại
    • Trong bối cảnh phải hỗ trợ đồng thời mobile và desktop, những UI trung gian không hoàn chỉnh lan rộng
    • Ví dụ: menu hamburger dành cho mobile vẫn được dùng nguyên trên desktop
    • Văn hóa tái sử dụng component mô-đun sao chép cả những mẫu sai, dẫn đến suy giảm chất lượng
    • Sau hơn 10 năm tích lũy, điều này gây ra sự xói mòn chất lượng UI/UX qua nhiều thế hệ

  • Sự thiếu vắng quy ước vượt ra ngoài HTML

    • Ở web thời kỳ đầu, từng có những quy ước rõ ràng như liên kết màu xanh có gạch chân, nhưng nay mỗi site lại có style riêng
    • Chuẩn HTML/CSS thì nghiêm ngặt, nhưng thực tế phần lớn đều dùng hệ thống build dựa trên React·TypeScript
    • Kết quả là các triển khai tùy biến thay cho phần tử HTML chuẩn xuất hiện tràn lan, kéo theo cả vấn đề accessibility
    • Ví dụ: dùng <span> có gắn onclick thay cho <a> làm hỏng chức năng của screen reader
    • Cũng có những ứng dụng như Figma dựa trên WebAssembly và hoàn toàn rời khỏi HTML
    • Các chức năng mặc định của trình duyệt như nút quay lại, phím tắt... bị phớt lờ, và một mô hình tương tác người-máy mới bị tái cấu trúc
    • Khi frontend phát triển theo hướng tốc độ và khả năng, việc hình thành những quy ước nhất quán trở nên khó khăn
    • Với vô số framework và kiểu tương tác tồn tại song song, đây là môi trường về mặt cấu trúc rất khó thiết lập một chuẩn duy nhất

Những ví dụ thành công của thiết kế theo quy ước

  • Apple được xem là ví dụ tiêu biểu hiện đại duy trì quy ước thiết kế mạnh mẽ
    • Font, nút bấm, màu sắc và toàn bộ hệ thống thiết kế đều thống nhất, mang lại trải nghiệm tương tác nhất quán trên toàn iOS
    • Chính sự nhất quán này tạo nên cảm giác tin cậy “it just works”
  • Substack cũng mang lại trải nghiệm người dùng ổn định nhờ khả năng tùy biến bị giới hạn và các mặc định thẩm mỹ được định sẵn
    • Các nguyên tắc thiết kế của Apple và Substack lan rộng thành chuẩn ngành thông qua thành công của chúng, và cuối cùng trở thành những quy ước mới

Những nguyên tắc nhà thiết kế sản phẩm nên theo

  • Với nhà phát triển sản phẩm, việc tuân theo các quy ước thiết kế hiện có càng nhiều càng tốt được xem là con đường nâng cao tính khả dụng và khả năng tương thích
    • Tuân thủ các quy ước cơ bản của HTML/CSS: liên kết nên được thể hiện bằng gạch chân, màu sắc, con trỏ pointer và thẻ <a>
    • Không tái hiện thực các phần tử HTML cơ bản bằng JavaScript, ví dụ dùng <button> thay vì React Button
    • Tuân thủ các quy ước của trình duyệt: nút quay lại phải hoạt động, sao chép URL phải truy cập được cùng một giao diện, CTRL+click phải mở tab mới
    • Nếu buộc phải rời khỏi quy ước phổ biến, hãy duy trì ít nhất một bộ quy tắc nhất quán trong nội bộ tổ chức
    • Ưu tiên văn bản, tối thiểu hóa biểu tượng, chỉ dùng biểu tượng khi chúng có thể được hiểu một cách phổ quát
    • Với yếu tố thị giác, sự rõ ràng phải được ưu tiên hơn vẻ đẹp thẩm mỹ
    • Khi khó đưa ra phán đoán, hãy tham khảo các website xuất sắc và sách thiết kế giao diện trong quá khứ
  • Cuối cùng, bài viết hướng tới một tương lai nơi bộ chọn ngày hay biểu mẫu nhập thẻ trên mọi website đều hoạt động giống nhau, và đề xuất mục tiêu về một môi trường web hội tụ vào những quy ước tối ưu sau hàng chục năm lặp lại và cải tiến

Bài viết liên quan

1 bình luận

 
GN⁺ 11 ngày trước
Ý kiến trên Hacker News

  • Ở một số ứng dụng, Enter là gửi nội dung còn Ctrl+Enter là xuống dòng (ví dụ: Slack), nhưng ở nơi khác thì lại ngược lại (ví dụ: GitHub)
    Sự thiếu nhất quán này từ góc nhìn người dùng khá gây bối rối. Người ta nói “hãy khôi phục thiết kế theo quy ước”, nhưng vấn đề là bản thân các quy ước chung lại đang thiếu vắng

    • Trước đây Return và Enter là hai phím khác nhau. Return dùng để xuống dòng, Enter dùng để gửi nội dung.
      Giờ thì hai phím đã được gộp làm một, nên nhìn chung trong ô nhập nhiều dòng, Enter là xuống dòng còn Ctrl+Enter là gửi.
      Trong khi đó, ứng dụng chat thường dùng nhập nội dung ngắn nên lại hoạt động theo chiều ngược lại. Ứng dụng tốt sẽ cho phép đổi hành vi này trong phần cài đặt
    • Teams có hai chế độ. Mặc định là Enter để gửi, Shift+Enter để xuống dòng, nhưng khi mở công cụ định dạng thì lại đảo ngược.
      Dù có hiển thị tổ hợp nào dùng để xuống dòng, nó vẫn rất dễ gây nhầm lẫn
    • Slack còn phức tạp hơn. Khi bật Markdown thì Shift+Enter là xuống dòng, nhưng bên trong khối mã (```) thì Enter là xuống dòng còn Shift+Enter là gửi.
      Có thể hiểu được ý đồ, nhưng tính khả dụng thì quá tệ
    • Giải pháp lý tưởng có lẽ là Ctrl+Enter luôn là gửi, Shift+Enter luôn là xuống dòng, còn Enter thì theo mặc định của ngữ cảnh
    • Tôi cũng từng nghĩ Shift+Enter là xuống dòng, và điều này cho thấy UX bị phân mảnh mới là vấn đề

  • Phần mềm ngày nay không còn được tạo ra như trước bởi những nhà thiết kế chu đáo nữa.
    Thay vào đó, nó bị dẫn dắt bởi PM hay người phụ trách Product vừa được đẩy lên vội vàng, thậm chí còn khuyến khích cả dark pattern để kiếm doanh thu

    • Với tư cách kỹ sư mobile, mỗi khi nói với stakeholder rằng “không thể cứ thế làm đúng theo ý tưởng được”, tôi thường nhận lại những ánh mắt ngơ ngác.
      Cần nhấn mạnh tầm quan trọng của tính nhất quán UX và kiến trúc thông tin (IA). Đừng quên rằng designer cũng là người giải quyết vấn đề
    • Kiểu phê phán này quá phiến diện. Trên thực tế, chỉ riêng việc làm một form online thôi cũng đã là địa ngục.
      Ví dụ khi tạo form thẻ tín dụng, có vô số biến số như có cho phép copy/paste hay không, hỗ trợ trình duyệt cũ ra sao, cân bằng giữa accessibility và bảo mật thế nào.
      Tham khảo thêm bài viết về platform của Steve Yegge, nó giải thích rất rõ sự phức tạp này
    • Trong thập niên 2010, các UX designer lành nghề rời đi, còn những designer không chuyên xuất thân từ in ấn hay đồ họa lại tràn vào, khiến chất lượng đi xuống
    • Tất nhiên có cả incentive lệch lạc và tiến độ gấp gáp, nhưng cũng khó quy hết cho sự kém năng lực hay ác ý. Bản thân hệ thống đã thay đổi
    • Ngay cả bây giờ, nhìn PM còn muốn tự tay thiết kế cả kiến trúc tổng thể lẫn lộ trình phát hành thì thấy nhận định này không sai

  • Các framework hệ thống từng là nền tảng tạo ra UI theo quy ước.
    Win32, AppKit, UIKit xử lý đến tận những chi tiết nhỏ, khiến developer tự nhiên đi theo một UX nhất quán.
    Ngược lại, web không có những thứ đó nên cái gì cũng phải tự triển khai, và kết quả là rất nhiều UI nửa vời

    • Tuy vậy, tác giả đã chỉ ra sai về sự thiếu nhất quán của web. “Kỷ nguyên desktop” thực chất gần như là kỷ nguyên Windows, và vì Win32 là mặc định nên ai cũng chỉ việc theo nó.
      Web ngay từ đầu đã xoay quanh tài liệu nên không có cách tiếp cận chuẩn, rồi sau này những thứ như Bootstrap xuất hiện và tạo ra một chuẩn tạm thời
    • HTML và CSS vốn đã có, nhưng ngày nay người ta lách qua bằng WebAssembly và các cách khác.
      Thực ra, bộ chọn ngày hay nhập thẻ nên dùng control HTML mặc định.
      Khi đó trình duyệt có thể cung cấp tính bảo mật và tiện ích ở cấp hệ điều hành (ví dụ: Safari tích hợp Apple Wallet, Android tích hợp Google Pay)
    • Những developer quen với hành vi nhất quán của OS sẽ tự nhiên cố mô phỏng môi trường đó.
      Nhưng web và mobile là những môi trường hộp kín hoàn toàn khác, nên tính nhất quán ấy đã bị phá vỡ.
      Ví dụ đã từng có cơ hội chuẩn hóa thao tác nhấp chuột phải trên desktop thành nhấn giữ trên mobile, nhưng không được thúc đẩy một cách nhất quán
    • Vấn đề gốc rễ của web là nó vẫn mắc kẹt trong mô hình lấy tài liệu làm trung tâm.
      Muốn tạo UI ứng dụng thì phải chồng lên trên UI tài liệu, nên va chạm là điều khó tránh.
      Trình duyệt có giảm bớt phần nào, nhưng đó không phải cải thiện tận gốc
    • Nhân tiện, ngay cả trong AppKit cũng có thể thay đổi chiều cao nút. Chỉ là nó không rõ ràng thôi

  • Bộ chọn ngày thực sự là một cơn ác mộng UX.
    Nhiều nơi chặn người dùng tự nhập ngày rồi ép phải bấm chọn.
    Chỉ cần bắt lỗi nhập sai là đủ, vậy mà vẫn cố làm cho bất tiện

    • Mỗi lần phải lật lịch lùi hàng chục năm để nhập ngày sinh là lại cảm nhận được sự hư vô của đời người
    • Bộ chọn thời gian trên mobile cũng mỗi nơi một kiểu. Có chỗ cuộn một lần từ 12:00 xuống 11:50, có chỗ thì không.
      Bộ chọn kiểu đồng hồ kim có vẻ trực quan hơn nên sẽ tốt nếu nó thành chuẩn
    • Định dạng ngày cũng là vấn đề. 03/04/2026 rất dễ gây nhầm là ngày 3 tháng 4 hay ngày 4 tháng 3.
      Với người dùng quốc tế, định dạng YYYY-MM-DD là an toàn nhất
    • Những website dùng cùng một bộ chọn ngày cho ngày sinh và lịch hẹn tương lai là tệ nhất.
      Bắt người dùng cuộn ngược 50 năm chỉ để thấy mình già đi rõ hơn
    • Việc phải cảm nhận tuổi tác của mình qua mỗi lần cuộn để nhập ngày sinh đúng là như tra tấn

  • Gần đây chất lượng UX xuống cấp nghiêm trọng, đặc biệt thấy rõ ở website ngân hàng.
    Thanh cuộn bị ẩn, khoảng trắng bị lãng phí, nút phẳng, biểu tượng khó hiểu... khiến trải nghiệm còn bất tiện hơn nhiều so với UI desktop ngày trước

    • Thật sự không thể hiểu nổi việc ẩn thanh cuộn. Có vẻ chỉ là vì lý do thẩm mỹ kiểu “trông cho đẹp”
    • Có cảm giác Material UI đã ảnh hưởng xấu đến nhiều ngành.
      GCP hay các công cụ của Google trở nên phức tạp không cần thiết, rồi các ô nhập không viền làm UX tệ đi.
      May là dạo này kiểu phong cách đó đang bị xem là lỗi thời

  • Một trong những khái niệm từ Mac đời cũ là nếu ở cuối chữ trên nút có dấu ba chấm (…) thì nghĩa là vẫn cần thêm đầu vào.
    Ngược lại, nút không có dấu ba chấm sẽ thực thi hành động ngay sau khi bấm

  • Tôi đồng ý với ý “hãy ưu tiên từ ngữ hơn biểu tượng”.
    Với đa số mọi người, tốc độ nhận diện từ ngữ nhanh hơn biểu tượng

    • Tất nhiên, biểu tượng mô tả vật thể thật thì vẫn ổn, nhưng dạo này có quá nhiều biểu tượng trừu tượng, kiểu nét mảnh.
      Nếu không có chú thích chữ thì cứ như chơi cò quay Nga, phải bấm thử mới biết nghĩa là gì
    • Như trường hợp “unvote/undown” trên HN, vì cùng chung tiền tố nên rất dễ nhầm. Mỗi lần bấm lại phải nhìn lại lần nữa
    • Nếu biểu tượng nhỏ hoặc vị trí thay đổi thường xuyên thì từ ngữ tốt hơn, còn trong môi trường cố định thì biểu tượng có thể nhanh hơn

  • Gần đây tôi phát hiện ra một công nghệ mới tên là CSS, cho phép định nghĩa layout theo kiểu khai báo và áp dụng style phân cấp dựa trên DOM.
    Nó giúp giảm tải cho client và server, đồng thời dễ chia sẻ stylesheet hay tạo theme tùy biến cho người dùng.
    Tôi muốn gọi đây là mô hình UI “no-framework”
    Ảnh ví dụ

    • Tôi đã thử rồi và đó đúng là cơn ác mộng. Không thể biết style nào đang áp dụng ở đâu, chỉ cần cấu trúc DOM đổi là style vỡ tung.
      Hơn nữa, chuyện “giảm tối đa tải phía client” chỉ là huyền thoại. Thực tế còn chậm hơn
    • Ý tưởng này nên thử đề xuất với đội framework vanilla-js

  • Những tính năng chung mà chúng ta đã đánh mất:
    Undo/Redo, trợ giúp (F1), gợi ý khi rê chuột, tùy biến phím tắt, menu chính, file/thư mục, đóng bằng ESC, kéo thả...
    Những tính năng từng rất đột phá ấy giờ gần như biến mất trên mobile và web

  • Nhiều vấn đề là hệ quả của việc designer thị giác chuyển sang làm thiết kế sản phẩm.
    Sự nhầm lẫn về vai trò trong các nghề thiết kế đến giờ vẫn chưa được giải quyết, và thực tế là ngay cả những dự án không cần “designer” cũng đang bị đưa quá nhiều designer vào