Các cách cải thiện UX thực tế cho startup sống sót mà không cần nhà thiết kế

• Dùng thư viện component như Material UI có thể là con đường dễ đi, nhưng chúng chỉ cung cấp các khối xây dựng cơ bản, còn việc thiết kế toàn bộ luồng người dùng vẫn cần làm riêng
• Nếu phải dành thời gian để làm cho sản phẩm trở nên khác biệt, thì làm thế nào để định nghĩa trải nghiệm người dùng tốt càng sớm càng tốt?

Trang trắng là một cái bẫy

• Đừng nhìn vào một canvas trống rồi băn khoăn “Trường nhập email nên trông như thế nào?”
• Có thể tận dụng các pattern đã được kiểm chứng ở các công ty lớn
  • Có thể tiết kiệm thời gian và cải thiện trải nghiệm người dùng

• Cách tiếp cận nên tránh

  • Trang web giải thưởng thiết kế – có tính độc đáo nhưng không đảm bảo tính khả dụng
  • Dribbble – tập trung vào yếu tố thẩm mỹ, không liên quan nhiều đến chức năng

• Cách tiếp cận nên tham khảo

  • Trang web đối thủ – tạo tài khoản và lưu lại bằng ảnh chụp màn hình
  • Trang web tổng hợp pattern – có thể tham khảo nhanh trên PageFlows, Mobbin v.v.

• Ghi chú các pattern UI phổ biến

  • Các thành phần UI phổ biến như trường email, mật khẩu, luồng xác nhận
  • Quy tắc về thị giác và bố cục:
    • Form căn giữa
    • Thiết kế responsive
    • Nút bấm rõ ràng
    • Logo ở phía trên

• Ma sát có chủ đích (Friction)

  • Một số công ty yêu cầu thông tin thẻ tín dụng → chiến lược để thu hút người dùng thực sự nghiêm túc
  • Trải nghiệm nhanh không phải lúc nào cũng tốt

Xác định mục tiêu thật rõ ràng

• Mục tiêu không đơn giản là “tạo trang đăng ký” mà là → “làm cho việc đăng ký dễ nhất có thể”
• Chuyển thành câu hỏi:

  “Làm thế nào để người dùng có thể đăng ký một cách dễ dàng?”

• Ví dụ về giải pháp

  • Hiển thị độ mạnh mật khẩu ngay khi nhập
  • Cung cấp lý do phải điền biểu mẫu đăng ký

• Câu hỏi bổ sung

  • Đăng nhập ngay sau khi đăng ký vs đăng nhập sau khi xác nhận email
  • Hiển thị trang xác nhận sau khi đăng ký vs hiển thị thông báo thành công

Cân nhắc các edge case (tình huống ngoại lệ)

• Người dùng thực tế không hành động đúng như dự đoán → họ vội vàng, bỏ qua hướng dẫn và mắc lỗi
• Kiểm tra khả năng phát sinh vấn đề bằng các câu hỏi:
  • Nếu người dùng nhập nhanh và mắc lỗi thì sẽ thế nào?
  • Lỗi phát sinh trong trường nhập có được truyền đạt rõ ràng cho người dùng không?

• Cách khắc phục khi có vấn đề

  • Bất cẩn khi tạo mật khẩu → có thể dẫn đến bị khóa tài khoản sau này
    • → thêm “trường xác nhận mật khẩu” để yêu cầu nhập lại
  • Khi mật khẩu không khớp → hiển thị thông báo lỗi
    • → hiển thị cảnh báo ngay khi nhập mật khẩu lần hai

Dùng AI để phát hiện vấn đề UX

• Có thể dùng các công cụ như ChatGPT để kiểm tra vấn đề UX
• Không hoàn hảo, nhưng có thể kiểm tra nhanh và hiệu quả

• Ví dụ prompt hữu ích

  • Red Team vs Blue Team:

    “Trong luồng đăng ký này, người dùng có thể bị mắc kẹt ở điểm nào?”
    “Vì sao thiết kế này lại trực quan?”

  • Tiêu chuẩn ngành:

    “Các công ty SaaS hàng đầu thiết kế luồng đăng ký như thế nào?”

  • Edge case:

    “Nếu người dùng nhập sai email mà không nhận ra thì chuyện gì sẽ xảy ra?”

Các mẹo cải thiện UX khác

• Thiết lập chỉ số đo lường
  • Tỷ lệ chuyển đổi, tỷ lệ giữ chân người dùng, mức độ hài lòng của người dùng v.v. → đánh giá kết quả bằng các chỉ số khách quan
• Dùng màu sắc đơn giản
  • Màu chính, màu phụ, màu nhấn → đề xuất Coolors
• Dùng ngôn ngữ quen thuộc
  • Thay vì “lỗi cơ sở dữ liệu” → “không thể lưu các thay đổi”

Kết luận

• Trong startup, tốc độ là quan trọng → đừng theo chủ nghĩa hoàn hảo
• Trong UX, tính khả dụng quan trọng hơn tính độc đáo
  • Luồng người dùng trực quan và rõ ràng hiệu quả hơn các thiết kế phức tạp và độc đáo
• Chỉ đổi mới ở giá trị cốt lõi → phần còn lại dùng các pattern đã được kiểm chứng
• Làm theo các pattern mà người dùng đã quen thuộc sẽ giảm gánh nặng học hỏi

[GN⁺]

Ý kiến trên Hacker News

• Đỉnh cao của tính khả dụng cách đây 25 năm là khi hầu hết ứng dụng đều có thanh công cụ và menu theo các mẫu tiêu chuẩn

  • Người dùng không chuyên dùng thường xuyên thì dùng thanh công cụ, còn người dùng không chuyên ít dùng hơn thì thao tác qua menu
  • Người dùng chuyên nghiệp ghi nhớ phím tắt thông qua các ký tự được gạch chân trong nhãn menu
  • Muốn thay đổi cài đặt thì mở hộp thoại cài đặt, trong đó có các tab như "Chung", "Phông chữ và Màu sắc"
  • Khi đó đa số mọi người biết ít về máy tính, nhưng vẫn có thể dùng phần lớn ứng dụng gần như không cần trợ giúp
  • Mục tiêu khi đó là giảm thiểu thời gian người dùng phải dành cho ứng dụng để hoàn thành công việc hiệu quả
  • UX hiện đại nhắm tới việc khiến người dùng "tương tác" nhiều nhất có thể; điều này có thể ổn với ứng dụng tiêu dùng nhưng lại bị áp sang cả ứng dụng doanh nghiệp và gây ra vấn đề
  • Có trường hợp nhân viên không kỹ thuật ở công ty thuộc Fortune 100 phàn nàn rằng SPA mới làm chậm công việc của họ và yêu cầu quay lại terminal cũ

• Sau khi thuê một graphic designer, thay đổi dễ thấy nhất là ứng dụng/trang web trông đẹp hơn

  • UX là một phạm vi rộng hơn, từ luồng tương tác cho tới từng widget chức năng đơn lẻ
  • Phần lớn mọi người dự đoán UX tổng thể của một hệ thống khá kém
  • UX được phát triển bằng cách sao chép các giải pháp sẵn có hoặc thử cái mới
  • Đánh giá một hệ thống bằng tưởng tượng khó hơn nhiều so với khi đã triển khai
  • Thiết kế hệ thống backend có thể dự đoán và tránh lỗi thông qua các nguyên tắc nền tảng và suy luận
  • Những designer hoặc engineer có trực giác UX xuất sắc cực kỳ giá trị, nhưng không thể chỉ ngồi chờ tìm được người như vậy

• Công cụ tốt nhất để tìm vấn đề về tính khả dụng là chia sẻ màn hình với Gemini và mô tả bằng giọng nói tác vụ bạn muốn làm

  • Gemini nhìn UI, tự tìm cách thực hiện tác vụ rồi hướng dẫn bằng giọng nói chỗ cần bấm
  • Nếu Gemini không làm được thì đó là vấn đề về tính khả dụng

• Theo "Jakob's Law", người dùng dành phần lớn thời gian trên các site khác, nên họ thích mọi thứ hoạt động giống những site khác mà họ đã biết

  • Người dùng chuyển kỳ vọng từ sản phẩm quen thuộc sang các sản phẩm tương tự khác
  • Có thể tận dụng mental model sẵn có để tạo ra trải nghiệm người dùng tốt hơn, giúp họ tập trung vào công việc thay vì phải học một mô hình mới
  • Khi thay đổi, nên giảm thiểu sự lệch pha bằng cách cho phép người dùng tiếp tục dùng phiên bản quen thuộc trong một thời gian giới hạn

• Có lý do khiến mọi sản phẩm đều hoạt động theo những cách giống nhau; nếu sản phẩm của bạn hoạt động khác đi, hãy tự hỏi đó là chủ ý hay là sai sót

  • Cần cân bằng giữa các mẫu quen thuộc với người dùng và những ý tưởng mới
  • Ví dụ, khi cố cải thiện trải nghiệm thanh toán của Amazon, bạn có thể đánh mất lợi thế của sự quen thuộc
  • Ưu tiên checkbox, radio button, dropdown và text field sẽ giúp bạn "miễn phí" có được cách đọc trạng thái và thay đổi trạng thái vốn đã quen thuộc với người dùng
  • "Không trực quan" nhiều khi chỉ có nghĩa là "không quen với mẫu này"

• Có thể dùng AI để xác định vấn đề UX, và các công cụ như ChatGPT có thể làm nổi bật những vấn đề UX mà bạn có thể bỏ sót

  • Không hoàn hảo, nhưng vẫn tốt hơn đoán mò

• Khuyến nghị tập trung vào các nguyên tắc thiết kế phổ quát và tư duy nền tảng

  • Đọc "The Design of Everyday Things" của Donald Norman sẽ giúp hiểu sự khác biệt giữa thiết kế tốt và thiết kế tệ
  • "The Art of Game Design" của Jesse Schell bàn về cách tạo ra trải nghiệm nhập vai, và game là lĩnh vực đặc biệt không khoan nhượng

• Bắt chước những gì các công ty lớn làm có thể dẫn tới tư duy cargo cult

  • Bạn phải biết chính xác vì sao mình xây từng phần của hệ thống
  • Chỉ vì CAPTCHA mà Google dùng gây khó chịu không có nghĩa là bạn cũng phải làm theo
  • Cần tự tin suy nghĩ xem phần nào mình có thể cải thiện

• Ngay cả ở giai đoạn bootstrap cũng có thể thuê UX designer, và đó là khoản đầu tư rất đáng giá

  • Không nhất thiết phải thuê toàn thời gian; có thể tổ chức design sprint để thiết kế một vài khái niệm, chạy workshop UX, rồi phát triển phương án đã chọn thành prototype có thể bấm được
  • Điều này đáng giá ngang với việc tiết kiệm $5k từ ngân sách phát triển frontend, và trong năm đầu có thể mang lại lợi ích hơn $5k nhờ tăng tỷ lệ giữ chân người dùng

• Không nhớ lần cuối cùng được làm việc cùng một designer chuyên trách là khi nào

  • DevOps cũng đang đi theo con đường tương tự, như thể người ta kỳ vọng coder sẽ làm luôn việc đó trong lúc chờ code biên dịch
  • Tiếp theo sẽ đến lượt coder
  • Thuê chuyên gia là điều rất khó chịu