Crowd testing, a kind of…

September 3, 2015 ~ binhtruong ~ 1 Comment

Thực hiện phương pháp test bởi nhóm người dùng khách quan (alternative focus group)

(Ảnh: Pixel Art Suits – Nguồn: blog.smartbear.com)

Crowd testing không phải topic mới, bởi nó khả phổ biến trên thế giới, đặc biệt là các công ty chuyên làm dịch vụ testing. Có 1 tên gọi khác mà bạn cũng hay gặp, đó là “crowd-source testing”, với nôm na ý tưởng là sử dụng 1 nhóm người dùng nhất định để test sản phẩm của bạn (hoặc công ty bạn) làm ra. Ở góc độ chuyên nghiệp, crowd testing nhằm giải quyết những vấn đề cụ thể như:

Cross-culture: Sản phẩm được thực hiện ở 1 nước, nhưng phục vụ global users, cũng có nghĩa là target users của bạn ở nhiều đất nước khác nhau, văn hóa, ngôn ngữ, tôn giáo và nhận thức / tư duy khác nhau. Chính vì thế mà nếu sản phẩm chỉ được test bởi 1 nhóm tester ở trong công ty của bạn là không đủ.
Alternative view: Với một nhóm được chọn ngẫu nhiên bao gồm những người chuyên nghiệp lẫn không chuyên, bạn sẽ có số liệu usability test có tính trung thực cao hơn. Bởi nếu bạn và những thành viên trong nhóm cùng test sản phẩm với nhau thì “tính khám phá” sẽ không còn do nhóm đã tham gia phát triển sản phẩm được 1 thời gian nhất định. Vd: nếu test phần registration thì sau vài lần self-test bạn / hoặc developer trong nhóm sẽ thao tác rất nhanh để đi qua bước đó. Cảm quan về layout, color, first feeling cũng không còn mới nữa.v.v..
Quick failure, quick rebuild: Khi đưa sản phẩm dạng MVP (Most Valuable Product) cho nhóm crowd testing, bạn có cơ hội kiểm chứng tính đúng đắn, hiệu quả của tính năng cũng như giao diện nhanh hơn. Điều này giúp giảm thiểu sự “tranh cãi” trong nội bộ nhóm, cũng như giảm thiểu lỗi usability tới end-user thực sự của bạn.
Improve personas: Personas là một công việc khá nặng nhọc nếu làm cẩn thận vả kỹ lưỡng, tuy nhiên trong nhiều dự án có thời gian phát triển ngắn, việc interview người dùng để phát triển nghiên cứu personas là khá khó khăn cũng như tốn nhiều thời gian và chi phí. Crowd-testing với sự lựa chọn của nhóm “rộng” hơn và “tập trung” hơn vào thị phần bạn hướng tới sẽ giúp bạn có phản hồi tích cực.
Ego is good: Ego (cái tôi), trong nhiều trường hợp bị tẩy chay, nhất là làm việc nhóm, nhưng trong testing lại là 1 điều tích cực. Tại sao? Bởi Ego là bản chất của con người. Khi được mời test 1 sản phẩm, bạn sẽ nghĩ gì? OK, sản phẩm này có phục vụ cho “tôi” đạt được cái “tôi” muốn hay không? Để xem họ làm ăn ra sao, kiểu gì chả có lỗi? và “tôi” thích thú khi tìm ra lỗi, và cảm giác đó giúp “tôi” thấy mình thật cool. (may mà có “tôi” không thì sản phẩm bị lọt lỗi ra ngoài nhé!).v.v…
v.v.. và nhiều lợi ích khác nữa (lúc nào rảnh mình chém tiếp).

(Ảnh minh họa crowd testing, nguồn Applause)

Ở nhóm của tôi, crowd testing được thực hiện đơn giản hơn và mục tiêu hướng tới usability nhiều hơn. Thay vì phân loại crowd testing thành từng phần chuyên nghiệp như: Functional, Security, UI, Performance.v.v.. thì tôi hướng tới việc để các bạn test tự phát (un-educated users). Mục đích là để tôi và nhóm phát triển có cái nhìn trung thực về end-users’s feeling.

Qua thời gian thử nhiệm 1 năm, tôi rút ra kinh nghiệm thực hiện crowd testing cho nhóm với các bước đơn giản như sau:

Thời điểm: Sau khi sản phẩm được QA test xong, các lỗi đã được xử lý, tôi gửi email cho cả công ty (khoảng 60 người) và yêu cầu họ hỗ trợ “dùng thử” sản phẩm.
Đối tượng: Tất cả mọi người, từ em lễ tân tới kế toán hay những nhóm chuyên môn (PM, QA, PHP, Front-end, Managers..) khác.
Thời gian test: 30 phút (bạn có thể để dài hơn nhưng thực ra theo mình thấy để dài hơn sẽ không hiệu quả, thời gian ngắn, bạn sẽ chỉ test những thứ mà bạn thích test nhất, hoặc 30 phút cũng cho bạn thấy với newbie users, thời gian đó có đủ để họ biết dùng sản phẩm hay không?)
Xử lý phản hồi / ý kiến đóng góp: Nên làm đơn giản nhất có thể. Tránh sử dụng những nhứ professional như JIRA, Trello, Basecamp… nó quá xa vời với người không chuyên và cũng “mất thời gian” để log bug. Với tôi, tạo 1 file Google excel hoặc 1 shared folder để mọi người kéo thả screen shots lên đó là đủ.
Sử dụng online chat tool: Cứ thử đi, xem có ai dùng không? có ai hỏi bạn cách sử dụng không? Zopim là 1 tool miễn phí tốt cho bạn.
Stop and review: Bạn phải kiên quyết giữ qui tắc 30 phút. Hết thời gian là ngắt truy nhập 🙂 để sau đó nhóm của bạn tiến hành review, thiết lập ưu tiên cho những bug / hay đóng góp quan trọng và lên kế hoạch hoàn thiện sản phẩm. Quyền quyết định vẫn nằm ở nhóm của bạn, nhưng hãy tập trung vào những ý kiến khách quan và có tính cụ thể cao. Tránh những ý kiến kiểu như “liệu tăng scale lên 1000 concurrent users thì sẽ thế nào?”, hoặc “Ứng dụng khó dùng quá..!”,v.v.. Nói chung là cần tỉnh táo, khách quan.

Crowd testing ở góc độ của tôi có phần nào giống Sprint Demo của Scrum, nhưng thay vì demo theo tuần (cái mà ít hiệu quả ở 1 công ty mà ai cũng bận rộn) thì nhóm của tôi demo ở giai đoạn sản phẩm đã có thể dùng được đối với user. Nghĩa là người dùng có thể chạy hết một user journey.

Bạn có thể áp dụng gamification như giải thưởng cho người test tốt nhất, lỗi tìm ra nhiều nhất, đóng góp về mặt usability hay nhất.v.v.. để tăng tính sôi nổi của cuộc chơi.

Khi sản phẩm được đem ra crowd testing, cũng có nghĩa là cả nhóm phải cố gắng làm thật tốt, chỉn chu hơn. Tester cũng cố gắng test cẩn thận hơn và vì thế bạn có cơ hội kiểm nghiệm nhiều hơn một chút.

Living UX, Are you?

April 14, 2015 ~ binhtruong ~ 7 Comments

Nếu bạn là 1 người làm về UX, CX, bạn có nên lưu ý hơn trong cuộc sống?

(Ảnh: bad driving – nguồn: drivingbad.vn)

Có một lần nói chuyện với Kiên 44 và mấy bạn làm graphic design mình có nghe được idea rằng “dân làm UX thì thông thường sẽ mang lại cuộc sống dễ chịu hơn cho những người xung quanh”. Ngẫm nghĩ ra thì thấy cũng có lý, nhưng chắc là ít người để ý điều này, hoặc là họ có làm về UX, nhưng lại chưa thực sự để ý tới việc mang UX vào cuộc sống?

Vậy Living UX là gì?

Nói một cách đơn giản, đó là tạo ra phong cách sống của chính bạn, mà qua đó bạn có thể mang lại cho những người xung quanh (bạn bè, gia đình, đồng nghiệp…) sự tiện lợi, am hiểu, và hỗ trợ tốt nhất. Nghe vẫn có vẻ mơ hồ, nhưng đôi khi đó là những điều đơn giản mang lại cảm giác, “trải nghiệm” thích thú, thoải mái cho mọi người.

Tôi sẽ chia sẻ một vài ví dụ, mà tôi tin rằng, ai trong chúng ta cũng đã từng làm như thế hoặc cảm thấy thoải mái khi đón nhận nó.

Ví dụ ở công ty

Sáng sáng đi làm, bạn có mỉm cười tươi tắn và nói “chào buổi sáng” với các đồng nghiệp? Lúc trước công ty mình có 1 bạn nữ làm lễ tân, sáng nào cũng vui vẻ chào đón mọi người, ai cũng thấy thoải mái và thân thiện, cảm giác vui vẻ khi bắt đầu 1 ngày mới. (Giờ thì bạn ấy stress vì công việc nên bỏ thói quen đó rồi )
Công ty có vài dụng cụ pha cafe (French press, Sunbeam..), mỗi lần sử dụng xong, bạn có bỏ bã cà phê và rửa sạch hay không? (Để người dùng sau bạn có thể sử dụng được luôn)
Công ty sử dụng Skype chat để trao đổi thông tin trong các dự án, theo thói quen, các đồng nghiệp sẽ đặt “book-mark” các group chat. Rồi 1 ngày tôi thấy 1 anh đồng nghiệp chat nhầm liên tục giữa 2 – 3 group chat dự án, để ý một chút thấy tên dự án khá giống nhau như: Willing donate website, Wendy website, Weird management… Tôi đoán hành vi sử dụng của bạn này là: Vào skype search, gõ “W…” và enter… Điều này dẫn tới khi thao tác nhanh, thường xuyên gõ nhầm “room” chat, tôi lẳng lặng đổi tên các group cho bạn ý rồi thông báo lại. Làm quen với 1 “group name” mới vẫn tốt hơn là nói chuyện “nhầm” với khách hàng.
QA vật lộn với phân loại bug trong JIRA, tôi nói chuyện và tạo thêm “custom field” cho họ.
Làm việc với khách hàng lệch múi giờ tới 3-4 tiếng đồng hồ, tôi dậy sớm hơn, kiểm tra email, trả lời và sắp xếp sẵn mọi thông tin để khi các đồng nghiệp khác tới văn phòng, mọi thứ đã sẵn sàng.
Khi bạn muồn nghỉ phép dài ngày (hơn 1 ngày), ngoài việc báo cho người quản lý, bạn có sắp xếp công việc và chuẩn bị các phương án dự phòng (plan B) để người khác có thể giúp bạn khi bạn ko có ở đó??
Có anh PM (Project manager) viết báo cáo hàng ngày cho khách hàng, trong email không bao giờ cách dòng giữa các ý chính, đọc rất nhức mắt, tôi đã góp ý để nội dung email “dễ đọc hơn”. Cũng có PM viết báo cáo quá dài, tôi cũng góp ý bởi khách hàng (các agencies) họ “không rảnh” để đọc báo cáo dài lê thê, cái họ cần là % completion, overall status, blocker issues… Tóm lại nếu là PM, bạn cần nghĩ rằng làm sao để khách hàng đọc báo cáo của bạn trong..1 phút là nắm đủ thông tin cơ bản của dự án. Bởi cũng như tôi, họ có 20-30 dự án cần theo dõi.
v.v…để ý 1 chút, có rất nhiều ví dụ phải ko?

Ví dụ trong cuộc sống

Trong cuộc sống thì nhiều vô kể, nhưng tôi ví dụ ở một số việc đơn giản, mà chắc rằng không ít lần bạn cảm thấy không thoải mái, vậy tại sao bản thân mình không “improve” nó?

Đi xe trong thành phố, bạn có bật đèn chiếu pha xa (đèn far) hay không? Nếu có, thì bạn nên điều chỉnh, bởi nó gây chói mắt và khó chịu cho người đi đối diện.
Khi dừng đèn đỏ, và khi chỉ còn 3-4 giây nữa là chuyển sang đèn xanh, bạn có bấm còi không? Và nếu đèn đỏ báo 50 giây, bạn có tắt máy?
Vẫn là khi dừng đèn đỏ, bạn có nhường đường ở những nơi cho phép xe rẽ phải?
Khi đứng chờ thang máy trong tòa nhà (chung cư, văn phòng) và khi thang đến, bạn có đứng sang 1 bên để dành chỗ cho người trong thang máy đi ra? Và nếu vào trước, bạn có bấm nút [<>] để cho những người khác đi vào không bị cửa sập vào người?
Khi bước qua cửa kinh cường lực và có người đi phía sau, bạn có dùng tay đỡ cánh cửa để giúp người đó đi qua thuận tiện hơn?
Đi chơi về muộn hoặc không về ăn cơm, bạn có gọi điện hoặc nhắn tin báo cho người thân? (a kind of informative feedback). Điều này cũng giống như khi bạn có hẹn ai đó và đến muộn, bạn cần “update” thông tin cho họ. Con người là đối tượng luôn “đói” thông tin và luôn “thiếu kiên nhẫn”, vì vậy việc cập nhật thông tin của bạn vô cùng hữu ích.
blah blah…

Đọc đến đây bạn thấy có rất nhiều ví dụ phải không? nó nhỏ nhặt, lắt nhắt? hay bạn cảm thấy phải để ý quá nhiều thứ? Hãy suy nghĩ đơn giản, bởi đó là cách giúp bạn thay đổi “thói quen” (building habit) và làm mọi thứ tốt hơn. Để làm được việc này, bạn phải “educate” chính bản thân mình.

David and Goliath

June 14, 2014June 14, 2014 ~ binhtruong ~ Leave a comment

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

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

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

Less is more vs A/B testing

June 4, 2014June 4, 2014 ~ binhtruong ~ 3 Comments

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

Eye tracking

May 31, 2014May 31, 2014 ~ binhtruong ~ Leave a comment

Vài điều cơ bản, cũng hơi xa vời ở Việt Nam

(Ảnh 1: mô tả eye tracking, nguồn: Tobii Technology, Digital trend blog: Internet)

Phải nói là eye tracking method không mới trong lĩnh vực nghiên cứu người dùng (User Research), marketing, quảng cáo… và những năm gần đây thì áp dụng trong UX khá phổ biến ở các nước phát triển. Tại sao ở thời điểm hiện tại, eye tracking vẫn còn “xa vời” ở Việt Nam? bởi 1 lẽ để thực hành nghiên cứu này đối với người sử dụng sản phẩm, các doanh nghiệp sẽ phải bỏ ra thêm nhiều chi phí (thiết bị phần cứng, phần mềm chuyên dụng, phòng Lab), bên cạnh đó cũng chưa có các công ty chuyên cung cấp dịch vụ này. Về mặt con người, Việt Nam cũng chưa có các kỹ sư/chuyên gia có chuyên môn thực sự… Tuy nhiên, điều đó không có nghĩa là chúng ta sẽ “bỏ qua” việc tìm hiểu lĩnh vực này trong quá trình nghiên cứu, áp dụng UX.

Eye tracking là gì?

Một cách ngắn gọn (nhưng hơi hàn lâm) thì eye tracking là phương pháp giúp các nhà nghiên cứu hiểu / thu thập được sự chú ý trực quan của đối tượng nghiên cứu. Còn nói một cách đơn giản, eye tracking là quá trình xác định xem người dùng đang nhìn ở đâu, nhìn trong bao lâu, và quá trình di chuyển mắt (cũng như các thành phần của mắt) của người đó diễn ra như thế nào.

(Ảnh 2: mô phỏng eye tracking, nguồn Morgan Kaufmann)

Một cách cụ thể hơn, những người nghiên cứu UX sử dụng các thiết bị (gọi là eye tracker) để theo dõi, đo đạc quá trình xử lý của võng mạc (cornea), giác mạc (retina), và đồng tử (pupil) thậm chí mống mắt (iris) của mắt người dùng trong lúc họ nhìn vào trước màn hình (máy tính hoặc mobile) để thao tác với phần mềm, website.

Lưu ý rằng, eye tracking là cả một quá trình chứ không chỉ là 1 hành vi theo dõi người dùng thông thường. Nó bao gồm theo dõi, đo đạc, phân tích số liệu để rồi sau đó đưa ra cải tiến. Chính vì vậy, eye tracking là quá trình tiếp diễn nhiều lần (continuous improvement) để có thể đưa ra sản phẩm / giải pháp tối ưu nhất.

Eye tracking được thực hiện như thế nào?

Để thực hiện eye tracking thì những người nghiên cứu về UX sẽ cần những thứ cơ bản như sau:

Trang thiết bị: còn được gọi là eye tracker. Hiện tại trên thị trường có những thiết bị phổ biến như eye tracker glasses (1 loại kính đặc dụng), eye tracker hat (mũ chụp qua đầu có gắn kính), eye tracker screen (màn hình được thiết kế đặc biệt). Những thiết bị này thường dùng 1 nguyên lý chung là sử dụng tia hồng ngoại sóng ngắn chiếu thẳng vào mắt người dùng (user) với các tiêu chuẩn an toàn sao cho không gây tổn hại sức khỏe. Sau cùng, tất nhiên là 1 máy tính xử lý thông tin có được. Lấy ví dụ như bạn đeo kính eye tracker cho người dùng và yêu cầu họ thao tác trên website bạn mới thiết kế, trong vòng 1 giờ đồng hồ, thiết bị này sẽ ghi lại mọi chuyển động của mắt và gửi về máy tính gần đó.
Phần mềm: Sau khi dữ liệu về eye tracking được gửi về máy tính, cần có một phần mềm chuyên biệt để phân tích dữ liệu đó. Hai loại dữ liệu quan trọng nhất là các điểm di chuyển của mắt người dùng (eye movement) và nơi người dùng nhìn vào (location) cũng như nhìn nhiều nhất (hot spot – điểm nóng).
Phòng lab (không bắt buộc): Bạn cần một phòng thí nghiệm để thực hiện điều này, yên tính và có đầy đủ sự hỗ trợ cần thiết.
Tình nguyện viên: Đây là cái tôi thêm vào ngoài những điều có trong sách vở, bởi cá nhân tôi nghĩ yếu tố này quan trọng và không nên làm qua loa. Bạn phải chọn “đúng người”, nghĩa là “target users”. Là những người sử dụng mà ngay từ đầu, trước khi thiết kế giao diện phần mềm / website, bạn đã hướng tới họ là đối tượng sử dụng chính của sản phẩm hoàn thiện sau này.
Tiền và thời gian: Tất nhiên roài, để làm eye tracking bạn phải có chi phí, và cần thời gian để thử nghiệm nhiều phương án khác nhau, kể cả dùng eye tracking với A/B testing. (tôi nghĩ vậy).

Khi đã đẩy đủ những thứ cần thiết, tùy vào thiết bị, dụng cụ mà chúng ta tiến hành thử nghiệm bằng các bước sau (tham khảo ảnh 1 phía trên):

Yêu cầu người tình nguyện viên đeo kính hoặc thiết bị eye tracker.
Yêu cầu tình nguyện viên ngồi trước màn hình để thao tác trên phần mềm / website. Việc thao tác cần tự nhiên như một người dùng bình thường tìm hiểu và khám phá, sử dụng sản phẩm.
Khởi động phần mềm theo dõi thời gian thực (real-time)
Thời gian theo dõi và thực hiện nên kéo dài ít nhất 30-60 phút.
Kết thúc thử nghiệm, chạy thống kê số liệu từ máy tính, kiểm tra kết quả.

Nôm na thì là vậy, nhưng để giải thích chi tiết hơn đối với 1 dự án eye tracking, có lẽ tôi sẽ viết series blog khác. Dưới đây là mô phỏng hot spot của giao diện kết quả tìm kiếm Google.

(Ảnh 3: một ví dụ về eye hot spot, nguồn internet)

Lưu ý rằng, việc sử dụng eye tracking không nhất thiết “phải ngồi 1 chỗ” mà có thể thực hiện tại các địa điểm ngoài trời, siêu thị, trung tâm thương mại.v.v…

Lợi ích và những hạn chế

Với việc áp dụng eye tracking, hẳn bạn sẽ thấy nhiều lợi ích mà nó mang lại. Điều dễ thấy nhất là việc theo dõi sự quan sát của người dụng một cách chính xác giúp chúng ta (những người thiết kế sản phẩm) có thể “hiểu” họ (người dùng) rõ hơn. Việc áp dụng eye tracking nhằm phục vụ công tác nghiên cứu người dùng (user research), vì thế, nó không chi giới hạn trong lĩnh vực UX mà còn mở rộng sang các ngành nghề như Marketing (vd: nghiên cứu cách hiệu quả trong cách bài trí của siêu thị), quảng cáo (vd: theo dõi cách người dùng nhìn và cảm nhận poster), xuất bản (vd: kiểm tra tính hiệu quả của cách dàn trang, trình bày văn bản), thói quen lái xe hơi, đào tạo phi công, thiết kế giao thông, biển báo, thiết kế games.v.v… Dữ liệu mà eye tracking mang lại cũng sẽ được khai thác giống như một dạng big data vậy.

(Ảnh 4: ứng dụng eye tracking trong thiết kế kệ giày shop bán giày, nguồn internet)

(Ảnh 5: ứng dụng eye tracking trong thiết kế trưng bày sản phẩm tại siêu thị, nguồn internet)

Bên cạnh những lợi ích hiển nhiên, eye tracking không phải là không có những hạn chế của nó. Giống như big data, dữ liệu mà eye tracking mang lại chỉ mang lại thông tin về hành vi của người dùng (what) chứ không giải thích tại sao (why). Nó không thể giải thích tại sao người lại nhìn vào bên phải màn hình 30 giây rồi nhìn lên phí top-menu 10 giây. Để lý giải nguyên nhân, chúng ta phải kết hợp eye tracking với những kỹ thuật UX khác, ví dụ như usability testing. Ngoài ra, một vài thí nghiệm đơn lẻ với eye tracking không thể mang lại hiệu quả cao cũng như lý giải tại sao người dùng lại tương tác như vậy khi nhìn vào website của bạn. Để đưa ra dự đoán / kết luận gần đúng nhất với hành vi của người dùng, chúng ta cần lượng thông tin “đủ lớn” và tiến hành nhiều kỹ thuật nghiên cứu, phân tích dữ liệu trong một khoảng thời gian đủ lâu nhưng hợp lý.

Tham khảo:

Thiết bị eye tracker Tobii: http://www.objectiveeyetracking.com.vn/
Eye tracking cũng là 1 phần của lĩnh vực visual perception / recognition
Áp dụng eye tracking trong thiết kế Windows 8 touch keyboard.