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.

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

What to Test in A/B

September 18, 2013September 19, 2013 ~ binhtruong ~ Leave a comment

Test cái gì trong A/B testing, và thực hiện A/B test cho website như thế nào?

(Ảnh: kết quả thử nghiệm A/B testing, nguồn Internet)

A/B testing hiện tại có lẽ đang là một khái niệm được áp dụng rộng rãi trong các chiến dịch marketing, đi kèm với micro site hoặc các landing page quảng cáo. Khái niệm cơ bản của A/B testing tôi đã trình bày trong blog trước đây, tuy nhiên thực hiện như thế nào thì cần phải có kế hoạch cũng như chiến thuật cụ thể hơn.

This process begins with the most important question of all: What is the purpose of your site?

Có thể nói, ở Việt Nam thì không nhiều công ty có đủ chi phí, sự kiên nhẫn và mindset làm A/B testing. Nghe thì hay, nói thì hay nhưng không phải ai cũng muốn thực hiện nghiêm túc, đa phần chỉ dừng lại ở mức theo dõi Google Analytic xem số liệu rồi điều chỉnh chi phí marketing mà thôi. Nhưng nếu muốn làm nghiêm túc thì sao? OK, đầu tiên bạn (hoặc team của bạn, bao gồm cả sếp) phải trả lời câu hỏi mục đích của website (hoặc landing page) là gì? Không có đích đến, sẽ không hoạch định được đường đi đúng đắn.

Khi đã có mục tiêu cụ thể, A/B testing được tiến hành theo 05 bước phổ biến như sau:

Define success: Thiết lập các số liệu dưới dạng tiêu chuẩn mà các nhóm triển khai sản phẩm (website cùng hướng tới). Thường sẽ có 02 nhóm A và B. Bạn sẽ không thể xác định xem giải pháp của nhóm nào giành phần thắng nếu như không xác định các số liệu định lượng một cách rõ ràng. Số liệu có thể là thời gian trung bình 01 user xem một trang web, số lượng pageviews, số lượng đơn đặt hàng trung bình, số lượng visitor, doanh thu / trên 1 visitor.v.v… (Cũng có thể lựa chọn các thông số như churn rate, exit rate, conversion rate…)
Identify bottlenecks: Phối hợp cùng với nhóm của bạn, cùng với số liệu analytic của website, phân tích xem website đang bị “tắc” ở đâu? nghẽn ở khâu nào? người dùng dừng lại và bỏ đi từ trang nào nhiều nhất trên website? trang checkout có vấn đề gì không? hoặc trang xem chi tiết sản phẩm có cần cải tiến ở khâu nào để người dùng đặt hàng dễ dàng hơn? A/B testing không nhất thiết phải test tất cả các trang trong 1 website, chỉ cần tìm ra “bottleneck” và cải tiến triệt để sẽ mang lại hiệu quả rõ rệt.
Construct a hypothesis: Hypothesis nghĩa là giả thuyết. Sau khi xác định được “bottleneck” của website ở đâu, các nhóm xây dựng website cần tiến hành hàng loạt các thủ tục, các bài test để đưa ra giả thuyết về người dùng. Ví dụ như phỏng vấn một lượng người dùng (user interview), theo dõi, quan sát hành vi của một nhóm người dùng (focus group) hoặc lấy thông tin phản hồi (thông qua feedback form)… để rồi từ đó đưa ra các giả thuyết, cũng như các thay đổi cần thiết, các cách thức thực hiện thay đổi (về giao diện, về qui trình mua hàng online chẳng hạn).
Prioritize: Khi có một mớ các giả thuyết, bước tiếp theo là đưa ra mức độ ưu tiên. Cải tiến cái nào trước, test cái nào trước, thử nghiệm giải pháp nào trước. Tất cả tùy thuộc vào mục tiêu mà chúng ta đã đặt ra ban đầu. Chẳng hạn như website e-commerce thì những màn hình check-out, payment cần ưu tiên hơn là test các API tương tác với các đại lý.
Test: Sau cùng, khi đã có các giải pháp thử nghiệm theo thứ tự ưu tiên (thường 1 trang màn hình trên website sẽ có 2 giải pháp A và B để 2 nhóm tiến hành test), công việc phải làm chính là test. Việc test được tiến hành với những nhóm người dùng ngẫu nhiên (có thể thuê freelancer, tình nguyện viên, sinh viên vào dự án test này).

Đầu ra của việc A/B test chính là các báo cáo, với những thông số analytic mới và các nhóm (nhóm A, nhóm B) lại tiến hành cập nhật, cải tiến giải pháp của mình. Chu trình A/B test bao gồm 5 bước nêu trên có thể được thực hiện lặp lại nhiều lần, cho tới khi các giải pháp thay đổi đáp ứng được mục tiêu đặt ra (thường là về số liệu) ban đầu.

Sau khi kết thúc dự án A/B testing (gọi là dự án nội bộ), người quản lý dự án chọn ra phương án (A hoặc B) đáp ứng yêu cầu tốt nhất để từ đó triển khai cho sản phẩm go live. Lưu ý nhỏ là A/B testing không nhất thiết phải tiến hành khi dự án website mới bắt đầu, A/B testing phục vụ cho cải tiến, kiểm nghiệm những phương áp thay đổi, phát triển sản phẩm trong suốt vòng đời của sản phẩm đó.

Một chút về A/B Testing

September 9, 2013September 9, 2013 ~ binhtruong ~ 5 Comments

Sơ lược về A/B Testing trong web design, mà thực ra khái niệm cũng không có gì phức tạp

(Ảnh mô tả A/B testing, nguồn Internet)

Testing thường được quan tâm bởi QA/QC hoặc đối với những người chịu trách nhiệm đầu ra của sản phẩm như marketing manager, product manager. Tuy nhiên với UX thì usability testing cũng đóng vai trò quan trọng, bởi nó giúp cho người thiết kế sản phẩm hiểu rõ hơn tính hiệu quả của bản thiết kế. (Thiết kế ở đây tôi muốn nói là product design, không đơn thuần là graphical design).

Về cơ bản, A/B testing (trong phạm vi web design) là quá trình thực hiện kiểm tra (test) và so sánh (compare) hai phiên bản khác nhau của một website trong cùng một thời điểm để từ đó rút ra kết luận rằng bản thiết kế nào tốt / phù hợp hơn với người dùng cũng như với mục đích kinh doanh. Một số tài liệu còn gọi A/B testing là “split testing”.

Ví dụ như bạn có một website bán dịch vụ email marketing, nhóm marketer và designer trong công ty đang tranh luận xem bản thiết kế nào tốt hơn, có khả năng chuyển đổi nhiều khách hàng tiềm năng thành người mua hàng hơn… vậy thì cách tốt nhất (hiện nay) là thực hiện A/B test để kiểm chứng. Việc này sẽ được thực hiện trên 02 phiên bản của website: phiên bản A và phiên bản B. Bên cạnh đó, một nhóm người sẽ được phân công để test (nếu công ty bạn đủ số lượng người mong muốn). Kết quả sau cùng (ví dụ số lượng click vào nút mua hàng) của phiên bản nào tốt hơn, phiên bản đó sẽ được lựa chọn để “go live”.

A/B testing (sometimes called split testing) is comparing two versions of a web page to see which one performs better. (source: Internet)

Tại sao và có thể test những gì ở website?

Nếu nói “tại sao phải A/B testing” thì có lẽ hơi… thừa. Nhưng tựu chung lại một sự lựa chọn tốt là kết quả của nhiều phép thử. Chính vì vậy, cho dù website của bạn là dạng news, hay e-commerce, blog, market place.v.v… thì cũng nên test để kiểm tra lượng truy cập, tỷ lệ convert từ visistor thành khách hàng (1) sao cho đạt được mục tiêu khi làm ra trang web.

(Ảnh: các phiên bản khác nhau của A/B testing. Nguồn Internet)

Vậy đối với một website, nếu muốn thực hiện A/B testing thì có thể “test” những cái gì? hay nói nôm na là lôi cái gì ra để test? Câu trả lời là hầu hết mọi thành phần của website đều có thể là đối tượng của A/B (xem hình trên). Ở góc độ đơn giản, chúng ta có thể test những thành phần như (ở danh sách dưới đây, tôi chỉ giải thích những khái niệm mà tôi nghĩ nhiều người chưa biết):

Headlines
Sub headlines
Paragraph Text
Testimonials (Thường là những comment khen ngợi, khách hàng tiêu biểu)
Call to Action text
Call to Action Button
Forms
Links
Images
Content near the fold (Phần nội dung hiển thị phía dưới màn hình trước khi cuộn chuột để xem phần còn lại của trang web) (2)
Social proof
Media mentions
Awards and badges (Một dạng khen thưởng thành viên/khách hàng, áp dụng lý thuyết gamification)

Có thể nhận thấy, mọi thành phần (bao gồm cả content, information architect và graphical) của website đều có thể đem ra test. Nhưng đặt trọng tâm ưu tiên test cái gì, thì lại phụ thuộc vào mục tiêu bạn mong muốn đạt được ở website. Phần lớn các marketer nhắm vào call-to-cation và designer nhắm vào images, color.

Ở góc độ nâng cao của A/B testing, những người làm ở vị trí website product manager thường nhắm tới chiến lược giá (pricing structure), sales promotion (khuyến mại), thời hạn dùng thử sản phẩm, menu navigation, cách tính free/paid delivery và checkout khi thanh toán online. Cá nhân tôi thì cho rằng menu navigation là advance A/B testing bởi nó liên quan tới việc điều hướng hành vi, cũng như cấu trúc thông tin của hệ thống và cần phải theo dõi dài hơi trước khi có sự thay đổi. Tất nhiên là mấy vụ testing nâng cao (A/B testing in advance) này tốn công sức khi thực hiện hơn vì thay đổi qui trình, cách thức với những chức năng dạng core, cũng như việc đo đạc mất thời gian hơn.

Câu hỏi sau cùng có lẽ là “Test bao lâu thì đủ?”. Cái đó tùy thuộc vào bạn. A/B testing có thể thực hiện nhiều vòng, cho tới khi đạt mục tiêu đặt ra ban đầu về số lượng traffic, visitor, click, conversion.v.v… nhưng đừng để test quá dài bởi nó sẽ gây ra các ảnh hưởng không tốt (ví dụ như SEO, hay nhận thức của user).

Ngày nay muốn test tốt thì phải dùng tools. Hiển nhiên. Có một số dịch vụ “advance” hơn thì có thể sử dụng embedded code. Phần này tôi để các bạn tự khám phá. Hãy bắt đầu với cụm từ “online a/b testing tools” và dùng thử vài dịch vụ, đặt ra giả thuyết, mục tiêu và hoàn thiện sản phẩm qua các phiên bản A, B và có thể là C, D nữa.

Ghi chú:

(1) Tỷ lệ convert: Thường được gọi là Conversion rate, ám chỉ số lượng khách ghé thăm website chuyển đổi thành người mua hàng trực tuyến. Ví dụ 1 người mua hàng / 100 khách ghé thăm thì tỷ lệ là 1%.

(2) The fold: Để dễ hiểu hơn, các bạn có thể xem phần hiển thị đầu tiên trên màn hình của một website là “above the fold”, giống như một tờ báo gập đôi và bạn xem phía trên của nếp gấp. Tôi sẽ nói rõ hơn về khái niệm này ở 1 blog khác.