Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn được giao viết requirement cho một tính năng "đặt lịch khám bệnh online". Bạn ngồi họp với stakeholder, ghi lại một danh sách chức năng: chọn bác sĩ, chọn giờ, thanh toán, nhận xác nhận. Nghe có vẻ đủ. Nhưng khi sản phẩm ra mắt, người dùng phàn nàn: "Tôi là người già, chữ nhỏ quá không đọc được", "Tôi đặt hộ cho mẹ nhưng hệ thống bắt nhập đúng số điện thoại của bệnh nhân", "Tôi đặt xong mà không biết phải mang giấy tờ gì đi khám".
Vấn đề ở đây không phải là bạn thiếu chức năng. Vấn đề là bạn viết requirement từ góc nhìn của hệ thống, chứ không phải từ góc nhìn của con người thật đang sử dụng nó. Đây chính xác là khoảng trống mà Persona và User Journey Map lấp đầy.
Với một BA fresher, hai công cụ này là "vũ khí bí mật" giúp bạn nổi bật. Rất nhiều bạn mới vào nghề chỉ biết viết user story và vẽ flow. Nhưng khi bạn biết dựng persona và map hành trình người dùng, bạn chứng minh được một điều quan trọng với sếp và team: bạn hiểu ai đang dùng sản phẩm và họ cảm thấy thế nào ở từng bước. Đó là tư duy khác biệt giữa một người "ghi chép yêu cầu" và một người "phân tích nghiệp vụ" thực thụ. Bài này sẽ dạy bạn cả hai công cụ đó, đủ sâu để bạn tự làm được ngay trong dự án đầu tiên.
Khái niệm cốt lõi
Persona là gì?
Persona (chân dung người dùng) là một nhân vật giả lập, có tên tuổi, đặc điểm cụ thể, đại diện cho một nhóm người dùng thật có chung hành vi, nhu cầu và mục tiêu. Persona không phải là một người có thật, mà là bản tổng hợp mang tính đại diện — được xây dựng dựa trên dữ liệu và phỏng vấn người dùng thực.
Tại sao phải "giả lập" một người thay vì nói chung chung "người dùng"? Vì não người làm việc tốt hơn với con người cụ thể. Khi bạn nói với team "người dùng muốn giao diện đơn giản", mỗi người trong phòng sẽ tưởng tượng một người dùng khác nhau. Nhưng khi bạn nói "chị An, 52 tuổi, không rành công nghệ, cần đặt lịch khám cho mẹ già 78 tuổi", cả team nhìn về cùng một hướng. Persona biến khái niệm trừu tượng "người dùng" thành một con người mà cả team có thể đồng cảm và ghi nhớ.
Một persona không phải là bản khai lý lịch. Điểm mấu chốt là nó phải chứa thông tin ảnh hưởng đến quyết định thiết kế sản phẩm: mục tiêu (goals), nỗi đau (pain points), hành vi (behaviors), và bối cảnh sử dụng (context). Tuổi tác hay nghề nghiệp chỉ có ý nghĩa khi chúng giải thích được hành vi.
Persona template một trang
Đây là khung persona chuẩn mà một BA fresher có thể dùng ngay:
Tên: An Nguyễn
Tuổi: 52
Nghề nghiệp: Chủ cửa hàng tạp hóa nhỏ ở Quận Tân Bình
Bối cảnh: Dùng điện thoại Android tầm trung, sóng 4G,
thường thao tác khi rảnh buổi tối
Trình độ công nghệ: Trung bình-thấp (biết Zalo, Facebook)Mục tiêu (Goals):
- Đặt lịch khám cho mẹ già mà không cần đến bệnh viện xếp hàng
- Biết chắc chắn lịch đã được xác nhận
Nỗi đau (Pain points):
- Sợ đặt nhầm, không chắc thao tác đã đúng chưa
- Chữ nhỏ, nút bấm khó thấy
- Không biết cần chuẩn bị giấy tờ gì
Câu nói tiêu biểu (Quote):
"Tôi chỉ cần biết đặt xong rồi, và mai đi khám cần mang gì."Kịch bản sử dụng:
Buổi tối sau khi đóng cửa hàng, An mở app đặt lịch khám
tim mạch cho mẹ tại bệnh viện gần nhà cho sáng thứ Bảy.
Bạn thấy đấy, mỗi dòng đều "kể một câu chuyện" và mỗi câu chuyện đều gợi ý một yêu cầu thiết kế: chữ to hơn, bước xác nhận rõ ràng, thông tin chuẩn bị giấy tờ hiển thị sau khi đặt.
Có mấy loại persona?
Trong dự án thực tế bạn thường gặp 2–4 persona, chia theo nhóm hành vi khác nhau, không phải theo nhân khẩu học. Ví dụ với app đặt lịch khám: "người tự đặt cho bản thân", "người đặt hộ người thân", "nhân viên lễ tân nhập lịch giúp bệnh nhân gọi điện". Ba nhóm này hành xử rất khác nhau nên cần ba persona.
Một lưu ý: đừng nhầm persona với stakeholder. Stakeholder là người có lợi ích hoặc ảnh hưởng đến dự án (đã học ở Bài 30). Persona là người sử dụng sản phẩm cuối cùng. Một giám đốc bệnh viện là stakeholder quan trọng nhưng có thể không phải là persona nếu ông ấy không trực tiếp dùng app.
User Journey Map là gì?
User Journey Map (bản đồ hành trình người dùng) là một hình dung trực quan về toàn bộ trải nghiệm của một persona khi họ tương tác để đạt được mục tiêu — từ trước khi chạm vào sản phẩm cho đến sau khi hoàn thành. Nó không chỉ vẽ các bước thao tác, mà quan trọng nhất là ghi lại cảm xúc, suy nghĩ và điểm đau ở từng giai đoạn.
Nếu như user flow (bạn sẽ dùng nhiều khi làm việc với dev) trả lời câu hỏi "người dùng bấm gì, đi qua màn hình nào", thì journey map trả lời câu hỏi rộng hơn: "người dùng trải nghiệm gì, cảm thấy ra sao, và ở đâu họ thất vọng nhất". Journey map bao gồm cả những khoảnh khắc ngoài phạm vi sản phẩm — như lúc người dùng nghe bạn bè giới thiệu app, hay lúc họ đến bệnh viện sau khi đặt lịch.
Cấu trúc một journey map cơ bản gồm các cột (giai đoạn) và các hàng (khía cạnh phân tích):
- Giai đoạn (Stages/Phases): ví dụ Nhận biết → Tìm kiếm → Đặt lịch → Chờ đợi → Đi khám → Sau khám.
- Hành động (Actions): người dùng làm gì ở mỗi giai đoạn.
- Suy nghĩ (Thoughts): họ đang nghĩ gì, tự hỏi gì.
- Cảm xúc (Emotions): thường vẽ thành một đường cảm xúc lên/xuống.
- Điểm đau (Pain points): chỗ nào gây khó chịu, bối rối.
- Cơ hội (Opportunities): ý tưởng cải thiện — đây là phần "vàng" mà BA đóng góp.
Vì sao hai công cụ này đi cùng nhau?
Persona trả lời câu hỏi AI, journey map trả lời câu hỏi TRẢI NGHIỆM CỦA HỌ NHƯ THẾ NÀO. Một journey map luôn phải gắn với một persona cụ thể, vì cùng một hành trình nhưng chị An 52 tuổi và bạn Minh 25 tuổi rành công nghệ sẽ có cảm xúc và điểm đau hoàn toàn khác nhau. Vẽ journey map mà không xác định persona thì giống như kể chuyện mà không biết nhân vật chính là ai.
Tình huống thực tế
Ví dụ 1: Fintech ví điện tử — persona "người bán hàng online nhỏ"
Một công ty fintech giả định tên PayMoi làm ví điện tử, muốn thêm tính năng "tạo mã QR nhận tiền" cho tiểu thương. Ban đầu team dev thiết kế theo hướng "chuẩn app ngân hàng": nhiều bước xác thực, nhập số tiền chính xác trước khi tạo QR.
BA fresher trong dự án dựng persona "Chị Hoa, 38 tuổi, bán quần áo online trên Facebook, mỗi ngày chốt 30–50 đơn, thao tác nhanh trên điện thoại giữa lúc livestream". Mục tiêu của chị Hoa: nhận tiền nhanh, không để khách chờ. Nỗi đau: mỗi giây chậm là mất khách.
Khi map journey, BA phát hiện một khoảnh khắc cảm xúc tụt dốc: ở bước "nhập chính xác số tiền trước khi tạo QR", chị Hoa phải dừng livestream, gõ số, dễ gõ sai. Insight rút ra: chị Hoa cần một mã QR tĩnh (khách tự nhập số tiền) để dán sẵn, thay vì tạo QR động mỗi lần.
Bài học: Persona đúng đã lật ngược giả định thiết kế. Nếu chỉ nhìn từ góc độ hệ thống, team sẽ làm QR động "an toàn hơn" nhưng lại giết chết trải nghiệm của nhóm người dùng chính. Con số 30–50 đơn/ngày trong persona chính là lý do khiến tốc độ trở thành ưu tiên số một.
Ví dụ 2: E-commerce — journey map lộ ra điểm rơi ở khâu vận chuyển
Một sàn thương mại điện tử (bối cảnh giống Tiki/Shopee) nhận thấy tỷ lệ hủy đơn cao ở nhóm khách hàng tỉnh. BA được giao tìm hiểu. Thay vì chỉ nhìn số liệu, BA dựng persona "Anh Tuấn, 29 tuổi, ở Cà Mau, mua đồ điện tử, quen thanh toán COD vì không tin tưởng trả trước" và vẽ journey map đầy đủ.
Đường cảm xúc của anh Tuấn hào hứng ở giai đoạn "chọn hàng" và "đặt đơn", nhưng tụt mạnh ở giai đoạn "chờ giao hàng": app hiển thị "dự kiến 2–3 ngày" nhưng thực tế hàng đi tỉnh mất 6–7 ngày. Đến ngày thứ 5 không thấy hàng, anh Tuấn nghĩ "chắc bị lừa rồi", và hủy đơn.
Điểm đau nằm ở kỳ vọng sai chứ không phải ở tốc độ giao hàng. Cơ hội cải thiện mà BA đề xuất: hiển thị thời gian giao dự kiến theo đúng khu vực địa lý, và gửi thông báo cập nhật vị trí đơn hàng ở ngày thứ 3, thứ 5 để "giữ nhịp niềm tin".
Bài học: Journey map cho thấy vấn đề thật không nằm ở nơi mọi người nghĩ (tốc độ giao) mà nằm ở khoảng cách giữa kỳ vọng và thực tế. Chỉ khi map cả cảm xúc theo thời gian, BA mới nhìn ra "khoảnh khắc mất niềm tin" ở ngày thứ 5.
Ví dụ 3: App nội bộ — persona của chính nhân viên công ty
Một chuỗi cà phê ở TP.HCM (giả định tên CoffeeGo, 40 chi nhánh) làm app quản lý ca cho nhân viên part-time. Đây là ví dụ để bạn thấy persona không chỉ dành cho khách hàng bên ngoài. BA dựng persona "Bạn Linh, 20 tuổi, sinh viên, làm part-time 3 buổi/tuần, hay đổi ca với đồng nghiệp, dùng app trên điện thoại đời cũ".
Journey map cho quy trình "xin đổi ca" lộ ra điểm đau: Linh phải nhắn tin riêng cho từng đồng nghiệp hỏi ai đổi được, rồi mới vào app xác nhận — tức là phần "khó nhất" (tìm người đổi ca) lại xảy ra ngoài app. Cơ hội: thêm tính năng "đăng ca cần đổi lên bảng tin chung để đồng nghiệp nhận".
Bài học: Journey map giúp BA nhìn ra phần trải nghiệm diễn ra bên ngoài sản phẩm — thứ mà user flow thuần túy không bao giờ thấy được. Persona là nhân viên nội bộ cũng cần được thấu hiểu như khách hàng.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng ngay trong dự án đầu tiên.
Bước 1 — Thu thập dữ liệu đầu vào. Đừng bịa persona ra từ trí tưởng tượng. Dùng các kỹ thuật elicitation (Bài 31): phỏng vấn 3–5 người dùng thật, đọc dữ liệu analytics, xem ticket support, hỏi đội sales/CSKH. Ngay cả khi dự án chưa có user, bạn vẫn nên phỏng vấn stakeholder hiểu về khách hàng.
Bước 2 — Phân nhóm hành vi. Nhìn vào dữ liệu, tìm những nhóm người có hành vi và mục tiêu giống nhau. Đừng chia theo tuổi hay giới tính, hãy chia theo cách họ dùng sản phẩm. Thường bạn sẽ ra 2–4 nhóm rõ rệt.
Bước 3 — Viết persona cho mỗi nhóm. Dùng template một trang ở trên. Đặt tên, tuổi, bối cảnh, nhưng dành nhiều tâm sức nhất cho mục tiêu và nỗi đau. Thêm một câu quote để persona "sống dậy". Giữ mỗi persona gọn trong một trang.
Bước 4 — Chọn persona để map journey. Không map cho tất cả cùng lúc. Chọn persona quan trọng nhất (persona chính) và một mục tiêu cụ thể của họ, ví dụ "chị An đặt lịch khám cho mẹ".
Bước 5 — Xác định các giai đoạn hành trình. Liệt kê theo dòng thời gian, bắt đầu trước khi người dùng chạm sản phẩm và kết thúc sau khi họ hoàn thành. Ví dụ: Nhận biết → Tìm kiếm → Đặt lịch → Chờ → Đi khám → Sau khám.
Bước 6 — Điền hành động, suy nghĩ, cảm xúc cho từng giai đoạn. Với mỗi cột, tự hỏi: người dùng làm gì? nghĩ gì? cảm thấy vui hay bực? Vẽ đường cảm xúc lên xuống để thấy chỗ nào tụt dốc.
Bước 7 — Đánh dấu điểm đau và cơ hội. Ở mỗi chỗ cảm xúc tụt, ghi lại pain point và ít nhất một ý tưởng cải thiện. Đây là phần tạo giá trị lớn nhất của BA.
Bước 8 — Kiểm chứng và chuyển thành yêu cầu. Đưa persona và journey map cho stakeholder xem để họ xác nhận. Sau đó, biến các "cơ hội" thành user story hoặc requirement cụ thể để đưa vào backlog.
Về công cụ: bạn có thể vẽ trên Figma, Miro, Mural, hoặc đơn giản là một bảng trong Google Sheets/Excel với cột là giai đoạn và hàng là khía cạnh. Đừng để công cụ cản trở — nội dung quan trọng hơn hình thức đẹp.
Lỗi thường gặp & mẹo
Lỗi 1: Bịa persona từ trong đầu. Đây là lỗi phổ biến nhất của fresher. Persona không dựa trên dữ liệu thật chỉ là "persona giả tưởng" phản ánh định kiến của bạn. Mẹo: luôn ghi rõ persona này dựa trên bao nhiêu cuộc phỏng vấn, nguồn dữ liệu nào.
Lỗi 2: Nhồi nhét chi tiết vô nghĩa. Ghi persona thích màu xanh, nuôi mèo, thích ăn phở… mà những thứ đó không ảnh hưởng gì đến sản phẩm. Mẹo: với mỗi dòng, tự hỏi "chi tiết này có làm thay đổi quyết định thiết kế không?". Nếu không, bỏ.
Lỗi 3: Tạo quá nhiều persona. Có bạn làm 8–10 persona, đến mức không ai nhớ nổi. Mẹo: 2–4 persona là đủ cho phần lớn dự án. Ưu tiên persona chính.
Lỗi 4: Journey map chỉ liệt kê thao tác, thiếu cảm xúc. Nếu journey map của bạn trông y hệt một user flow thì bạn đã làm sai. Điểm khác biệt sống còn là cảm xúc và suy nghĩ. Mẹo: luôn có hàng "cảm xúc" với đường lên xuống.
Lỗi 5: Map xong rồi để đó. Persona và journey map đẹp nhưng không dẫn tới hành động gì thì vô dụng. Mẹo: mỗi journey map phải kết thúc bằng danh sách "cơ hội" và những cơ hội đó phải chuyển thành item trong backlog.
Lỗi 6: Quên các giai đoạn ngoài sản phẩm. Nhiều điểm đau (như ví dụ đổi ca của CoffeeGo) nằm ngoài phạm vi app. Mẹo: luôn bắt đầu journey từ trước khi mở app và kết thúc sau khi đóng app.
Mẹo vàng cho fresher: Khi trình bày với team, đừng nói "theo tôi nghĩ người dùng muốn…". Hãy nói "theo persona chị An và journey map, ở giai đoạn X người dùng gặp khó khăn Y, nên tôi đề xuất Z". Cách nói dựa trên artifact khiến bạn nghe chuyên nghiệp và thuyết phục hơn nhiều.
Bài tập thực hành
Bài 1 — Dựng persona. Chọn một app bạn dùng hàng ngày (ví dụ Grab, MoMo, Shopee). Tưởng tượng bạn là BA của app đó và viết 2 persona khác nhau về hành vi, dùng đúng template một trang ở trên. Bắt buộc mỗi persona có ít nhất 2 mục tiêu và 2 nỗi đau. Tự hỏi: hai persona này có thực sự cần thiết kế khác nhau không?
Bài 2 — Vẽ journey map. Với persona chính bạn vừa tạo, chọn một mục tiêu cụ thể (ví dụ "đặt xe đi sân bay lúc 4 giờ sáng") và vẽ journey map gồm ít nhất 5 giai đoạn, mỗi giai đoạn có: hành động, suy nghĩ, cảm xúc (cao/thấp), điểm đau. Vẽ trên giấy, Google Sheets hoặc Miro đều được.
Bài 3 — Từ insight ra requirement. Nhìn vào journey map ở Bài 2, tìm giai đoạn cảm xúc tụt thấp nhất. Viết ít nhất 2 cơ hội cải thiện, rồi chuyển mỗi cơ hội thành một user story theo mẫu "Là [persona], tôi muốn [gì], để [đạt được gì]".
Bài 4 — Phản biện. Đưa persona của bạn cho một người bạn xem và hỏi: "Đọc xong, bạn có hình dung rõ đây là ai không? Chi tiết nào thừa?". Ghi lại phản hồi và tinh chỉnh persona. Đây chính là bước kiểm chứng mà BA thật luôn làm.
Tóm tắt
- Persona là chân dung giả lập đại diện cho một nhóm người dùng thật, giúp cả team đồng cảm và cùng nhìn về một hướng. Điểm cốt lõi của persona là mục tiêu và nỗi đau, không phải chi tiết nhân khẩu học vô nghĩa.
- User Journey Map hình dung toàn bộ trải nghiệm của một persona theo dòng thời gian, tập trung vào cảm xúc, suy nghĩ, điểm đau và cơ hội — khác với user flow chỉ mô tả thao tác.
- Hai công cụ luôn đi cùng nhau: persona trả lời "ai", journey map trả lời "trải nghiệm của họ thế nào".
- Giá trị lớn nhất mà BA tạo ra là biến các điểm đau trên journey map thành cơ hội, rồi thành requirement đưa vào backlog.
- Luôn dựa trên dữ liệu thật, giữ số lượng persona 2–4, và đừng bao giờ để artifact nằm im — chúng phải dẫn tới hành động.