Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là BA của một dự án xây dựng app đặt vé xe khách liên tỉnh cho một hãng xe ở miền Trung. Trong buổi họp đầu tiên, Product Owner nói: "App phải dễ dùng cho người dùng của mình." Bạn gật đầu. Nhưng "người dùng" ở đây là ai? Là cô sinh viên 20 tuổi đặt vé về quê dịp lễ qua điện thoại? Là bác tài xế 50 tuổi muốn xem lịch chạy? Là chị nhân viên phòng vé ngồi quầy nhập đơn cả ngày? Ba con người này có nhu cầu, thói quen, mức độ rành công nghệ và nỗi sợ hoàn toàn khác nhau. Nếu cả đội cùng nói "người dùng" mà mỗi người trong đầu lại đang hình dung một nhân vật khác, thì mọi quyết định về tính năng sẽ va vào nhau.
Persona chính là công cụ để giải quyết đúng vấn đề này. Persona biến cụm từ mơ hồ "người dùng" thành những nhân vật cụ thể, có tên, có khuôn mặt, có động lực và nỗi đau rõ ràng — để cả đội cùng nói về một con người thay vì một khái niệm trừu tượng. Với vai trò BA, persona không phải là việc của riêng UX designer. Nó là cách bạn neo các yêu cầu (requirements) vào con người thật, giúp bạn ưu tiên tính năng, phản biện những đòi hỏi vô lý, và giữ cho cả đội không "tự nghĩ ra" những gì người dùng cần.
Bài này tập trung riêng vào persona development — cách xây dựng persona dựa trên dữ liệu, các thành phần cấu tạo, và cách dùng nó trong công việc BA. Đây là người anh em song sinh với customer journey mapping (Bài 41) và là nền tảng cho việc viết user story (Bài 6, 46) ở các bài sau.
Khái niệm cốt lõi
Persona là gì — và không là gì
Persona là một đại diện hư cấu nhưng được xây dựng trên nền dữ liệu (fictional but data-grounded) của một nhóm người dùng mục tiêu (target user segment). Hãy đọc kỹ ba chữ quan trọng: hư cấu (nhân vật này không có thật, ta đặt tên, đặt ảnh), nhưng dựa trên dữ liệu (mọi đặc điểm của nhân vật phải đến từ phỏng vấn, khảo sát, số liệu thực tế — chứ không phải tưởng tượng của BA).
Đây là điểm phân biệt sống còn. Một persona được "nghĩ ra" trong phòng họp mà không có dữ liệu nền thì người ta gọi đó là proto-persona (persona giả định) — vẫn dùng được để khởi động, nhưng phải ghi rõ là giả định và cần xác minh sau. Còn một persona đúng nghĩa phải truy vết được về dữ liệu: "Anh ấy ngại nhập thẻ tín dụng vì 7/12 người chúng tôi phỏng vấn nói họ chỉ tin thanh toán khi nhận hàng."
Persona không phải là một người thật cụ thể (đó là một case study hay một user). Persona không phải là chân dung thị trường kiểu marketing (tuổi, thu nhập, học vấn để chạy quảng cáo) — dù có giao nhau, persona của BA tập trung vào hành vi, mục tiêu và nỗi đau khi tương tác với sản phẩm. Và persona không phải là phân khúc (segment) — một segment có thể sinh ra một hoặc nhiều persona.
Các thành phần của một persona
Một persona đầy đủ thường gồm các yếu tố sau. Tôi để dạng bảng để bạn dễ tra cứu, kèm ví dụ trên bối cảnh app đặt vé xe ở trên:
| Thành phần | Mô tả | Ví dụ |
|---|---|---|
| Tên + ảnh | Một cái tên người thật và ảnh chân dung để "nhân cách hóa" | "Sinh viên Lan", ảnh một bạn nữ trẻ |
| Câu trích dẫn (quote) | Một câu nói tóm gọn thái độ của họ | "Em chỉ cần đặt nhanh, đừng bắt em đăng ký nhiều bước" |
| Nhân khẩu học | Tuổi, nghề, nơi sống — chỉ phần liên quan đến hành vi | 20 tuổi, sinh viên, ở trọ TP.HCM, quê Đà Nẵng |
| Bối cảnh & công nghệ | Họ dùng thiết bị gì, mức độ rành công nghệ | Dùng điện thoại Android tầm trung, 4G, rành app nhưng dữ liệu mạng yếu |
| Mục tiêu (goals) | Họ muốn đạt được điều gì khi dùng sản phẩm | Đặt vé về quê dịp lễ trong vài phút, chọn được ghế gần cửa |
| Nỗi đau / cản trở (pain points) | Điều gì đang làm họ khó chịu, thất vọng | Sợ hết vé giờ cao điểm; ghét phải gọi điện đặt vé |
| Hành vi & thói quen | Cách họ thường làm việc đó hiện nay | Hỏi vé qua Zalo của nhà xe, chuyển khoản cọc |
| Động lực (motivation) | Yếu tố thúc đẩy: giá rẻ, nhanh, an toàn, uy tín | Ưu tiên giá rẻ và đặt được đúng chuyến |
| Mức độ ảnh hưởng | Họ quan trọng thế nào với mục tiêu kinh doanh | Nhóm chiếm ~60% lượng đặt vé dịp lễ |
Phân biệt persona với buyer persona và user role
Trong nhiều dự án Việt Nam, ba khái niệm này hay bị trộn lẫn:
- User persona: người dùng sản phẩm (BA quan tâm nhất). Ví dụ: nhân viên phòng vé nhập đơn.
- Buyer/customer persona: người ra quyết định mua/trả tiền, có thể không phải người dùng. Ví dụ: chủ hãng xe ký hợp đồng mua phần mềm.
- User role: một vai trò chức năng trong hệ thống (admin, nhân viên, khách), không có chiều sâu tâm lý.
Tình huống thực tế
Tình huống 1: Tiki và bài học "đừng gộp tất cả người mua thành một"
Một sàn thương mại điện tử lớn ở Việt Nam (lấy bối cảnh kiểu Tiki) từng thiết kế luồng thanh toán theo giả định "người mua online đều rành công nghệ và có thẻ". Khi mở rộng ra các tỉnh, đội BA phát hiện một nhóm người dùng hoàn toàn khác: các bà nội trợ 35–50 tuổi ở tỉnh, mua hàng qua điện thoại con cái cài hộ, không có thẻ tín dụng và không tin thanh toán online.
Đội xây hai persona đối lập: "Minh — dân văn phòng 28 tuổi ở Hà Nội, trả thẻ, ưu tiên giao nhanh" và "Cô Hạnh — nội trợ 45 tuổi ở Nam Định, chỉ trả COD, cần ảnh sản phẩm rõ và đánh giá thật". Từ persona "Cô Hạnh", các requirements mới sinh ra: ưu tiên hiển thị COD lên đầu, nút gọi hotline to rõ, ảnh sản phẩm phóng to dễ, hạn chế thuật ngữ tiếng Anh. Kết quả: tỉ lệ hoàn tất đơn hàng ở nhóm khách tỉnh tăng đáng kể.
Bài học: Khi một nhóm người dùng có hành vi và niềm tin trái ngược với nhóm chủ đạo, đừng cố gộp họ vào một persona "trung bình". Một persona "trung bình" của hai thái cực thường mô tả... một người không tồn tại.
Tình huống 2: App nội bộ cho ngân hàng — persona bị bỏ quên là nhân viên
Một dự án xây hệ thống xử lý hồ sơ vay cho một ngân hàng (bối cảnh kiểu Techcombank). Cả đội ban đầu chỉ làm persona cho khách vay. Nhưng người dùng phần mềm thực sự cả ngày lại là chuyên viên thẩm định tín dụng — người nhập liệu, kiểm tra hồ sơ, ra quyết định.
BA dựng persona "Anh Tuấn — chuyên viên thẩm định 32 tuổi, xử lý 40 hồ sơ/ngày, mục tiêu là duyệt nhanh nhưng không sai, nỗi đau là phải nhảy qua lại 5 màn hình để gom đủ thông tin một hồ sơ". Persona này lập tức làm lộ ra requirement quan trọng: cần một màn hình tổng hợp (single view) gom toàn bộ thông tin hồ sơ, thay vì bắt anh Tuấn click qua 5 tab. Con số "40 hồ sơ/ngày" giúp đội tính ra rằng tiết kiệm 30 giây mỗi hồ sơ tương đương 20 phút/ngày/người — nhân với 50 chuyên viên là con số đủ thuyết phục ban lãnh đạo đầu tư.
Bài học: Với hệ thống nội bộ (internal systems), persona quan trọng nhất thường là nhân viên vận hành, không phải khách hàng cuối. BA hay bỏ quên họ vì họ "không phải khách" — nhưng họ là người dùng dành nhiều giờ nhất với hệ thống.
Tình huống 3: Proto-persona "trên trời" và cái giá phải trả
Một startup giao đồ ăn ở Đông Nam Á (bối cảnh kiểu một đối thủ nhỏ của Grab) vội ra mắt, đội ngồi phòng họp "chế" ra persona "Gen Z thành thị thích đồ ăn lành mạnh, sẵn sàng trả thêm cho organic". Họ xây cả tính năng lọc món "healthy", "low-carb". Ba tháng sau, dữ liệu thực tế cho thấy 80% đơn là trà sữa, cơm tấm và đồ ăn nhanh lúc đêm khuya — đúng tệp sinh viên ít tiền, đặt theo combo khuyến mãi.
Persona thật hóa ra là "Sinh viên đói lúc 11 giờ đêm, săn mã giảm giá, nhạy cảm giá ship". Toàn bộ công sức cho tính năng "healthy" gần như lãng phí.
Bài học: Proto-persona dựa trên trực giác rất nguy hiểm nếu bạn quên mất nó chỉ là giả định. Hãy ghi rõ "GIẢ ĐỊNH — chưa xác minh" lên persona đó và lên kế hoạch kiểm chứng bằng dữ liệu thật càng sớm càng tốt.
Hướng dẫn từng bước
Đây là quy trình xây dựng persona mà bạn có thể áp dụng ngay trong dự án.
Bước 1 — Thu thập dữ liệu nền. Persona tốt bắt đầu từ dữ liệu, không phải từ phòng họp. Nguồn gồm: phỏng vấn người dùng (5–8 người mỗi nhóm là đủ để thấy pattern), khảo sát định lượng, dữ liệu hành vi (analytics, log), phản hồi từ chăm sóc khách hàng, và phỏng vấn nội bộ với sales/support — những người tiếp xúc khách hàng hàng ngày. Nếu hoàn toàn chưa có dữ liệu, hãy bắt đầu bằng proto-persona và đánh dấu rõ "cần xác minh".
Bước 2 — Tìm pattern và phân nhóm. Sau khi có dữ liệu, đừng nhóm người theo nhân khẩu học. Hãy nhóm theo hành vi và mục tiêu. Hai người cùng 25 tuổi nhưng một người "đặt vé sớm để chắc chỗ" và một người "luôn đặt phút chót" là hai persona khác nhau. Tìm các trục khác biệt rõ rệt (axes of differentiation): mức độ rành công nghệ, tần suất sử dụng, động lực chính, mức độ chấp nhận rủi ro.
Bước 3 — Quyết định số lượng persona. Nguyên tắc: ít mà sâu. Hầu hết dự án chỉ cần 3–5 persona. Quá nhiều persona thì cả đội không ai nhớ nổi và nó mất tác dụng "ngôn ngữ chung". Chọn 1 primary persona (persona chính bạn tối ưu trải nghiệm cho họ) và vài secondary persona.
Bước 4 — Viết persona. Điền các thành phần ở bảng trên. Mẹo: viết phần goals và pain points trước, vì đó là phần "có thịt". Thêm tên, ảnh, quote để nhân cách hóa. Giữ mỗi persona gọn trong một trang A4 — nếu dài hơn, không ai đọc.
Bước 5 — Xác thực (validate). Đưa persona cho người tiếp xúc khách hàng thật (sales, support, nhân viên cửa hàng) xem và hỏi: "Anh/chị có thấy đúng người mình gặp hàng ngày không?". Họ sẽ phản biện rất nhanh nếu persona sai.
Bước 6 — Đưa persona vào công việc. Đây là bước nhiều người bỏ lỡ. Treo persona lên tường/Confluence. Khi viết requirement hay user story, gắn nó với persona: "Là Sinh viên Lan, tôi muốn đặt vé không cần đăng ký tài khoản, để tiết kiệm thời gian." Khi tranh luận tính năng, hỏi: "Tính năng này phục vụ persona nào? Có phải primary persona không?".
Bước 7 — Cập nhật định kỳ. Persona không phải làm một lần rồi cất tủ. Hành vi người dùng thay đổi (đặc biệt sau biến động lớn như đại dịch). Soát lại persona mỗi 6–12 tháng hoặc khi có dữ liệu mới đáng kể.
Lỗi thường gặp & mẹo
Lỗi 1: Persona "tự chế" không có dữ liệu. Đây là lỗi phổ biến nhất. Cả đội ngồi tưởng tượng ra người dùng rồi tin đó là sự thật. Mẹo: với mỗi đặc điểm trên persona, tự hỏi "căn cứ vào đâu?". Nếu không trả lời được, đó là giả định cần đánh dấu.
Lỗi 2: Persona kiểu "Frankenstein trung bình". Gộp tất cả người dùng vào một persona "trung bình" sẽ tạo ra một nhân vật không tồn tại — vừa rành công nghệ vừa không, vừa thích nhanh vừa thích kỹ. Mẹo: nếu hai đặc điểm mâu thuẫn nhau xuất hiện trong cùng một persona, đó là dấu hiệu bạn cần tách thành hai persona.
Lỗi 3: Nhồi quá nhiều nhân khẩu học vô nghĩa. Tuổi, cung hoàng đạo, số con... đẹp mà vô dụng nếu không ảnh hưởng đến giải pháp. Mẹo: chỉ giữ thông tin nào thay đổi quyết định thiết kế. Hỏi: "Nếu đổi chi tiết này, requirement có đổi không?". Không thì bỏ.
Lỗi 4: Quá nhiều persona. Làm 12 persona cho một dự án nhỏ thì không ai dùng. Mẹo: ép mình xuống 3–5, chọn rõ một primary.
Lỗi 5: Làm xong rồi cất tủ. Persona chỉ có giá trị khi được dùng hàng ngày trong quyết định. Mẹo: gắn persona vào user story, vào tiêu chí ưu tiên backlog, vào câu hỏi trong mọi buổi họp tính năng.
Lỗi 6: Lẫn lộn persona người dùng với người ra quyết định mua. Mẹo: luôn hỏi "ai dùng?" và "ai trả tiền?" — đôi khi là hai persona khác nhau với nhu cầu xung đột.
Mẹo vàng: Một persona tốt phải giúp đội từ chối được một số yêu cầu. Nếu persona của bạn "ai cũng đúng, cái gì cũng cần", nó vô dụng. Sức mạnh của persona nằm ở chỗ nó giúp nói "không" với tính năng không phục vụ primary persona.
Bài tập thực hành
Bài tập 1 — Dựng proto-persona (30 phút). Chọn một sản phẩm bạn đang dùng hàng ngày (ví dụ Momo, Grab, Shopee). Dựng 2 proto-persona đối lập cho sản phẩm đó, mỗi persona điền đủ: tên, quote, mục tiêu, 3 nỗi đau, hành vi hiện tại. Đánh dấu rõ những đặc điểm nào là "giả định chưa xác minh".
Bài tập 2 — Truy nguồn dữ liệu (20 phút). Với mỗi nỗi đau (pain point) bạn vừa viết ở Bài tập 1, viết một câu trả lời cho "căn cứ vào đâu?". Nếu không có căn cứ thực tế, viết ra một cách bạn sẽ thu thập dữ liệu để xác minh (phỏng vấn ai, hỏi câu gì, xem số liệu nào).
Bài tập 3 — Từ persona ra requirement (25 phút). Lấy primary persona của bạn, viết 3 user story theo cấu trúc "Là [persona], tôi muốn [hành động], để [giá trị]". Sau đó viết 1 tính năng mà bạn sẽ từ chối vì nó không phục vụ persona này — và giải thích lý do. Đây là phần quan trọng nhất: persona phải giúp bạn nói "không".
Bài tập 4 (nâng cao) — Phát hiện persona bị bỏ quên. Với một hệ thống nội bộ bất kỳ (ví dụ phần mềm quản lý kho, CRM), liệt kê tất cả những người thực sự ngồi dùng nó nhiều giờ mỗi ngày. Bạn có bỏ sót nhân viên vận hành nào không? Dựng nhanh persona cho người dễ bị quên nhất.
Tóm tắt
Persona là đại diện hư cấu nhưng dựa trên dữ liệu của một nhóm người dùng mục tiêu — công cụ biến cụm từ mơ hồ "người dùng" thành những nhân vật cụ thể mà cả đội cùng hiểu chung. Với BA, ba thành phần quan trọng nhất của persona là mục tiêu, nỗi đau và hành vi hiện tại, vì đó là nguồn trực tiếp sinh ra requirements.
Nguyên tắc cốt lõi cần nhớ:
- Persona phải dựa trên dữ liệu, không phải trí tưởng tượng phòng họp. Mọi đặc điểm phải truy vết được. Nếu chưa có dữ liệu, dùng proto-persona và ghi rõ "cần xác minh".
- Nhóm người theo hành vi và mục tiêu, không theo nhân khẩu học. Tránh persona "trung bình Frankenstein".
- Giữ 3–5 persona, chọn một primary. Mỗi persona gọn trong một trang.
- Đừng quên persona của nhân viên vận hành trong các hệ thống nội bộ.
- Persona chỉ có giá trị khi được dùng hàng ngày — gắn vào user story, vào ưu tiên backlog, vào quyết định tính năng. Một persona tốt giúp bạn từ chối được những yêu cầu không phục vụ đúng người.