Abstraction Hub

IA, UX, UI, User Experiences, Usability, Web Design, Information Architect, HCI

Month: June, 2014

David and Goliath

Đi tìm ưu thế trong những điều bất lợi?

david-and-goliath

(Ảnh 1: Bìa sách “David and Goliath”, tác giả: Malcolm Gladwell)

Malcolm Gladwell vẫn giữ phong cách viết lách như mọi khi, đó là đưa ra một quan điểm (ở đây là “lợi thế của những điều bất lợi”) rồi thu thập dữ liệu, một khối lượng dữ liệu khá công phu và tỉ mỉ, để chứng minh, lý giải những điều đó.

Tuy nhiên trong cuốn sách này, Gladwell có vẻ như hơi “xuống tay” trong văn phong và lập luận của mình. Ông dùng quá nhiều ví dụ như những người mắc chứng khó đọc, những người dân London bị đánh bom, những người sinh ra trong hoàn cảnh khắc nghiệt… để dẫn chứng chung chung chứ chưa lý giải cặn kẽ cũng như lập luận chặt chẽ cho quan điểm của mình. Nhiều ví dụ nhét trong một cuốn sách gần 300 trang khiến các dẫn chứng như bị rời rạc hơn so với quan điểm xuyên suốt của nội dung.

Ở đâu đó trong cuốn sách này ta thấy rõ “yếu tố hoàn cảnh” giường như nổi trội hơn. Đây là khái niệm chủ đạo trong cuốn “Điểm bùng phát” của ông xuất bản khá lâu. Yếu tố hoàn cảnh tạo ra sự bão hòa trên đồ thị đường cong của sự bất lợi (còn gọi là Inverted U-Curve), cốt để nói lên rằng hoàn cảnh sẽ tự thích nghi nếu các điều kiện (dù là lợi thế) đi quá giới hạn của nó. Ngược lại, nếu các điều kiện của hoàn cảnh quá bất lợi và nếu người ta không thể thay đổi các yếu tố bất lợi đó, người ta sẽ tự thích nghi, thay đổi bản thân mình để biến nó thành lợi thế, thành môi trường để tôi luyện, qua đó thành công hơn.

u-curve_large

(Ảnh 2: mô hình U-Curve của Malcolm Gladwell)

Lập luận trên nghe “có lý” nhưng không hoàn toàn đúng. Bởi để một người biến những điều bất lợi thành lợi thế, hoặc một môi trường tốt vô tình gây ra những hạn chế cho những người tham gia (ví dụ như trường chuyên, lớp chọn) cũng chỉ có thể chứng minh ở cấp độ “thiểu số”. Điều đó có nghĩa là “David và Goliath” chỉ đưa ra được lập luận rằng: dù ở hoàn cảnh nào, cũng luôn có cơ hội để người ta vượt qua những giới hạn của nó (dù thực tế không phải ai cũng làm được như vậy). Cuốn sách không chứng minh cho bạn thấy 1 chân lý, cũng không khẳng định một định luật, chỉ là sự sưu tầm các hiện tượng lịch sử rồi từ đó đưa ra một cách nhìn khách quan, và phần nào mới mẻ hơn. (Nghĩa là giúp bạn khám phá thêm một góc nhìn).

Nội dung chính của cuốn sách không đề cập tới việc cạnh tranh giữa các doanh nghiệp lớn / nhỏ, mà chỉ nói tới những cá nhân, hoặc cộng đồng vượt qua nỗi sợ hãi, hay những khó khăn trong cuộc sống của họ. Trong thực tế, khi bạn bị bám đuổi và tẩy chay bởi đám đông, hay bạn buộc phải sống trong chiến tranh, bạn có thể vẫn “lo sợ”. Bạn vượt qua nỗi sợ đó bởi “bạn không còn gì để mất”, hoặc phải liều lĩnh đi tiếp về phía trước khi đó là hy vọng duy nhất của bạn chứ không phải mọi nỗi sợ hãi / lo lắng, mọi điều “bất lợi” đã đi quá giới hạn của nó như Malcolm biện luận.

Câu truyện David đánh bại Goliath bằng chiếc “ná dây thun” (còn gọi là súng cao su) và những viên sỏi được sử dụng làm viên đạn. Goliath được miêu tả là một người cao lớn, đội mũ sắt, mang khiên và kiếm… Vì vậy điều vô lý trong câu truyện của Malcolm Gladwell là ở chỗ: nếu Goliath đội mũ bảo vệ bằng sắt thì David không thể nào bắn hạ Goliath một cách dễ dàng như vậy dù sức của David có khỏe tới đâu. Một điểm không hợp lý nữa là David có thể dễ dàng dùng chính thanh gươm của Goliath (sẽ nặng hơn rất nhiều so với thể trạng của David) để tiêu diệt đối thủ của mình (Goliath). (Trên WallStreetJournal có bạn nói về vụ này)

Độc giả nên tỉnh táo khi đọc cuốn sách này, và cũng nên giữ thái độ trung lập để có cái nhìn khách quan.

Advertisements

Less is more vs A/B testing

5 cách đơn giản để áp dụng less is more trong A/B testing

less-is-more

(Ả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ở @.@)

less-is-more2

(Ả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:

  1. 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.
  2. 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.
  3. 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…
  4. 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).
  5. 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.

distraction

(Ả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).