Mở đầu — vì sao bài này quan trọng
Trong các bài trước, bạn đã học cách viết Problem, Goals, user stories và acceptance criteria. Nhưng có một câu hỏi mà rất nhiều PM mới né tránh hoặc trả lời qua loa khi viết PRD: "Chúng ta đang xây cái này CHO AI?"
Nghe thì hiển nhiên, nhưng thực tế trong phòng họp, mỗi người ngồi quanh bàn lại tưởng tượng ra một "người dùng" khác nhau trong đầu mình. Kỹ sư nghĩ đến một người dùng am hiểu công nghệ. Designer nghĩ đến một bạn trẻ thành thạo app. Sếp nghĩ đến khách hàng doanh nghiệp đã ký hợp đồng. Còn team Customer Support thì nghĩ đến những người gọi điện than phiền mỗi ngày. Bốn người, bốn hình dung khác nhau — và thế là sản phẩm ra đời mâu thuẫn với chính nó.
Persona (chân dung người dùng) trong PRD chính là công cụ để cả team đồng ý về một hình dung chung. Nó không phải là phần "trang trí" hay "cho có" mà nhiều người tưởng. Một persona viết đúng chỗ, đúng lúc sẽ định hướng toàn bộ các quyết định thiết kế và kỹ thuật phía sau. Một persona viết sai hoặc thừa thãi sẽ làm loãng tài liệu, khiến người đọc bỏ qua phần quan trọng.
Trong bài này, chúng ta tập trung vào persona ở góc độ tài liệu PRD — khi nào nên đưa persona vào, viết bao nhiêu là đủ, cấu trúc một persona gọn gàng, và quan trọng nhất: làm sao để persona thực sự ảnh hưởng đến quyết định sản phẩm thay vì nằm chết trong một slide đẹp đẽ.
Khái niệm cốt lõi
Persona trong PRD khác với persona của team Research
Trước hết phải phân biệt rõ. Team User Research thường xây dựng persona toàn diện — những tài liệu dày, có ảnh đại diện, tên gọi, câu chuyện đời sống, hành vi tiêu dùng, được rút ra từ hàng chục cuộc phỏng vấn và khảo sát định lượng. Đó là tài sản chiến lược của cả công ty, dùng đi dùng lại qua nhiều quý.
Persona trong PRD thì gọn và phục vụ một mục đích cụ thể: giúp người đọc tài liệu này hiểu bạn đang giải quyết vấn đề cho ai, và tại sao những lựa chọn thiết kế trong tài liệu lại hợp lý cho đối tượng đó. Nó là một lát cắt, không phải toàn bộ bức tranh. Bạn thường chỉ cần 3–6 câu cho mỗi persona, đặt ngay sau phần Problem hoặc Context.
Nói cách khác: persona của Research trả lời "khách hàng của chúng ta là ai?". Persona trong PRD trả lời "tính năng này phục vụ ai, và nhu cầu nào của họ định hình giải pháp?".
Khi nào NÊN đưa persona vào PRD
Đây là phần quan trọng nhất, vì lỗi phổ biến nhất là đưa persona vào mọi PRD theo thói quen. Hãy đưa persona vào khi:
1. Tính năng nhắm tới một segment cụ thể. Nếu bạn đang xây tính năng chỉ dành cho người bán hàng chuyên nghiệp trên sàn thương mại điện tử, chứ không phải toàn bộ người dùng, thì persona giúp người đọc không nhầm lẫn. Khi cả team biết rõ "chúng ta tối ưu cho người bán có trên 100 đơn/ngày", các quyết định về tốc độ thao tác, phím tắt, xử lý hàng loạt trở nên rõ ràng.
2. Giải pháp cần motivation (động cơ) rõ ràng. Có những tính năng mà vì sao người dùng cần không hiển nhiên. Nếu bạn không giải thích động cơ và bối cảnh của người dùng, kỹ sư và designer sẽ thiết kế dựa trên suy đoán. Persona ở đây đóng vai trò "cây cầu" giữa vấn đề trừu tượng và con người cụ thể.
3. Có nhiều hơn một loại người dùng với nhu cầu khác nhau. Đây là tín hiệu mạnh nhất. Khi tính năng có nhiều "vai" tham gia — ví dụ người tạo nội dung và người tiêu thụ nội dung, hoặc quản trị viên và nhân viên — thì việc liệt kê rõ từng persona và nhu cầu trái ngược của họ là cực kỳ giá trị. Nó ngăn việc team thiết kế cho một vai mà quên vai còn lại.
Khi nào KHÔNG cần persona
Ngược lại, hãy mạnh dạn bỏ persona khi:
- Tính năng phục vụ tất cả người dùng như nhau (ví dụ: thêm nút "lưu nháp" — ai dùng cũng có nhu cầu y hệt).
- Đây là cải tiến kỹ thuật/nội bộ không có user-facing motivation đặc biệt (ví dụ: tối ưu thời gian tải trang).
- Persona đã được mô tả đầy đủ ở một tài liệu khác mà bạn chỉ cần link tới, không cần chép lại.
Cấu trúc một persona gọn cho PRD
Một persona hiệu quả trong PRD nên có các thành phần sau, viết càng ngắn càng tốt:
- Tên & nhãn vai trò ngắn: ví dụ "Hằng — Chủ shop bán lẻ trên di động". Tên giúp cả team gọi chung dễ nhớ trong các cuộc họp sau.
- Bối cảnh & môi trường dùng: họ dùng sản phẩm khi nào, ở đâu, trên thiết bị gì, trong tâm trạng/áp lực nào.
- Mục tiêu chính (goal): họ đang cố hoàn thành điều gì.
- Nỗi đau / rào cản hiện tại (pain): điều gì đang cản trở họ.
- Mức độ thành thạo & ràng buộc: rành công nghệ tới đâu, có giới hạn về thời gian, ngôn ngữ, kết nối mạng không.
- Hàm ý cho thiết kế (implication) — đây là dòng quan trọng nhất và hay bị bỏ quên nhất: persona này dẫn đến quyết định thiết kế nào?
Tình huống thực tế
Ví dụ 1 — Tiệm tạp hóa số: hai persona, hai thế giới
Một startup fintech tại TP.HCM (gọi là "ChợSố") xây dựng app giúp các tiệm tạp hóa truyền thống quản lý công nợ và nhập hàng. PM ban đầu viết PRD chỉ với một persona chung chung: "tiểu thương Việt Nam". Kết quả là bản thiết kế đầu tiên dày đặc biểu đồ phân tích doanh thu, dashboard nhiều màu — thứ mà sau khi mang đi test với 12 chủ tiệm thật, không ai dùng tới.
Khi viết lại PRD, PM tách thành hai persona rõ ràng:
- Cô Tư (52 tuổi) — Chủ tiệm tạp hóa: Dùng điện thoại Android giá rẻ, mắt kém, ghi công nợ bằng cuốn sổ. Mục tiêu: nhớ ai còn nợ bao nhiêu. Pain: sợ bấm nhầm, ngại app phức tạp. Implication: chữ to, ít bước, nút lớn, không có thuật ngữ tài chính.
- Minh (26 tuổi) — Con trai phụ tiệm: Rành smartphone, thường là người cài app giúp mẹ. Mục tiêu: dựng sổ sách gọn để mẹ dùng được. Pain: phải nhập dữ liệu cũ thủ công. Implication: cần luồng onboarding nhanh, nhập liệu hàng loạt, có thể chuyển quyền cho cô Tư sau khi cài.
Bài học: Khi một tính năng có người thiết lập và người sử dụng khác nhau, gộp họ vào một persona sẽ giết chết sản phẩm. Tách ra, và viết implication cho từng người.
Ví dụ 2 — Persona thừa làm loãng PRD
Một PM tại một công ty SaaS B2B (đặt tên là "DocFlow") viết PRD cho tính năng "tự động lưu nháp mỗi 5 giây". Theo thói quen, anh dán nguyên ba persona công ty đã có sẵn vào đầu tài liệu: quản trị viên, biên tập viên, người xem.
Vấn đề: tính năng tự lưu nháp phục vụ mọi người soạn thảo như nhau — không có sự khác biệt segment nào đáng kể. Ba persona dày một trang rưỡi khiến reviewer phải đọc lướt qua, và phần Edge Cases quan trọng (lưu nháp khi mất mạng, khi hai tab cùng mở) bị đẩy xuống dưới, ít người đọc kỹ.
Trong buổi review, một senior PM hỏi thẳng: "Ba persona này dẫn đến quyết định thiết kế khác nhau nào không?" Câu trả lời là không. PM gỡ toàn bộ persona, thay bằng một câu: "Phục vụ mọi user có quyền soạn thảo; không có khác biệt theo segment." Tài liệu ngắn lại 40%, và cuộc thảo luận tập trung đúng vào edge cases.
Bài học: Persona không phải nghĩa vụ. Nếu nó không tạo ra implication khác biệt, nó là nhiễu. Kiểm tra mỗi persona bằng câu hỏi: "Bỏ persona này đi thì quyết định thiết kế có đổi không?"
Ví dụ 3 — Persona làm lộ xung đột nhu cầu trong app gọi xe
Một team product tại một ứng dụng gọi xe ở Đông Nam Á (giả định "GoRide") xây tính năng "đặt chuyến cho người khác" — ví dụ con đặt xe cho bố mẹ, hoặc lễ tân đặt xe cho khách công ty. PM viết hai persona:
- Lan — Người đặt hộ: Trẻ, rành app, đặt xe cho mẹ ở quê. Goal: theo dõi chuyến đi của mẹ từ xa. Pain: mẹ không có app, không nhận được thông tin tài xế.
- Bà Hoa — Người đi xe thực tế: 68 tuổi, dùng điện thoại phổ thông (feature phone), chỉ nhận được SMS. Goal: lên đúng xe, an toàn. Pain: không đọc được app, không biết tài xế nào là của mình.
Bài học: Khi "người ra quyết định" và "người chịu trải nghiệm" tách rời nhau, persona giúp bạn thiết kế cho cả hai. Đây chính là tín hiệu "nhiều hơn một user type với nhu cầu khác nhau" mà phần lý thuyết đã nói.
Hướng dẫn từng bước
Đây là quy trình thực tế để đưa persona vào PRD một cách có kỷ luật:
Bước 1 — Hỏi câu hỏi sàng lọc trước. Trước khi viết bất kỳ persona nào, tự hỏi: tính năng này có (a) nhắm segment cụ thể, (b) cần motivation rõ, hoặc (c) có nhiều user type khác nhu cầu không? Nếu không thuộc cả ba, viết một câu "Phục vụ tất cả người dùng như nhau" và bỏ qua phần persona.
Bước 2 — Liệt kê các "vai" tham gia. Đừng nghĩ ngay tới persona, hãy nghĩ tới các vai trò khác nhau trong luồng tính năng: ai khởi tạo, ai phê duyệt, ai tiêu thụ, ai quản trị. Mỗi vai có nhu cầu khác biệt thì xứng đáng có persona riêng.
Bước 3 — Với mỗi vai, điền 6 thành phần. Tên + nhãn, bối cảnh, goal, pain, mức độ thành thạo/ràng buộc, và implication. Giữ mỗi mục một dòng. Nếu một mục bạn phải bịa ra vì không có dữ liệu, hãy đánh dấu "(giả định — cần verify)" thay vì viết như sự thật.
Bước 4 — Viết dòng implication cuối cùng cho từng persona. Đây là bước bắt buộc. Mỗi persona phải dẫn tới ít nhất một quyết định thiết kế cụ thể. Nếu không viết được, gỡ persona đó.
Bước 5 — Kiểm tra phản chứng. Đọc lại từng persona và hỏi: "Nếu bỏ persona này, PRD có nghèo đi không?" Bỏ những persona không vượt qua bài kiểm tra này.
Bước 6 — Gắn persona với phần còn lại của tài liệu. Trong phần user stories và acceptance criteria phía sau, hãy tham chiếu lại persona ("Là Cô Tư, tôi muốn..."). Persona chỉ có giá trị khi nó được dùng xuyên suốt, không phải đặt ở đầu rồi quên.
Lỗi thường gặp & mẹo
Lỗi 1 — Persona "đẹp mà rỗng". Thêm ảnh stock, sở thích cà phê, cung hoàng đạo... nhưng không có dòng nào ảnh hưởng tới sản phẩm. Mẹo: cắt mọi chi tiết không dẫn tới quyết định. Trong PRD, "cô Tư mắt kém nên cần chữ to" có giá trị; "cô Tư thích xem cải lương" thì không.
Lỗi 2 — Một persona gánh nhiều vai mâu thuẫn. Khi bạn thấy mình viết "người dùng vừa muốn đơn giản vừa muốn nhiều tùy chọn nâng cao", đó là dấu hiệu bạn đang gộp hai persona làm một. Tách ra.
Lỗi 3 — Quá nhiều persona. Năm, sáu persona trong một PRD khiến không ai nhớ nổi. Quy tắc thực tế: hiếm khi cần quá 2–3 persona cho một tính năng. Nếu nhiều hơn, có lẽ scope tính năng đang quá rộng.
Lỗi 4 — Persona bịa đặt không có dữ liệu. Persona đoán mò nguy hiểm vì nó nghe có vẻ chắc chắn. Mẹo: ghi rõ nguồn ("dựa trên 8 phỏng vấn quý trước" hoặc "giả định — cần test"). Sự trung thực về độ tin cậy giúp team biết chỗ nào cần kiểm chứng.
Lỗi 5 — Persona không kết nối với phần sau. Đặt persona ở đầu rồi cả tài liệu không nhắc lại lần nào. Mẹo: dùng tên persona trong user stories để giữ sợi dây xuyên suốt.
Mẹo vàng: Đặt câu hỏi "So what?" (Rồi sao?) sau mỗi câu mô tả persona. "Cô Tư 52 tuổi" — rồi sao? — "nên dùng chữ to và ít bước". Nếu không trả lời được "rồi sao", câu đó nên bị xóa.
Bài tập thực hành
Bài tập 1 — Sàng lọc. Cho ba tính năng sau, quyết định tính năng nào cần persona, tính năng nào không, và viết một câu lý do:
- Thêm chế độ tối (dark mode) cho toàn app.
- Bảng điều khiển phân tích doanh thu cho người bán chuyên nghiệp.
- Tính năng "chia sẻ giỏ hàng" để một người chọn, người khác thanh toán.
Bài tập 3 — Cắt gọt. Lấy một persona dài 10 dòng bất kỳ (tự bịa hoặc lấy từ tài liệu cũ của bạn), áp dụng bài kiểm tra "So what?" cho từng dòng, và rút xuống còn tối đa 5 dòng chỉ giữ phần dẫn tới quyết định thiết kế.
Bài tập 4 — Phản chứng. Tìm một PRD cũ của bạn (hoặc của team) có chứa persona. Với mỗi persona, hỏi "bỏ đi thì PRD có nghèo đi không?". Đếm xem bao nhiêu persona thực sự cần thiết.
Tóm tắt
Persona trong PRD không phải một mục bắt buộc phải có cho đẹp tài liệu — nó là một công cụ ra quyết định, và chỉ có giá trị khi dùng đúng lúc. Hãy nhớ:
- Đưa persona vào khi tính năng nhắm segment cụ thể, cần motivation rõ, hoặc có nhiều user type với nhu cầu khác nhau. Bỏ persona khi mọi người dùng như nhau hoặc đây là cải tiến kỹ thuật thuần túy.
- Persona trong PRD phải gọn — 3–6 câu, không phải tài liệu nghiên cứu đầy đủ. Cấu trúc: tên+nhãn, bối cảnh, goal, pain, ràng buộc, và quan trọng nhất là implication (hàm ý thiết kế).
- Dòng implication là linh hồn của persona. Nếu không viết được "persona này dẫn tới quyết định thiết kế nào", persona đó không nên tồn tại trong tài liệu.
- Kiểm tra bằng câu hỏi "So what?" và "Bỏ đi có nghèo đi không?" để loại bỏ persona thừa thãi làm loãng PRD.
- Giữ persona sống xuyên suốt bằng cách tham chiếu lại trong user stories và acceptance criteria.