UX cost và dự án

September 15, 2015December 6, 2017 ~ binhtruong ~ 6 Comments

Nói về UX cost cho các dự án ở Việt Nam

(Ảnh: cost doodle, nguồn doodlecreative)

Tháng trước có bạn hỏi tôi về chi phí dành cho UX trong các dự án tôi đang làm, câu hỏi làm tôi phải suy nghĩ, khá hay, và ở vị trí đang làm tôi phần nào hiểu được thực trạng đó ở Việt Nam. Vậy nên hôm tôi muốn ghi lại vài dòng, biết đâu mấy năm nữa tình hình thị trường UX ở Việt Nam khá hơn, lúc đó đọc lại bài này sẽ thấy vui vui.

Ở Việt Nam có 3 mảng dự án mà tôi nghĩ có thể “có phần” cho UX:

Product & creative: Đa phần là các dự án phát triển sản phẩm ở “các công ty product”. Các công ty này có nguồn vốn đầu tư để build sản phẩm. Ví dụ như Tiki, Foody, Ringier Media, Lazada, Vietnamworks, Zalora.. hay các cty chủ quản của website Dân Trí, VNExpress, Danhgiaxe.com v.v… Nói chung là build product hoặc duy trì, phát triển 1 sản phẩm (đa phần là sản phẩm công nghệ). Cơ hội làm UX ở đây, theo tôi, là lớn nhất. Chi phí dành cho UX (nếu có) cũng khá nghiêm túc. Tuy nhiên, chi phí này nhiều khi là 1 phần của chi phí design hoặc BA (business analysis)
Outsourcing: Đây là mảng thị phần lớn nhất trong ngành IT ở Việt Nam. 70-80% các công ty IT là làm về outsourcing, các công ty này làm nhiều thị trường, nhiều mảng nghiệp vụ, nhưng với các công ty làm về Digital Marketing (như cty tôi đang làm) thì công việc liên quan tới UX là đáng kể nhất. Cụ thể hơn là bạn được làm trực tiếp với digital design team và qua đó được “tham gia phần nào” vào công việc UX thường xuyên hơn. Chi phí này được tính vào chi phí product design hoặc đúng nghĩa UX job.
In house projects: Là những dự án dành cho những team UX chuyên biệt của các tập đoàn lớn. Loại hình này không nhiều nhưng theo tôi biết họ, các công ty này, được đầu tư và có team UX riêng. Ví dụ như FSoft, Vinagame, và mới đây theo tôi thấy là VIB. Có lẽ còn nhiều công ty khác mà tôi chưa biết. Nhưng nói chung là vẫn hiếm. Chi phí cho UX trong phân khúc này chủ yếu nằm trong chi phí R&D (research and development). Vậy nên hàng năm vẫn sẽ có trường hợp review budget. Thực ra cái này thì ở đâu cũng thế, team UX phải tự sale chính mình, và các dự án của mình với cấp lãnh đạo cao hơn.

Đó là mảng dự án, còn sale cho chí phí này thì sao? Với loại hình dự án số 1 và số 3 thì chi phí này đã được “cấp trên” tính đến, vì dù sao đó cũng là chi phí đầu tư, do vậy chỉ còn băn khoăn với loại hình số 2: outsource. Cá nhân tôi sau 1,5 năm làm ở mảng digital marketing với thị trường Úc, Singapore, UK và Hongkong thì rút ra một số trải nghiệm như sau:

Khi việc tới tay mình thì đa phần đã qua khâu UX và UI/graphic design rồi, tuy nhiên mình được làm việc cùng với team UX bên phía đối tác để review và điều chỉnh (gọi là verify and adjustment). Mặc dù value không nhiều nhưng vẫn có thể đưa ra những điều không hợp lý, cung cấp giải pháp (bắt buộc bạn phải có alternative solution thì hẵng nói chuyện review nhé) để hiệu quả của sản phẩm được tốt hơn. Theo tôi thấy, dân làm trong ngành này cởi mở và sẵn sàng lắng nghe hơn là khách hàng của mảng enterprise .
Chi phí UX được tính vào những dự án lớn (khoảng 100K USD trở lên) khi đối tác không thực sự có team UX mạnh hoặc đội ngũ UX của họ quá bận rộn, quá mỏng. 6 tháng trở lại đây, tôi thường được làm việc với UX lead của đối tác, hoặc Design director / creative director của khách hàng để triển khai các công việc UX design. Nghĩa là không có được làm UX strategy hoặc UX project từ A tới Z mà làm các khâu như phân tích (analyse), customer experience journey, và phần lớn là interactive wireframe. Chính vì vậy mà thời gian làm việc với Axure của tôi ngày một nhiều lên.
Với những dự án re-design (website hoặc mobile app) thì chi phí cho UX là rõ ràng, tách biệt, tuy nhiên cũng không nhiều. Một lần nữa, chi phí này không dành cho user research. Các công việc cần làm là hợp tác với nhóm creative design (có thể của 1 bên thứ ba), với nhóm marketing để có số liệu. Các công việc như personas, user interview chủ yếu được thực hiện dưới dạng remote research. Tất nhiên vì thế mà tính hiệu quả không thực sự mạnh, làm đi làm lại cũng nhiều và chi phí UX cho phía công ty tôi đang làm cũng không cao. (vì đâu có làm được full qui trình cho họ). Mặc dù vậy, xét một cách tích cực thì khi đã có chi phí UX, nó cũng chiếm 20-30% tổng chi phí của dự án, có khi ngang bằng chi phí development, deploy, support cộng lại.

Như vậy có thể thấy rằng, chi phí cho UX ở đây (các công ty và dự án ở Việt Nam) hiện tại chưa nhiều và chưa định hình rõ ràng. Muốn làm về UX bạn cũng cần chọn những nơi có chi phí để làm, cũng như có chính sách hỗ trợ nó.

Một khía cạnh khác mà bạn cũng cần quan tâm là “không ai rót chi phí UX cho bạn để làm chơi”. Chi phí UX, theo kinh nghiệm của tôi, trước giờ luôn gắn với KPI dự án. Dù là dự án nội bộ. Ví dụ như một khách hàng của tôi, website của họ có doanh số online 500k – 1 triệu USD / tháng, họ đặt ra tiêu chí tăng trưởng 1% – 3% cũng khiến cả team của tôi “chạy theo” hết hơi rồi.

Vẫn biết UX project là ideal – build – test rồi lặp đi lặp lại, nhưng nếu quá trình này kéo dài quá lâu thì bạn sẽ không còn chi phí để thực hiện, lúc đó sẽ lẹm vào chi phí của các hạng mục khác trong dự án và thua lỗ là khó tránh. Vì vậy, UX lead và Project lead cần phối hợp chặt chẽ với nhau trong hoạch định dự án, và tới đây bạn cũng có thể thấy rằng làm UX cũng nhiều áp lực.

Persona or User Stories?

September 9, 2015September 9, 2015 ~ binhtruong ~ 1 Comment

Nên sử dụng kỹ thuật persona hay là dùng user’s stories?

(Ảnh: 90’s game – nguồn: www.hanselman.com)

Dạo gần đây thấy nhiều bạn (kể cả bạn sếp của mình) hay nói về user stories khi phân tích yêu cầu người sử dụng trong quá trình phát triển sản phẩm /dự án. Phần lớn tôi thấy các bạn có thể liệt kê ra hàng loạt user stories đối với một dự án web hoặc mobile. Ai cũng thuộc làu làu “khẩu quyết võ công” như sau:

“As a <type of user>, I want <some goal> so that <some reason>.”

Cá nhân tôi thấy pattern này áp dụng khá dễ dàng, dễ hiểu, có thể thể hiện cái người dùng muốn mà không phải giải thích nhiều ở góc độ kỹ thuật. User stories nếu liệt kê ra (đối với sản phẩm mang tính phức tạp cao như e-Commerce, Enterprise app) thì dài hàng chục trang giấy. Nó không phải là vô ích, nhưng với MVP hay Lean thì.. hơi mệt (cá nhân mình thấy vậy)

Tôi bắt đầu làm Scrum vào năm 2006 khi công tác tại Cebu – Philippines. Lúc đó tôi cũng áp dụng “máy móc” theo cách “As user.. I want…” để liệt kê đủ những stories mà mình thấy hệ thống cần có. Chẳng quan tâm tới những gì khác, cũng không biết người dùng thực sự họ nghĩ gì… Và tôi cảm thấy: xác định user stories không phải (không nên) là bước đi đầu tiên. Với tôi, nó là persona.

Nói một cách đơn giản, ví dụ như trong cuộc sống, trước khi nghĩ rằng mình nên làm thế này, thế kia để lấy lòng 1 bạn gái, bạn cần phải hiểu người ta trước đã. Persona cũng vậy. Trước khi viết ra những user stories chính xác và phù hợp với user’s needs, bạn cần phải hiểu target users của mình cũng như hiểu khách hàng của mình cần gì. Trong nhóm target user của bạn, có bao nhiêu personas? Hay đơn giản hơn, bạn phân loại người dùng của mình theo nhóm, rồi tìm hiểu những nhu cầu, khó khăn và mục tiêu cần đạt được của họ khi sử dụng sản phẩm, rồi qua đó mới đưa ra những thứ họ cần về mặt chức năng của hệ thống.

Ví dụ dưới đây là sự phân cấp theo cách hiểu của tôi (cách tôi được học) về user research, kết hợp UX và Agile:

Persona
- Epic
  - User stories
    - Task break-down (WBS)

..qua đó, trước khi đưa ra các user stories chúng ta tiến thành phân nhóm người dùng bằng cách xây dựng các persona tiêu biểu, rồi qua đó đưa ra nhưng chức năng chính của hệ thống, sau cùng mới xây dựng những chức năng cụ thể cho từng nhóm người dùng.

Nếu ngay từ đầu, bạn dựa vào thảo luận nhóm, dựa vào kinh nghiệm, dựa vào survey 1 nhóm người bạn quen, và đưa ra danh sách các user stories thì theo tôi, sẽ có nhiều điểm không phù hợp với UX approach, cụ thể như sau:

Wrong target user: Không đúng đối tượng người dùng. Bạn thiết kế 1 website bán hàng rau củ quả, nhưng bạn, dựa vào kinh nghiệm thiết kế UX, liệt kê ra một loạt tính năng của e-commerce trong khi bạn không hiểu họ là những ai? Cụ thể hơn, user của bạn là phụ nữ, độ tuổi 25-40 tuổi, thường online vào giờ nào (để mua sắm)? , cần trình bày thông tin của những sản phẩm thiết yếu gì? khó khăn của họ là gì? Họ quan tâm tới rau tươi, tiết kiệm thời gian mua thực phẩm thiết yếu, giao hàng nhanh chóng đúng hẹn v.v.. Những thứ khác kiểu như so sánh sản phẩm, nhóm sản phẩm, bộ lọc, các loại hình thanh toán, zoom in/out sản phẩm… chỉ là thứ yếu.
No role: với persona, bạn chỉ quan tâm tới người dùng thực sự, phân loại họ dựa trên các yếu tố con người , không phải tuân theo các vai trò của người dùng hệ thống (Kiểu như admin, mod, super user, newbie). Điều này tránh sa đà vào việc phân tích hệ thống thay vì phải phân tích người dùng.
Wrong time (and waste): Loanh quanh với user stories ở giai đoạn đầu của quá trình phát triển sản phẩm sẽ khiến bạn và team của bạn tốn rất rất nhiều thời gian. Thời gian phân tích, rồi xếp loại, rồi thiết lập thứ tự ưu tiên.. một lần nữa, nó khiến bạn tốn nhiều công sức trong khi bạn cần tập trung toàn lực vào suy nghĩ làm sao hiểu được nhóm user nào bạn cần phục vụ, khó khăn của họ là gì và mong muốn của họ ra sao (ở một mức độ rất high level).

Nói tóm lại, mấy thứ như epic, user stories, use case, scrum.. là cần thiết nhưng không nên lạm dụng. Scrum là 1 framework chứ không phải là process. Nghĩa là cái gì phù hợp đúng hoàn cảnh, thời điểm, đặc tính của sản phẩm thì ta áp dụng. UX vẫn cần chú trọng tới tìm hiểu và phân loại người dùng, xây dựng và điều chỉnh persona trong suốt vòng đời của sản phẩm, và những thứ như Lean, Scrum concepts là bạn đồng hành đi theo và hỗ trợ lẫn nhau.

P.s: Bài viết này phần lớn là quan điểm cá nhân. Tôi không muốn thấy quá nhiều bạn cứ băm bổ vào Agile/Scrum và cứ mang nó “đè” lên cái cơ bản của UX 🙂

Tìm hiểu IA – Slide shared

September 8, 2015 ~ binhtruong ~ Leave a comment

Ôn lại khái niệm IA qua slide của Perter Morville

(Ảnh: Understanding IA – nguồn: Peter Morville)

IA (Information Architect) không phải là khái niệm mới, đây thậm chí là khái niệm cơ bản với những ai muốn học và làm về UX. Trong mô hình The Elements of User Experience của JJG (Jesse James Garrett) thì IA đứng ở lớp thứ 3 từ dưới lên.

IA – kiến trúc thông tin – là một môn học khó, đòi hỏi người tiếp cận nó có tư duy hệ thống, hiểu cách tìm kiếm và xử lý thông tin của người dùng, rồi từ đó xây dựng nên kiến trúc thông tin của sản phẩm (web hoặc mobile).

Cuốn sách tham khảo về IA nổi tiếng là cuốn OReilly – Information Architecture for the WWW, 3rd Ed (2007) của Peter Morville (mới tái bản năm 2015) là một tài liệu căn bản và cũng rất phổ biến với dân làm UX, IA. Tuy nhiên, để giúp bạn tiếp cận với kiên thức căn bản nhanh gọn hơn và dễ hiểu hơn, Morville đã giới thiệu một slide tổng hợp với tựa đề “Understanding Information Architecture” mà qua đó ban sẽ có cái nhìn tổng quan về các vấn đề mà Morville đề cập trong cuốn sách của ông.

Nếu bạn thích học UX bài bản, thì IA là một trong những bước đi đầu tiên và là một trong những kỹ năng quan trọng trong việc xây dựng và phát triển hệ thống thông tin, điển hình là website mà hàng tỷ người dùng đang sử dụng, khai thác hiện nay.

Về IA, tôi sẽ lần lượt giới thiệu các kỹ năng, kỹ thuật trong các blog sau này.

Happy learning! 🙂

Findability Tiki

September 6, 2015September 6, 2015 ~ binhtruong ~ Leave a comment

Bug noted – lỗi cấu trúc thông tin của Tiki

(Hình 1: Tiki.vn – nguồn Tiki.vn)

Từ trước tới giờ, thỉnh thoảng tôi vẫn viết về các lỗi thiết kế (UI, service) của các website, việc này không nhằm chê bai hay “tự sướng”, mà là để chỉ ra những thứ ta có thể làm tốt hơn, và bản thân tôi cũng học hỏi từ đó.

Trở lại với Tiki.vn sau sự cố bị từ chối cộng điểm vì ban quản trị nghĩ rằng tôi “copy” bình luận sách từ trên Internet. Sau khi chứng minh là tôi copy từ chính… blog của mình, tôi đã được bổ sung “tiki xu” trở lại. Nhưng sau đó thì cũng không engage với website này nữa, một phần vì muốn đi lượn phố Nguyễn Xí hơn, và một phần Tiki mở rộng sang đa ngành nghề (tôi biết áp lực tăng trưởng là phải vậy). Tuy nhiên hôm nay cần mua một cuốn mà lười ra phố, nên tôi lại truy cập website này.

Về cơ bản thì hệ thống website Tiki.vn vẫn vậy, ngoài những tính năng cơ bản thì có nhiều không gian được thiết kế lại để dành cho quảng cáo hơn. Cấu trúc thông tin top-down vẫn như cũ, nghĩa là danh mục chính, rồi các cấp danh mục nhỏ hơn qui hoạch bên trong.

(Hình 2: on top banner của Tiki )

Tuy nhiên, đi sâu vào phần tìm kiếm sách, tôi nhận thấy 2 vấn đề “cản trở” người dùng tìm được thông tin mình cần trước khi ra quyết định mua sách:

Vấn đề #1 – Cover to detail: Nghĩa là cấu trúc thông tin bên ngoài và thông tin chi tiết bên trong không có sự đồng nhất. Mặt này có 2 điểm: một là mental model của cá nhân tôi nghĩ rằng hình ảnh thumbnail của 1 category sẽ được lựa chọn từ 1 trong những sản phẩm thuộc category đó. Cụ thể là cuốn REWORK đáng ra phải nằm trong phần “Kỹ năng sống – Làm việc” như hình bên dưới:

(Hình 3: Category “Kỹ năng sống – Làm việc” nhìn từ bên ngoài với hình ảnh cover là cuốn REWORK)

Nhưng khi click vào bên trong, category này hoàn toàn không có sản phẩm REWORK như tôi hình dung:

(Hình 4: Bên trong category “Kỹ năng sống – Làm việc”)

Bên cạnh đó, khi vào xem chi tiết category nêu trên, toàn bộ phần thông tin của tên category, menu thứ cấp breadcrumb đều tự động chuyển sang tiếng Anh. Điều này một lần nữa sẽ khiến người dùng “bối rối” bởi không biết “có phải mình vừa chọn sai category hay không?”. Vậy tôi phải làm gì đây? Tất nhiên là phải nhờ tới chức năng “tìm kiếm”, một thành phần cơ bản của IA, và điều này cho thấy vấn đề tiếp theo.

Vấn đề #2 – deep organize & breadcrumb: Tôi chủ động gõ từ khóa “reworkd” vào ô tìm kiếm, phần gợi mở (suggestion) hiển thị ra cuốn REWORK nhưng khi gõ “enter” để tìm kiếm thì kết quả không tìm thấy. Ok, tôi sửa lại từ khóa thành “rework” và tìm thấy thông tin sản phẩm mình mong muốn:

(Hình 5: Hình ảnh sản phẩm REWORK)

Từ vị trí này, tôi để ý lên phần menu breadcrumb. Tại sao tôi phải làm vậy? một lần nữa, nó là logic theo mental modal của user’s brain. Lý do là ở các bước đã nêu ở trên, tôi là một người dùng đã tìm sản phẩm (hoặc đã được định hướng tìm sản phẩm) tại một category không chính xác. Chính vì thế nên tôi mới thắc mắc là sản phẩm này nằm ở category nào ? và làm sao để tìm thấy nó?

Theo thứ tự, tôi bắt đầu tìm theo chiều cấu trúc từ trong ra ngoài để tìm category chính thức của sản phẩm. Thứ tự này bao gồm:

Trang chủ ->
- English books ->
  - Business – Investing ->
    - Entrepreneurship – Small Business

Vậy là có tới 4 cấp category dẫn tới sản phẩm tôi muốn tìm mua. Tới đây, tôi lần lượt bấm vào các category theo thứ tự từ trong ra ngoài, từ dưới lên trên với mong muốn trở về đúng category listing của sản phẩm. Nhưng kết quả tôi nhận được lại là các category không có dữ liệu bên trong:

(Hình 6: category Entrepreneurship – Small Business không có dữ liệu bên trong)

(Hình 7: category Business – Investing không có dữ liệu bên trong)

Sau cùng, không biết làm thế nào để tìm được đúng category cần thiết, tôi bấm vào “English book” thì hệ thống đưa tôi trở về trang chuyên các sản phẩm sách tiếng Anh, mà trong đó, tôi gặp lại category “Kỹ năng sống – Làm việc” ở Hình 3 phía trên. Là một người dùng, tôi hoàn toàn mất phương hướng (completely lost).

Nhìn ở góc độ tổng thể, website vẫn vận hành bình thường. Các đơn hàng có lẽ vẫn đều đặn và thỏa mãn chỉ tiêu KPI của đội ngũ kinh doanh, nhưng không chắc thời gian tìm kiếm trung bình đối với một sản phẩm rồi từ đó dẫn đến hành vi đặt hàng, mua hàng của người dùng là bao lâu? Sẽ ảnh hưởng tới conversion rate có đáng kể hay không? Có thể, mọi thứ là không đáng kể.

Bài viết này tôi muốn chỉ ra một điều đơn giản: IA luôn có thể làm kỹ lưỡng hơn nữa để sản phẩm phục vụ người dùng tốt hơn, trải nghiệm qua đó cũng tăng lên, bởi e-Commerce, nói một cách khác, là để tiết kiệm thời gian.

Findability is a critical success factor for overall usability. If users can’t find what they need through some combination of browsing, searching, and asking, then the system fails. – IA definition, Peter Morville

Có 1 designer lâu năm nói với tôi rằng “Người làm thiết kế có nghề thì có thể nhìn ra vấn đề sau vài bước quan sát”. Bản thân tôi cũng đang luyện rèn kỹ năng đó.

Noted:

IA (Information Architect ): Kiến trúc thông tin.

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.