Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Persona: Proto-persona, anti-persona và cần bao nhiêu persona

Đã đọc 0/11 mục · còn khoảng 8 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Vì sao chủ đề quan trọng

Bài 1 cho bạn một persona có bằng chứng: Người chạy lịch. Ngay sau đó, đội sẽ gặp ba câu hỏi. Có nên vẽ persona trước khi phỏng vấn không? Cần bao nhiêu persona thì đủ? Và có cần persona cho người không phải sinh viên không?

Trả lời sai câu nào cũng tốn kém. Không có persona nào trước khi phỏng vấn thì đội không biết mình đang giả định gì. Có tám persona thì không ai nhớ, và mọi tính năng đều "phục vụ một persona nào đó". Bỏ quên nhân viên bếp thì đội thiết kế một luồng đặt trước rất đẹp phía sinh viên, rồi phát hiện Cô Hạnh không có cách nào nhìn thấy đơn.

Bài này lấy đầu vào là persona đầu tiên và danh sách P1 tới P12, rồi trả ra bộ persona cuối cùng của Căng tin số: ba persona sinh viên, một persona nhân viên, và một anti-persona cho giai đoạn 1.

Bức tranh lớn

Persona giả định (proto-persona) là persona đội viết ra trước khi có dữ liệu, từ những gì đội tin. Nó không sai về bản chất; nó sai khi bị coi là kết quả. Cách dùng đúng: viết nó ra, gắn nhãn "giả thuyết", rồi dùng chính nó để chọn người phỏng vấn và soạn câu hỏi. Sau phỏng vấn, mỗi dòng sẽ được xác nhận, sửa, hoặc xóa.

Cần bao nhiêu persona? Quy tắc thực dụng: tách hai persona khi mục tiêu hoặc hành vi khác nhau đủ để một quyết định thiết kế khác nhau. Nếu hai kiểu người sẽ được phục vụ bởi cùng một màn hình, cùng một luồng, gộp lại. Với một dự án sinh viên ở giai đoạn khám phá, hai tới ba persona người dùng chính là đủ. Nhiều hơn thường là dấu hiệu đội đang chia theo nhân khẩu học thay vì theo hành vi.

Persona loại trừ (anti-persona) mô tả người mà sản phẩm không phục vụ trong giai đoạn đang làm. Nó không nói họ không quan trọng; nó nói "lần này chưa". Anti-persona giúp đội từ chối yêu cầu một cách có căn cứ.

Persona nhân viên là persona cho người vận hành phía sau. Nếu sản phẩm có màn hình cho bếp hay quầy, người đứng trước màn hình đó là người dùng, có mục tiêu, hành vi và nỗi đau riêng.

flowchart TD
    A[Đội viết persona giả định] --> B[Gắn nhãn giả thuyết]
    B --> C[Chọn người phỏng vấn theo giả thuyết]
    C --> D[Phỏng vấn và tổng hợp]
    D --> E{Dòng giả thuyết khớp bằng chứng?}
    E -->|Khớp| F[Giữ và ghi nguồn]
    E -->|Lệch| G[Sửa theo bằng chứng]
    E -->|Không ai nhắc tới| H[Xóa]
    F --> I[Persona có bằng chứng]
    G --> I

Ví dụ chi tiết

Persona giả định của đội, trước phỏng vấn. Đội Căng tin số từng tin rằng người dùng chính là "sinh viên ngại xếp hàng, muốn đồ ăn giao tới giảng đường". Sau sáu cuộc phỏng vấn, không ai nhắc tới giao tận nơi. Minh Anh không ngại xếp hàng; em không kịp xếp hàng vì lớp 12:45. Quốc Bảo không cần giao tận nơi; em cần biết trước là hết món. Dòng "muốn giao tận nơi" bị xóa. Dòng "ngại xếp hàng" được sửa thành "không đủ thời gian giữa hai buổi học". Đó là toàn bộ giá trị của persona giả định: nó làm lộ ra điều đội đã tin sai.

Tách hay gộp. Minh Anh và Quốc Bảo đều "khổ vì giờ giấc". Gộp lại thì gọn. Nhưng hãy chạy phép thử quyết định thiết kế: Minh Anh tới lúc 11:30 khi đồ ăn còn đủ, nỗi đau là hàng dài (P1), nên thứ em cần là lấy suất nhanh. Quốc Bảo tới lúc 12:40, hàng đã vãn, nỗi đau là hết món mặn (P2), nên thứ em cần là biết trước còn gì. Hai nhu cầu dẫn tới hai quyết định khác nhau, nên tách.

Thảo Vy là trường hợp rõ hơn. Nỗi đau của em là không biết thành phần (P3) và ngại đưa phiếu hỗ trợ giữa hàng người (P12). Cả hai không liên quan tới giờ giấc.

PersonaNgười đại diệnMục tiêuPain point chínhQuyết định thiết kế bị ảnh hưởng
Người chạy lịchMinh AnhĂn xong và vào lớp 12:45 đúng giờP1, P10Tốc độ nhận suất, lo ngại trả trước
Người tới muộnQuốc BảoCó món mình muốn khi tới lúc 12:40P2, P4Thông tin còn hay hết món trước khi tới
Người ăn cẩn trọngThảo VyĂn an toàn và kín đáoP3, P12Thành phần món, cách dùng suất hỗ trợ
Người đứng bếp giờ cao điểmCô HạnhNấu đủ, không bỏ phí, không rời tay khỏi bếpP6, P11Cách bếp nhận số đơn, giờ chốt đặt trước
Persona nhân viên: Người đứng bếp giờ cao điểm. Cô Hạnh là người am hiểu nghiệp vụ (domain expert), nhưng nếu ứng dụng có màn hình cho bếp thì cô cũng là người dùng. Mục tiêu: nấu đủ số suất, không phải bỏ món nấu quá bốn tiếng. Hành vi: nấu theo mẻ từ 10 giờ 30. Bối cảnh: "Giờ cao điểm cô không cầm điện thoại được, tay đâu mà xem." Nỗi đau: P6 thừa thiếu, mỗi ngày bỏ khoảng 40 suất; P11 không xem được điện thoại. Câu này một mình loại bỏ mọi thiết kế kiểu "bếp nhận thông báo đặt món trên điện thoại".

Anti-persona giai đoạn 1: Người đặt suất cho sự kiện. Anh Tuấn kể: "Câu lạc bộ, lớp gọi điện đặt 20, 30 suất cho sự kiện, ghi tay vào sổ." Đây là P8, có thật. Nhưng Chị Lan đặt yêu cầu "Học kỳ 2 phải chạy thử được ở một quầy". Đơn 30 suất kéo theo cách chia mẻ nấu, đặt cọc, giao tận nơi, không cái nào cần cho một quầy thử nghiệm. Đội ghi rõ: giai đoạn 1 không phục vụ đặt nhóm; sổ tay của Anh Tuấn vẫn chạy song song.

Một lựa chọn sai rất dễ mắc là đưa giảng viên và nhân viên trường vào anti-persona cho đơn giản. Họ chiếm khoảng 15% doanh thu, và Anh Tuấn nói rõ "không có mã số sinh viên đâu". Loại họ ra là chọn một phía trong mâu thuẫn C2 mà không có căn cứ. Họ không cần persona riêng ở giai đoạn này, nhưng cũng không phải anti-persona.

Lộ trình từng bước

  • Viết persona giả định trước phỏng vấn, gắn nhãn giả thuyết, mỗi dòng là một điều đội tin.
  • Sau tổng hợp, đối chiếu từng dòng với ghi chú: giữ, sửa, hay xóa.
  • Liệt kê các ứng viên persona từ cụm pain point.
  • Chạy phép thử quyết định thiết kế cho từng cặp: nếu phục vụ chung một luồng, gộp.
  • Dừng ở hai tới ba persona người dùng chính. Nếu có nhiều hơn, xem lại có đang chia theo tuổi hay năm học không.
  • Tìm người dùng phía sau: ai sẽ nhìn vào màn hình nào? Mỗi vai trò vận hành có màn hình riêng cần một persona.
  • Viết anti-persona dựa trên phạm vi giai đoạn 1, có trích dẫn lý do.
  • Ghi ngày và người duyệt cho bộ persona.
stateDiagram-v2
    GiaThuyet --> DangKiemChung: sau phỏng vấn
    DangKiemChung --> CoBangChung: khớp ghi chú
    DangKiemChung --> BiXoa: không ai xác nhận
    CoBangChung --> CanCapNhat: có ghi chú mới mâu thuẫn
    CanCapNhat --> CoBangChung: đã sửa theo bằng chứng

Sơ đồ trên là vòng đời của một persona: giả thuyết, đang kiểm chứng, có bằng chứng, cần cập nhật khi có ghi chú mới mâu thuẫn, hoặc bị xóa khi không ai xác nhận.

Thói quen & kỷ luật

Thói quenTần suấtKết quả mong đợi
Ghi trạng thái cho từng personaMỗi lần sửaKhông ai nhầm giả thuyết với kết quả
Chạy phép thử quyết định thiết kế khi muốn thêm personaMỗi lần đề xuấtBộ persona không phình quá ba người dùng chính
Hỏi "ai đứng sau màn hình này?" khi thêm màn hìnhMỗi lần thiết kếKhông bỏ quên người vận hành
Đọc lại anti-persona khi có yêu cầu mớiMỗi buổi họp phạm viTừ chối có căn cứ, không cảm tính

Cần luyện tập

Drill một: Viết một persona giả định cho Căng tin số như thể bạn chưa phỏng vấn ai. Sau đó đối chiếu với sáu người trong ghi chú. Đánh dấu dòng nào giữ, dòng nào sửa, dòng nào xóa, và tính tỷ lệ dòng sống sót.

Drill hai: Một bạn trong đội đề xuất tách "sinh viên năm 1" và "sinh viên năm 4" thành hai persona. Viết một đoạn ngắn trả lời bằng phép thử quyết định thiết kế, dùng Thảo Vy và Quốc Bảo làm ví dụ. Kết luận phải dựa trên mục tiêu và hành vi, không phải năm học.

Drill ba: Lấy Anh Tuấn. Viết thử một persona nhân viên cho anh từ năm câu nói của anh, rồi quyết định: giai đoạn 1 có màn hình nào anh trực tiếp dùng không? Nếu không, ghi anh là bên liên quan và giải thích vì sao chưa cần persona.

Checklist hành động tuần này

  • [ ] Viết persona giả định của dự án bạn và gắn nhãn giả thuyết
  • [ ] Đối chiếu từng dòng với ghi chú phỏng vấn
  • [ ] Chạy phép thử quyết định thiết kế cho mọi cặp persona
  • [ ] Viết ít nhất một persona cho người vận hành phía sau
  • [ ] Viết một anti-persona có trích dẫn lý do phạm vi

Chỉ số cho cách làm

Các con số dưới đây đo cách nhóm làm bước này, không đo app có thành công hay không. Câu hỏi app có hiệu quả không, và làm gì tiếp, là việc của khóa Đo lường thành công.

Loại chỉ sốVí dụVai trò
North StarSố persona người dùng chính trong khoảng hai tới baGiữ bộ persona đủ nhỏ để cả đội nhớ
Chỉ số dẫn dắtTỷ lệ dòng giả thuyết đã được kiểm chứngCho biết persona giả định đã thành persona thật chưa
Chỉ số độ phủSố màn hình có persona người dùng tương ứngBắt lỗi quên người vận hành như Cô Hạnh
Chỉ số phạm viSố yêu cầu bị từ chối nhờ anti-personaCho thấy anti-persona đang bảo vệ phạm vi

Dấu hiệu bạn đã thành thạo

Bạn viết persona giả định mà không thấy ngại, vì biết nó sẽ bị sửa. Bạn giải thích được vì sao Minh Anh và Quốc Bảo là hai persona bằng một câu về quyết định thiết kế. Khi ai đó đề xuất thêm màn hình, bạn hỏi ngay ai sẽ đứng trước nó. Bạn nói được "chưa phục vụ trong giai đoạn 1" mà không biến nó thành "không quan trọng".

Cạm bẫy thường gặp

Cạm bẫyBiểu hiệnCách tránh
Persona giả định thành sự thậtKhông ai nhớ nó chưa được kiểm chứngGhi trạng thái ở đầu mỗi persona
Quá nhiều personaTám persona, chia theo năm học hay ngànhPhép thử quyết định thiết kế, dừng ở ba
Quên người vận hànhChỉ có persona sinh viên, bếp không có aiHỏi ai đứng sau mỗi màn hình
Anti-persona để né việc khóLoại giảng viên vì vướng chuyện đăng nhậpAnti-persona phải dựa trên phạm vi có trích dẫn

Chốt lại

Persona giả định là công cụ để lộ ra điều đội đang tin; phỏng vấn biến nó thành persona thật. Hai tới ba persona người dùng chính là đủ khi mỗi persona dẫn tới một quyết định thiết kế khác. Căng tin số chốt bộ persona: Người chạy lịch, Người tới muộn, Người ăn cẩn trọng, cùng Người đứng bếp giờ cao điểm, và một anti-persona là Người đặt suất cho sự kiện. Bài 3 đặt Người chạy lịch vào một buổi trưa thứ Hai cụ thể và vẽ từng bước em đi qua.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi