Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là Product Manager (PM) tại một startup giao đồ ăn ở TP.HCM. Trong buổi họp sáng, một bạn engineer hỏi: "Mình nên ưu tiên làm tính năng đặt món theo nhóm cho văn phòng, hay tính năng lưu địa chỉ giao hàng cho người dùng cá nhân?". Cả phòng nhìn nhau. Có người nói "người dùng cần cái này", người khác cãi "không, user của mình thích cái kia hơn". Vấn đề là: mỗi người trong phòng đang tưởng tượng ra một "user" khác nhau trong đầu, và không ai có cùng một bức tranh.
Đây chính là lý do persona ra đời. Sau khi bạn đã đi phỏng vấn người dùng (Bài 15) và thu thập được hàng đống ghi chú, bạn cần một cách để đóng gói những hiểu biết đó thành thứ mà cả team có thể nhìn vào, ghi nhớ và đưa ra quyết định cùng nhau. Persona biến "người dùng" — một khái niệm mơ hồ, vô danh — thành một con người cụ thể có tên, có khuôn mặt, có nỗi đau và mục tiêu rõ ràng.
Trong bài này, chúng ta sẽ tập trung hoàn toàn vào kỹ thuật tạo persona: persona thực chất là gì, gồm những thành phần nào, làm sao để dựng nó từ dữ liệu research thật (chứ không phải bịa), và làm sao để nó thực sự được dùng chứ không nằm chết trong một file slide nào đó. Đây là một kỹ năng nền tảng mà bất kỳ PM nào cũng phải thành thạo, vì nó là cầu nối giữa research và mọi quyết định sản phẩm sau này.
Khái niệm cốt lõi
Persona là gì?
Persona là một nhân vật hư cấu (fictional character) đại diện cho một nhóm (segment) người dùng cụ thể, được xây dựng dựa trên dữ liệu research thật.
Hãy đọc kỹ định nghĩa này, vì có hai vế cực kỳ quan trọng và dễ bị hiểu sai:
- "Nhân vật hư cấu" — Persona không phải là một người dùng có thật. Bạn không lấy hồ sơ của chị Lan, khách hàng số 247, rồi gọi đó là persona. Persona là một sự tổng hợp (composite) — bạn gom nhiều người dùng có chung đặc điểm, hành vi, mục tiêu, rồi "đúc" họ thành một nhân vật đại diện. Cái tên, khuôn mặt là hư cấu.
- "Dựa trên research thật" — Đây là vế phân biệt persona chuyên nghiệp với persona "bịa đặt". Nếu bạn ngồi trong phòng họp tưởng tượng ra một người dùng rồi gán cho họ những đặc điểm bạn nghĩ là đúng, đó không phải persona — đó là proto-persona (persona giả định), chỉ nên dùng tạm khi chưa có dữ liệu. Persona thật phải bắt nguồn từ phỏng vấn, khảo sát, dữ liệu hành vi.
Vì sao team cần persona
Persona giải quyết ba vấn đề kinh điển của một team sản phẩm:
- Tạo ngôn ngữ chung. Khi cả team biết "Minh — nhân viên văn phòng bận rộn" là ai, câu hỏi "tính năng này có hợp với Minh không?" sẽ thay thế cho những tranh cãi dựa trên ý kiến cá nhân.
- Chống lại thiên kiến "tôi chính là người dùng". PM, designer, engineer thường vô thức thiết kế cho chính mình. Persona kéo bạn ra khỏi cái bẫy đó.
- Định hướng ưu tiên. Khi một tính năng phục vụ persona chính, nó được ưu tiên; khi nó chỉ phục vụ một nhóm rìa, bạn biết để nó xuống dưới.
Các thành phần (elements) của một persona
Một persona đầy đủ thường gồm các phần sau. Đừng máy móc nhồi đủ mọi mục — hãy giữ lại những gì thực sự ảnh hưởng đến quyết định sản phẩm.
1. Tên + ảnh đại diện (Name + photo). Nghe có vẻ vặt vãnh nhưng đây là yếu tố khiến persona trở nên "sống". Một cái tên cụ thể như "Minh", "Chị Hương" giúp cả team gọi tên và ghi nhớ. Ảnh nên là ảnh stock hợp lý, tránh dùng ảnh người nổi tiếng hay người trong team (gây nhiễu). Mẹo nhỏ: chọn tên gợi đúng bối cảnh — persona người dùng Việt nên có tên Việt, đừng đặt "John" cho một sản phẩm phục vụ thị trường Việt Nam.
2. Thông tin nhân khẩu học (Demographics). Tuổi, nghề nghiệp, thu nhập, nơi sống, tình trạng gia đình. Chỉ đưa vào những thông tin có liên quan đến hành vi sử dụng sản phẩm. Với một app fintech, thu nhập rất quan trọng; với một app đọc tin tức, nó gần như vô nghĩa.
3. Mục tiêu (Goals). Người này muốn đạt được điều gì khi dùng sản phẩm của bạn? Mục tiêu nên ở mức "công việc cần hoàn thành" (job-to-be-done), không phải mức tính năng. Ví dụ: "Đặt được bữa trưa cho cả phòng trước 11h mà không phải nhắn tin hỏi từng người" — chứ không phải "dùng tính năng đặt nhóm".
4. Nỗi đau / điểm khó chịu (Pain points / Frustrations). Những trở ngại, bực bội hiện tại. Đây thường là phần đắt giá nhất, vì mỗi pain point là một cơ hội sản phẩm. (Lưu ý: phân tích pain point sâu là chủ đề của một bài riêng; ở đây ta chỉ ghi nhận chúng như một thành phần của persona.)
5. Hành vi và bối cảnh (Behaviors & context). Họ dùng sản phẩm khi nào, ở đâu, trên thiết bị gì, tần suất ra sao? Một persona dùng app chủ yếu trên điện thoại lúc di chuyển sẽ dẫn đến những quyết định thiết kế rất khác.
6. Trích dẫn đại diện (Quote). Một câu nói "đắt", lấy hoặc chưng cất từ chính lời người dùng trong phỏng vấn, tóm gọn tinh thần của persona. Ví dụ: "Tôi không có thời gian dò từng món, tôi chỉ muốn bấm vài cái là xong."
7. Mức độ thành thạo công nghệ (Tech savviness) — tùy sản phẩm. Nếu bạn làm app cho người lớn tuổi hay tiểu thương, mức độ rành công nghệ là yếu tố sống còn.
Primary persona và secondary persona
Một sản phẩm thường phục vụ nhiều nhóm, nên bạn có thể tạo nhiều persona. Nhưng đừng tạo 10 cái — thực tế 2 đến 4 persona là vừa đủ. Trong đó hãy xác định rõ:
- Primary persona (persona chính): nhóm mà nếu bạn làm họ hài lòng, sản phẩm sẽ thành công. Khi phải đánh đổi, bạn thiết kế cho người này.
- Secondary persona (persona phụ): quan trọng nhưng không phải trọng tâm. Bạn phục vụ họ miễn là không làm hỏng trải nghiệm của persona chính.
Tình huống thực tế
Ví dụ 1: App giao đồ ăn và hai persona đối nghịch
Một startup giao đồ ăn ở Hà Nội (gọi là "FoodFast") sau 20 buổi phỏng vấn nhận ra người dùng của họ chia thành hai nhóm rõ rệt. Thay vì nói chung chung "user của mình", team dựng hai persona:
- "Minh — dân văn phòng bận rộn", 29 tuổi, nhân viên marketing ở quận Cầu Giấy. Mục tiêu: đặt bữa trưa nhanh, lặp lại đơn cũ. Pain point: "Mở app ra phải scroll mãi mới tìm được quán quen." Hành vi: đặt vào đúng khung 11h30–12h, gần như cùng vài quán mỗi tuần. Quote: "Tôi ăn gần như cùng mấy món, sao bắt tôi chọn lại từ đầu mỗi ngày?"
- "Chị Hương — bà nội trợ thích khám phá", 41 tuổi. Mục tiêu: tìm món mới cho cả nhà cuối tuần. Pain point: "Không biết quán nào ngon, sợ đặt phải quán dở." Hành vi: đặt cuối tuần, đọc kỹ đánh giá, so sánh nhiều quán.
Bài học: Persona biến một quyết định ưu tiên gây tranh cãi thành một quyết định dựa trên bằng chứng. Khi engineer hỏi "làm cái nào trước?", câu trả lời rõ ràng: "Làm cho Minh trước, vì Minh là primary."
Ví dụ 2: Spotify và "personas" theo khoảnh khắc nghe nhạc
Spotify nổi tiếng với cách tiếp cận persona thiên về hành vi và bối cảnh hơn là nhân khẩu học. Thay vì dựng persona kiểu "nam 18-24 tuổi", họ tập trung vào khoảnh khắc: người nghe nhạc lúc tập gym, lúc tập trung làm việc, lúc tiệc tùng, lúc đi ngủ. Một sinh viên 20 tuổi có thể "là" nhiều persona khác nhau trong cùng một ngày.
Diễn giải: Đây là minh họa cho việc với một số sản phẩm, yếu tố quan trọng nhất của persona không phải tuổi tác hay thu nhập, mà là ngữ cảnh sử dụng. Chính cách nhìn này đã sinh ra các playlist theo hoạt động ("Focus", "Workout", "Sleep") — một trong những tính năng giữ chân người dùng mạnh nhất của họ.
Bài học: Đừng nhồi nhân khẩu học một cách máy móc. Hãy hỏi: "Yếu tố nào thực sự quyết định hành vi của người dùng với sản phẩm của tôi?" và đặt yếu tố đó vào trung tâm persona.
Ví dụ 3: Cái bẫy proto-persona ở một startup B2B
Một startup SaaS làm phần mềm quản lý kho cho các shop online tại Việt Nam dựng một persona ngay tuần đầu: "Anh Tuấn — chủ shop thời trang, 30 tuổi, rành công nghệ, muốn tự động hóa mọi thứ." Team thiết kế một sản phẩm đầy tính năng tự động cao cấp. Ba tháng sau, khi cuối cùng cũng đi phỏng vấn 15 chủ shop thật, họ phát hiện đa số khách hàng thực tế là phụ nữ 35-45 tuổi, không rành công nghệ, chủ yếu thao tác trên điện thoại, sợ những giao diện phức tạp.
Diễn giải: "Anh Tuấn" là một proto-persona — đẹp đẽ nhưng bịa đặt, phản chiếu chính những người sáng lập (vốn là dân tech trẻ tuổi) chứ không phải khách hàng thật. Hậu quả: sản phẩm quá phức tạp, tỷ lệ rời bỏ cao trong tháng đầu.
Bài học: Proto-persona có giá trị để khởi động, nhưng bắt buộc phải thay thế bằng persona dựa trên dữ liệu thật càng sớm càng tốt. Nếu không, bạn sẽ xây cả một sản phẩm cho một người không tồn tại.
Hướng dẫn từng bước
Đây là quy trình thực tế để dựng persona từ dữ liệu research bạn đã có.
Bước 1 — Gom toàn bộ dữ liệu research. Tập hợp ghi chú phỏng vấn, kết quả khảo sát, dữ liệu hành vi (analytics), phản hồi từ support. Persona chỉ tốt bằng dữ liệu nuôi nó. Mục tiêu lý tưởng: ít nhất 5-8 cuộc phỏng vấn cho mỗi nhóm bạn nghi ngờ tồn tại.
Bước 2 — Tìm các nhóm theo điểm chung (clustering). Trải các quan sát ra (giấy nhớ, bảng tính) và nhóm những người dùng có cùng mục tiêu, cùng hành vi, cùng pain point. Lưu ý: hãy nhóm theo hành vi và mục tiêu, không phải theo nhân khẩu học. Hai người cùng 30 tuổi có thể thuộc hai persona khác nhau; hai người 25 và 50 tuổi có thể là cùng một persona nếu họ hành xử giống nhau.
Bước 3 — Quyết định số lượng persona. Mỗi cụm đủ lớn và đủ khác biệt trở thành một persona. Giữ ở mức 2-4. Nếu bạn ra 8 cụm, hãy gộp lại — quá nhiều persona thì chẳng persona nào được dùng.
Bước 4 — Đặt tên và "thổi hồn". Với mỗi cụm, đặt tên, chọn ảnh, và viết ra các thành phần: demographics liên quan, goals, pain points, behaviors, một câu quote lấy từ phỏng vấn thật. Viết ở ngôi thứ ba, ngắn gọn, để vừa một trang.
Bước 5 — Xác định primary và secondary. Quyết định persona nào là trọng tâm chiến lược. Ghi rõ lý do (ví dụ: tần suất sử dụng cao nhất, đóng góp doanh thu lớn nhất, hoặc là nhóm bạn muốn chiếm lĩnh).
Bước 6 — Đưa persona vào đời sống của team. Đây là bước hay bị bỏ qua nhưng quan trọng nhất. Dán persona lên tường, đặt tên cho các epic theo persona, mở đầu mỗi tài liệu yêu cầu bằng câu "Persona nào hưởng lợi từ tính năng này?". Một persona không được dùng là một persona đã chết.
Bước 7 — Cập nhật định kỳ. Người dùng thay đổi, thị trường thay đổi. Hãy xem lại persona mỗi 6-12 tháng, hoặc sau mỗi đợt research lớn.
Lỗi thường gặp & mẹo
Lỗi 1 — Persona bịa đặt, không có dữ liệu. Như ví dụ "Anh Tuấn" ở trên. Mẹo: với mỗi đặc điểm bạn viết ra, tự hỏi "Dữ liệu nào ủng hộ điều này?". Nếu câu trả lời là "tôi nghĩ vậy", hãy gắn cờ đỏ.
Lỗi 2 — Nhồi quá nhiều chi tiết vô nghĩa. Persona ghi cả tên thú cưng, hãng xe, món ăn yêu thích... nhưng chẳng cái nào ảnh hưởng đến sản phẩm. Mẹo: nguyên tắc "mọi chi tiết phải kiếm được chỗ đứng" — nếu một thông tin không thay đổi quyết định thiết kế nào, hãy xóa.
Lỗi 3 — Quá nhiều persona. Tạo 8-10 persona khiến team tê liệt. Mẹo: gộp lại còn 2-4, và luôn chỉ rõ ai là primary.
Lỗi 4 — Persona theo nhân khẩu học thuần túy. "Nam 25-34" không nói gì về việc người đó cần gì. Mẹo: luôn ưu tiên goals, pain points và behaviors; nhân khẩu học chỉ là phần phụ.
Lỗi 5 — Persona làm xong rồi cất tủ. Đẹp như tranh nhưng không ai mở ra. Mẹo: gắn persona vào quy trình hằng ngày — đặt tên user story theo persona ("Là Minh, tôi muốn..."), treo lên tường, nhắc tên trong mỗi buổi review.
Lỗi 6 — Lẫn lộn persona với buyer persona / segment marketing. Persona sản phẩm tập trung vào người dùng và việc họ cần làm; persona marketing tập trung vào quyết định mua và kênh tiếp cận. Đừng trộn hai mục đích vào một tài liệu kẻo cả hai đều mờ nhạt.
Mẹo vàng — Quote thật làm nên sức mạnh. Một câu nói thật, nguyên văn từ người dùng, có sức thuyết phục hơn mười dòng mô tả. Hãy săn những câu "đắt" ngay trong lúc phỏng vấn.
Bài tập thực hành
Hãy chọn một sản phẩm bạn quen thuộc (có thể là sản phẩm bạn đang làm, hoặc một app bạn dùng hằng ngày như ví điện tử, app gọi xe). Thực hiện các bước sau:
- Phác thảo dữ liệu giả định. Liệt kê 5-6 đặc điểm bạn quan sát/biết được về người dùng sản phẩm đó (từ trải nghiệm, đánh giá trên store, bạn bè dùng app...). Đánh dấu rõ cái nào là bằng chứng và cái nào là giả định của bạn.
- Nhóm thành 2 persona. Dựa trên khác biệt về mục tiêu và hành vi (không phải tuổi), chia người dùng thành hai cụm.
- Viết đầy đủ một persona. Chọn một cụm và viết ra: tên + mô tả ảnh, demographics liên quan, 2 goals, 2 pain points, 1-2 behaviors, và một câu quote đại diện. Giới hạn trong một trang.
- Xác định primary. Trong hai persona, ai là primary? Viết một câu giải thích lý do dựa trên giá trị kinh doanh hoặc tần suất sử dụng.
- Kiểm tra "đã dùng được chưa". Nghĩ ra một quyết định tính năng cụ thể và thử trả lời: "Tính năng này phục vụ persona nào? Nó có làm hại trải nghiệm của persona còn lại không?" Nếu persona giúp bạn trả lời được, bạn đã làm đúng.
Tóm tắt
- Persona là một nhân vật hư cấu đại diện cho một segment người dùng, được xây từ research thật — đây là cầu nối biến hiểu biết về người dùng thành công cụ ra quyết định cho cả team.
- Một persona đầy đủ gồm: tên + ảnh, nhân khẩu học liên quan, mục tiêu, pain points, hành vi/bối cảnh, và một câu quote thật. Nguyên tắc: mọi chi tiết phải ảnh hưởng đến quyết định sản phẩm, nếu không thì bỏ.
- Hãy nhóm người dùng theo mục tiêu và hành vi, không phải nhân khẩu học. Giữ số lượng ở mức 2-4 persona, và luôn chỉ rõ đâu là primary persona — đây là một quyết định chiến lược.
- Cẩn thận với proto-persona (persona giả định, chưa có dữ liệu): hữu ích để khởi động, nhưng phải thay bằng persona thật càng sớm càng tốt, kẻo bạn xây sản phẩm cho một người không tồn tại.
- Sức mạnh của persona không nằm ở lúc tạo ra mà ở lúc được dùng: gắn nó vào user story, vào ưu tiên backlog, vào mọi buổi review. Một persona không được dùng là một persona đã chết.