57 lỗi UX/UI website thường gặp và cách sửa

Một khảo sát của Baymard Institute trên hàng trăm website thương mại điện tử lớn cho thấy phần lớn các lỗi khiến người dùng bỏ giữa chừng không nằm ở thiết kế xấu hay đẹp, mà nằm ở những chi tiết nhỏ tưởng như không đáng kể: 1 field nhập sai định dạng, 1 nút bấm không rõ trạng thái, 1 bước xác nhận thừa. Bài viết này tổng hợp 57 lỗi UX/UI website thường gặp nhất, chia theo 15 nhóm, dựa trên các nguồn nghiên cứu được ngành UX công nhận rộng rãi: Nielsen Norman Group (NN/g), Baymard Institute, Laws of UX của Jon Yablonski, và WCAG. Mỗi lỗi đều đi kèm lý do vì sao những lỗi UX/UI này lại gây hại và cách fix cụ thể.

1. Lỗi Navigation & Information Architecture

Navigation (điều hướng) là nơi user hình thành ấn tượng đầu tiên về việc website có "hiểu" họ hay không. Đa số lỗi trong nhóm này xuất phát từ việc doanh nghiệp tự thiết kế menu theo cách nội bộ nghĩ, thay vì theo cách user thực sự tìm kiếm thông tin. Điều hướng tốt giúp người dùng biết mình đang ở đâu, có thể đi đâu và quay lại bằng cách nào. Nhóm này cần được kiểm tra trước nếu website có nhiều dịch vụ, danh mục hoặc tầng nội dung.

1.1 Menu cấp 1 có quá nhiều mục

Theo Hick’s Law, thời gian ra quyết định tăng khi số lượng và độ phức tạp của các lựa chọn tăng. Menu càng nhiều mục, người dùng càng mất thời gian xác định nên chọn gì, đặc biệt khi các mục có nội dung hoặc tên gọi gần giống nhau.

Dấu hiệu nhận biết:

• Menu cấp 1 có quá nhiều mục, khó quét nhanh trên màn hình.

• Nhiều mục có nội dung hoặc ý nghĩa chồng chéo, khó phân biệt.
• Các nội dung quan trọng bị đẩy xuống hoặc ẩn trong nhiều tầng menu.
• Người dùng phải mở nhiều dropdown/mega menu mới tìm được nội dung cần thiết.
• Không có thứ tự ưu tiên rõ ràng giữa các nhóm điều hướng.

Tác động: Quá nhiều lựa chọn ở cấp điều hướng chính làm tăng cognitive load, khiến người dùng khó xác định bước tiếp theo và khó tìm thấy nội dung quan trọng.

Cách sửa: Giữ khoảng 5–7 nhóm điều hướng chính ở cấp 1 khi phù hợp. Các nội dung còn lại nên được gom vào mega menu hoặc dropdown, đồng thời phân nhóm theo nhu cầu và hành trình người dùng.

Kiểm tra sau khi sửa: Người dùng có thể nhanh chóng trả lời: “Tôi cần tìm gì và nên bấm vào đâu?”

Mốc kiểm tra: Khoảng 5–7 mục điều hướng cấp 1, với nhãn rõ ràng, dễ phân biệt và không trùng ý nghĩa.

1.2 Information Architecture (IA) không khớp cách user tự phân loại thông tin

Đây là lỗi vi phạm nguyên tắc Match Between System and the Real World của Nielsen Norman Group: giao diện nên sử dụng ngôn ngữ, cách phân loại và cách tư duy quen thuộc với người dùng, thay vì phản ánh cơ cấu tổ chức nội bộ của doanh nghiệp.

Dấu hiệu nhận biết:

• Menu được tổ chức theo phòng ban hoặc cơ cấu nội bộ thay vì nhu cầu của người dùng.
• Tên mục sử dụng thuật ngữ nội bộ, viết tắt hoặc tên đơn vị mà người dùng khó hiểu.
• Người dùng phải biết doanh nghiệp tổ chức như thế nào mới đoán được nội dung nằm ở đâu.
• Một nhu cầu của người dùng bị phân tán ở nhiều phòng ban hoặc nhiều mục khác nhau.
• Người dùng thường phải hỏi hoặc tìm kiếm mới xác định được nơi cần truy cập.

Tác động: Cách tổ chức theo nội bộ làm tăng cognitive load, buộc người dùng phải hiểu “doanh nghiệp tổ chức thế nào” thay vì chỉ cần biết “mình muốn làm gì”.

Cách sửa: Xây dựng sitemap dựa trên nhu cầu, nhiệm vụ và cách phân loại của người dùng. Thực hiện card sorting với người dùng mục tiêu để kiểm chứng cách nhóm và đặt tên nội dung trước khi chốt cấu trúc điều hướng.

Kiểm tra sau khi sửa: Người dùng có thể tìm đúng nội dung dựa trên nhu cầu của họ mà không cần biết phòng ban nào phụ trách.

Mốc kiểm tra: Kết quả card sorting và khả năng người dùng xác định đúng nội dung/nhiệm vụ từ menu.

1.3 Website nhiều tầng nhưng thiếu breadcrumb

Khi website có cấu trúc nhiều tầng nhưng không có breadcrumb, người dùng khó xác định vị trí hiện tại và quay lại các cấp trước đó. Điều này làm giảm khả năng điều hướng và kiểm soát hành trình của người dùng.

Dấu hiệu nhận biết:

• Website có cấu trúc từ 2 tầng nội dung trở lên nhưng trang con không hiển thị vị trí trong cấu trúc.
• Người dùng không biết mình đang ở danh mục hay cấp nội dung nào.
• Muốn quay lại danh mục trước phải dùng nút Back hoặc mở lại menu chính.
• Các trang con có nhiều cấp nhưng không có cách điều hướng trực tiếp về cấp cha.

Tác động: Người dùng dễ mất phương hướng, khó hiểu mối quan hệ giữa trang hiện tại và các trang cấp trên, đồng thời phải thực hiện thêm thao tác để quay lại nội dung trước đó.

Cách sửa: Thêm breadcrumb trên các trang thuộc cấu trúc nhiều tầng, thể hiện rõ đường dẫn từ trang chủ → danh mục → danh mục con → trang hiện tại. Breadcrumb nên có thứ tự và nhãn nhất quán.

Kiểm tra sau khi sửa: Người dùng có thể xác định ngay “Tôi đang ở đâu?” và quay về bất kỳ cấp cha nào mà không cần sử dụng nút Back.

Mốc kiểm tra: Áp dụng khi website có từ 2 tầng nội dung/điều hướng trở lên.

1.4 Nút Back làm mất trạng thái đã nhập

Khi người dùng bấm Back để quay lại trang trước, hệ thống nên khôi phục trạng thái trước đó thay vì tải lại trang về trạng thái mặc định. Việc mất dữ liệu đã nhập hoặc bộ lọc đã chọn làm gián đoạn hành trình và buộc người dùng phải thao tác lại.

Dấu hiệu nhận biết:

• Người dùng đã nhập dữ liệu vào form nhưng mất dữ liệu khi quay lại trang.
• Bộ lọc, lựa chọn hoặc vị trí cuộn bị reset sau khi bấm Back.
• Trang quay về trạng thái mặc định thay vì trạng thái người dùng vừa thao tác.
• Người dùng phải nhập lại form hoặc thiết lập lại bộ lọc từ đầu.

Tác động: Người dùng mất công sức đã thực hiện, dễ gián đoạn hành trình và có thể bỏ dở tác vụ khi phải thao tác lại.

Cách sửa: Duy trì trạng thái trang và dữ liệu người dùng đã nhập khi điều hướng Back/Forward. Quản lý đúng browser history và page state, tránh reload hoặc khởi tạo lại trang về trạng thái mặc định.

Kiểm tra sau khi sửa: Chọn bộ lọc → chuyển sang trang khác → bấm Back → bộ lọc và trạng thái trước đó vẫn được giữ nguyên.

Mốc kiểm tra: Giữ đúng state khi người dùng sử dụng Back/Forward.

1.5 Label menu dùng thuật ngữ nội bộ

Nhãn điều hướng nên sử dụng ngôn ngữ quen thuộc với người dùng, thay vì thuật ngữ nội bộ hoặc cách gọi chỉ được sử dụng trong doanh nghiệp. Một label tốt cần giúp người dùng đoán đúng nội dung phía sau trước khi click.

Dấu hiệu nhận biết:

• Menu sử dụng viết tắt, mã dự án hoặc tên gọi nội bộ mà khách hàng không quen thuộc.
• Label không phản ánh cách người dùng thường gọi hoặc tìm kiếm nội dung.
• Người dùng phải click vào nhiều mục mới xác định được nội dung mình cần.
• Các label mang tính khái niệm, nhưng không cho biết rõ nội dung phía sau.
• Người dùng diễn giải cùng một label theo nhiều cách khác nhau.

Tác động: Label khó hiểu làm tăng cognitive load, khiến người dùng không dự đoán được nội dung phía sau liên kết và làm chậm quá trình tìm kiếm thông tin.

Cách sửa: Sử dụng ngôn ngữ của khách hàng và ưu tiên các thuật ngữ phổ biến, dễ hiểu. Test label với người dùng mục tiêu hoặc người ngoài team trước khi publish để kiểm tra khả năng hiểu và dự đoán nội dung.

Kiểm tra sau khi sửa: Cho người dùng xem label và hỏi: “Bạn nghĩ sẽ tìm thấy gì khi click vào đây?” Nếu phần lớn người dùng đoán đúng nội dung, label có tính rõ ràng.

Mốc kiểm tra: Ngôn ngữ khách hàng + khả năng đoán đúng nội dung.

2. Lỗi Forms & Input Fields

Form (biểu mẫu) là nơi ý định chuyển thành dữ liệu, đăng ký hoặc giao dịch. Form là nơi tỷ lệ bỏ cuộc cao nhất trên toàn bộ hành trình website, đặc biệt ở các bước đăng ký, thanh toán, hoặc xác minh danh tính. Chỉ một nhãn mơ hồ, định dạng lạ hoặc lỗi báo muộn cũng đủ làm người dùng bỏ cuộc.

2.1 Website bán hàng tạo định dạng ngày hết hạn không khớp với thẻ vật lý

Field ngày hết hạn nên sử dụng đúng định dạng mà người dùng nhìn thấy trên thẻ thanh toán. Nếu thẻ hiển thị MM/YY nhưng form yêu cầu MM/YYYY, người dùng phải tự chuyển đổi định dạng, làm tăng khả năng nhập sai.

Dấu hiệu nhận biết:

• Form yêu cầu định dạng ngày hết hạn khác với định dạng in trên thẻ.
• Placeholder hoặc hướng dẫn yêu cầu MM/YYYY trong khi thẻ hiển thị MM/YY.
• Người dùng phải tự suy nghĩ hoặc chuyển đổi YY thành YYYY trước khi nhập.
• Form từ chối giá trị hợp lệ chỉ vì khác định dạng hiển thị trên thẻ.

Tác động: Người dùng phải thực hiện thêm một bước chuyển đổi thông tin, làm tăng friction và nguy cơ nhập sai dữ liệu thanh toán.

Cách sửa: Khớp định dạng field, placeholder và validation với định dạng ngày hết hạn phổ biến được in trên thẻ. Nếu cần hỗ trợ nhiều định dạng, cho phép hệ thống tự chuẩn hóa thay vì bắt người dùng chuyển đổi.

Kiểm tra sau khi sửa: Xem ngày hết hạn trên thẻ → nhập trực tiếp vào field → không cần chuyển đổi định dạng và không bị báo lỗi.

Mốc kiểm tra: Định dạng field phải khớp với định dạng hiển thị trên thẻ.

2.2 Layout form nhiều cột cho các field không thực sự liên quan

Theo Baymard Institute, multicolumn layout trong form có thể khiến người dùng khó xác định thứ tự điền, đặc biệt khi các field không có mối quan hệ rõ ràng. Với phần lớn form, single-column giúp tạo luồng đọc và nhập dữ liệu tự nhiên hơn.

Dấu hiệu nhận biết:

• Các field độc lập được bố trí cạnh nhau dù không có mối quan hệ trực tiếp.
• Người dùng phải di chuyển mắt giữa nhiều cột để xác định field tiếp theo.
• Thứ tự đọc bằng mắt không rõ ràng, đặc biệt trên màn hình desktop.
• Các field quan trọng dễ bị bỏ sót hoặc điền không theo thứ tự mong muốn.

Tác động: Bố cục nhiều cột làm tăng cognitive load, khiến người dùng khó xác định thứ tự thao tác và tăng nguy cơ bỏ sót hoặc nhập sai thông tin.

Cách sửa: Ưu tiên form một cột cho các field độc lập. Chỉ đặt nhiều field trên cùng một hàng khi chúng có mối quan hệ trực tiếp và logic, chẳng hạn Thành phố + Mã bưu điện.

Kiểm tra sau khi sửa: Người dùng có thể điền form từ trên xuống dưới theo một luồng rõ ràng, không cần suy nghĩ field nào cần nhập trước.

Mốc kiểm tra: Single-column cho field độc lập; multicolumn chỉ khi các field có quan hệ logic rõ ràng.

2.3 Placeholder thay label, biến mất ngay khi user bắt đầu gõ.

Việc dùng placeholder thay cho label khiến thông tin mô tả field biến mất ngay khi người dùng bắt đầu nhập. Điều này đi ngược nguyên tắc Recognition Rather Than Recall của Nielsen Norman Group, vì người dùng phải nhớ field đang yêu cầu thông tin gì thay vì luôn có thông tin để nhận biết.

Dấu hiệu nhận biết:

• Field chỉ có placeholder mà không có label cố định.
• Placeholder biến mất ngay khi người dùng bắt đầu nhập.
• Khi form có nhiều field, người dùng khó xác định lại ý nghĩa của một field đã điền.
• Sau khi chuyển tab, quay lại hoặc bị gián đoạn, người dùng không còn thông tin để xác định field đang yêu cầu gì.

Tác động: Thông tin nhận diện field biến mất trong quá trình nhập, làm tăng cognitive load và buộc người dùng phải nhớ thay vì nhận biết.

Cách sửa: Đặt label cố định phía trên hoặc bên cạnh field. Chỉ sử dụng placeholder để minh họa định dạng hoặc đưa ra ví dụ, không dùng placeholder làm nhãn duy nhất.

Kiểm tra sau khi sửa: Nhập dữ liệu → chuyển sang field khác → label của field vẫn hiển thị và người dùng vẫn xác định được nội dung cần nhập.

Mốc kiểm tra: Recognition thay vì Recall.

2.4 Chỉ báo lỗi sau khi submit toàn bộ form

Việc chỉ hiển thị lỗi sau khi người dùng submit toàn bộ form khiến họ phải quay lại tìm từng field sai, đặc biệt với form dài. Validation nên cung cấp phản hồi đúng thời điểm và đúng vị trí, nhưng không nên báo lỗi quá sớm khi người dùng chưa hoàn thành thao tác nhập.

Dấu hiệu nhận biết:

• Người dùng điền nhiều field rồi mới biết có lỗi sau khi bấm Submit.
• Thông báo lỗi nằm cách xa field cần sửa.
• Có nhiều lỗi xuất hiện cùng lúc ở các vị trí khác nhau.
• Người dùng phải cuộn lên xuống để tìm từng field bị lỗi.
• Field lỗi không được focus hoặc đánh dấu rõ ràng.

Tác động: Người dùng nhận phản hồi quá muộn, phải tìm lại nguyên nhân và thực hiện nhiều thao tác sửa lỗi, làm tăng frustration và nguy cơ bỏ dở form.

Cách sửa: Validation tại thời điểm phù hợp, ưu tiên khi người dùng rời khỏi field (on blur) đối với các trường có thể kiểm tra ngay. Hiển thị thông báo lỗi ngay sát field, nêu rõ lỗi gì và cách sửa.

Kiểm tra sau khi sửa: Nhập email → rời khỏi field → nhận biết ngay email chưa đúng định dạng và có thể sửa trực tiếp tại field.

Mốc kiểm tra: On blur + lỗi hiển thị ngay tại field cần sửa.

2.5 CAPTCHA quá khó hoặc quá nhiều bước

CAPTCHA là một lớp bảo vệ chống bot, nhưng nếu yêu cầu quá nhiều thao tác hoặc xác minh lặp lại, nó có thể trở thành rào cản hoàn tất tác vụ. Vấn đề thường rõ hơn trên mobile, nơi thao tác chọn ảnh, nhập ký tự hoặc xác minh nhiều lần kém thuận tiện hơn.

Dấu hiệu nhận biết:

• Người dùng phải thực hiện nhiều lượt chọn ảnh hoặc nhập ký tự mới hoàn tất xác minh.
• CAPTCHA yêu cầu thử lại hoặc xác minh nhiều lần dù người dùng đã thực hiện đúng.
• Thao tác xác minh khó thực hiện chính xác trên màn hình nhỏ.
• CAPTCHA xuất hiện ở những hành động có rủi ro thấp, không cần mức xác minh cao.

Tác động: Quy trình xác minh phức tạp làm tăng friction, khiến người dùng thật dễ bỏ cuộc trước khi hoàn tất hành động, đặc biệt trên mobile.

Cách sửa: Ưu tiên xác minh tự động hoặc CAPTCHA ít tương tác. Chỉ yêu cầu người dùng xác minh khi hệ thống phát hiện rủi ro, đồng thời giảm số bước xuống mức tối thiểu cần thiết cho bảo mật.

Kiểm tra sau khi sửa: Thực hiện tác vụ → được xác minh tự động nếu rủi ro thấp; chỉ yêu cầu xác minh khi cần → tiếp tục hoàn tất tác vụ.

Mốc kiểm tra: Ít bước xác minh nhất nhưng vẫn đáp ứng yêu cầu bảo mật.

2.6 Form KYC không giải thích lý do thu thập

Khi form KYC yêu cầu thông tin nhạy cảm nhưng không giải thích vì sao cần cung cấp và dữ liệu được sử dụng như thế nào, người dùng có thể cảm thấy thiếu an toàn hoặc không hiểu mục đích của yêu cầu. Microcopy ngắn đặt ngay tại field giúp cung cấp đúng ngữ cảnh tại thời điểm người dùng cần quyết định.

Dấu hiệu nhận biết:

• Form yêu cầu số giấy tờ tùy thân, ảnh chân dung hoặc thông tin cá nhân nhưng không có giải thích.
• Người dùng không biết thông tin được thu thập để phục vụ mục đích gì.
• Thông tin về bảo mật hoặc cách sử dụng dữ liệu chỉ xuất hiện ở trang khác hoặc trong điều khoản dài.
• Các field nhạy cảm không có microcopy hỗ trợ ngay tại vị trí nhập.

Tác động: Yêu cầu dữ liệu nhạy cảm nhưng thiếu ngữ cảnh làm tăng sự do dự và lo ngại về quyền riêng tư, từ đó tăng nguy cơ người dùng dừng hoặc bỏ dở quy trình KYC.

Cách sửa: Thêm microcopy ngay tại field hoặc trước nhóm field nhạy cảm, giải thích ngắn gọn lý do thu thập, mục đích sử dụng và thông tin bảo mật liên quan. Nội dung phải chính xác và phù hợp với chính sách thực tế.

Kiểm tra sau khi sửa: Người dùng nhìn vào field → hiểu tại sao thông tin được yêu cầu và dữ liệu được sử dụng cho mục đích gì mà không cần rời khỏi form để tìm thông tin.

Mốc kiểm tra: Giải thích tại chỗ + đúng mục đích sử dụng dữ liệu.

3 Lỗi checkout và luồng chuyển đổi trên website

Mỗi bước thừa trong luồng chuyển đổi đều có thể trở thành một điểm rơi. Mục tiêu không phải cắt giảm bước bằng mọi giá, mà là loại bỏ những ma sát không tạo thêm giá trị, an toàn hoặc tuân thủ. Đây cũng là nhóm lỗi tác động trực tiếp đến doanh thu, bởi mỗi bước thừa trong checkout đều có thể khiến người dùng rời đi.

3.1 Bắt tạo tài khoản trước khi cho xem giá

Yêu cầu người dùng tạo tài khoản trước khi được xem giá, phí hoặc thông tin sản phẩm/dịch vụ quan trọng tạo ra friction ngay từ đầu hành trình. Người dùng chưa đủ thông tin để đánh giá giá trị nhưng đã phải cung cấp dữ liệu hoặc thực hiện thêm một bước đăng ký.

Dấu hiệu nhận biết:

• Người dùng phải tạo tài khoản trước khi xem giá hoặc phí.
• Thông tin quan trọng về sản phẩm/dịch vụ bị khóa sau form đăng ký.
• Người dùng chưa thể so sánh hoặc đánh giá các phương án trước khi đăng ký.
• Form đăng ký xuất hiện trước khi người dùng có lý do rõ ràng để tiếp tục.

Tác động:
Người dùng phải thực hiện một hành động có friction trước khi nhận được thông tin cần thiết để ra quyết định, làm tăng khả năng rời khỏi hành trình.

Cách sửa: Áp dụng nguyên tắc Value First: cho phép người dùng xem giá, phí và thông tin cần thiết trước. Chỉ yêu cầu tạo tài khoản khi thực sự cần cho bước tiếp theo như mua hàng, lưu thông tin hoặc sử dụng tính năng cá nhân hóa.

Kiểm tra sau khi sửa: Xem giá & phí → so sánh/chọn phương án → chỉ tạo tài khoản khi bước tiếp theo thực sự yêu cầu.

Mốc kiểm tra: Value First + Account Later.

3.2 Ẩn phí phát sinh đến tận bước cuối cùng của checkout

Khi các khoản phí chỉ xuất hiện ở bước cuối, người dùng có thể gặp “sticker shock” vì tổng chi phí cao hơn đáng kể so với kỳ vọng ban đầu. Vấn đề càng nghiêm trọng khi người dùng đã dành thời gian nhập thông tin và gần hoàn tất giao dịch.

Dấu hiệu nhận biết:

• Giá sản phẩm được hiển thị nhưng phí bổ sung chưa được thông báo.
• Tổng tiền chỉ được cập nhật ở bước thanh toán hoặc xác nhận cuối.
• Các khoản phí phát sinh xuất hiện đột ngột sau khi người dùng đã nhập thông tin.
• Người dùng không thể ước tính tổng chi phí trước khi bắt đầu checkout.

Tác động: Chi phí phát sinh bất ngờ làm tăng sticker shock, khiến người dùng phải đánh giá lại quyết định ở bước cuối và có thể hủy giao dịch.

Cách sửa: Hiển thị giá và các khoản phí dự kiến càng sớm càng tốt. Cập nhật tổng chi phí minh bạch khi có thay đổi, đồng thời giải thích rõ từng khoản phí trước bước thanh toán.

Kiểm tra sau khi sửa: Giá sản phẩm → phí dự kiến → tổng chi phí được ước tính và cập nhật trước khi người dùng đến bước thanh toán.

Mốc kiểm tra: Minh bạch chi phí sớm + không có phí bất ngờ ở bước cuối.

3.3 Flow nhiều bước nhưng không có thanh tiến độ

Với flow gồm nhiều bước, người dùng cần biết đang ở đâu và còn bao xa mới hoàn tất. Nếu không có tiến độ, họ khó ước tính thời gian và dễ mất cảm giác kiểm soát hành trình.

Dấu hiệu nhận biết:

• Flow có nhiều bước nhưng không cho biết tổng số bước.
• Người dùng không biết mình đang ở bước nào.
• Không thể ước tính còn bao lâu hoặc bao nhiêu bước để hoàn tất.
• Các bước được hiển thị tuần tự nhưng không có chỉ báo tiến độ.

Tác động: Không biết còn bao xa mới xong làm giảm cảm giác kiểm soát, đặc biệt khi flow yêu cầu nhiều thông tin hoặc thao tác liên tiếp.

Cách sửa: Hiển thị progress bar hoặc số bước rõ ràng, chẳng hạn “Bước 2/4”, đồng thời cho biết các bước chính trong hành trình nếu phù hợp.

Kiểm tra sau khi sửa: Người dùng nhìn vào flow và trả lời được ngay: “Tôi đang ở đâu?” và “Còn bao nhiêu bước?”

Mốc kiểm tra: Bước 2/4 + hiển thị rõ tiến độ.

3.4 Quy trình nạp/rút tiền có quá nhiều xác nhận trùng lặp

Mỗi bước xác nhận bổ sung là một điểm rơi mới, đặc biệt với giao dịch giá trị nhỏ khi thời gian và công sức người dùng bỏ ra không tương xứng với giá trị nhận được. Flow nên chỉ giữ những bước thực sự cần thiết cho giao dịch, bảo mật hoặc compliance.

Dấu hiệu nhận biết:

• Người dùng phải xác nhận cùng một thông tin nhiều lần.
• Có nhiều màn hình “Xác nhận” liên tiếp nhưng không tạo thêm giá trị.
• OTP hoặc xác thực được yêu cầu lặp lại dù không có thay đổi đáng kể.
• Flow có thể hoàn tất với ít bước hơn nhưng vẫn duy trì các bước trung gian.

Tác động: Mỗi bước xác nhận thêm làm tăng thời gian và thao tác, tạo thêm điểm rơi mà không cải thiện đáng kể kết quả giao dịch.

Cách sửa: Rà soát từng bước theo nguyên tắc “Có thực sự cần thiết không?”. Gộp các bước trùng lặp và chỉ giữ những xác nhận bắt buộc về giao dịch, bảo mật hoặc compliance.

Kiểm tra sau khi sửa: Kiểm tra thông tin → OTP khi thực sự cần → Hoàn tất.

Mốc kiểm tra: Bỏ bước thừa + mỗi bước đều có lý do rõ ràng.

3.5 Sửa bước trước làm mất toàn bộ tiến trình

Hình 3.5. Minh họa lỗi “Sửa bước trước làm mất toàn bộ tiến trình” và cách sửa.

Đây là vấn đề về User Control and Freedom: người dùng cần có khả năng quay lại sửa thông tin mà không bị buộc phải làm lại toàn bộ flow. Khi một thay đổi nhỏ khiến dữ liệu đã nhập bị reset, người dùng cảm thấy mình đang bị “phạt” vì muốn sửa lỗi.

Dấu hiệu nhận biết:

• Người dùng đang ở bước 3 nhưng phải quay lại bước 1 để chỉnh thông tin.
• Dữ liệu ở các bước đã hoàn thành bị xóa hoặc reset.
• Người dùng phải nhập lại thông tin sau khi quay lại.
• Không có cách chỉnh trực tiếp một bước cụ thể mà không ảnh hưởng các bước khác.

Tác động: Mất dữ liệu đã nhập làm tăng công sức, thời gian và frustration, đặc biệt trong các flow dài.

Cách sửa: Cho phép người dùng chỉnh sửa trực tiếp từng bước qua progress bar hoặc nút Edit, đồng thời giữ nguyên dữ liệu của các bước không thay đổi.

Kiểm tra sau khi sửa: Đang ở bước 3 → chỉnh bước 1 → dữ liệu bước 2 và 3 vẫn được giữ nguyên.

Mốc kiểm tra: Edit không reset dữ liệu.

4 Lỗi CTA & Buttons

CTA (Call to Action) là điểm chuyển từ ý định sang hành động. Một CTA yếu có thể làm mất hiệu quả của toàn bộ trải nghiệm tối ưu trước đó. CTA tốt cần làm rõ hành động chính, kết quả sau khi bấm và lý do chưa thể thực hiện. Thiết kế đúng giúp giảm do dự và thúc đẩy người dùng hành động ngay tại thời điểm quyết định.

4.1 Nhiều CTA cạnh tranh trên cùng màn hình

Hình 4.1. Minh họa lỗi “Nhiều CTA cạnh tranh trên cùng màn hình” và cách sửa.

Theo Hick’s Law, khi có quá nhiều lựa chọn ngang hàng, thời gian ra quyết định tăng và người dùng khó xác định hành động tiếp theo. Mỗi màn hình nên có một CTA chính rõ ràng, các hành động phụ cần được phân cấp về mặt thị giác.

Dấu hiệu nhận biết:

• Một màn hình có nhiều CTA cùng kích thước và độ nổi bật.
• Các nút hướng người dùng đến những hành động khác nhau nhưng không có ưu tiên rõ ràng.
• Người dùng khó xác định đâu là hành động chính cần thực hiện.
• CTA phụ cạnh tranh trực tiếp với CTA chính về màu sắc, kích thước hoặc vị trí.

Tác động: Các lựa chọn ngang cấp làm tăng thời gian cân nhắc và có thể khiến người dùng trì hoãn hoặc không thực hiện hành động nào.

Cách sửa: Xác định một CTA chính theo mục tiêu của từng màn hình. Các hành động phụ dùng secondary button hoặc text link với mức độ nổi bật thấp hơn.

Kiểm tra sau khi sửa: Nhìn vào màn hình và xác định ngay: “Hành động chính tôi nên làm là gì?”

Mốc kiểm tra: 1 CTA chính + phân cấp rõ CTA phụ.

4.2 CTA không nói rõ hành động và kết quả

Hình 4.2. Minh họa lỗi “CTA không nói rõ hành động và kết quả” và cách sửa.

CTA là điểm người dùng chuyển từ ý định sang hành động. Những nhãn quá chung như “Submit”, “Click here” hay “Xác nhận” không cho biết bấm xong sẽ làm gì hoặc nhận được gì, khiến người dùng phải cân nhắc thêm ngay trước thời điểm quyết định.

Dấu hiệu nhận biết:

• CTA dùng các nhãn chung như “Submit”, “Click here”, “Xác nhận”.
• Người dùng không thể dự đoán kết quả sau khi bấm.
• CTA không mô tả rõ hành động hoặc giá trị nhận được.
• Cùng một nhãn CTA được dùng cho nhiều hành động khác nhau.

Tác động: CTA thiếu thông tin làm giảm confidence và tăng do dự ngay trước khi người dùng thực hiện hành động.

Cách sửa: Viết CTA theo hành động cụ thể + kết quả người dùng nhận được, thay vì mô tả thao tác chung chung.

Kiểm tra sau khi sửa:
“Nhận báo cáo audit” → biết sẽ nhận báo cáo.
“Đặt lịch tư vấn” → biết sẽ đặt lịch.
“Nạp 500K ngay” → biết rõ hành động và số tiền.

Mốc kiểm tra: Action + Outcome.

4.3 Kích thước hoặc khoảng cách touch target không đủ

Hình 4.3. Minh họa lỗi “Kích thước hoặc khoảng cách touch target không đủ” và cách sửa.

Theo Fitts’s Law, mục tiêu càng nhỏ hoặc càng gần các mục tiêu khác, người dùng càng khó chạm chính xác. Trên mobile, touch target quá nhỏ hoặc đặt quá sát nhau dễ gây bấm nhầm và buộc người dùng thao tác lại.

Dấu hiệu nhận biết:

• Icon hoặc nút có vùng chạm nhỏ hơn kích thước hiển thị cần thiết.
• Các phần tử có thể bấm nằm quá sát nhau.
• Người dùng thường bấm nhầm sang phần tử bên cạnh.
• Phải chạm nhiều lần mới thực hiện đúng hành động.

Tác động: Touch target nhỏ hoặc quá sát nhau làm tăng lỗi thao tác, đặc biệt trên mobile và khi người dùng thao tác nhanh.

Cách sửa: Đảm bảo touch target đạt tối thiểu 24 × 24 CSS px theo WCAG 2.2 hoặc đáp ứng yêu cầu về khoảng cách giữa các target. Với CTA chính trên mobile, nên ưu tiên vùng chạm khoảng 44 × 44 px để thao tác thoải mái hơn.

Kiểm tra sau khi sửa: Chạm vào từng target → không cần căn chính xác vào icon → không kích hoạt nhầm phần tử bên cạnh.

Mốc kiểm tra: WCAG: ≥24 × 24 CSS px + 44 × 44 px là khuyến nghị usability.

4.4 Nút bấm CTA không đủ tương phản với nền

Hình 4.4. Minh họa lỗi “Nút bấm CTA không đủ tương phản với nền” và cách sửa.

Độ tương phản (Contrast) thấp làm giảm khả năng nhận diện giữa CTA và nền, khiến người dùng khó xác định đâu là phần tử có thể tương tác. Vấn đề đặc biệt rõ khi màn hình có ánh sáng mạnh hoặc với người dùng có khả năng nhìn hạn chế.

Dấu hiệu nhận biết:

• CTA có màu gần với màu nền.
• Chữ và nền nút khó phân biệt bằng mắt thường.
• Nút không nổi bật so với các thành phần xung quanh.
• Người dùng phải nhìn kỹ mới xác định được đâu là phần tử có thể bấm.

Tác động: CTA khó nhận diện làm giảm khả năng phát hiện và tương tác, khiến người dùng có thể bỏ qua hành động cần thực hiện.

Cách sửa: Kiểm tra contrast giữa chữ, nền CTA và các thành phần liên quan. Đảm bảo màu sắc đáp ứng WCAG AA và không chỉ dựa vào màu sắc để thể hiện khả năng tương tác.

Kiểm tra sau khi sửa: CTA nổi bật khỏi nền → chữ dễ đọc → vùng có thể bấm được nhận diện ngay.

Mốc kiểm tra: WCAG AA: ≥4.5:1 cho text thông thường.

4.5 Nút CTA bị disable nhưng không nói lý do

Hình 4.5. Minh họa lỗi “Nút CTA bị disable nhưng không nói lý do” và cách sửa.

Khi một nút bị disable mà không có giải thích, người dùng không biết đang thiếu điều kiện nào để tiếp tục. Điều này dễ khiến họ hiểu rằng hệ thống bị lỗi thay vì biết mình cần làm gì.

Dấu hiệu nhận biết:

• CTA “Tiếp tục” bị disable nhưng không có hướng dẫn.
• Người dùng không biết còn thiếu thông tin hoặc thao tác nào.
• Không có trạng thái hoặc thông báo chỉ rõ điều kiện chưa đáp ứng.
• Người dùng phải thử nhiều lần hoặc tự tìm nguyên nhân.

Tác động: Thiếu feedback khiến người dùng mất phương hướng, tưởng hệ thống lỗi và có thể bỏ cuộc giữa flow.

Cách sửa: Hiển thị microcopy hoặc tooltip ngắn giải thích điều kiện còn thiếu và cách hoàn thành để kích hoạt CTA.

Kiểm tra sau khi sửa: CTA “Tiếp tục” bị disable → người dùng thấy ngay “Vui lòng chọn phương thức” → hoàn thành điều kiện → CTA được kích hoạt.

Mốc kiểm tra: Nói rõ điều kiện còn thiếu.

5 Lỗi Visual Hierarchy & Layout

Khi mọi thứ trên trang đều được làm nổi bật, không có gì thực sự nổi bật. Đây là lỗi thường gặp ở những website được xây dựng bởi nhiều team nhưng thiếu một Design System thống nhất. Visual Hierarchy quyết định người dùng sẽ nhìn gì trước, hiểu gì trước và hành động ở đâu. Khi mọi thành phần cùng tranh sự chú ý, người dùng phải tự đoán đâu mới là thông tin quan trọng.

5.1 Mọi phần tử đều cùng lúc nổi bật

Hình 5.1. Minh họa lỗi “Mọi phần tử đều cùng lúc nổi bật” và cách sửa.

Khi quá nhiều thành phần có cùng mức độ nổi bật, Visual Hierarchy bị phá vỡ. Người dùng không biết nên nhìn, đọc và hành động theo thứ tự nào. Mỗi màn hình nên có một điểm nhấn chính, sau đó dùng các cấp độ thị giác thấp hơn để dẫn mắt.

Dấu hiệu nhận biết:

• Nhiều thành phần cùng dùng font lớn, bold hoặc màu nổi bật.
• SALE, MỚI, HOT, CTA và banner cùng cạnh tranh sự chú ý.
• Không xác định được đâu là thông điệp chính khi nhìn vào màn hình.
• Thứ tự đọc và hành động không rõ ràng.

Tác động: Khi mọi thành phần đều nổi bật, không có thành phần nào thực sự nổi bật. Người dùng phải tự xác định đâu là thông tin quan trọng, làm tăng cognitive load và giảm khả năng tập trung vào CTA chính.

Cách sửa: Xác định một điểm nhấn chính cho mỗi màn hình. Phân cấp các thành phần còn lại theo thứ tự: thông điệp chính → bằng chứng → CTA → thông tin phụ.

Kiểm tra sau khi sửa: Nhìn màn hình trong vài giây → xác định được ngay thông điệp chính và hành động cần thực hiện.

Mốc kiểm tra: 1 điểm nhấn chính + hierarchy rõ ràng.

5.2 Nội dung quan trọng bị giấu trong tab

Hình 5.2. Minh họa lỗi “Nội dung quan trọng bị giấu trong tab” và cách sửa.

Baymard ghi nhận 28% website dùng layout tab ngang (horizontal tabs) khiến nội dung cốt lõi như thông số kỹ thuật hoặc mô tả bị user bỏ qua vì không cuộn xuống hoặc không bấm vào tab. Horizontal tabs có thể khiến nội dung quan trọng bị ẩn sau một thao tác click, đặc biệt khi người dùng không nhận ra còn nội dung bên trong các tab. Với thông tin ảnh hưởng trực tiếp đến quyết định, nên hiển thị ngay trên trang thay vì đặt sau tab.

Dấu hiệu nhận biết:

• Thông số kỹ thuật, mô tả hoặc chính sách quan trọng nằm trong tab khác.
• Nội dung quyết định bị ẩn khỏi màn hình mặc định.
• Người dùng phải click tab hoặc cuộn ngang mới tiếp cận được thông tin.
• Tab không làm rõ nội dung nào chứa thông tin quan trọng.

Tác động: Người dùng có thể bỏ qua thông tin cần thiết để đánh giá sản phẩm hoặc dịch vụ, dẫn đến quyết định dựa trên thông tin chưa đầy đủ.

Cách sửa: Đưa nội dung ảnh hưởng trực tiếp đến quyết định ra ngoài tab. Chỉ sử dụng tab cho thông tin bổ sung hoặc nội dung người dùng không cần xem ngay.

Kiểm tra sau khi sửa: Thông số chính hiển thị → lợi ích cốt lõi hiển thị → tab chỉ chứa chi tiết phụ.

Mốc kiểm tra: Nội dung quyết định không bị ẩn sau tab.

5.3 Khoảng cách làm nhóm sai các phần tử

Hình 5.3. Minh họa lỗi “Khoảng cách làm nhóm sai các phần tử” và cách sửa.

Theo nguyên tắc Gestalt Proximity (Nguyên tắc gần gũi/gần kề), người dùng có xu hướng xem các phần tử đặt gần nhau là cùng một nhóm trước khi đọc nội dung. Nếu khoảng cách được phân bổ sai, người dùng có thể ghép nhầm các thành phần và hiểu sai cấu trúc thông tin.

Dấu hiệu nhận biết:

• Nhãn của một trường nằm gần dữ liệu của trường khác hơn dữ liệu của chính nó.
• Khoảng cách giữa các nhóm tương đương với khoảng cách giữa các phần tử trong cùng nhóm.
• Các nhóm nội dung bị trộn về mặt thị giác.
• Người dùng khó xác định phần tử nào thuộc cùng một nhóm.

Tác động: Proximity sai khiến người dùng ghép nhầm các phần tử ngay từ cái nhìn đầu tiên, trước cả khi đọc nội dung, làm tăng thời gian hiểu và khả năng diễn giải sai.

Cách sửa: Dùng khoảng cách để thể hiện quan hệ: phần tử trong cùng nhóm đặt gần nhau, các nhóm khác nhau cách nhau rõ rệt. Khoảng cách giữa hai nhóm nên lớn hơn đáng kể khoảng cách bên trong nhóm.

Kiểm tra sau khi sửa: Nhãn A → dữ liệu A → khoảng cách nhóm rõ → nhãn B → dữ liệu B.

Mốc kiểm tra: Gestalt Proximity + khoảng cách nhóm > khoảng cách trong nhóm.

5.4 Cỡ chữ và khoảng cách thiếu nhất quán

Hình 5.4. Minh họa lỗi “Cỡ chữ và khoảng cách thiếu nhất quán” và cách sửa.

Khi typography và spacing thay đổi tùy từng trang hoặc từng component, người dùng phải liên tục thích nghi với một “nhịp” giao diện mới. Điều này làm tăng cognitive load, đồng thời khiến website thiếu tính nhất quán và giảm cảm nhận về độ chuyên nghiệp.

Dấu hiệu nhận biết:

• Cùng một cấp nội dung nhưng dùng nhiều cỡ chữ khác nhau.
• Khoảng cách giữa các section hoặc component không theo quy luật.
• Cùng một loại component nhưng spacing khác nhau giữa các trang.
• Mỗi trang tạo cảm giác có một hệ thống typography và spacing riêng.

Tác động: Sự thiếu nhất quán làm người dùng khó nhận diện cấp độ thông tin và mối quan hệ giữa các thành phần, đồng thời làm giảm tính nhất quán của trải nghiệm.

Cách sửa: Xây dựng type scale và spacing token cố định trong design system. Quy định rõ cỡ chữ, line-height và khoảng cách cho từng cấp độ, component và layout, sau đó áp dụng xuyên suốt website.

Kiểm tra sau khi sửa: Cỡ chữ theo scale → spacing theo token → cùng một component có cùng quy tắc trên mọi trang.

Mốc kiểm tra: Một hệ thống type scale + spacing dùng chung toàn website.

6 Lỗi Mobile & Responsive

Phần lớn traffic hiện nay đến từ mobile, nhưng nhiều website vẫn được thiết kế theo tư duy desktop rồi thu nhỏ lại. Mobile không phải bản desktop bị thu nhỏ. Nội dung, thao tác, khoảng chạm và thứ tự ưu tiên phải được thiết kế cho màn hình hẹp và thao tác bằng ngón tay.

6.1 Thiết kế desktop trước rồi thu nhỏ cho mobile

Hình 6.1. Minh họa lỗi “Thiết kế desktop trước rồi thu nhỏ cho mobile” và cách sửa.

Thiết kế desktop rồi thu nhỏ trực tiếp xuống mobile thường làm mất hierarchy, gây chật chội và không tối ưu cho thao tác bằng ngón tay. Mobile-first giúp xác định trước nội dung và hành động cốt lõi trong không gian màn hình hạn chế, sau đó mới mở rộng cho desktop.

Dấu hiệu nhận biết:

• Layout desktop nhiều cột bị thu nhỏ thành các khối chật trên mobile.
• Nội dung quan trọng bị đẩy xuống hoặc mất thứ tự ưu tiên.
• Nút và các vùng tương tác nằm quá sát nhau.
• Người dùng phải zoom hoặc cuộn ngang để xem và thao tác.

Tác động: Layout mất hierarchy và không phù hợp với không gian màn hình cũng như thao tác bằng ngón tay trên mobile.

Cách sửa: Thiết kế mobile-first, xác định trước nội dung, hierarchy và CTA cốt lõi trên màn hình nhỏ. Desktop là phiên bản mở rộng từ cấu trúc này, không phải bản mobile thu nhỏ của desktop.

Kiểm tra sau khi sửa: Mobile 1 cột → nội dung quan trọng ưu tiên trước → CTA nằm trong vùng thao tác thuận tiện.

Mốc kiểm tra: Mobile-first + hierarchy được giữ nguyên trên mọi breakpoint.

6.2 Chữ nhỏ đến mức phải zoom mới đọc được

Hình 6.2. Minh họa lỗi “Chữ nhỏ đến mức phải zoom mới đọc được” và cách sửa.

Cỡ chữ quá nhỏ làm giảm khả năng đọc trên màn hình nhỏ và buộc người dùng phải phóng to hoặc tăng thêm thao tác chỉ để tiếp nhận nội dung cơ bản. Với nội dung chính trên mobile, nên ưu tiên kích thước chữ đủ lớn và line-height thoáng.

Dấu hiệu nhận biết:

• Nội dung chính dùng cỡ chữ quá nhỏ, đặc biệt khoảng 12–14 px.
• Các đoạn văn dài có mật độ chữ dày, khó quét.
• Người dùng phải zoom để đọc nội dung.
• Line-height thấp khiến các dòng chữ bị dính vào nhau.

Tác động: Khả năng đọc giảm, người dùng phải thực hiện thêm thao tác và dễ bỏ qua nội dung trên màn hình nhỏ.

Cách sửa: Dùng tối thiểu khoảng 16 px cho nội dung chính trên mobile và thiết lập line-height đủ thoáng để cải thiện khả năng đọc.

Kiểm tra sau khi sửa: Cỡ chữ ≥16 px → line-height khoảng 1.5–1.7 → đọc nội dung ngay ở mức zoom mặc định.

Mốc kiểm tra: Nội dung chính ≥16 px + line-height đủ thoáng.

6.3 Layout nhảy khi ảnh hoặc quảng cáo tải xong

Hình 6.3. Minh họa lỗi “Layout nhảy khi ảnh hoặc quảng cáo tải xong” và cách sửa.

Hiện tượng này được gọi là Cumulative Layout Shift (CLS), một chỉ số trong Core Web Vitals. Khi nội dung hoặc thành phần tải không đồng thời làm thay đổi vị trí các element, người dùng có thể mất vị trí đang đọc hoặc bấm nhầm vào element khác.

Dấu hiệu nhận biết:

• Nội dung đang đọc bất ngờ bị đẩy xuống hoặc sang vị trí khác.
• Ảnh hoặc banner xuất hiện khiến layout thay đổi kích thước.
• CTA hoặc nút tương tác di chuyển ngay trước khi người dùng bấm.
• Người dùng phải tìm lại vị trí nội dung sau khi trang tiếp tục tải.

Tác động: Layout không ổn định làm gián đoạn trải nghiệm, gây bấm nhầm và khiến người dùng mất vị trí đang đọc hoặc thao tác.

Cách sửa: Reserve sẵn kích thước hoặc aspect ratio cho ảnh, video, quảng cáo và các thành phần tải bất đồng bộ trước khi nội dung thực tế xuất hiện.

Kiểm tra sau khi sửa: Khung ảnh được giữ cố định → nội dung tải vào đúng vị trí → CTA không bị dịch chuyển.

Mốc kiểm tra: Layout ổn định + giảm CLS.

6.4 Popup mobile che kín màn hình và khó đóng

Hình 6.4. Minh họa lỗi “Popup mobile che kín màn hình và khó đóng” và cách sửa.

Popup chiếm toàn màn hình mà không có cách đóng rõ ràng làm giảm User Control and Freedom. Người dùng cần có khả năng thoát hoặc tiếp tục xem nội dung chính mà không phải tìm cách xử lý một lớp giao diện đang chặn màn hình.

Dấu hiệu nhận biết:

• Popup chiếm gần hoặc toàn bộ màn hình mobile.
• Nút đóng nhỏ, khó nhìn hoặc nằm ở vị trí khó chạm.
• Không thể đóng popup bằng thao tác rõ ràng.
• Nội dung phía sau bị chặn hoàn toàn dù popup không thực sự bắt buộc.

Tác động: Người dùng cảm thấy bị mắc kẹt, khó tiếp cận nội dung chính và có thể rời trang thay vì tiếp tục tương tác.

Cách sửa: Dùng nút đóng rõ ràng, đủ lớn và dễ chạm. Hạn chế popup che toàn bộ nội dung; nếu không bắt buộc, nên giữ một phần nội dung nền để người dùng vẫn nhận biết context.

Kiểm tra sau khi sửa: Popup/banner gọn → nút đóng dễ nhận biết → vùng chạm khoảng 44 × 44 px → nội dung chính vẫn có thể tiếp cận.

Mốc kiểm tra: Thoát trong 1 chạm + không bị khóa trong popup.

7 Lỗi Performance & Loading

Tốc độ thực tế quan trọng, nhưng cảm nhận về thời gian chờ cũng quan trọng không kém. Người dùng cần biết hệ thống đang xử lý, thao tác đã được ghi nhận và khi nào có kết quả. Tốc độ tải ảnh hưởng trực tiếp đến trải nghiệm và hiệu suất SEO, đặc biệt thông qua các chỉ số Core Web Vitals.

7.1 Trang tải chậm nhưng không có loading state

Hình 7.1. Minh họa lỗi “Trang tải chậm nhưng không có loading state” và cách sửa.

Theo heuristic Visibility of System Status của Nielsen Norman Group, hệ thống cần cho người dùng biết trạng thái hiện tại và phản hồi kịp thời sau mỗi thao tác. Khi trang mất thời gian tải nhưng không có loading state, người dùng khó phân biệt giữa “đang xử lý” và “hệ thống bị treo”.

Dấu hiệu nhận biết:

• Màn hình trắng hoặc nội dung trống trong thời gian chờ.
• Không có chỉ báo hệ thống đang tải dữ liệu.
• Người dùng không biết thao tác đã được ghi nhận hay chưa.
• Người dùng có xu hướng reload hoặc bấm lại thao tác.

Tác động: Người dùng mất cảm giác kiểm soát, dễ cho rằng hệ thống lỗi hoặc bị treo, dẫn đến reload, thao tác lặp hoặc rời trang.

Cách sửa: Hiển thị skeleton screen hoặc spinner ngay khi bắt đầu tải; với thao tác cần thời gian xử lý, hiển thị trạng thái phù hợp như “Đang xử lý...”.

Kiểm tra sau khi sửa: Thực hiện thao tác → loading state xuất hiện ngay → người dùng biết hệ thống đang xử lý → nội dung hiển thị sau khi hoàn tất.

Mốc kiểm tra: Visibility of System Status + loading state xuất hiện ngay khi hệ thống bắt đầu xử lý.

7.2 Ảnh chưa được tối ưu dung lượng

Hình 7.2. Minh họa lỗi “Ảnh chưa được tối ưu dung lượng” và cách sửa.

Ảnh có dung lượng lớn làm tăng thời gian tải tài nguyên và có thể ảnh hưởng trực tiếp đến Largest Contentful Paint (LCP), đặc biệt với ảnh hero hoặc nội dung nằm trong viewport đầu tiên. Các ảnh dưới màn hình đầu nên được lazy-load để tránh tải tài nguyên không cần thiết quá sớm.

Dấu hiệu nhận biết:

• Ảnh hero có dung lượng lớn, không phù hợp với kích thước hiển thị.
• Nhiều ảnh được tải ngay khi mở trang dù chưa xuất hiện trên màn hình.
• LCP bị ảnh hưởng bởi thời gian tải ảnh.
• Ảnh có kích thước file lớn hơn đáng kể so với nhu cầu hiển thị thực tế.

Tác động: Tăng thời gian tải trang, làm chậm LCP và khiến người dùng phải chờ lâu hơn trước khi nội dung chính xuất hiện.

Cách sửa: Nén ảnh, dùng định dạng phù hợp như WebP/AVIF, cung cấp kích thước ảnh phù hợp với viewport và lazy-load các ảnh nằm dưới màn hình đầu. Không lazy-load ảnh LCP.

Kiểm tra sau khi sửa: Ảnh được nén → ảnh dưới fold chỉ tải khi cần → ảnh LCP được ưu tiên → kiểm tra lại LCP và tổng dung lượng trang.

Mốc kiểm tra: Image size + LCP + Lazy loading.

7.3 Hành động đang xử lý nhưng không có phản hồi

Hình 7.3. Minh họa lỗi “Hành động đang xử lý nhưng không có phản hồi” và cách sửa.

Khi một thao tác đang được xử lý nhưng giao diện không phản hồi, người dùng có thể cho rằng thao tác chưa được ghi nhận và thực hiện lại. Điều này vừa làm tăng ma sát vừa có thể dẫn đến duplicate request.

Dấu hiệu nhận biết:

• Bấm Submit nhưng nút không thay đổi trạng thái.
• Không có loading hoặc thông báo đang xử lý.
• Người dùng có thể tiếp tục bấm nút nhiều lần.
• Một thao tác tạo ra nhiều request liên tiếp.

Tác động: Người dùng mất niềm tin vào trạng thái hệ thống, dễ thao tác lặp và có nguy cơ tạo dữ liệu hoặc giao dịch trùng.

Cách sửa: Ngay sau lần bấm đầu tiên, disable nút và hiển thị trạng thái như “Đang gửi…”. Đồng thời xử lý phía backend theo hướng idempotent khi phù hợp để ngăn request trùng.

Kiểm tra sau khi sửa: Bấm Gửi → nút chuyển sang “Đang gửi…” → nút tạm khóa → chỉ ghi nhận một request.

Mốc kiểm tra: Immediate Feedback + Chặn Duplicate Request.

Với các ngành đòi hỏi độ tin cậy cao như tài chính, y tế hoặc các sản phẩm liên quan đến tiền của người dùng, nhóm lỗi này ảnh hưởng trực tiếp đến quyết định sử dụng mà không chỉ là vấn đề thẩm mỹ. Niềm tin được xây dựng từ những bằng chứng nhỏ nhưng nhất quán: đơn vị vận hành, thông tin liên hệ, chính sách, giấy phép và các đánh giá có thể kiểm chứng.

8.1 Thông tin pháp lý và đơn vị vận hành bị giấu

Hình 8.1. Minh họa lỗi “Thông tin pháp lý và đơn vị vận hành bị giấu” và cách sửa.

Với các sản phẩm tài chính và crypto, thông tin về pháp nhân, đơn vị vận hành và giấy phép là những yếu tố quan trọng để người dùng đánh giá mức độ minh bạch và tin cậy. Nếu thông tin này khó tìm hoặc không được cung cấp rõ ràng, người dùng có thể do dự trước khi đăng ký, nạp tiền hoặc giao dịch.

Dấu hiệu nhận biết:

• Không tìm thấy thông tin pháp nhân hoặc đơn vị vận hành.
• Thông tin giấy phép không được công bố rõ ràng.
• Footer thiếu thông tin doanh nghiệp và pháp lý cơ bản.
• Người dùng phải qua nhiều tầng menu mới tìm được thông tin.
• Không có liên kết đến nguồn xác minh giấy phép khi cần.

Tác động: Người dùng thiếu cơ sở để đánh giá tính minh bạch và có thể giảm mức độ tin tưởng khi thực hiện các hành động có rủi ro tài chính.

Cách sửa: Công khai thông tin pháp nhân, đơn vị vận hành và giấy phép ở footer hoặc một trang pháp lý riêng dễ truy cập. Với giấy phép có thể xác minh, nên liên kết đến nguồn chính thức khi phù hợp.

Kiểm tra sau khi sửa: Footer → thông tin doanh nghiệp → giấy phép/pháp lý → nguồn xác minh có thể truy cập trực tiếp.

Mốc kiểm tra: Legal Transparency + Information Findability

8.2 Testimonial không thể xác minh nguồn

Hình 8.2. Minh họa lỗi “Testimonial không thể xác minh nguồn” và cách sửa.

Testimonial là một dạng social proof, nhưng giá trị thuyết phục phụ thuộc vào khả năng xác minh nguồn. Những review quá chung chung, không có danh tính hoặc nguồn tham chiếu rõ ràng có thể khiến người dùng khó đánh giá mức độ đáng tin cậy.

Dấu hiệu nhận biết:

• Testimonial chỉ có nội dung chung chung như “Dịch vụ rất tốt”.
• Không có tên hoặc thông tin nhận diện người đánh giá.
• Không có công ty, chức danh hoặc bối cảnh sử dụng.
• Không có liên kết hoặc nguồn gốc để kiểm tra.
• Nhiều testimonial có cách viết, độ dài hoặc cấu trúc tương tự nhau.

Tác động: Người dùng thiếu bằng chứng để kiểm chứng review, từ đó giảm giá trị của social proof và có thể nghi ngờ tính xác thực của nội dung.

Cách sửa: Ưu tiên testimonial có danh tính, bối cảnh và nguồn có thể xác minh. Có thể bổ sung tên, chức danh, công ty/dự án và liên kết đến nguồn gốc khi được phép.

Kiểm tra sau khi sửa: Tên + chức danh → công ty/bối cảnh → nội dung đánh giá → nguồn có thể kiểm tra.

Mốc kiểm tra: Traceable Social Proof.

8.3 Thông tin liên hệ khó tìm

Hình 8.3. Minh họa lỗi “Thông tin liên hệ khó tìm” và cách sửa.

Thông tin liên hệ là một phần của transparency và trust. Khi người dùng không dễ dàng tìm thấy cách liên hệ hoặc xác định đơn vị đứng sau website, họ có thể do dự, đặc biệt với các sản phẩm yêu cầu giao dịch hoặc cung cấp thông tin cá nhân.

Dấu hiệu nhận biết:

• Trang Liên hệ chỉ nằm sâu trong menu phụ.
• Không có liên kết Liên hệ hoặc Giới thiệu ở các vị trí quen thuộc.
• Website chỉ cung cấp form mà không có kênh liên hệ khác.
• Không có email, số điện thoại hoặc địa chỉ rõ ràng.
• Người dùng phải tìm kiếm nhiều bước mới xác định được cách liên hệ.

Tác động: Tăng nỗ lực tìm kiếm thông tin và làm giảm cảm nhận về tính minh bạch, khả năng hỗ trợ của tổ chức.

Cách sửa: Đặt Liên hệ và Giới thiệu ở vị trí dễ nhận biết như header hoặc footer trên toàn website. Cung cấp các kênh liên hệ phù hợp như email, điện thoại và địa chỉ.

Kiểm tra sau khi sửa: Mở bất kỳ trang nào → tìm Liên hệ/Giới thiệu → truy cập trực tiếp → thấy email, điện thoại và địa chỉ rõ ràng.

Mốc kiểm tra: Contact Findability + Site-wide Access.

8.4 Tạo khẩn cấp giả bằng dark pattern

Hình 8.4. Minh họa lỗi “Tạo khẩn cấp giả bằng dark pattern” và cách sửa.

Sử dụng urgency không có cơ sở thực tế như đồng hồ đếm ngược giả hoặc số lượng còn lại không chính xác có thể tạo áp lực không cần thiết và làm suy giảm niềm tin. Với các thông tin về thời hạn, số lượng hoặc ưu đãi, dữ liệu hiển thị cần phản ánh đúng trạng thái thực tế.

Dấu hiệu nhận biết:

• Đồng hồ đếm ngược về 0 nhưng ưu đãi vẫn tiếp tục.
• Số lượng “còn lại” thay đổi bất thường hoặc không khớp dữ liệu thực tế.
• Countdown hoặc số lượng được reset khi reload/truy cập lại.
• Không có điều kiện hoặc thời hạn rõ ràng cho thông tin khẩn cấp.

Tác động: Người dùng có thể cảm thấy bị thúc ép hoặc đánh lừa, làm suy giảm trust và trong một số trường hợp có thể phát sinh rủi ro pháp lý tùy thị trường.

Cách sửa: Chỉ sử dụng urgency khi có dữ liệu thực tế phía sau. Hiển thị rõ thời hạn, số lượng hoặc điều kiện áp dụng và đảm bảo dữ liệu được cập nhật nhất quán.

Kiểm tra sau khi sửa: “Hạn đăng ký 30/09” → thời hạn có thật → “Còn 12 chỗ” → đối chiếu được với dữ liệu thực tế → điều kiện áp dụng rõ ràng.

Mốc kiểm tra: Real Urgency + Data Accuracy + Clear Conditions.

9 Lỗi Feedback & System Status

Đây là nhóm lỗi tưởng nhỏ nhưng có thể ảnh hưởng trực tiếp đến cảm giác tin tưởng vào hệ thống ngay từ những tương tác đầu tiên. Mọi thao tác đều cần một phản hồi phù hợp. Khi người dùng không nhận được tín hiệu sau khi bấm nút, họ dễ bấm lại, nghi ngờ hệ thống hoặc rời khỏi quy trình.

9.1 Bấm nút nhưng không có phản hồi

Hình 9.1. Minh họa lỗi “Bấm nút nhưng không có phản hồi” và cách sửa.

User bấm nút nhưng không nhận được phản hồi. Đây là lỗi vi phạm heuristic Visibility of System Status của Nielsen Norman Group. Mọi thao tác cần có tín hiệu xác nhận trong thời gian hợp lý, dù chỉ là một thay đổi trạng thái nhỏ.

Dấu hiệu nhận biết:

• Bấm nút nhưng giao diện không thay đổi.
• Không có trạng thái nhấn, loading hoặc thông báo.
• Người dùng bấm lại vì không chắc thao tác đã được ghi nhận.
• Kết quả của thao tác không được phản ánh trên giao diện.

Tác động: Thiếu phản hồi khiến người dùng mất định hướng, dễ thao tác lặp hoặc cho rằng hệ thống không hoạt động.

Cách sửa: Phản hồi ngay bằng trạng thái nhấn, loading, thay đổi giao diện hoặc thông báo ngắn tùy loại hành động.

Kiểm tra sau khi sửa: Bấm nút → có phản hồi ngay → “Đã ghi nhận” hoặc “Đang xử lý…” → hiển thị kết quả sau khi hoàn tất.

Mốc kiểm tra: Immediate Feedback + Visibility of System Status.

9.2 Submit thành công nhưng không có confirmation rõ ràng

Hình 9.2. Minh họa lỗi “Submit thành công nhưng không có confirmation rõ ràng” và cách sửa.

Sau một hành động quan trọng, người dùng cần biết thao tác đã hoàn tất và kết quả là gì. Nếu giao diện không xác nhận rõ ràng, người dùng có thể nghi ngờ trạng thái giao dịch và thực hiện lại.

Dấu hiệu nhận biết:

• Submit thành công nhưng giao diện gần như không thay đổi.
• Không có thông báo xác nhận kết quả.
• Không có mã giao dịch, mã yêu cầu hoặc thông tin tham chiếu khi cần.
• Người dùng phải kiểm tra email hoặc lịch sử giao dịch mới biết kết quả.

Tác động: Người dùng không chắc hành động đã hoàn tất, dễ submit lại, tạo duplicate hoặc rời khỏi flow trong trạng thái không rõ ràng.

Cách sửa: Hiển thị confirmation ngay sau khi hoàn tất. Với hành động quan trọng, cung cấp thông tin tham chiếu như mã yêu cầu/giao dịch và gửi email hoặc thông báo bổ sung khi phù hợp.

Kiểm tra sau khi sửa: Submit → “Gửi thành công” → mã yêu cầu #2481 → email xác nhận đã được gửi.

Mốc kiểm tra: Clear Confirmation + Result Visibility.

10 Lỗi Error Handling & Recovery

Cách website xử lý lỗi phản ánh rõ mức độ trưởng thành của thiết kế sản phẩm. Một thông báo lỗi chuẩn không chỉ nói rằng có vấn đề, mà cần giúp người dùng hiểu lỗi ở đâu, vì sao xảy ra, cần làm gì tiếp theo và dữ liệu nào vẫn được giữ lại.

10.1 Thông báo lỗi quá chung chung

Hình 10.1. Minh họa lỗi “Thông báo lỗi quá chung chung” và cách sửa.

Thông báo lỗi cần giúp người dùng hiểu điều gì đã xảy ra, lỗi nằm ở đâu và cần làm gì tiếp theo. Các thông báo như “Đã có lỗi xảy ra” hoặc “Vui lòng thử lại” không cung cấp đủ thông tin để người dùng tự khắc phục.

Dấu hiệu nhận biết:

• Chỉ hiển thị “Đã có lỗi xảy ra” hoặc “Vui lòng thử lại”.
• Không xác định được field hoặc bước gây lỗi.
• Không giải thích nguyên nhân hoặc điều kiện cần đáp ứng.
• Người dùng phải thử lại nhiều lần để tìm cách xử lý.

Tác động: Người dùng không xác định được nguyên nhân và cách khắc phục, dễ thao tác ngẫu nhiên hoặc bỏ cuộc.

Cách sửa: Error message cần nêu rõ lỗi gì + ở đâu + cách sửa, đặt gần vị trí lỗi và cung cấp ví dụ khi cần.

Kiểm tra sau khi sửa: Nhập email sai → “Email không đúng định dạng” → chỉ rõ tại field Email → “Ví dụ: name@company.com”.

Mốc kiểm tra: Actionable Error + Clear Recovery Path.

10.2 Gặp lỗi là mất toàn bộ dữ liệu đã nhập

Hình 10.2. Minh họa lỗi “Gặp lỗi là mất toàn bộ dữ liệu đã nhập” và cách sửa.

Khi form gặp lỗi nhưng làm mất toàn bộ dữ liệu đã nhập, người dùng phải thực hiện lại những thao tác không liên quan đến lỗi. Hệ thống nên giữ lại dữ liệu hợp lệ và chỉ yêu cầu người dùng sửa phần không hợp lệ.

Dấu hiệu nhận biết:

• Người dùng đã điền nhiều field nhưng form bị reset sau khi submit lỗi.
• Chỉ một field sai nhưng toàn bộ dữ liệu bị xóa.
• Người dùng phải nhập lại thông tin đã hợp lệ.
• Không có cơ chế khôi phục dữ liệu sau lỗi hoặc reload.

Tác động: Mất công sức đã nhập, tăng frustration và làm người dùng có xu hướng bỏ form, đặc biệt với form dài.

Cách sửa: Preserve toàn bộ dữ liệu hợp lệ sau lỗi; chỉ đánh dấu field không hợp lệ và yêu cầu người dùng sửa đúng phần đó.

Kiểm tra sau khi sửa: Submit → 5 field hợp lệ vẫn được giữ → 1 field lỗi được đánh dấu → sửa field → gửi lại thành công.

Mốc kiểm tra: Preserve Input + Field-level Recovery.

10.3 Không có Undo cho hành động quan trọng

Hình 10.3. Minh họa lỗi “Không có Undo cho hành động quan trọng” và cách sửa.

Theo heuristic User Control and Freedom, người dùng cần có cách thoát hoặc khôi phục khi thực hiện nhầm một hành động. Với các thao tác như xoá hoặc huỷ, nếu hệ thống thực hiện ngay và không có khả năng phục hồi, chỉ một click nhầm cũng có thể gây hậu quả khó đảo ngược.

Dấu hiệu nhận biết:

• Hành động xoá/huỷ được thực hiện ngay sau một click.
• Không có Undo hoặc cơ chế khôi phục.
• Dữ liệu biến mất ngay và không thể lấy lại.
• Người dùng không có cơ hội kiểm tra hoặc huỷ thao tác trước khi hoàn tất.

Tác động: Một thao tác nhầm có thể dẫn đến mất dữ liệu hoặc thay đổi trạng thái ngoài ý muốn, làm tăng rủi ro và frustration.

Cách sửa: Với hành động có thể đảo ngược, cung cấp Undo trong một khoảng thời gian ngắn sau khi thực hiện. Với hành động không thể đảo ngược, nên có bước xác nhận rõ ràng trước khi thực hiện.

Kiểm tra sau khi sửa: Xoá dự án → “Đã xoá dự án” → Hoàn tác trong 10 giây → dữ liệu được khôi phục.

Mốc kiểm tra: User Control + Undo Window.

11 Lỗi Search & Filter

Với website có nhiều nội dung hoặc sản phẩm, Search và Filter thường là con đường ngắn nhất đến mục tiêu, nhưng cũng dễ bị bỏ quên khi tối ưu UX. Khi tìm kiếm không hiệu quả, trang không có kết quả hoặc bộ lọc quá phức tạp, hành trình của người dùng rất dễ biến thành ngõ cụt.

11.1 Search không chịu được lỗi chính tả

Hình 11.1. Minh họa lỗi “Search không chịu được lỗi chính tả” và cách sửa.

Search nên có khả năng xử lý lỗi chính tả phổ biến và truy vấn gần đúng thay vì trả về 0 kết quả ngay khi người dùng gõ sai một vài ký tự. Khi ý định tìm kiếm vẫn có thể xác định, hệ thống nên gợi ý hoặc trả về kết quả phù hợp.

Dấu hiệu nhận biết:

• Chỉ sai một ký tự nhưng search trả về 0 kết quả.
• Không có gợi ý từ khóa gần đúng.
• Không đề xuất cách sửa truy vấn.
• Người dùng phải tự đoán và nhập lại từ khóa.

Tác động: Một lỗi nhập liệu nhỏ có thể khiến người dùng không tìm thấy nội dung dù hệ thống có kết quả phù hợp.

Cách sửa: Sử dụng fuzzy search, typo tolerance và gợi ý từ khóa gần nhất. Khi có độ tin cậy cao, có thể tự động sửa truy vấn và thông báo cho người dùng.

Kiểm tra sau khi sửa: Nhập “audti UX” → “Có phải bạn muốn tìm audit UX?” → hiển thị kết quả phù hợp.

Mốc kiểm tra: Fuzzy Search + Typo Tolerance.

11.2 Không có autosuggest khi người dùng gõ

Hình 11.2. Minh họa lỗi “Không có autosuggest khi người dùng gõ” và cách sửa.

Autosuggest giúp người dùng định hướng truy vấn ngay khi nhập và nhanh chóng tiếp cận nội dung phù hợp. Khi không có gợi ý, người dùng phải tự hoàn thiện từ khóa và không biết hệ thống đang có những nội dung nào liên quan.

Dấu hiệu nhận biết:

• Người dùng phải nhập toàn bộ từ khóa trước khi thấy kết quả.
• Không có gợi ý truy vấn khi đang gõ.
• Không đề xuất nội dung hoặc danh mục liên quan.
• Người dùng phải thử nhiều cách diễn đạt để tìm đúng nội dung.

Tác động: Tăng thời gian tìm kiếm và số lần nhập lại, đồng thời làm giảm khả năng người dùng khám phá đúng nội dung có sẵn.

Cách sửa: Hiển thị autosuggest theo thời gian thực, có thể kết hợp gợi ý truy vấn, danh mục và nội dung phổ biến hoặc phù hợp với từ khóa đang nhập.

Kiểm tra sau khi sửa: Nhập “thiết kế web” → gợi ý “thiết kế website” → “thiết kế web chuẩn SEO” → “báo giá thiết kế website”.

Mốc kiểm tra: Realtime Autosuggest + Relevant Suggestions.

11.3 Trang 0 kết quả không gợi ý bước tiếp

Hình 11.3. Minh họa lỗi “Trang 0 kết quả không gợi ý bước tiếp” và cách sửa.

Trang 0 kết quả không nên trở thành điểm kết thúc của hành trình tìm kiếm. Khi không tìm thấy nội dung phù hợp, hệ thống nên giúp người dùng tiếp tục bằng cách gợi ý truy vấn, danh mục hoặc nội dung liên quan.

Dấu hiệu nhận biết:

• Hiển thị “0 kết quả” nhưng không có hướng xử lý tiếp theo.
• Không gợi ý từ khóa gần đúng hoặc cách tìm khác.
• Không có liên kết đến danh mục hoặc nội dung liên quan.
• Người dùng phải quay lại hoặc tìm kiếm lại từ đầu.

Tác động: Người dùng không có đường đi tiếp, biến trang tìm kiếm thành dead end và tăng khả năng rời website.

Cách sửa: Khi không có kết quả, hiển thị từ khóa gần đúng, danh mục liên quan, nội dung phổ biến hoặc đề xuất tìm kiếm khác.

Kiểm tra sau khi sửa: 0 kết quả → gợi ý từ khóa gần nhất → dịch vụ liên quan → nội dung phổ biến.

Mốc kiểm tra: No Dead End + Recovery Path.

11.4 Hiển thị quá nhiều tùy chọn bộ lọc

Hình 11.4. Minh họa lỗi “Hiển thị quá nhiều tùy chọn bộ lọc” và cách sửa.

Bộ lọc có quá nhiều lựa chọn hiển thị cùng lúc làm tăng cognitive load và khiến người dùng khó xác định tiêu chí quan trọng. Đây là một trường hợp có thể áp dụng Hick’s Law và nguyên tắc Progressive Disclosure: ưu tiên lựa chọn phổ biến, các tùy chọn nâng cao chỉ hiển thị khi cần.

Dấu hiệu nhận biết:

• Có quá nhiều tùy chọn filter hiển thị đồng thời.
• Tất cả nhóm filter đều mở sẵn dù mức độ sử dụng khác nhau.
• Các option ít dùng chiếm nhiều không gian hơn filter quan trọng.
• Người dùng mất thời gian xác định nên bắt đầu từ filter nào.
• Không có phân nhóm hoặc thứ tự ưu tiên rõ ràng.

Tác động: Danh sách filter dài làm tăng decision time, gây quá tải lựa chọn và khiến các tiêu chí quan trọng khó được nhận diện.

Cách sửa: Ưu tiên các filter được sử dụng nhiều nhất; nhóm các tùy chọn nâng cao vào “Bộ lọc nâng cao” hoặc accordion; hiển thị số lượng kết quả dự kiến khi phù hợp.

Kiểm tra sau khi sửa: 4 filter phổ biến → Bộ lọc nâng cao ▾ → chọn filter → Xem 128 kết quả.

Mốc kiểm tra: Progressive Disclosure + Filter Prioritization.

12 Lỗi Accessibility

Accessibility thường bị xem là “nice to have”, nhưng thực tế ảnh hưởng đến khả năng sử dụng của một bộ phận đáng kể người dùng và có thể hỗ trợ SEO. Accessibility giúp nhiều người hoàn thành tác vụ trong nhiều điều kiện sử dụng khác nhau. Đây không chỉ là một mục kiểm tra cuối cùng, mà là một tiêu chí chất lượng cần được tích hợp ngay từ quá trình thiết kế sản phẩm.

12.1 Contrast giữa chữ và nền không đạt chuẩn

Hình 12.1. Minh họa lỗi “Contrast giữa chữ và nền không đạt chuẩn” và cách sửa.

Contrast giữa chữ và nền quá thấp làm giảm khả năng đọc, đặc biệt với người có thị lực yếu hoặc khi sử dụng thiết bị trong điều kiện ánh sáng không thuận lợi. Theo WCAG 2.2, văn bản thông thường cần đạt tỷ lệ contrast tối thiểu 4.5:1 để đáp ứng mức AA.

Dấu hiệu nhận biết:

• Chữ xám nhạt trên nền trắng hoặc màu tương tự.
• Nội dung khó đọc khi giảm độ sáng hoặc thay đổi điều kiện ánh sáng.
• Text phụ có contrast thấp hơn đáng kể so với nội dung chính.
• Công cụ kiểm tra contrast cho kết quả dưới 4.5:1 với văn bản thông thường.

Tác động: Giảm khả năng đọc và tiếp cận nội dung, đặc biệt với người có thị lực yếu hoặc trong môi trường ánh sáng không thuận lợi.

Cách sửa: Tăng độ tương phản giữa text và background; đảm bảo tối thiểu 4.5:1 cho văn bản thông thường và 3:1 cho văn bản lớn theo WCAG AA.

Kiểm tra sau khi sửa: Chữ navy → nền trắng → contrast 7.8:1 → đạt WCAG AA.

Mốc kiểm tra: WCAG AA: ≥4.5:1 cho văn bản thông thường.

12.2 Ảnh có ý nghĩa nhưng không có alt text

Hình 12.2. Minh họa lỗi “Ảnh có ý nghĩa nhưng không có alt text” và cách sửa.

Ảnh chứa thông tin hoặc truyền tải ý nghĩa nội dung cần có alt text để công nghệ hỗ trợ có thể nhận biết và truyền đạt nội dung đó. Alt text cũng giúp công cụ tìm kiếm hiểu ngữ cảnh của hình ảnh.

Dấu hiệu nhận biết:

• Ảnh chứa biểu đồ, infographic hoặc thông tin quan trọng nhưng không có thuộc tính alt.
• Screen reader chỉ đọc “image” hoặc không cung cấp thông tin hữu ích.
• Khi ảnh không tải được, người dùng không biết ảnh đang truyền tải nội dung gì.
• Alt text chỉ là tên file như chart.png, image01.jpg hoặc chứa từ khóa không liên quan.
• Ảnh mang nội dung nhưng alt để trống mà không có lý do phù hợp.

Tác động: Người dùng sử dụng screen reader không tiếp cận được thông tin trong ảnh; đồng thời website bỏ lỡ cơ hội cung cấp ngữ cảnh cho công cụ tìm kiếm.

Cách sửa: Viết alt text ngắn gọn, chính xác và mô tả đúng ý nghĩa của ảnh. Ảnh chỉ mang tính trang trí nên dùng alt=""; không nhồi từ khóa vào alt text.

Kiểm tra sau khi sửa: Ảnh biểu đồ → alt="Biểu đồ tăng trưởng lead theo quý" → mô tả đúng nội dung → không nhồi từ khóa.

Mốc kiểm tra: Meaningful Alt + Accurate Description + No Keyword Stuffing.

12.3 Không thể hoàn tất flow bằng bàn phím

Hình 12.3. Minh họa lỗi “Không thể hoàn tất flow bằng bàn phím” và cách sửa.

Theo WCAG 2.2, mọi chức năng của website cần có thể thao tác bằng bàn phím, không phụ thuộc vào chuột. Đây là yêu cầu quan trọng để đảm bảo người dùng có thể hoàn thành tác vụ bằng keyboard hoặc công nghệ hỗ trợ.

Dấu hiệu nhận biết:

• Nhấn Tab nhưng focus không hiển thị hoặc bị mất.
• Thứ tự focus không theo logic của giao diện.
• Không thể mở menu, dropdown hoặc button bằng bàn phím.
• Focus bị kẹt trong modal hoặc không quay lại phần tử phù hợp sau khi đóng.
• Có bước trong flow chỉ thực hiện được bằng chuột.

Tác động: Người dùng không thể hoàn thành các tác vụ chính nếu không sử dụng chuột, tạo rào cản tiếp cận và có thể khiến một phần người dùng không sử dụng được chức năng.

Cách sửa: Đảm bảo toàn bộ interactive elements có thể thao tác bằng bàn phím; duy trì visible focus, thứ tự Tab hợp lý và xử lý đúng focus khi mở/đóng modal, dropdown hoặc menu.

Kiểm tra sau khi sửa: Thực hiện toàn bộ flow chỉ bằng bàn phím → Tab/Shift + Tab di chuyển đúng thứ tự → Enter kích hoạt → Esc đóng modal khi phù hợp → hoàn tất flow không cần chuột.

Mốc kiểm tra: Keyboard-only + Visible Focus + Logical Focus Order.

13 Lỗi Content & Microcopy

Nội dung và microcopy là lớp giao tiếp trực tiếp nhất giữa sản phẩm và user, đặc biệt quan trọng với các ngành có nhiều thuật ngữ chuyên môn như fintech và crypto. Microcopy là lớp giao tiếp trực tiếp giữa sản phẩm và người dùng. Câu chữ tốt làm rõ hành động, điều kiện, hậu quả và khái niệm chuyên môn đúng lúc.

13.1 Thuật ngữ chuyên ngành không được giải thích

Hình 13.1. Minh họa lỗi “Thuật ngữ chuyên ngành không được giải thích” và cách sửa.

Theo heuristic Match Between System and the Real World, giao diện nên sử dụng ngôn ngữ phù hợp với cách người dùng hiểu và gọi vấn đề. Với các thuật ngữ chuyên ngành như gas fee, slippage, KYC, người dùng mới cần được giải thích ngắn gọn ngay tại thời điểm gặp thuật ngữ.

Dấu hiệu nhận biết:

• Thuật ngữ chuyên ngành xuất hiện nhưng không có giải thích.
• Người dùng phải rời flow để tìm hiểu ý nghĩa.
• Tooltip hoặc chú thích không xuất hiện tại nơi thuật ngữ được sử dụng.
• Cùng một thuật ngữ được sử dụng xuyên suốt nhưng không có ngữ cảnh giải thích lần đầu.

Tác động: Người dùng không hiểu điều kiện hoặc chi phí liên quan, dễ do dự, thao tác sai hoặc bỏ dở flow.

Cách sửa: Giải thích ngắn gọn ngay lần đầu thuật ngữ xuất hiện; có thể dùng microcopy, tooltip hoặc link “Tìm hiểu thêm” tùy mức độ phức tạp.

Kiểm tra sau khi sửa: Slippage tolerance → “Mức trượt giá cho phép” → tooltip giải thích ngắn → người dùng hiểu trước khi tiếp tục.

Mốc kiểm tra: First-use Explanation + Contextual Help.

13.2 Copy dài dòng, không đi thẳng vào việc

Hình 13.2. Minh họa lỗi “Copy dài dòng, không đi thẳng vào việc” và cách sửa.

Nội dung giao diện nên giúp người dùng nhanh chóng hiểu thông tin và biết cần làm gì tiếp theo. Copy quá dài hoặc chứa nhiều ý trong một đoạn làm tăng cognitive load, khiến hành động quan trọng dễ bị bỏ qua.

Dấu hiệu nhận biết:

• Một đoạn văn dài nhiều dòng nhưng không có cấu trúc rõ ràng.
• Một câu chứa nhiều ý hoặc thông tin không cần thiết.
• Hành động chính nằm sau phần giải thích dài.
• CTA hoặc thông tin quan trọng bị chìm trong nội dung.

Tác động: Người dùng mất nhiều thời gian đọc, khó xác định thông tin quan trọng và dễ bỏ qua hành động cần thực hiện.

Cách sửa: Viết câu ngắn, mỗi đoạn một ý, đưa thông tin quan trọng và hành động chính lên đầu. Phần giải thích bổ sung đặt phía sau hoặc trong tooltip khi cần.

Kiểm tra sau khi sửa: “Tải báo cáo trước 17:00” → hành động xuất hiện ngay → nội dung giải thích ngắn phía sau.

Mốc kiểm tra: Action First + One Idea per Paragraph.

13.3 Cùng một hành động nhưng dùng nhiều nhãn

Hình 13.3. Minh họa lỗi “Cùng một hành động nhưng dùng nhiều nhãn” và cách sửa.

Theo heuristic Consistency and Standards, cùng một hành động hoặc khái niệm nên được gọi bằng một thuật ngữ nhất quán trong toàn bộ sản phẩm. Việc thay đổi label giữa các màn hình khiến người dùng phải xác định liệu các thuật ngữ khác nhau có đang chỉ cùng một hành động hay không.

Dấu hiệu nhận biết:

• Cùng một hành động nhưng dùng nhiều label như “Nạp tiền”, “Deposit”, “Add funds”.
• Một thuật ngữ được dùng ở menu nhưng thuật ngữ khác xuất hiện trên CTA.
• Cùng một chức năng nhưng tên gọi thay đổi giữa các bước trong flow.
• Người dùng phải suy đoán liệu các label khác nhau có phải cùng một chức năng.

Tác động: Tăng cognitive load, làm giảm khả năng nhận diện và khiến người dùng có thể hiểu nhầm các thuật ngữ là những chức năng khác nhau.

Cách sửa: Xác định một thuật ngữ chuẩn cho mỗi hành động/khái niệm và áp dụng nhất quán trên menu, CTA, heading, form, thông báo và tài liệu hướng dẫn.

Kiểm tra sau khi sửa: Cùng một hành động → “Nạp tiền” trên menu → “Nạp tiền” trên CTA → “Nạp tiền” trong confirmation.

Mốc kiểm tra: Consistency + One Concept, One Label.

14 Lỗi Onboarding & Empty States

Onboarding quyết định người dùng có ở lại đủ lâu để nhận ra giá trị của sản phẩm hay không. Mục tiêu là đưa họ đến giá trị đầu tiên càng sớm càng tốt. Empty state cũng không nên chỉ báo rằng chưa có dữ liệu, mà cần giải thích điều gì đang xảy ra và người dùng nên làm gì tiếp theo.

14.1 Onboarding quá dài trước khi thấy giá trị

Hình 14.1. Minh họa lỗi “Onboarding quá dài trước khi thấy giá trị” và cách sửa.

Onboarding nên đưa người dùng đến giá trị cốt lõi đầu tiên càng sớm càng tốt. Khi phải hoàn thành quá nhiều bước trước khi thấy sản phẩm có ích gì, time-to-value tăng và người dùng có thể rời flow trước khi đạt được “aha moment”.

Dấu hiệu nhận biết:

• Người dùng phải hoàn thành nhiều bước trước khi được sử dụng chức năng chính.
• Yêu cầu thông tin hoặc thiết lập nhiều hơn mức cần thiết để bắt đầu.
• Các bước như chọn sở thích, xem tour hoặc kết nối ứng dụng xuất hiện trước giá trị cốt lõi.
• Người dùng chưa tạo được kết quả đầu tiên nhưng đã phải hoàn thành một chuỗi thiết lập dài.

Tác động: Tăng time-to-value, làm giảm động lực tiếp tục và tăng khả năng người dùng rời onboarding trước khi trải nghiệm giá trị thực tế.

Cách sửa: Áp dụng Progressive Onboarding: chỉ yêu cầu thông tin thực sự cần thiết để bắt đầu, đưa người dùng đến kết quả đầu tiên sớm và cho phép bổ sung thông tin sau.

Kiểm tra sau khi sửa: Chọn mục tiêu → tạo kết quả đầu tiên → trải nghiệm giá trị → bổ sung thông tin khi cần.

Mốc kiểm tra: Time-to-Value + First Value Delivered.

14.2 Empty state để trống, không hướng dẫn

Hình 14.2. Minh họa lỗi “Empty state để trống, không hướng dẫn” và cách sửa.

Empty state không chỉ thông báo rằng chưa có dữ liệu mà còn là cơ hội hướng dẫn người dùng thực hiện bước tiếp theo. Khi trạng thái trống không có context hoặc CTA, người dùng có thể không biết bắt đầu từ đâu.

Dấu hiệu nhận biết:

• Khu vực nội dung chỉ hiển thị “Chưa có dữ liệu” hoặc để trống.
• Không giải thích vì sao chưa có dữ liệu hoặc cần làm gì tiếp theo.
• Không có CTA cho hành động đầu tiên.
• Người dùng phải tự tìm menu hoặc chức năng để bắt đầu.

Tác động: Người dùng gặp trạng thái trống nhưng không có hướng dẫn, làm gián đoạn hành trình và tăng khả năng bỏ dở.

Cách sửa: Thiết kế empty state gồm context + lợi ích + CTA, tập trung vào hành động đầu tiên người dùng cần thực hiện.

Kiểm tra sau khi sửa: “Chưa có dự án” → “Tạo dự án đầu tiên để bắt đầu” → Tạo dự án → có thêm Xem mẫu nếu phù hợp.

Mốc kiểm tra: First Action + Actionable Empty State.

14.3 Tour onboarding che màn hình và ép đọc

Hình 14.3. Minh họa lỗi “Tour onboarding che màn hình và ép đọc” và cách sửa.

Onboarding nên hỗ trợ người dùng làm quen với sản phẩm mà không cản trở việc sử dụng. Tour hoặc tooltip xuất hiện quá dày, che nội dung hoặc bắt người dùng hoàn thành toàn bộ hướng dẫn có thể làm gián đoạn hành trình và hạn chế khả năng tự khám phá.

Dấu hiệu nhận biết:

• Nhiều tooltip xuất hiện liên tiếp ngay khi người dùng mới vào sản phẩm.
• Tooltip che CTA, nội dung hoặc khu vực người dùng cần thao tác.
• Người dùng không thể tiếp tục sử dụng sản phẩm nếu chưa xem hết tour.
• Không có tùy chọn bỏ qua hoặc đóng hướng dẫn.
• Hướng dẫn xuất hiện trước khi người dùng có nhu cầu sử dụng tính năng.

Tác động: Onboarding trở thành rào cản thay vì hỗ trợ, làm gián đoạn hành trình và khiến người dùng khó khám phá sản phẩm theo nhịp của mình.

Cách sửa: Ưu tiên Contextual Onboarding: hiển thị hướng dẫn ngắn ngay khi người dùng bắt đầu sử dụng tính năng liên quan, cho phép bỏ qua và không khóa các thao tác không cần thiết.

Kiểm tra sau khi sửa: Người dùng mở tính năng → 1 gợi ý ngắn xuất hiện đúng lúc → có thể bỏ qua → tiếp tục thao tác ngay.

Mốc kiểm tra: Contextual + Optional + Non-blocking Onboarding.

15 Lỗi Dark Patterns

Dark pattern là nhóm lỗi khác biệt vì đây không chỉ là sai sót trong thiết kế, mà có thể là cách thiết kế có chủ đích nhằm định hướng hoặc thao túng hành vi người dùng. Một thiết kế như vậy có thể cải thiện chỉ số ngắn hạn nhưng đồng thời làm giảm quyền kiểm soát, tính minh bạch, sự đồng thuận và niềm tin. Với các ngành được quản lý chặt như tài chính, rủi ro còn có thể mở rộng sang tuân thủ và pháp lý.

15.1 Checkbox nhận tin được tick sẵn

Hình 15.1. Minh họa lỗi “Checkbox nhận tin được tick sẵn” và cách sửa.

Checkbox đăng ký nhận tin nên yêu cầu người dùng chủ động lựa chọn. Khi checkbox được tick sẵn, người dùng có thể vô tình đồng ý nhận marketing mà không thực sự chủ động xác nhận. Với các hoạt động thu thập consent, cách thiết kế này cũng có thể không đáp ứng yêu cầu pháp lý tùy thị trường và mục đích xử lý dữ liệu.

Dấu hiệu nhận biết:

• Checkbox nhận email/SMS marketing đã được tick sẵn.
• Người dùng phải chủ động bỏ chọn để không nhận tin.
• Nội dung đồng ý nằm chung với các điều khoản khác, khó xác định phạm vi consent.
• Không có lựa chọn rõ ràng giữa đồng ý và không đồng ý.

Tác động: Người dùng có thể đồng ý ngoài ý muốn, làm giảm quyền kiểm soát và mức độ minh bạch của consent.

Cách sửa: Để checkbox mặc định unchecked, diễn đạt rõ nội dung và phạm vi đồng ý. Không gộp consent marketing vào điều khoản bắt buộc nếu hai mục đích khác nhau.

Kiểm tra sau khi sửa: Mở form → checkbox ở trạng thái ☐ → người dùng chủ động chọn → nội dung consent rõ ràng.

Mốc kiểm tra: Unchecked by Default + Explicit Consent + Clear Scope.

15.2 Nút từ chối dùng confirm shaming

Hình 15.2. Minh họa lỗi “Nút từ chối dùng confirm shaming” và cách sửa.

Confirm shaming là cách dùng ngôn ngữ khiến người dùng cảm thấy có lỗi hoặc xấu hổ khi từ chối một đề nghị. Thay vì giúp người dùng lựa chọn dựa trên giá trị, cách viết này tạo áp lực cảm xúc và làm giảm cảm giác tự chủ.

Dấu hiệu nhận biết:

• Nút từ chối dùng ngôn ngữ tiêu cực hoặc mang tính phán xét.
• Lựa chọn đồng ý được viết tích cực, còn từ chối được viết theo hướng gây cảm giác có lỗi.
• Người dùng có cảm giác phải giải thích hoặc biện minh khi từ chối.
• Hai lựa chọn không có mức độ trung lập tương đương.

Tác động: Làm giảm cảm giác tự chủ và tạo áp lực tâm lý thay vì giúp người dùng đưa ra lựa chọn tự nguyện.

Cách sửa: Viết hai lựa chọn bằng ngôn ngữ trung lập, rõ ràng và tương xứng, không gán giá trị đạo đức cho quyết định từ chối.

Kiểm tra sau khi sửa: Nhận ưu đãi → Để sau → cả hai lựa chọn đều trung lập và không gây áp lực.

Mốc kiểm tra: Neutral Language + Equal Choice Weight.

15.3 Flow hủy khó hơn nhiều so với đăng ký

Hình 15.3. Minh họa lỗi “Flow hủy khó hơn nhiều so với đăng ký” và cách sửa.

Flow hủy dịch vụ không nên cố tình tạo nhiều ma sát hơn đáng kể so với flow đăng ký. Sự bất đối xứng về effort có thể khiến người dùng cảm thấy bị giữ lại ngoài ý muốn và làm suy giảm trust.

Dấu hiệu nhận biết:

• Đăng ký chỉ mất vài bước nhưng hủy yêu cầu nhiều bước hơn đáng kể.
• Đăng ký online nhưng hủy phải gọi hotline hoặc gửi yêu cầu thủ công.
• Người dùng phải qua nhiều màn hình thuyết phục trước khi được hủy.
• Có thời gian chờ hoặc điều kiện hủy không cần thiết.
• Không thể hoàn tất hủy trực tiếp trong cùng kênh đã đăng ký.

Tác động: Tăng friction và làm giảm cảm giác kiểm soát, có thể giữ người dùng trong ngắn hạn nhưng gây ảnh hưởng tiêu cực đến trust và trải nghiệm dài hạn.

Cách sửa: Cho phép hủy đơn giản, rõ ràng và tương xứng với flow đăng ký, chỉ giữ lại các bước thực sự cần thiết cho xác nhận, bảo mật hoặc yêu cầu pháp lý.

Kiểm tra sau khi sửa: Đăng ký → 2 bước → Hủy → 2 bước → xác nhận trạng thái hủy rõ ràng.

Mốc kiểm tra: Symmetric Flow + User Control + No Unnecessary Friction.

Cách ưu tiên lỗi UX UI website

Không phải lỗi UX/UI nào cũng cần sửa ngay. Ưu tiên nên dựa trên mức độ ảnh hưởng đến khả năng hoàn thành tác vụ, chuyển đổi, dữ liệu, rủi ro và trải nghiệm người dùng, thay vì chỉ dựa vào mức độ dễ nhìn thấy của lỗi.

Nguyên tắc: Ưu tiên theo Impact × Frequency × Risk, sau đó cân nhắc effort và dependency để xác định thứ tự triển khai.

Quy trình audit UX UI website trong 90 phút

1. Xác định 3 tác vụ quan trọng nhất

Chọn những hành động gắn trực tiếp với mục tiêu website, chẳng hạn:

• Gửi form liên hệ.
• Đặt hàng hoặc checkout.
• Tìm sản phẩm hoặc thông tin quan trọng.

Không audit theo kiểu “đi hết từng trang”. Hãy bắt đầu từ user goal và business goal.

2. Chạy từng tác vụ trên mobile trước

Ghi lại những điểm người dùng:

• Bị kẹt.
• Phải đoán.
• Không biết bước tiếp theo.
• Phải làm lại.
• Không nhận được phản hồi.
• Có nguy cơ bỏ cuộc.

3. Kiểm tra các điểm có khả năng tạo ma sát cao

Tập trung vào:

• Navigation và information architecture.
• Search và filter.
• Form và validation.
• CTA.
• Loading và system feedback.
• Error message.
• Confirmation sau khi submit.
• Khả năng giữ dữ liệu khi quay lại hoặc xảy ra lỗi.

Điều này phù hợp với các nguyên tắc usability của Nielsen Norman Group, trong đó hệ thống cần cho người dùng biết trạng thái hiện tại, giúp họ nhận biết và xử lý lỗi thay vì để họ tự đoán.

4. Kiểm tra hiệu năng và accessibility

Dùng PageSpeed Insights, Lighthouse và Search Console để kiểm tra hiệu năng thực tế và các vấn đề kỹ thuật có thể phát hiện tự động.

Với Core Web Vitals, Google hiện sử dụng ba chỉ số chính:

• LCP: ≤ 2,5 giây.
• INP: < 200 ms.
• CLS: < 0,1.

Đây là các ngưỡng Google khuyến nghị cho trải nghiệm tốt.

Đồng thời, kiểm tra accessibility bằng bàn phím để phát hiện:

• Focus không rõ.
• Tab order sai.
• Keyboard trap.
• Thành phần không thể thao tác bằng bàn phím.
• Form hoặc lỗi không được mô tả rõ bằng text.

WCAG 2.2 yêu cầu chức năng phải có thể sử dụng bằng bàn phím và lỗi input được xác định, mô tả bằng văn bản.

5. Ghi nhận bằng chứng, không chỉ ghi nhận ý kiến

Mỗi lỗi nên có:

Issue → Evidence → Impact → Recommendation → Priority → Owner

Ví dụ:

Issue: CTA “Đăng ký” không phản hồi sau khi click.
Evidence: Không có loading hoặc confirmation trong 3 giây.
Impact: User có thể click lại hoặc nghĩ hệ thống không hoạt động.
Fix: Hiển thị trạng thái loading và confirmation sau khi submit.
Priority: P1.

6. Xếp lỗi vào P0 → P3

Cuối audit, gom các vấn đề theo mức độ ưu tiên và đưa vào backlog cùng evidence, impact, owner và trạng thái xử lý.

Mục tiêu không phải tìm ra nhiều lỗi nhất, mà là xác định những lỗi đáng sửa nhất.

UX UI ảnh hưởng đến SEO như thế nào

UX/UI và SEO có mối liên hệ, nhưng không nên đánh đồng UX với ranking factor.

Google xác nhận Core Web Vitals được sử dụng trong hệ thống xếp hạng, đồng thời khuyến nghị website cung cấp trải nghiệm trang tốt về tổng thể. Tuy nhiên, Google cũng nói rõ rằng đạt điểm Core Web Vitals tốt không đảm bảo website đứng top, vì hệ thống Search còn xem xét nhiều tín hiệu khác.

Có thể hiểu mối quan hệ theo 3 lớp: 

• UX/UI → giảm ma sát → người dùng dễ hoàn thành mục tiêu
• Technical performance → cải thiện loading, responsiveness, visual stability → hỗ trợ Page Experience
• SEO → cần kết hợp nội dung hữu ích, khả năng crawl/index, relevance, technical SEO và nhiều tín hiệu khác

Google cũng nhấn mạnh rằng nội dung hữu ích, đáng tin cậy và people-first vẫn là nền tảng của Search; Page Experience không thay thế cho chất lượng và mức độ phù hợp của nội dung.

Vì vậy, đừng audit UX/UI chỉ với câu hỏi: “Điểm Lighthouse có cao chưa?”

Hãy hỏi: “Người dùng có thể tìm thấy thông tin, hiểu giao diện và hoàn thành tác vụ một cách nhanh chóng, rõ ràng và ít lỗi nhất không?”

Đó mới là điểm giao giữa UX, Conversion, Accessibility, Performance và SEO.

Kết luận

57 lỗi trong checklist không cần được sửa cùng lúc. Hãy bắt đầu từ tác vụ tạo doanh thu hoặc tạo lead, ghi lại bằng chứng, ưu tiên P0 và P1, rồi đo lại sau mỗi đợt sửa. Khi một lỗi đã được sửa, tiêu chí hoàn tất phải mô tả được hành vi mới, không chỉ là nhận xét giao diện trông đẹp hơn.