Lời nói đầu

UI UX là cách gọi tắt của User Interface (giao diện người dùng) và User Experience (trải nghiệm người dùng). Đây là 2 yếu tố rất quan trọng trong việc quyết định một website hay một app đẹp và giúp người dùng sử dụng mà không cần phải nghĩ. Bài viết hôm nay, mình xin chia sẻ những kinh nghiệm, checklist UX cơ bản thường gặp đối với ứng dụng WEB.

I. UI UX là gì?

1. UI

UI là viết tắt của từ User Interface có nghĩa là giao diện người dùng. Hiểu một cách đơn giản nhất thì UI bao gồm tất cả những gì người dùng có thể nhìn thấy như: màu sắc web, bố cục sắp xếp như thế nào, web/app sử dụng fonts chữ gì, hình ảnh trên web có hấp dẫn hay không,… Trong thiết kế thì UI đóng vai trò là yếu tố truyền tải thông điệp từ người thiết kế, nhà cung cấp dịch vụ, sản phẩm tới người dùng. Đơn giản hơn thì nhà thiết kế đóng vai trò như 1 lập trình viên hoặc nhà xây dựng để bất cứ ai cũng có thể hiểu và sử dụng được sản phẩm của họ .

2. UX

UX là viết tắt của từ User Experience có nghĩa là trải nghiệm người dùng. Đơn giản hơn thì UX là những đánh giá của người dùng khi sử dụng sản phẩm. như: Website hay App của bạn có dễ sử dụng hay không, có thân việc bố trí sắp xếp bố cục như vậy đã được hay chưa? sản phẩm đó có đạt được mục đích đề ra không. Người làm về UX hay còn gọi là UX Designer. UX Designer sẽ nghiên cứu và đánh giá về thói quen và cách mà khách hàng sử dụng rồi đánh giá về sản phẩm website/App nào đó. Sử dụng và đánh giá ở đây đơn giản là những vấn đề: tính dễ sử dụng, sự tiện ích, sự hiệu quả khi hệ thống hoạt động.

3. Kết luận

UI là cái người dùng nhìn thấy. UX là cách người dùng sử dụng website/app đó. Một website/app có thể có UI đẹp nhưng UX tệ. Cả UI và UX đều có vai trò quan trọng như nhau mang một mục đích đó là tạo sự thoải mái cho người dùng.

II. Chia sẻ những kinh nghiệm, checklist UX cơ bản thường gặp đối với ứng dụng WEB

1. Theme

1.1. Phải có favicon để nhận diện ứng dụng trên browser. Ví dụ khi người dùng đang sử dụng hoặc bookmarked lại thì nhìn vào favicon sẽ dễ nhận biết ra ứng dụng. Yêu cầu:

• Trên tab của trình duyệt có favicon.
• Ở danh sách bookmarked có favicon.

1.2. Không được có ngõ cụt (dead end). Ngõ cụt là nơi người dùng không biết nên làm gì/đi đâu tiếp. Nên cần có nút để tắt/back lại trang trước đó/đi tiếp sang một trang khác. 1.3. Logo của web/ứng dụng phải nằm ở cùng một vị trí trên tất cả các trang và khi bấm vào sẽ trở về cùng một trang (trang chủ).

2. Font

2.1. Font chữ phải được sử dụng nhất quán và dễ nhìn.

• Không sử dụng quá 3 fonts trong 1 ứng dụng (kể cả Logo Font).
• Đối với các nội dung quan trọng/ thường đọc: sử dụng font tối thiểu là 13px-14px để đảm bảo không bị mỏi mắt.
• Không sử dụng font chữ có chân (thuộc dòng serif, ví dụ Times-New Roman).

2.2. Hạn chế viết nghiêng, trừ khi đó là thông tin không quan trọng. 2.3. Font đậm hoặc viết hoa dùng để thu hút sự chú ý, cần tiết chế khi sử dụng. Chỉ sử dụng khi thực sự liên quan và cần thiết. Các sản phẩm thường hay gặp vấn đề:

• Quá nhiều label viết đậm.
• Menu và button toàn viết hoa, không biết là ý đồ muốn nhấn mạnh sự chú ý vào đâu.

3. Popup

3.1. Nhấn esc hoặc click vào vùng tối xung quanh phải đóng được popup. Chỉ áp dụng khi popup là read-only (không có ô edit dữ liệu). 3.2. Phải có icon đóng ở góc trên cùng, bên phải của popup. Chú ý là icon này chỉ cần theo chuẩn icon, dễ click là được, không cần quá to vì đã yêu cầu có cả button “Cancel” ở bottom của popup.

4. Upload

4.1. Khu vực upload phải thông báo rõ ràng cho người dùng biết về định dạng và kích cỡ file cho phép. 4.2. Phải kiểm tra tính hợp lệ định dạng và dung lượng file cho phép trước khi upload lên server. Yêu cầu:

• Không có lệnh POST lên server khi file không hợp lệ.
• Cần có “Validation Message” báo cho người dùng biết lý do.

5. Breadcrumb

5.1. Yêu cầu tất cả các page có >=3 levels phân cấp phải có breadcrumb để cho người dùng biết mình đang đứng ở đâu trong hệ thống. Dấu phân cách trên breadcrumb cần thể hiện chỉ hướng như ”>”, không dùng ”|” hoặc ”/” vì có vẻ là ngang hàng chứ không phải dẫn đường.

• Di chuột vào các label (các lá khác trên breadcrumb) mà điều hướng được cần có hiệu ứng clickable.
• Bắt đầu phải là Home. Khi người dùng click vào Home thì sẽ điều hướng về trang chủ.

6. Icon

6.1. Đối với icon tương tác được phải có các hiệu ứng khi di chuột vào như sau:

• Đổi màu nền hoặc màu icon,
• Trỏ chuột thành hình bàn tay,
• Có tooltip giải thích ý nghĩa/ mục đích.

Chú ý: đối với icon của button, thì màu icon nên cùng màu với màu text trong mọi trường hợp.

7. Bảng biểu (datatable)

7.1. Các dòng chẵn/lẻ phải là dạng màu sắc ngựa vằn cho dễ đọc. Gợi ý ví dụ dùng các màu sau:

• Dòng chẵn: #ffffff,

• Dòng lẻ: #f0f3f5,

• Màu viền: 1px solid #c9cdd2,

• Khi di chuột vào 1 dòng: #c9cdd2,

• Phải bảo đảm màu chữ đạt độ tương phản tối với mọi màu nền chẵn/lẻ/hover/selected.

• Khi click vào 1 dòng: là màu chủ đạo của ứng dụng.

  7.2. Trường hợp có phân trang: phân trang phải giúp người dùng thuận tiện/dễ dàng khi next/back. 7.3. Đối với bảng hiển thị kết quả tìm kiếm phải hiển thị rõ là bao nhiêu kết quả tìm thấy, bao nhiêu kết quả được lấy ra, số lượng kết quả mỗi trang. 7.4. Thông tin tổng số kết quả tìm thấy rất quan trọng, cần hiển thị nổi bật và ấn tượng.

8. Form

8.1. Ô nhập liệu có độ lớn (width và height) tương ứng với nội dung mong muốn.

• Nếu height không đủ thì gõ chữ thấp “g” hoặc chữ cao “k” có thể sẽ bị cắt mất chữ. => Failed.
• Có những trường dữ liệu thường dài hơn là width của textbox, ví dụ trường “Địa chỉ” cần gõ đủ số nhà/đường/phố/phường/tỉnh. => Failed.

8.2. Các form nhập liệu cần phải có tiêu đề nói rõ form này là làm gì. Nếu form trong một panel thì cần có Header ở đầu panel, hoặc dùng field-set có tiêu đề của field-set. 8.3. Cho phép tối đa việc sử dụng bàn phím (không có chuột vẫn tương tác được):

• Khi tab/shift-tab thì phải lần lượt đi qua các control element và thao tác được.

• Việc thao tác bằng bàn phím phải thuận tiện (ít lần gõ bàn phím nhất có thể).

  8.4. Khi vào một màn hình nhập liệu, tự hiển thị con trỏ về vị trí cần nhập đầu tiên. 8.5. Khi di chuột/focus/click vào một UI Element mà tương tác được thì phải có hiệu ứng đồ họa, ví dụ đổi màu viền hoặc màu nền, cho người dùng biết. Khuyến nghị:

• Đổi màu viền đối với ô nhập liệu,

• Đổi màu nền đối với button, dòng trong bảng.

8.6. Khi enter phải focus vào một button quan trọng và an toàn nhất (default button).

• Ví dụ khi edit hoặc search thì focus vào button “Lưu”/“Tìm kiếm”.
• Khi delete thì focus vào button “Cancel”.

Chú ý: khi enter thì button đó cũng phải có hiệu ứng đổi màu. 8.7. Phải có sự phân biệt giữa các trường thông tin bắt buộc và không bắt buộc. Thường phân biệt bằng dấu * đỏ ở trường bắt buộc. 8.8. Các form nên có place holder với nội dung text cover tổng quát nhất hướng dẫn điền dữ liệu hợp lệ. 8.9. Dữ liệu phải được kiểm tra tính hợp lệ cơ bản nhất tại client trước khi gửi (submit) lên server. Một dữ liệu được coi là hợp lệ khi đạt các tiêu chí như: định dạng dữ liệu cho phép, độ dài/dung lượng cho phép, nhập đủ các trường bắt buộc,…

9. Button

9.1. Tránh sử dụng các từ chung chung như “Submit” không thực sự thể hiện được hành động của button. Ví dụ, nếu là “đăng ký” thì đặt luôn tên button là “Đăng ký”. 9.2. Cần phải bo viền button, không sử dụng góc vuông (vì vấn đề Contour Bias). Người dùng từ khi sinh ra đã có phản ứng tự nhiên là rất sợ các vật sắc nhọn. Do đó, nếu một trang có quá nhiều góc vuông, đặc biệt là button vuông (nơi người dùng tương tác và sẽ gây ra kết quả nào đó), thì người dùng sẽ rất sợ click vào các button này. Tất nhiên, không phải lúc nào cũng bắt bo viền button. Còn tùy vào tổng thể thiết kế của trang. Nếu như thiết kế hài hòa, thì khi đưa button vuông vào cũng không sao. Hoặc có những button muốn gây sự chú ý mạnh của người dùng sẽ dùng góc vuông. Nhưng nói chung không nên lạm dụng việc thiết kế vuông góc như vậy. Thông thường bo góc (border-radius) khoảng 2px tới 3px là vừa 9.3. Tên button phải là động từ/cụm động từ. 9.4. Cần phân biệt 3 loại button sau:

• Positive – Changes, sends, or adds information.
• Neutral – Makes no change or takes users back a screen (e.g. Cancel).
• Negative – Deletes, resets or blocks information.

• Sau đó thiết kế cấp độ tương phản màu sắc theo công thức từ cao tới thấp là: Positive > Negative > Neutral.

10. Tương tác

10.1 Khi xử lý xong tác vụ, cần phải có thông báo rõ ràng về kết quả thực hiện (kể cả thành công hay thất bại cũng phải thông báo). Ví dụ:

• Đã thêm mới thành công 20 người dùng mới.
• Thông tin tài khoản đã tồn tại. Hãy chọn một tài khoản khác.

10.2. Bất cứ tương tác nào cần hơn 1s để xử lý, thì phải sử dụng Progress Indicator. Chú ý: Khi tương tác với server như tìm kiếm, lưu, sửa, xóa,… thì cần có hiệu ứng processing cho người dùng biết. 10.3 Tránh sử dụng các Progress Indicator dạng tĩnh. Ví dụ chỉ sử dụng text “Loading…” hoặc “Please wait…” mà không có bất kỳ hiệu ứng chuyển động nào. 10.4 Xác nhận (confirm) với người dùng về các thao tác nguy hiểm/quan trọng (ví dụ các thao tác xóa dữ liệu).

11. Checkbox

11.1 Khi click vào label của option thì cũng phải coi như click được vào option, vì diện tích tương tác lớn thì người dùng thuận tiện thao tác hơn. 11.2 Các lựa chọn ở checkbox nên được sắp xếp theo một trong 2 tiêu chí sau:

• Theo thứ tự quan trọng: cao xuống thấp,
• Theo ABC nếu không biết sắp xếp thế nào là quan trọng.

12. Dropdown

12.1 Các item trong dropdown phải được sắp xếp theo một trong 2 tiêu chí sau:

• Theo thứ tự quan trọng: cao xuống thấp.
• Theo ABC nếu không biết sắp xếp thế nào là quan trọng.
• Có thể kết hợp cả 2: quan trọng và ABC. Dropdown list có thể chia thành 2 phần: quan trọng (ví dụ lựa chọn gần đây nhất) bên trên, phân tách 1 đường kẻ nhẹ, và ABC các phần còn lại.

12.2. Các giá trị đặc biệt như “—Select all—” hoặc chỉ dẫn “—Chọn—” cần thiết kế sao cho phân biệt với các giá trị thật của dropdown. 12.3. Các dropdown là bắt buộc nhập thì không để giá trị mặc định là 1 trong các giá trị hợp lệ, người dùng có thể sẽ bỏ qua không chọn giá trị đúng. => Gây lỗi dữ liệu. 12.4. Khi dropdown có nhiều tùy chọn (>= 10), thì hỗ trợ gõ và auto-suggestion để người dùng dễ dàng lựa chọn được item mong muốn. 12.5. Khi dropdown có nhiều tùy chọn thì phải hỗ trợ gõ/auto-suggestion: gõ chữ cái đầu tiên vẫn suggest nhảy tới item có từ đầu tiên đó. 12.6. Khi di chuột qua các item của dropdown, cần phải có hiệu ứng rõ nét cho người dùng biết mình đang di chuột vào item nào. 12.7. Multiple choices dropdown:

• Các item được chọn nên hiển thị dạng tag cho dễ nhìn. Bởi vì theo lý thuyết, danh sách hiển thị theo chiều ngang (ví dụ item1, item2, item3,…) sẽ rất khó đọc. Đưa vào tag thì dễ nhìn và cũng dễ xóa bớt.
• Nên hỗ trợ gõ và auto-suggestion.
• Nếu không có quá nhiều lựa chọn, thì cân nhắc chuyển thành Checkbox.

13. Import nhiều dữ liệu qua file CSV/Excel

13.1. Cung cấp file mẫu cho người dùng tải về và nhập liệu. 13.2. Khi import bị lỗi do nhập liệu thì cần thông báo cho người dùng biết dòng nào trong file excel bị lỗi; nguyên nhân lỗi; cách sửa; và thông báo sao cho người dùng thuận tiện sửa nhất có thể. Ví dụ, báo lỗi bằng cách xuất ra file lỗi, người dùng sẽ xem nội dung file và sửa dòng bị lỗi trực tiếp luôn cho nhanh.

14. Session

14.1. Khi hết session, mà người dùng thao tác trên ứng dụng thì phải tự mở ra trang hoặc popup đăng nhập.

Tổng kết

Trên đây là những chia sẻ của mình về checklist UX thường gặp đối với ứng dụng WEB. Những chia sẻ này hy vọng sẽ giúp ích nhiều cho BA, Tester, Dev… sẽ có những suggestion hay cho SRS dự án để tạo ra những sản phẩm Web không những đẹp mà còn thân thiện người dùng. Cảm ơn các bạn đã đọc đến đây và cùng chờ đón phần 2 sẽ là những chia sẻ về Mobile nhé!