Mở đầu — vì sao bài này quan trọng
Trong toàn bộ khóa học này, bạn đã học rất nhiều kỹ thuật: color contrast, semantic HTML, ARIA, keyboard navigation, screen reader. Đó là phần "làm thế nào". Nhưng có một câu hỏi lớn hơn, đứng trước mọi kỹ thuật: chúng ta đang thiết kế cho ai?
Đa số designer khi làm persona vẫn vẽ ra một nhân vật lý tưởng: trẻ, khỏe mạnh, mắt tinh, tay nhanh, dùng iPhone đời mới, ngồi trong văn phòng có wifi mạnh. Kết quả là toàn bộ sản phẩm được tối ưu cho người dùng "hoàn hảo" đó — và vô tình loại bỏ hàng triệu người thật đang cố gắng dùng nó trong điều kiện khác hẳn.
Đây là điểm mấu chốt mà bài học này muốn bạn hiểu: accessibility không phải là một danh sách kiểm tra bạn nhét vào cuối quy trình, mà bắt đầu từ cách bạn hình dung về người dùng ngay từ đầu. Nếu persona của bạn chỉ toàn người khỏe mạnh, thì mọi quyết định thiết kế phía sau sẽ nghiêng theo hướng đó, và không có checklist WCAG nào ở cuối dự án cứu được. Inclusive persona chính là cách bạn "gài" sự đa dạng của con người vào ngay từ khâu tư duy, để tính bao trùm trở thành mặc định chứ không phải phần vá lỗi.
Khái niệm cốt lõi
Persona chuẩn vs. Inclusive persona
Một persona chuẩn mà bạn hay gặp trong các workshop UX ở Việt Nam thường trông thế này:
> Mai, 28 tuổi, chuyên viên marketing ở Sài Gòn. Dùng iPhone 15, thành thạo công nghệ, hay lướt Instagram giờ nghỉ trưa. Mục tiêu: tìm khóa học nhanh, thanh toán tiện lợi.
Persona này không sai — nhưng nó chỉ mô tả một lát cắt rất hẹp. Nó ngầm giả định Mai luôn nhìn rõ màn hình, luôn có hai tay rảnh, luôn ở nơi mạng tốt, luôn tập trung 100%. Thực tế con người phức tạp hơn nhiều.
Inclusive persona giữ nguyên khung persona quen thuộc nhưng bổ sung các chiều liên quan đến khả năng và bối cảnh:
- Khuyết tật vĩnh viễn (permanent): mù, khiếm thị, điếc, mất một tay, khó vận động, khó khăn nhận thức.
- Khuyết tật tạm thời (temporary): gãy tay bó bột, đau mắt sau phẫu thuật, mất giọng vì viêm họng.
- Khuyết tật hoàn cảnh (situational): đang bế con bằng một tay, đang đứng ngoài nắng chói không nhìn rõ màn hình, đang ở quán cà phê ồn không nghe được video, mạng 3G yếu ở vùng quê.
Ba yếu tố cần thêm vào mỗi persona
Khi nâng cấp persona thành inclusive, hãy trả lời ba câu:
- Khả năng (abilities): Người này nhìn, nghe, vận động, ghi nhớ, đọc hiểu ở mức nào? Họ có dùng công nghệ hỗ trợ (screen reader, phóng to, điều khiển bằng giọng nói) không?
- Bối cảnh sử dụng (context): Họ dùng sản phẩm ở đâu, thiết bị gì, mạng thế nào, có bị phân tâm không, một tay hay hai tay?
- Rào cản & động lực (barriers & motivations): Điều gì khiến họ bỏ cuộc? Điều gì khiến họ kiên trì? Họ đã có "mẹo" nào để vượt qua giao diện khó dùng chưa?
Persona không thay thế người thật
Một cảnh báo quan trọng ngay từ đầu: persona là công cụ tư duy và giao tiếp, không phải bằng chứng. Persona giúp cả nhóm cùng hình dung, cùng ra quyết định, cùng có "gương mặt" để tranh luận. Nhưng persona được xây từ giả định của bạn, còn testing với người khuyết tật thật (nội dung của Bài 54) mới cho bạn sự thật. Persona là điểm khởi đầu để đặt câu hỏi đúng, không phải điểm kết thúc.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT và persona "chỉ có Mai"
Một sàn thương mại điện tử tầm trung ở Việt Nam (giả định là "ChợViệt") làm lại app. Team UX xây 3 persona: Mai (marketer trẻ), Hùng (nhân viên văn phòng), Lan (mẹ bỉm sữa mua đồ cho con). Cả ba đều khỏe mạnh, dùng smartphone đời mới.
App ra mắt, chỉ số CSAT tốt trong nội bộ. Nhưng sáu tháng sau, bộ phận chăm sóc khách hàng báo cáo một cụm phàn nàn lặp đi lặp lại: nhiều khách lớn tuổi không đọc được giá vì chữ xám nhạt và quá nhỏ; nút "Đặt hàng" nằm sát cạnh nút "Xóa" khiến người tay run bấm nhầm; khách ở tỉnh mạng yếu bỏ giỏ hàng vì ảnh sản phẩm tải quá lâu.
Điều đáng nói: nhóm khách lớn tuổi lại chính là nhóm chi tiêu cao và trung thành. Team đã "quên" họ ngay từ khâu persona.
Bài học: Persona đồng nhất (toàn người giống nhau) tạo ra điểm mù có thật, gây thiệt hại doanh thu thật. Khi team làm lại persona, họ thêm "Bác Tư, 62 tuổi, viễn thị, tay run nhẹ, dùng điện thoại Android tầm trung, mạng 4G chập chờn ở quê". Chỉ một persona này thôi đã buộc các quyết định về cỡ chữ tối thiểu, khoảng cách touch target, và tối ưu ảnh trở thành yêu cầu bắt buộc — chứ không còn là "nice to have".
Ví dụ 2 — Grab và persona hoàn cảnh (situational)
Hãy nhìn một sản phẩm quen thuộc: ứng dụng gọi xe/giao đồ ăn kiểu Grab. Người dùng của họ thường xuyên ở trong tình huống khuyết tật hoàn cảnh: tài xế đang chạy xe không thể nhìn màn hình lâu; khách đứng ngoài trời nắng gắt buổi trưa Sài Gòn khó đọc chữ; người đi bộ vừa xách túi đồ nặng vừa thao tác một tay.
Nếu team chỉ có persona "ngồi yên trong phòng nhìn màn hình rõ ràng", họ sẽ không bao giờ nghĩ tới việc: nút xác nhận phải to và dễ chạm bằng ngón cái; thông báo quan trọng nên có cả âm thanh lẫn rung; màu và độ tương phản phải đủ mạnh để nhìn được dưới nắng. Một inclusive persona như "Sơn, tài xế, thao tác một tay khi dừng đèn đỏ, mắt liếc nhanh, tai đeo tai nghe" trực tiếp dẫn tới những quyết định thiết kế đó.
Bài học: Khuyết tật hoàn cảnh áp dụng cho gần như tất cả người dùng vào lúc nào đó. Thiết kế cho nó không phải là "làm thêm cho người thiểu số" — nó nâng trải nghiệm cho toàn bộ tệp người dùng. Đây là lý do inclusive persona thường mang lại ROI rõ ràng, dễ thuyết phục sếp.
Ví dụ 3 — Ngân hàng số và quy trình có persona khuyết tật vĩnh viễn
Một ngân hàng số (giả định "VConnect Bank") đưa vào quy trình thiết kế một inclusive persona: "Chị Ngọc, 35 tuổi, khiếm thị hoàn toàn, dùng screen reader VoiceOver trên iPhone, làm kế toán, tự lập tài chính". Persona này được dán lên tường phòng thiết kế và xuất hiện trong mọi buổi review.
Kết quả là mỗi khi có tính năng mới, cả nhóm tự hỏi: "Chị Ngọc dùng cái này bằng screen reader thì nghe ra thứ tự thế nào? Nút này có nhãn không? Mã OTP đọc lên có rõ không?". Câu hỏi đó buộc họ gán label đúng, sắp xếp thứ tự đọc hợp lý, tránh dùng hình ảnh chứa chữ mà screen reader không đọc được.
Bài học: Persona vĩnh viễn có sức mạnh biến accessibility thành một phần của cuộc trò chuyện hằng ngày, thay vì một buổi audit cuối dự án. Nó cho team một "khách hàng có tên" để bảo vệ. Khi có ai đề xuất cắt bớt để kịp deadline, câu hỏi "thế chị Ngọc thì sao?" giữ được sự bao trùm không bị hy sinh đầu tiên.
Hướng dẫn từng bước
Bước 1 — Rà soát persona hiện có và tìm điểm mù. Lấy toàn bộ persona đang dùng ra. Với mỗi cái, hỏi: nhân vật này có khiếm khuyết nào về nhìn/nghe/vận động/nhận thức không? Bối cảnh của họ có luôn lý tưởng không? Nếu tất cả persona đều khỏe mạnh và ở điều kiện tốt — bạn vừa tìm ra điểm mù.
Bước 2 — Chọn chiều đa dạng dựa trên dữ liệu, không dựa trên cảm tính. Đừng thêm khuyết tật một cách ngẫu nhiên. Nhìn vào tệp người dùng thật: sản phẩm cho người lớn tuổi thì viễn thị và tay run rất phổ biến; sản phẩm ở vùng nông thôn thì mạng yếu là chuyện thường ngày; sản phẩm nhiều video thì người dùng ở nơi ồn cần caption. Tham chiếu số liệu WHO (khoảng 16% dân số thế giới sống với một dạng khuyết tật đáng kể) để đặt câu hỏi đúng ưu tiên.
Bước 3 — Áp dụng Persona Spectrum cho mỗi persona chính. Với mỗi persona quan trọng, viết ra ba biến thể: bản vĩnh viễn, bản tạm thời, bản hoàn cảnh của cùng một rào cản. Ví dụ với thao tác một tay: người cụt tay (vĩnh viễn), người gãy tay (tạm thời), người bế con (hoàn cảnh). Điều này giúp cả nhóm thấy rằng giải pháp phục vụ cả ba.
Bước 4 — Viết inclusive persona đầy đủ. Mỗi persona nên gồm: tên + ảnh (dùng ảnh đa dạng, tránh chỉ toàn người mẫu trẻ đẹp), tuổi, nghề, mục tiêu, khả năng & công nghệ hỗ trợ đang dùng, bối cảnh sử dụng cụ thể, rào cản chính, và một câu trích dẫn (quote) nói lên nỗi bực dọc của họ. Câu quote rất quan trọng — nó khiến persona sống động và dễ nhớ trong các buổi họp.
Bước 5 — Gắn persona vào từng khâu của quy trình thiết kế.
- Discovery: dùng persona để định hình câu hỏi phỏng vấn.
- Ideation: mỗi ý tưởng phải trả lời được "persona này dùng được không?".
- Wireframe/UI: dán persona lên tường, review theo góc nhìn của họ.
- Review/QA: mỗi acceptance criteria kèm câu hỏi "chị Ngọc / bác Tư dùng thế nào?".
Bước 7 — Xem persona là tài liệu sống. Sau mỗi vòng research hoặc test với người thật, cập nhật lại persona. Persona sai sẽ dẫn dắt sai — nên nó cần được nuôi dưỡng bằng dữ liệu thật theo thời gian.
Lỗi thường gặp & mẹo
Lỗi 1 — "Persona khuyết tật" tách rời. Tạo một persona riêng tên "Người khuyết tật" đứng bên lề, còn các persona "chính" vẫn khỏe mạnh. Cách này biến accessibility thành trường hợp ngoại lệ dễ bị bỏ qua. Mẹo: tích hợp chiều khả năng vào persona chính, và đảm bảo ít nhất một persona cốt lõi có khuyết tật vĩnh viễn.
Lỗi 2 — Biến persona thành nhân vật đáng thương. Mô tả kiểu "tội nghiệp, không dùng được internet" là sai và xúc phạm. Người khuyết tật là người dùng thành thạo công nghệ hỗ trợ, có mục tiêu và năng lực. Mẹo: viết persona ở thế chủ động — họ có kỹ năng, có mẹo riêng, chỉ bị cản bởi thiết kế tồi, không phải bởi bản thân họ.
Lỗi 3 — Stereotype (rập khuôn). Cho rằng "người khiếm thị thì luôn dùng chữ nổi", "người lớn tuổi thì luôn kém công nghệ". Thực tế đa dạng hơn nhiều. Mẹo: dựa trên hành vi và công nghệ hỗ trợ cụ thể, không dựa trên định kiến nhóm.
Lỗi 4 — Làm persona đẹp rồi cất vào Drive. Persona chỉ có giá trị khi được dùng liên tục. Mẹo: in ra dán tường, đưa vào template review, biến thành câu hỏi bắt buộc trong quy trình.
Lỗi 5 — Nhầm persona với dữ liệu thật. Mẹo: luôn nói rõ persona là giả định để định hướng, và lên kế hoạch kiểm chứng bằng test với người dùng khuyết tật thật.
Mẹo vàng: Khi thuyết phục stakeholder, hãy dùng lập luận Persona Spectrum. Đừng nói "chúng ta cần làm cho người khuyết tật" (dễ bị xem là chi phí phụ). Hãy nói "thiết kế cho thao tác một tay giúp cả người gãy tay và người bế con — tức phần lớn khách hàng của chúng ta vào lúc nào đó". Ngôn ngữ ROI thuyết phục hơn ngôn ngữ từ thiện.
Bài tập thực hành
Bài tập 1 — Nâng cấp một persona. Lấy persona "Mai, 28, marketer Sài Gòn, iPhone" ở đầu bài. Viết lại thành inclusive persona đầy đủ bằng cách thêm: khả năng & công nghệ hỗ trợ, bối cảnh sử dụng cụ thể, một rào cản chính, và một câu quote. Sau đó tạo thêm hai biến thể theo Persona Spectrum (một tạm thời, một hoàn cảnh) cho cùng một rào cản bạn chọn.
Bài tập 2 — Persona Spectrum cho tính năng thật. Chọn một tính năng bạn từng làm hoặc dùng (ví dụ: màn hình thanh toán). Viết ba biến thể persona (vĩnh viễn / tạm thời / hoàn cảnh) cùng chia sẻ một rào cản. Với mỗi biến thể, ghi ra một quyết định thiết kế mà persona đó buộc bạn phải cân nhắc.
Bài tập 3 — Biến persona thành user story. Từ inclusive persona ở Bài tập 1, viết ba user story theo mẫu "Là [persona], tôi muốn [mục tiêu] để [lợi ích]". Đảm bảo ít nhất hai story phản ánh nhu cầu accessibility cụ thể, và mỗi story kèm một acceptance criteria kiểm chứng được.
Bài tập 4 (nâng cao) — Audit persona đội bạn. Nếu bạn đang đi làm, thu thập toàn bộ persona của một dự án và đánh giá: bao nhiêu phần trăm là người khỏe mạnh ở điều kiện lý tưởng? Viết một đề xuất ngắn (nửa trang) chỉ ra điểm mù và đề nghị thêm ít nhất một persona có khuyết tật vĩnh viễn, kèm lập luận ROI theo Persona Spectrum.
Tóm tắt
- Persona chuẩn thường mô tả một người dùng lý tưởng, khỏe mạnh, ở điều kiện hoàn hảo — và chính điều đó tạo ra điểm mù về accessibility ngay từ khâu tư duy.
- Inclusive persona bổ sung ba chiều: khả năng (nhìn/nghe/vận động/nhận thức + công nghệ hỗ trợ), bối cảnh sử dụng, và rào cản chính.
- Persona Spectrum của Microsoft cho thấy mỗi rào cản tồn tại ở ba dạng — vĩnh viễn, tạm thời, hoàn cảnh — nên thiết kế cho khuyết tật phục vụ luôn phần lớn người dùng thông thường.
- Persona phải được gắn vào từng khâu của quy trình (discovery, ideation, wireframe, review) và chuyển thành user story để yêu cầu accessibility vào backlog tự nhiên.
- Tránh các lỗi: persona khuyết tật tách rời, mô tả đáng thương, rập khuôn, làm xong rồi cất, và nhầm persona với dữ liệu thật.
- Persona là công cụ tư duy mạnh mẽ nhưng không thay thế việc kiểm chứng với người dùng khuyết tật thật — đó là bước tiếp theo trong hành trình của bạn.