5 cách đơn giản để áp dụng less is more trong A/B testing
(Ảnh 1: mô tả less is more, nguồn internet)
Đầu tiên xin được nhắc lại khái niệm (có thể nói là phổ biến) “less is more” trong thiết kế có nghĩa là bạn càng cố gắng giảm thiểu những thứ (có thể là) thừa thãi, không cần thiết, các chi tiết không bắt buộc trong bản thiết kế… bạn càng đạt được sự hoàn thiện, và mục tiêu truyền tải thông tin hoặc điều hướng người dùng. Đây là gói gọn trong thiết kế web/mobile app. Khái niệm này có từ lâu, đặc biệt trong lĩnh vực hội họa, còn trong ngành “design” riêng có câu nói nổi tiếng rằng:
A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away. – Antoine de Saint-Exupery
Tạm dịch là người thiết kế nhận thấy sự hoàn thiện khi anh ta không thể loại bỏ chi tiết nào từ sản phẩm của mình nữa chứ không phải không tìm ra điểm nào có thể bổ sung thêm nữa. (dịch hơi dở @.@)
(Ảnh 2: một mẫu form đơn giản, nguồn: Internet)
Giông dài như vậy đủ rồi, bây giờ tôi quay trở lại với A/B testing. Về cơ bản thì chúng ta đã biết A/B testing là phương pháp thử nghiệm nhiều mẫu thiết kế khác nhau với một nhóm người dùng trong cùng một thời điểm. Vậy nhiều mẫu thiết kế khác nhau ở đây cụ thể như thế nào? Không nhất thiết phải là các bản vẽ Photoshop hoặc Wire-frame hoàn toàn khác biệt, mà trong thực tế, đôi khi chúng ta chỉ cần thay đổi vài chi tiết nhỏ để kiểm chứng tính hiệu quả của nó. Một cách đơn giản hơn là bỏ bớt các chi tiết không quan trọng đi. Ví dụ như với web design, ta có thể tham khảo 5 cách cơ bản như sau:
- Field counts: Giảm bớt số trường dữ liệu mà người dùng bắt buộc phải điền thông tin, và ẩn nó đi. Nếu một form của bạn yêu cầu người dùng phải điền 10 loại thông tin như tên, tuổi, địa chỉ, điện thoại, giới tính.v.v.. thì bạn nên rút ngắn lại khoảng từ 3-5 thông tin cơ bản. Những thông tin khác, hãy để người dùng nhập sau nếu họ thấy cần thiết, email, điện thoại + mật khẩu là quá đủ cho một sự khởi đầu. Bạn có thể lý luận là form của bạn đã có required field validator /notation rồi, và những trường dữ liệu không có dấu * thì có thể bỏ qua? Thực ra, người dùng không quan tâm tới điều đó, nhìn 1 form dài là đủ ngại rồi.
- Keep it simple: Hãy đưa ra những thông tin, thông điệp, qui trình đơn giản. Nếu người dùng muốn tìm danh sách các cửa hàng thông qua website của bạn (còn gọi là store locator) thì tốt nhất là hiển thị bản đồ và đánh dấu các địa điểm của các cửa hàng lên đó, thay vì liệt kê 1 danh sách dài ngoằng. Nếu bạn làm survey, hãy đặt câu hỏi và đưa ra các phương án lựa chọn đơn giản, dễ hiểu và hạn chế “bắt” người dùng phải suy nghĩ hay đánh máy dài dòng.
- Hide options: Ẩn bớt những lựa chọn mở rộng. Ví dụ trong màn hình “check-out” của website thương mại điện tử, bạn nên để người dùng tập trung vào việc…”check-out”. Vì vậy, hãy thử “remove” bớt những thông tin khuyến mại, các sản phẩm đang giảm giá, thậm chí cả phần nhập “voucher code” cũng có thể thu nhỏ lại và cho phép người dùng tắt/bật khi cần thiết…
- Remove distraction: Cái này dễ hiểu, bởi đơn giản là loại bỏ những thành phần gây mất tập trung đối với người dùng. Ví dụ như việc sử dụng quá nhiều banner với màu sắc sặc sỡ ở khắp nơi trên trang web khiên người dùng không biết phải tập trung vào đâu. Trong khi việc bạn cần hướng người dùng chú ý là các nút bấm CTA (Xem ảnh 3).
- Lower the Slope: Giảm thiểu khó khăn trong quá trình thao tác các chức năng. Nêu form dài quá, hãy thu ngắn lại (như bước 1). Nếu quá trình “check-out” với giỏ hàng trên site e-commerce quá phức tạp, hãy loại bỏ một vài bước không cần thiết hoặc chia ra nhiều “steps” để người dùng dễ sử dụng hơn…
Tóm lại, một cách đơn giản và nhanh chóng, khi thử nghiệm A/B testing, thay vì nghĩ cách thay đổi giao diện, thiết kế của mình, bạn hãy cùng thảo luận với nhóm của mình xem có thể “gỡ bỏ” chi tiết nào ra khỏi bản vẽ hiện tại. Thậm chí có thể bỏ bớt các bước rườm ra trong qui trình, chức năng của phần mềm. Càng dễ sử dụng, càng thuận tiện, nhanh chóng thao tác, người dùng càng gắn bó với sản phẩm của bạn nhiều hơn, tương tác nhiều hơn, và conversion rate vì thế cũng sẽ nhiều hơn. Less is more đôi khi đơn giản là vậy.
(Ảnh 3: trang chủ Viettel store với 2 banner vàng rực 2 bên khiến người dùng không biết nên tập trung vào đâu, nguồn Internet)
Thay cho lời kết, chắc bạn đã biết, trong suốt quãng thời gian tranh cử tổng thống, Obama và các cộng sự của ông đã rất thành công khi sử dụng website để kêu gọi, vận động tài trợ cho chiến dịch của mình. Nhóm của công đã thay đổi, thử nghiệm liên tục với hình ảnh, nội dung và bố cục của website. Có một thống kê thú vị rằng, nhóm phụ trách web design của tổng thống Obama đã tiến hành khoảng 500 cuộc thử nghiệm A/B testing trong suốt thời gian đó. Như vậy, trung bình cứ khoảng 1 ngày, họ lại có một điều chỉnh (dù nhỏ). Nghe có vẻ không khả thi? Thực ra không có gì to tát nếu đội ngũ kỹ thuật của bạn có thể thực hiện tốt CI (Continuous Integration) và CD (Continuous Delivery).
Abstraction Hub 
Đọc xong tự dưng nhớ lại chương trình thí điểm của Bộ Giáo Dục, cũng là A/B Testing khi mà một số trường ở phía khu vực cầu giấy học chương trình thí điểm nhưng cái goal chung vẫn là thi tốt nghiệp chung :>
Đứng ở góc độ thiết kế, từ xưa em rất phản đối A/B Testing vì lý do cầu toàn, em không muốn đem đến cho người dùng một yếu tố mang tính “thử nghiệm”.
Nhưng khi chuyển sang sản phẩm, đặc biệt là một số sản phẩm liên quan tới thương mại điện tử với tập khách hàng lớn, đa dạng thao tác; thì A/B Testing lại là yếu tố sống còn giúp sản phẩm được cải tiến sát với thực tế người dùng hơn.
A/B testing không nhất thiết cần phải có khác biệt hoàn toàn giữa 2 phiên bản, nhiều khi chỉ là điều chỉnh nhỏ (text, button..)
Với sản phẩm web, mobile app, áp dụng A/B testing có tính khả thi cao, và không gây hậu quả nghiêm trọng so với việc áp dụng trong cải cách giáo dục 😀
cảm ơn vì đã chia sẽ