11 phút

UX vs. UI

Mình là một người sử dụng ví MoMo hàng ngày. Tuy nhiên, trong quá trình sử dụng, mình gặp khá nhiều bất tiện.

Trong bài viết này, mình phân tích một số lỗi UI&UX trong MoMo. Những lỗi này rất phổ biến khi làm game/ứng dụng trên điện thoại đi động.

Cập nhật: mình không dùng ZaloPay, nhưng một người bạn của mình nói ZaloPay dễ sử dụng hơn, nên mình sẽ dùng thử và nhận xét cả hai nếu thích hợp.

User Interface (UI)

Có 4 yếu tố trong thiết kế UI cần cân nhắc: bố cục, màu sắc, biểu tượng & nội dung

Bố cục (layout)

Đây là yếu tố quan trọng nhất trong thiết kế UI, thể hiện bố cục chung của ứng dụng. Điều này rất quan trọng trong ứng dụng, giúp người dùng có thể định vị tính năng cần dùng (discoverability).

Do đó, bạn cần phải nhóm các chức năng tương tự gần nhau (proximity). Có thể phân nhóm theo bất kỳ logic nào, nhưng phải có phân nhóm.

MoMo

  • Trước: các chức năng trộn lẫn vào nhau, khó định vị. Các chức năng thường dùng nằm phía trên cùng màn hình, bắt buộc phải sử dụng bằng 2 tay.
  • Sau: nhóm các chức năng lại thành 4 nhóm
    • Đưa các chức năng thường dùng xuống dưới, để có thể sử dụng bằng 1 tay. (tăng reachability)
    • Các chức năng chính của MoMo: nằm phía dưới cùng
    • Các chức năng sử dụng thường xuyên trong tháng: nạp tiền điện thoại, thanh toán điện/nước/internet,…
      • Các nhóm phụ trong này sẽ mở ra khi nhấn vào. VD: trả trước, trả sau, data, mã thẻ,…
    • Các chức năng ít dùng hơn: mua vé tàu, xe, máy bay…
    • Các chức năng branding đưa lên trên cùng thì màu sắc và hình dạng không đồng nhất, sẽ làm rối các biểu tượng khác.
  • Không có cách phân nhóm nào tối ưu cả, do đó, cách tốt nhất là cho người dùng tuỳ chọn vị trí & chức năng thường dùng.

ZaloPay

  • Mặc dù giao diện của ZaloPay có gọn gàng hơn, ít các Branding Logos, nhưng về bố cục và màu sắc đều vi phạm nguyên tắc tổ chức.

Màu sắc (color)

Màu sắc (color): các biểu tượng giống nhau (similarity) sẽ được người dùng cho là có liên quan với nhau. Và màu sắc thể hiện sự tương tự này tốt nhất.

Đồng thời, màu sắc là yếu tố đầu tiên người dùng để ý, do đó cần được tận dụng tối đa.

Tiền Việt Nam/EU sử dụng màu sắc+kích thước để phân biệt mệnh giá, do đó dễ phân biệt hơn tiền USD, sử dụng hình ảnh & số.

MoMo

  • Trước: không hiểu màu sắc trong icon có ý nghĩa gì luôn: tại sao thanh toán nước, data 3G/4G, bảo hiểm & mua vé xe khách có màu xanh dương?
  • Sau: màu sắc theo các nhóm chức năng: momo, thường xuyên, ít dùng

ZaloPay

  • Cũng tương tự, màu sắc biểu tượng không có nguyên tắc chung.

Biểu tượng (icon)

Giúp người dùng có thể ghi nhận thông tin & chức năng nhanh chóng nhất. Nếu được thiết kế tốt, ghi chú sẽ không cần thiết nữa.

Có 4 cách thể hiện, từ cụ thể đến trừu tượng. Nên hạn chế dùng 2 cách bên dưới, nếu buộc phải dùng thì cần chọn các biểu tượng đã chuẩn hoá.

Tips: có thể tham khảo thêm các biểu tượng trên fontawesome.comthenounproject.com vì thiết kế khá chuẩn.

  • Similar: Thể hiện trực tiếp đối tượng.
    VD: Rút tiền/Nạp tiền Khe rút tiền ATM.
  • Example: Dùng ví dụ để thể hiện đối tượng.
    Nạp tiền tài xế Thay bằng biểu tượng GrabBike, GrabCar, tuỳ vào lịch sử sử dụng của người dùng,…
  • Symbolic: Trừu tượng hoá đối tượng.
    Điểm thanh toán Map Marker trong các ứng dụng bản đồ
  • Arbitrary: Không liên quan đến đối tượng, cần phải học ý nghĩa.
    Chữ thập đỏ Bệnh viện

Nội dung (text)

  • Người dùng sẽ nhận diện Màu sắc Biểu Tượng Mô tả.
  • Người dùng rất ít khi đọc, nên viết càng ngắn gọn càng tốt.
  • Hạn chế nội dung trải trên nhiều dòng, nếu cần thì có thể viết tắt.
    ĐT/Điện /Nước/HĐ Khác

UX (Interaction)

Tính Đồng Nhất (consistency)

Giao diện cần phải có tính đồng nhất trong suốt ứng dụng. Điều này sẽ giúp người dùng chỉ cần học cách sử dụng 1 lần, áp dụng nhiều lần trong các chức năng khác nhau. Tính đồng nhất cần thể hiện trong từng thành phần UI:

  • Màu sắc: mang ý nghĩa thống nhất. Đặc biệt những màu theo thông lệ.
    Màu xanh lá cây là xác nhận/đồng ý, màu đỏ là huỷ thao tác/lỗi, màu xám là chức năng bị tắt,…
  • Vị trí: các nút cần phải thống nhất, để người dùng có thể dễ dàng thao tác.
    Nút đóng phía trên bên phải, nút xác nhận phía dưới cùng, nút back bên trái, nút giúp đỡ phía trên bên phải,…
  • Hình thức: của các giao diện cần chuẩn hoá.
    Khung nhập text, nút bấm, dropbox, liên kết, nút đóng, nút giúp đỡ…
  • Biểu tượng: của chức năng, thông báo, log cần thống nhất với nhau.
  • Thao tác: các thao tác trượt màn hình để trở về, kéo xuống để đóng,… nên áp dụng thao tác chuẩn của iOS để người dùng không cần học lại.

MoMo

  • Mỗi màn hình/UI elements trong MoMo là có một cách bố trí/hình thức/vị trí giao diện khác nhau: rất nhiều kiểu khung nhập text, lẫn lộn giữa nút bấm (hành động) và liên kết (thông tin tham khảo), hình thức nút đóng không thống nhất,…, tựa như mỗi tính năng do một người khác làm & ráp lại với nhau.

ZaloPay

  • Nhìn chung giao diện của ZaloPay chuẩn hơn: màu sắc, vị trí, hình thức, icon
Thanh Toán Tiền Nước

MoMo

  • Danh sách các tỉnh thành không sắp theo thứ tự. Cái này cũng là lỗi thường gặp ở hầu hết các ứng dụng.
    Đơn giản nhất là nhóm Bắc-Trung-Nam > sắp tỉnh/thành theo ABC . Nếu có quyền GPS thì có thể định vị tỉnh thành & đề nghị.
  • Hoá đơn của mỗi tỉnh/thành có một cấu trúc khác nhau:
    • Tiêu đề: hoá đơn, Nước Bạc Liêu
    • Biểu tượng: lúc có lúc không
    • Mô tả: tên cty Cấp Nước, mô tả phạm vi thanh toán, thanh toán tất cả cũng mô tả luôn, Cần Thơ thì có thêm Địa Bàn Hỗ Trợ.
    • Nhập mã khách hàng: thay đổi mô tả theo cty Cấp nước. Lúc thì focus vào text field, lúc không.
    • Link bên cạnh ID: không có, Cách lấy mã, Địa bàn hỗ trợ.
    • Hoá đơn mẫu: lúc có lúc không, đôi lúc nhỏ quá cũng không thấy được.
    • Nút Kiểm Tra/Tiếp Tục: lúc thì enable, mặc dù chưa nhập mã, lúc thì disable.
  • Ở đây có thể thấy rõ nhất là không có kiến trúc thông tin (information architect)
    • Tiêu đề: Hoá đơn nước Tỉnh/Thành
    • Biểu tượng: không cần thiết, vì biểu tượng không đồng nhất, chỉ làm rối thêm thông tin.
    • Mô tả: tên cty Cấp Nước
    • Địa bàn:
      • Thanh toán tất cả địa bàn trong tỉnh thành.
      • Chỉ hỗ trợ một số địa bàn. Xem danh sách.
      • Thanh toán cho Quận Hồ Tây.
    • Nhập mã khách hàng: Nhập mã khách hàng/danh bộ/ID.
      • Luôn focus vào text field, giảm thao tác cho người dùng.
    • Link bên cạnh ID: Nút [Kiểm Tra], để kiểm tra thông tin khách hàng trước khi thanh toán.
    • Hoá đơn mẫu: chỉ cần crop lại khu vực xung quanh mã khách hàng, danh bộ, ID khách hàng để có thể nhìn thấy.
    • Nút [Thanh Toán]: chỉ kích hoạt khi kiểm tra đúng mã khách hàng.

ZaloPay

  • Danh sách các công ty cấp nước có sắp theo ABC (nhưng không hiểu sao Cấp nước Nhơn Trạch nằm trên cùng?). Nhưng sắp ngang hàng các công ty cấp nước của tỉnh & từng địa bàn thành phố thì không được hợp lý.

Nạp tiền điện thoại

MoMo

  • Chức năng trả sau cho Mobifone có thể truy cập qua 2 chức năng khác nhau, UI khác nhau: Trả Trước & Trả Sau
  • Đối với người sử dụng, tất cả đều là trả tiền điện thoại, việc tách ra chỉ khiến người sử dụng nhầm lẫn.
  • Giao diện của các chức năng này có thể thống nhất lại, chỉ cần tổ chức lại thông tin:
    • Nhập số điện thoại
    • Tự động xác định nhà mạng
      • Nếu nhà mạng không hỗ trợ tắt nút Thanh Toán
    • Nếu là mua mã thẻ thì có thêm phần chọn mệnh giá & số lượng
      • Chỉ nên có một hướng cuộn trong 1 màn hình. Ở chức năng này, nhà mạng thì cuộn trái phải, trong khi hầu hết các màn hình đều là cuộn lên xuống
      • Nút số lượng nên canh trái (align với các nút tuỳ chọn bên trên) hoặc giữa (align với nút mua bên dưới), tránh việc di chuyển mắt của người dùng từ bên này qua bên khác không cần thiết.

ZaloPay

  • Các tính năng nạp tiền điện thoại tách riêng và đặt nhiều nơi. Tính năng [ĐT Trả Sau] có link đến [Nạp ĐT] [Thẻ ĐT] [Nạp 3G/4G], nhưng không có chiều ngược lại.
  • Kích thước font trong các giao diện không đồng nhất

Phản Hồi (feedback)

Phản hồi là một trong các nguyên tắc quan trọng trong thiết kế. Nó giúp người dùng biết được kết quả của hành động mình thực hiện. Tuy nhiên, để phản hồi/thông báo có hiệu quả, designer cần phải hoạch định trước:

  • Đánh giá mức độ quan trọng của phản hồi/thông báo
  • Phản hồi vừa đủ thông tin cần thiết, ẩn các thông tin không quan trọng
  • Quá nhiều thông báo sẽ khiến người dùng bỏ qua TẤT CẢ thông báo do quá phiền phức

MoMo vs. ZaloPay

  • Về phía MoMo, các thông tin quá dư thừa & trùng lắp.
  • Về phần này, ZaloPay làm tốt hơn ở phần thể hiện thông tin vừa đủ. Tuy nhiên vẫn không có sự ưu tiên/phân loại giữa các thông báo.
Sắp thứ tự ưu tiên

Tuỳ theo mức độ quan trọng của thông báo sẽ chọn hình thức phù hợp, từ dễ chịu nhất (log) đến khó chịu nhất (pop-up):

  • Log: giao dịch phát sinh
  • Thông báo: thẻ quà tặng, khuyến mãi,…
    • Có thể gộp Log/Thông báo lại, phân biệt bằng tab
    • Nhưng không nên gom log & message chung 1 màn hình như hiện nay, vì 2 chức năng phục vụ 2 mục đích khác nhau
  • Banner: khuyến mãi
    • Nên xoay vòng các banner
    • Nên chú ý đến kích thước text trên điện thoại: chữ trên banner không thể nào đọc được vì quá nhỏ
  • Top banner: khuyến mãi lớn, hoá đơn đến hạn,…
    • Nên gộp các chức năng tương tự lại với nhau
  • Pop-up: bảo mật tài khoản, đăng ký thông tin CMND,…
    • Chú ý thời điểm hiện thông báo.
      Vừa đăng nhập vào.
    • Không nên hiện khi người dùng đang thực hiện các thao tác khác như trong hình.
      Thanh toán, nạp tiền,…
Xác nhận
  • Sau khi nhấn [Xác nhận] không có phản hồi về tình trạng xử lý, dẫn đến tình trạng không biết giao dịch có thành công hay không.
  • Nên bổ sung thêm animation/text/thời gian để biết trạng thái đang xử lý của giao dịch.

Improve payment experience with animations in Stripe

Mua thẻ điện thoại
  • Trước
    • Quá nhiều thông tin không cần thiết
    • Không thống nhất về giao diện giữa màn hình thành công và log
    • 3 nút chức năng liên quan đến mã thẻ rời rạc, không đồng nhất
      • SAO CHÉP: màu xanh, viết hoa toàn bộ, như liên kết (trong log thì là icon màu xám)
      • Gửi thẻ nạp: màu xám, trông như bị tắt
      • Nạp ngay: màu hồng, nút nhấn
    • Nên thiết kế tinh gọn, vừa đủ thông tin trong màn hình hoàn tất
      • Các thông tin chi tiết như mã giao dịch, thời gian,… nên để trong log
  • Sau
    • Bỏ tất cả các thông tin không cần thiết
    • Đưa số seri lên trên, màu xám, thể hiện thông tin phụ
    • 3 nút chức năng ngay phía dưới Mã thẻ
Xác thực tài khoản

Ở đây, mình chỉ lấy một ví dụ để cho thấy rằng designer cần phải để ý tất cả các chi tiết trong thiết kế để tránh người dùng bối rối.

MoMo

  • Khung chụp & hình chụp không khớp nhau.
  • Đổi góc nhìn điện thoại từ portrait sang landscape là không cần thiết.

ZaloPay

  • Khung chụp hình vuông!? CMND nào hình vuông.
  • Khung chụp & hình chụp không khớp nhau.

Lỗi (Error)

Error-message Guidelines Ở đây mình chỉ phân tích thông báo lỗi và ngăn ngừa lỗi.

Thông báo lỗi

Các thông báo lỗi cần chỉ rõ nguyên nhân VÀ cách khắc phục cho người dùng.

Tránh thông báo chung chung: Lỗi (-24) đã xảy ra. Vui lòng thử lại sau.

Nên cụ thể nhất có thể: Hệ thống hiện đang bảo trì đến 13:00. Vui lòng thử lại sau thời gian này.

Ngăn ngừa lỗi

Lỗi trong quá trình sử dụng là không thể tránh khỏi, do đó designer cần thiết kế để có thể giảm thiểu các lỗi có thể phát sinh.

  • Constraint: giới hạn thao tác.
    Không cho xoá: các thông báo KM hết hạn sẽ tự mất, tách log ra màn hình riêng, các thông báo khác sẽ ẩn đi sau 30 ngày
  • Undo: là một phương pháp phổ biến nhất, quay lại bước trước đó.
    Cho phép huỷ thao tác xoá, có thể xem video bên dưới để thấy việc kết hợp nhiều biện pháp ngăn ngừa lỗi
  • Confirmation: xác nhận lại hành động. Nếu có quá nhiều xác nhận, người dùng sẽ bỏ qua, do đó cần tiết chế.
    Xác nhận xoá thông báo
    • 0 Bước: không xác nhận, nhưng cho phép lấy lại từ Thùng rác, đây là cách ít phiền người dùng nhất và phổ biến nhất.
      Chức năng mua lại đồ từ NPC trong game, nếu bán nhầm;
      xoá email trong Spark sẽ cho vào Thùng rác
    • 1 Bước: xác nhận lại bằng một hộp thoại như cách MoMo đang làm khi xoá tin nhắn.
      ZaloPay thì không confirm gì hết, xoá luôn.
    • 2 Bước: xác nhận sẽ thực hiện thao tác bằng cách nhập thêm thông tin xác nhận.

Góp ý

Khi thiết kế, designer cần nghĩ về hoạt động (activity-based) người dùng muốn thực hiện (mua sắm cuối tuần/quản lý chi tiêu), chứ không chỉ nghĩ đến công việc (task-based) đang thực hiện (thanh toán hoá đơn siêu thị)

Sản phẩm càng đáp ứng được nhiều cấp độ bên dưới thì càng thoả mãn người dùng.

  1. Functionality: đáp ứng được chức năng cơ bản
    Thanh toán hoá đơn. Có muốn thanh toán ZaloPay trong Circle-K/Co-op cũng không được.
  2. Reliability: hoạt động ổn định trong thời gian dài
    Không bị lỗi: mất kết nối, không quét được mã; không bị pop-up che màn hình, MoMo thường bị nhất.
  3. Usability: dễ sử dụng, UI dễ nhận diện, thao tác thuận tiện

    Có thể quét mã thành viên của siêu thị & thanh toán hoá đơn, đồng thời chụp hình hoá đơn sau khi thanh toán để tham khảo
    Tự động nạp thêm tiền nếu không đủ
    Gộp các tính năng nạp tiền điện thoại vào một chỗ
  4. Proficiency: tăng năng suất công việc
    Quản lý chi tiêu hàng tháng theo nhóm chi tiêu, nhận dạng nội dung hoá đơn, tự động thanh toán hoá đơn hàng tháng (ZaloPay có chức năng này)
  5. Creativity: có thể sử dụng cho nhiều mục đích khác
    Lì xì, lừa người khác chuyển tiền cho mình (thông báo của MoMo không ghi nhận số tiền chuyển đi mặc dù log có ghi nhận, bug!?).

The Design of Everyday Things

Tài liệu tham khảo

Bên dưới là một số tài liệu/sách đề nghị về UI/UX. Đây là dạng sách tham khảo lâu dài, nên mua sách giấy.

Apple Human Interface Guidelines

Đây là một bộ hướng dẫn hầu hết các nguyên tắc thiết kế giao diện (UI) đã đề cập bên trên. Nên dùng các thao tác/giao diện chuẩn của iOS khi có thể. Điều này đảm bảo người dùng có thể nhanh chóng học được các sử dụng.