Persona or User Stories?

by binhtruong

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

x1

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

  1. 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.
  2. 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.
  3. 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 🙂

Advertisements