Khi một sản phẩm phát triển, việc thêm tính năng gần như là điều không thể tránh khỏi. Người dùng muốn nhiều tiện ích hơn, business muốn mở rộng giá trị sản phẩm, marketing muốn tăng engagement, còn product team luôn có những ý tưởng mới để cải thiện trải nghiệm. Nhưng có một nghịch lý khá thú vị: càng nhiều tính năng không có nghĩa là sản phẩm càng tốt. Nếu không được tổ chức và ưu tiên hợp lý, mỗi tính năng mới có thể khiến sản phẩm trở nên khó hiểu và khó sử dụng hơn.
Hãy thử tưởng tượng một ứng dụng đặt đồ ăn. Ban đầu, người dùng chỉ cần tìm món, thêm vào giỏ hàng và thanh toán. Sau một thời gian, sản phẩm bổ sung thêm voucher, điểm thưởng, membership, combo, đề xuất món ăn, ưu đãi theo giờ, nhiều phương thức thanh toán, giao hàng nhanh, đặt trước... Tất cả những tính năng này đều có lý do để tồn tại. Nhưng khi chúng cùng xuất hiện trên một màn hình, người dùng không chỉ phải suy nghĩ về việc “mình muốn ăn gì?”, mà còn phải xử lý rất nhiều lựa chọn khác trước khi hoàn thành một nhiệm vụ vốn rất đơn giản.
Đây là một trong những vấn đề được giải thích bởi Hick’s Law. Nghiên cứu của Hick (1952) cho thấy thời gian phản ứng có xu hướng tăng khi số lượng lựa chọn tăng. Trong thiết kế sản phẩm, nguyên tắc này thường được hiểu đơn giản là: khi người dùng phải lựa chọn giữa quá nhiều phương án, quá trình ra quyết định sẽ trở nên khó khăn hơn.
Tuy nhiên, vấn đề không nằm ở việc “nhiều tính năng là xấu”. Một hệ thống ngân hàng, phần mềm quản trị doanh nghiệp hay công cụ dành cho designer chắc chắn cần rất nhiều chức năng. Điều quan trọng là người dùng có phải nhìn thấy và xử lý tất cả những chức năng đó cùng một lúc hay không.
Đây là lúc Information Architecture và cách tổ chức trải nghiệm trở nên quan trọng. Một sản phẩm có thể chứa hàng trăm tính năng nhưng vẫn dễ sử dụng nếu người dùng chỉ được đưa đến những lựa chọn phù hợp với mục tiêu hiện tại. Các chức năng nâng cao hoặc ít được sử dụng có thể được đặt ở những lớp sâu hơn thay vì xuất hiện ngay trên màn hình chính. Cách tiếp cận này thường được gọi là Progressive Disclosure: chỉ cung cấp thông tin hoặc hành động cần thiết ở thời điểm người dùng cần chúng, thay vì đưa toàn bộ khả năng của hệ thống ra cùng lúc.
Một vấn đề khác là choice overload – quá nhiều lựa chọn có thể khiến người dùng khó đưa ra quyết định. Nghiên cứu nổi tiếng của Iyengar và Lepper (2000) cho thấy trong một số bối cảnh, những người được cung cấp ít lựa chọn hơn có khả năng đưa ra quyết định cao hơn và cảm thấy hài lòng hơn với lựa chọn của mình so với nhóm được cung cấp quá nhiều lựa chọn.
Điều này cũng thường xảy ra trong các sản phẩm số. Một tính năng có thể rất hữu ích nhưng không nhất thiết phải xuất hiện ngay trên màn hình chính. Một chức năng có thể quan trọng với power user nhưng hoàn toàn không cần thiết đối với người dùng mới. Vì vậy, câu hỏi của designer không nên chỉ là “Sản phẩm còn thiếu tính năng gì?”, mà còn phải là “Người dùng cần tính năng nào ở thời điểm này?”
Mình nghĩ đây cũng là một trong những điểm khó nhất của công việc UI/UX. Khi nhận được yêu cầu “thêm một tính năng”, việc thiết kế thêm một màn hình thường dễ hơn việc đặt câu hỏi liệu tính năng đó có thực sự cần thiết hay không. Nhưng nếu mọi yêu cầu đều được đưa trực tiếp vào sản phẩm, giao diện sẽ ngày càng phức tạp, user flow sẽ dài hơn và người dùng sẽ phải đưa ra nhiều quyết định hơn.
Vì vậy, designer không chỉ có nhiệm vụ thêm. Designer cũng cần biết ưu tiên, nhóm, ẩn bớt và đôi khi loại bỏ.
Một sản phẩm tốt không nhất thiết là sản phẩm có nhiều tính năng nhất. Đó là sản phẩm giúp người dùng nhanh chóng tìm thấy và thực hiện điều họ thực sự cần.
Đôi khi, thiết kế tốt không phải là thêm một button mới.
Mà là biết button nào không cần xuất hiện.
Tài liệu tham khảo
Hick, W. E. (1952). On the rate of gain of information. Quarterly Journal of Experimental Psychology, 4(1), 11–26. https://doi.org/10.1080/17470215208416600
Iyengar, S. S., & Lepper, M. R. (2000). When choice is demotivating: Can one desire too much of a good thing? Journal of Personality and Social Psychology, 79(6), 995–1006. https://doi.org/10.1037/0022-3514.79.6.995
Nielsen, J. (2006, December 3). Progressive disclosure. Nielsen Norman Group. https://www.nngroup.com/articles/progressive-disclosure/