Trong nhiều thập kỷ, quá trình phát triển phần mềm thường bị chi phối bởi nhà phát triển, kỹ sư và nhà quản lý dự án. Người dùng – những người thực sự sẽ tương tác với hệ thống hàng ngày – thường chỉ xuất hiện như một danh sách yêu cầu đầu vào. Khi sản phẩm hoàn thiện, họ được “mời” đến kiểm thử và đưa ra ý kiến – nhưng khi ấy, mọi thứ đã gần như “xong rồi”.

Đây chính là điều mà User Centred Design (Thiết kế Lấy Người Dùng Làm Trung Tâm) tìm cách thay đổi.

Khác với các phương pháp truyền thống chỉ lấy ý kiến người dùng, UCD yêu cầu chúng ta đặt người dùng làm trung tâm thực sự:

• Không chỉ hỏi họ muốn gì, mà còn phải quan sát cách họ làm việc
• Không chỉ nhận phản hồi cuối cùng, mà còn mời họ tham gia vào quá trình thiết kế
• Không chỉ xây dựng phần mềm đúng yêu cầu, mà còn xây dựng phần mềm phù hợp với tư duy và trải nghiệm của họ

Nói cách khác, người dùng không phải là “khách mời”, mà là “đồng thiết kế”.

UCD không tập trung vào “phần mềm trông ra sao” mà vào cách phần mềm tương tác với người dùng:

• Có dễ dùng không?
• Có tạo cảm giác tự tin không?
• Có giúp người dùng hoàn thành công việc nhanh hơn không?

Giá trị của UCD mô tả ngắn gọn:

Phần mềm tốt không phải phần mềm nhiều tính năng – mà là phần mềm hiểu người dùng.

Người dùng “bình thường”

Chúng ta không phải người dùng bình thường – Và điều đó quan trọng

Trong quá trình phát triển phần mềm, nhiều lập trình viên vô tình rơi vào cái bẫy nguy hiểm: dùng chính mình để hình dung cách người dùng sẽ tương tác với hệ thống.

Nhưng sự thật là: chúng ta không đại diện cho người dùng bình thường.

Là người làm kỹ thuật, chúng ta:

• Có khả năng học nhanh những giao diện phức tạp
• Dễ dàng ghi nhớ các tổ hợp phím, shortcut, hoặc quy trình nhiều bước
• Có tư duy logic và khả năng trừu tượng tốt hơn phần đông người dùng

Chính vì vậy, thiết kế phần mềm dựa trên kinh nghiệm của bản thân có thể gây ra hậu quả nghiêm trọng: sản phẩm trở nên khó dùng, rườm rà, hoặc tách rời thực tế sử dụng.

Đi tìm “sự thật hiện trường” (Ground Truth)

Muốn thiết kế hiệu quả, chúng ta cần biết:

• Người dùng thực sự làm gì?
• Họ gặp rào cản ở đâu?
• Họ có hành vi và thói quen như thế nào?

Câu trả lời nằm ở thực tế tại hiện trường – không phải những gì được mô tả trên tài liệu yêu cầu kỹ thuật. Đây chính là “ground truth”.

Hiểu người dùng – dễ nói, khó làm

Hiểu người dùng không phải chuyện đơn giản:

• Người dùng khác nhau rất nhiều về tuổi tác, nền tảng kỹ năng, khả năng tiếp cận, mong đợi
• Nhiều người không biết diễn đạt rõ ràng nhu cầu
• Có thể gặp vấn đề về địa lý, chi phí, thời gian khi tiếp cận người dùng
• Cần tuân thủ đạo đức nghiên cứu người dùng (không làm phiền, không lấy dữ liệu cá nhân trái phép…)

Ghi nhớ: Lập trình viên giỏi không phải người hiểu code nhất — mà là người hiểu người dùng sâu nhất.

Người dùng trung bình

Không có người dùng trung bình – Và đó là điều quan trọng

Một trong những ngộ nhận nguy hiểm nhất trong thiết kế phần mềm là giả định rằng “người dùng trung bình” tồn tại. Trên thực tế, người dùng trung bình chỉ là một khái niệm tưởng tượng, không phải con người thật.

Người dùng thật thì khác biệt. Người dùng tưởng tượng thì giống nhau.

Vì sao không có người dùng trung bình

• Mỗi người dùng có:
  • Kỹ năng riêng (có người rành công nghệ, có người không)
  • Mục tiêu sử dụng khác nhau
  • Môi trường và thiết bị khác nhau
  • Ngôn ngữ, văn hóa, tư duy khác nhau

Do đó, một thiết kế “vừa đủ cho tất cả” thường sẽ không đủ tốt cho ai cả.

Nguy cơ từ tư duy “điển hình hóa người dùng”

Khi bạn cố gắng tạo ra một “người dùng tiêu biểu”, bạn dễ:

• Đơn giản hóa quá mức sự đa dạng người dùng
• Rập khuôn theo cảm tính cá nhân hoặc văn hóa nhóm
• Thiết kế sai trọng tâm, làm cho phần mềm chỉ phù hợp với nhóm nhỏ – và loại trừ phần còn lại

Ví dụ thực tế:

• Giao diện màu sắc thấp để “phù hợp với người già” → khiến người trẻ thấy buồn tẻ
• Quá nhiều tính năng nâng cao để phục vụ “người giỏi” → làm người mới bối rối

Tự soi lại chính mình

Là nhà phát triển, ta thường mang theo thiên kiến cá nhân:

• “Tôi thấy dễ” = “Ai cũng thấy dễ”
• “Tôi nghĩ thế này tốt hơn” = “Người dùng cũng vậy”

Điều quan trọng là:

Nhận ra những gì giới hạn góc nhìn của ta, để mở rộng được góc nhìn người dùng.

Thiên kiến “Người giống tôi” – People like me bias

Là lập trình viên hay nhà thiết kế, chúng ta thường có một thói quen khó nhận ra: thiết kế sản phẩm dựa trên chính cách mình tư duy, mình hành xử, và mình sử dụng công nghệ.

Đây gọi là thiên kiến “Người giống tôi” (People Like Me Bias).

Thiên kiến này làm cho phần mềm trở nên:

• Quá kỹ thuật, gây khó hiểu
• Quá logic, thiếu trực quan
• Quá “giống lập trình viên”, nhưng không giống người dùng thật

Thực tế ngành công nghệ hiện nay:

• Phần lớn phần mềm được tạo ra bởi:
  • Nam giới trẻ tuổi
  • Có nền tảng kỹ thuật
  • Đam mê công nghệ, có trải nghiệm số phong phú

Tuy nhiên, người dùng thực tế lại vô cùng đa dạng:

• Người lớn tuổi
• Người dùng không rành máy tính
• Người cần hỗ trợ tiếp cận đặc biệt
• Người dùng theo cảm tính, không logic

Nếu không kiểm soát, thiên kiến “người giống tôi” sẽ tạo ra khoảng cách nguy hiểm giữa người thiết kế và người sử dụng.

Giải pháp: tiếp xúc thật – thiết kế thật

Cách duy nhất để tránh bẫy này là:

Tiếp xúc thường xuyên, thật sự, và liên tục với người dùng.

Không phải chỉ phỏng vấn 1–2 lần rồi tự “suy diễn”, mà là:

• Quan sát cách họ thao tác
• Lắng nghe khó khăn thực tế
• Đặt bản thân vào tình huống sử dụng của họ
• Tạo mẫu – kiểm thử – lặp lại – điều chỉnh dựa trên phản hồi thực

Điều quan trọng: tiếp xúc này cần xuyên suốt cả vòng đời dự án, không phải giai đoạn đầu hay cuối.

Ghi nhớ: “Thiết kế cho người giống mình” là dễ – nhưng “thiết kế cho người khác mình” mới tạo ra phần mềm đột phá.

Giả định người dùng đã biết

Tưởng người dùng biết – và cái giá của sự tự tin quá mức

Là người làm kỹ thuật, chúng ta sống trong thế giới đầy biệt ngữ, công cụ, quy trình và từ viết tắt. Theo thời gian, ta hấp thụ những khái niệm đó đến mức không còn thấy chúng là “lạ” nữa.

Nhưng đối với người dùng, đó là một ngôn ngữ hoàn toàn xa lạ.

Giả định hiểu biết – con dao hai lưỡi

Ta thường nghĩ người dùng:

• Biết hệ thống hoạt động thế nào
• Hiểu các thuật ngữ cơ bản như “tài khoản”, “xác thực”, “lưu tạm”
• Biết vì sao cần thực hiện bước A trước khi đến bước B

Nhưng thực tế:

• Người dùng thường không hiểu vì sao mọi thứ diễn ra
• Họ làm theo thói quen, cảm tính, hoặc thử sai
• Và họ rất dễ thất vọng, bỏ cuộc, hoặc làm sai thao tác

Rào cản ngôn ngữ = rào cản trải nghiệm

Khi ta không dùng ngôn ngữ người dùng hiểu:

• Người dùng ngại hỏi, dẫn đến thao tác sai
• Giao diện trở nên mơ hồ, thiếu thân thiện
• Phần mềm dù “đúng chức năng” vẫn gây khó chịu và bỏ rơi người dùng

Giải pháp: chuyển từ “giả định” sang “lắng nghe”

Cần thực hiện các nguyên tắc:

Nguyên tắc	Giải thích ngắn gọn
Ngôn ngữ đơn giản, dễ hiểu	Tránh thuật ngữ nội bộ, ưu tiên từ ngữ phổ thông
Kiểm tra giao diện bằng “mắt người lạ”	Cho người chưa từng dùng thử xem họ hiểu gì
Hướng dẫn rõ ràng từng bước	Giải thích ngắn gọn các thao tác không hiển nhiên
Phản hồi theo hành vi người dùng	Hệ thống cần giải thích mỗi khi có lỗi, không im lặng

Mô hình tinh thần

Một người lái xe lần đầu đến thành phố mới có thể cảm thấy choáng ngợp. Nhưng nếu họ nhìn thấy bản đồ, họ sẽ dần hình dung được nên rẽ trái hay rẽ phải để đến đích. Khi dùng phần mềm, người dùng cũng như vậy – họ cần có một “bản đồ trong đầu” để đoán biết điều gì sẽ xảy ra sau mỗi thao tác.

Đó chính là mô hình tinh thần (mental model).

Cách mô hình tinh thần hình thành

Người dùng xây dựng mô hình tinh thần dựa trên:

• Kinh nghiệm cá nhân (đã từng dùng app tương tự chưa?)
• Biểu tượng, vị trí, màu sắc (nút màu xanh = chấp nhận, nút đỏ = hủy)
• Sự nhất quán (mọi trang web đều có logo ở góc trái trên → nghĩ rằng nhấp vào sẽ quay về trang chủ)

Điều quan trọng là: mô hình này được hình thành một cách vô thức, không cần giải thích.

Mô hình sai vẫn có tác động thật

• Người dùng không cần hiểu hết hệ thống, nhưng họ vẫn hành động dựa trên những gì họ nghĩ là sẽ xảy ra.
• Nếu hệ thống phản hồi đúng như kỳ vọng, họ cảm thấy dễ dùng.
• Nếu khác với mô hình tinh thần họ có:
  • Họ thấy “rối”, “khó hiểu”
  • Họ dễ kết luận “phần mềm này dở”

Mô hình của người phát triển có vấn đề gì?

Người thiết kế thường có:

• Kiến thức nội bộ, cấu trúc hệ thống
• Hiểu rõ luồng dữ liệu – nhưng lại không nhìn từ góc độ người thao tác thực tế

Kết quả là:

• Thiết kế theo logic hệ thống, chứ không phải logic hành vi
• Tạo ra giao diện khó hiểu với người không quen

Mục tiêu của thiết kế UX đúng đắn:

Không phải bắt người dùng thay đổi cách nghĩ
→ Mà là điều chỉnh hệ thống để phù hợp với mô hình tinh thần của người dùng.

Ví dụ thực tiễn:

Tình huống người dùng nghĩ	Hành động họ làm	Nếu thiết kế tốt thì…	Nếu thiết kế sai thì…
“Tôi nhấn nút 💾 là lưu lại”	Nhấn biểu tượng đĩa mềm	Dữ liệu được lưu, có xác nhận	Không có gì xảy ra → mất dữ liệu
“Tôi tìm nút gửi ở góc dưới bên phải”	Nhìn góc phải để gửi mail	Gửi mail thành công	Không tìm thấy → rối, bực, bỏ cuộc
“Tôi kéo ảnh vào khung là tải lên”	Kéo & thả ảnh vào trang	Ảnh được upload và hiển thị	Không có gì xảy ra → cho rằng lỗi hệ thống

Làm thế nào để thiết kế dựa trên mô hình tinh thần người dùng?

1. Quan sát hành vi thực tế thay vì chỉ hỏi
2. Sử dụng mô hình quen thuộc (giao diện phổ biến, biểu tượng dễ hiểu)
3. Giữ sự nhất quán giữa các chức năng
4. Kiểm thử với người thật, không chỉ đồng nghiệp kỹ thuật
5. Tránh gây bất ngờ không cần thiết

Ghi nhớ: Thiết kế hiệu quả là khi người dùng không cần học – chỉ cần đoán – mà vẫn dùng được đúng.

Xây dựng mô hình tinh thần – Building a Mental Model

ếu bạn đã từng dùng Microsoft Word, lần đầu mở Excel bạn vẫn có thể:

• Tìm thấy nút “Lưu”
• Biết tab “Home” chứa các tính năng định dạng
• Dự đoán rằng Ctrl+Z sẽ hoàn tác thao tác

Bạn làm được điều đó vì bạn đã có mô hình tinh thần từ trải nghiệm trước đó, và phần mềm mới củng cố hoặc tái sử dụng những yếu tố quen thuộc ấy.

Mục tiêu của nhà thiết kế UX là: xây dựng giao diện giúp người dùng đoán đúng ngay cả khi chưa được dạy.

🧠 Người dùng đoán – chứ không học

Trong thực tế, người dùng hiếm khi đọc tài liệu hướng dẫn, họ:

• Đoán chức năng từ biểu tượng
• Tìm kiếm theo vị trí quen thuộc
• Làm thử và quan sát phản hồi

Nếu hệ thống hành xử đúng như họ đoán, họ thấy “dễ dùng”.
Nếu hệ thống phản hồi khác kỳ vọng, họ thấy “khó dùng”, “bực mình”, “lỗi”.

🔎 Các yếu tố giúp người dùng xây dựng mô hình tinh thần

Nguồn mô hình	Ví dụ thực tế
Kinh nghiệm trước đó	Từng dùng Gmail, nên kỳ vọng mọi email có nút Gửi ở góc phải
Phần mềm tương tự	Dùng Photoshop → quen thao tác bằng layer, nên tìm layer ở app khác
Nguyên lý Gestalt (gần nhau là liên quan)	Nhóm các nút căn lề lại gần nhau → người dùng biết chúng cùng chức năng
Gợi ý trực quan (icon)	Biểu tượng máy in → chắc chắn là in chứ không phải tải về
Tổ chức giao diện nhất quán	Menu ở bên trái, logo góc trên → người dùng dễ định hướng

🛠 Làm sao để thiết kế giúp người dùng xây dựng mô hình tinh thần hiệu quả?

1. Tận dụng biểu tượng phổ biến (universal icons)
   • Không “sáng tạo” quá đà làm người dùng đoán sai
2. Nhất quán trong bố cục, vị trí, hành vi
   • Không đổi vị trí nút “Lưu” mỗi màn hình
3. Nhóm chức năng liên quan lại gần nhau
   • Dễ giúp người dùng nhận diện “cụm chức năng”
4. Sử dụng màu sắc & hiệu ứng trực quan để tăng đoán đúng
   • Nút “Xóa” nên có màu đỏ → cảnh báo

📌 Tóm tắt bài học chính

Kết luận	Hành động thiết kế nên làm
Người dùng hành động dựa trên mô hình tinh thần	Thiết kế giao diện giúp mô hình này hình thành nhanh và đúng
Không cần hiểu toàn bộ để dùng được	Chỉ cần có đủ gợi ý và sự nhất quán để đoán đúng
Mô hình tinh thần giúp giảm học hỏi	Tăng hiệu quả sử dụng, giảm thời gian đào tạo

💬 Ghi nhớ: Giao diện tốt giống như một người bạn quen thuộc – bạn không cần được giới thiệu, nhưng vẫn biết phải làm gì.

Skeuomorphism – Cầu nối giữa thế giới số và thế giới thật

Bạn đã từng thấy biểu tượng chiếc đĩa mềm để lưu file? Dù phần lớn người dùng ngày nay chưa bao giờ dùng đĩa mềm thật, họ vẫn biết đó là nút “Lưu”.

Đó chính là hiệu ứng của Skeuomorphism – một nguyên lý thiết kế giao diện dựa trên việc mô phỏng hình ảnh, vật thể quen thuộc trong thế giới vật lý, nhằm giúp người dùng dễ hiểu và dễ đoán hành vi của phần mềm.

💡 Tại sao skeuomorphism lại hiệu quả?

• Con người học qua hình ảnh và trải nghiệm thực tế. Khi thấy một biểu tượng giống vật thật, họ liên tưởng ngay đến chức năng của nó, không cần học lại từ đầu.
• Điều này rút ngắn thời gian học phần mềm mới, đặc biệt cho:
  • Người dùng phổ thông
  • Người không quen công nghệ
  • Người lớn tuổi

🖼 Ví dụ skeuomorphism trong phần mềm:

Biểu tượng / hình ảnh	Mô phỏng vật gì ngoài đời	Người dùng sẽ hiểu là…
📁 Thư mục màu vàng	Bìa hồ sơ giấy	Nơi lưu trữ tập tin
💾 Đĩa mềm	Thiết bị lưu trữ cũ	Lưu dữ liệu
✏️ Bút chì	Dụng cụ viết	Chỉnh sửa nội dung
🗑️ Thùng rác	Thùng rác văn phòng	Xóa dữ liệu
Nút tròn xoay âm lượng	Núm vặn trên radio	Điều chỉnh âm lượng
Góc giấy bị gập	Tờ giấy vật lý	Có thể lật/trang tiếp theo

---

🎮 Skeuomorphism trong thiết kế vật lý và trò chơi

• Trong game hoặc app giải trí:
  • Kéo cần → bật/tắt thiết bị
  • Vuốt → giống hành động ngoài đời thật (lật sách, mở cửa…)
• Trong ứng dụng media:
  • Chạm nhẹ → phát nhạc
  • Vuốt ngang → chuyển bài

Những thiết kế này dựa vào hành vi vật lý quen thuộc → làm cho trải nghiệm người dùng trở nên tự nhiên và mượt mà.

⚖️ Skeuomorphism và xu hướng hiện đại:

Quan điểm tích cực	Quan điểm tiêu cực
Dễ hiểu với người mới	Có thể “lỗi thời”, gây rối
Gợi liên tưởng quen thuộc	Khó thiết kế nhất quán nếu mô phỏng quá thật
Tăng tính cảm xúc	Không phù hợp với thiết kế tối giản (flat)

Trong thực tế, nhiều hệ thống hiện nay kết hợp skeuomorphism ở mức vừa đủ, gọi là flat design with affordances – giữ lại biểu tượng dễ hiểu, nhưng loại bỏ hiệu ứng đổ bóng, 3D rườm rà.

📌 Tóm tắt bài học chính:

Nội dung	Ý nghĩa
Skeuomorphism là gì	Thiết kế mô phỏng hình ảnh hoặc hành vi vật lý ngoài đời
Lợi ích chính	Giúp người dùng đoán đúng hành vi phần mềm mà không cần học lại
Cách áp dụng hiệu quả	Dùng biểu tượng dễ hiểu, quen thuộc, không quá “đồ họa nặng”
Cảnh báo	Tránh làm quá mức → rối mắt, lỗi thời

💬 Ghi nhớ: Thiết kế tốt không cần phải hiện đại nhất – chỉ cần khiến người dùng cảm thấy “quen thuộc ngay từ lần đầu tiên”. Skeuomorphism là một công cụ mạnh mẽ để đạt điều đó.

Chân dung người dùng – Personas

Trong quá trình thiết kế, cụm từ “người dùng” thường được dùng quá chung chung. Nhưng “người dùng” là ai? Họ bao nhiêu tuổi? Họ sợ điều gì? Họ dùng phần mềm vào lúc nào và ở đâu?

Personas chính là cách biến người dùng vô hình thành nhân vật cụ thể – sống động – có hoàn cảnh, nhu cầu, và hành vi.

👤 Persona là gì?

• Là một hồ sơ nhân vật hư cấu, mô tả một người đại diện cho một nhóm người dùng mục tiêu.
• Persona không phải là người thật, nhưng phải đủ thực tế để nhóm phát triển tin tưởng và dùng làm kim chỉ nam thiết kế.

---

🎯 Persona trả lời 3 câu hỏi cốt lõi:

1. Người dùng của tôi là ai? (hành vi, vai trò, năng lực)
2. Họ muốn đạt được điều gì? (mục tiêu, động lực)
3. Điều gì cản trở họ? (nỗi sợ, trở ngại, giới hạn)

---

📋 Persona thường bao gồm:

Thành phần	Ví dụ
Tên, tuổi, giới tính	Minh, 38 tuổi, nam
Vai trò và công việc	Nhân viên chăm sóc khách hàng tại công ty điện máy
Mục tiêu	Muốn xử lý yêu cầu nhanh, không cần thao tác phức tạp
Khó khăn	Không rành công nghệ, ghét giao diện nhiều bước
Môi trường sử dụng	Làm việc tại quầy lễ tân, đông người, màn hình nhỏ
Vấn đề tiếp cận (accessibility)	Thị lực yếu, không nhìn rõ chữ nhỏ

---

🧑‍🤝‍🧑 Tại sao cần nhiều persona?

• Không một người dùng nào giống người khác hoàn toàn.
• Một sản phẩm có thể phục vụ:
  • Người dùng mới bắt đầu
  • Người dùng chuyên sâu
  • Người lớn tuổi
  • Người có giới hạn thể chất

→ Do đó, cần xây dựng tập hợp persona để đảm bảo thiết kế không bỏ sót nhóm người dùng quan trọng.

---

📌 Lợi ích khi dùng persona:

Lợi ích	Ý nghĩa thực tế
Gắn khuôn mặt cho người dùng	Nhóm phát triển dễ liên hệ và thấu cảm hơn
Tập trung vào nhu cầu thật	Thiết kế giải quyết mục tiêu cụ thể thay vì “đoán mò”
Giảm tranh cãi nội bộ	Mọi người cùng hướng đến một mẫu người dùng được xác định
Hỗ trợ xây dựng use-case	Kịch bản sử dụng cụ thể hơn, thực tế hơn
Thay thế cho kiểm thử tạm thời	Có thể diễn vai (roleplay) trước khi có người dùng thật

---

⚠️ Rủi ro nếu dùng persona sai cách:

Sai lầm	Hậu quả
Dựa trên giả định cá nhân	Thiết kế lệch thực tế, phục vụ “ảo tưởng” chứ không phải người thật
Stereotype (rập khuôn)	Ví dụ: “phụ nữ thì thích màu hồng”, “người già thì kém công nghệ”
Không có dữ liệu hỗ trợ	Mất niềm tin từ nhóm phát triển
Quá sơ sài hoặc quá dài dòng	Không ai muốn đọc hoặc sử dụng

---

🛠 Cách xây dựng persona hiệu quả:

1. Phỏng vấn người dùng thật
2. Tổng hợp đặc điểm lặp lại
3. Gắn thành một nhân vật cụ thể
4. Kiểm tra: nhân vật đó có “thật” không? có logic không?
5. Chia sẻ trong nhóm và cập nhật định kỳ

---

💬 Ghi nhớ: Persona không phải chỉ là tài liệu để in ra treo tường – đó là “đại diện” cho người mà bạn đang xây dựng phần mềm cho họ.

Dùng hay không dùng Persona? Cân nhắc giữa hiệu quả và sai lệch

Khi nào nên dùng Personas?

1. Nhân hóa người dùng trừu tượng

Trong quá trình phát triển phần mềm, “người dùng” thường là một khái niệm… vô hình. Personas giúp gắn mặt, tên, hành vi và cảm xúc cho nhóm người dùng ấy.

→ Khi ta nhắc đến “Lan, nhân viên bán hàng, 42 tuổi, làm ca tối, không rành công nghệ” – mọi người dễ hình dung hơn “người dùng cấp thấp”.

2. Tập trung mục tiêu thiết kế

Mỗi persona đại diện cho một nhu cầu cụ thể, giúp cả nhóm:

• Tập trung vào mục tiêu chính (end goal)
• Không bị sao nhãng bởi tính năng râu ria
• Tránh tranh cãi vì đã có “người thật” làm chuẩn

3. Xây dựng đồng thuận nội bộ

Personas tạo ra một điểm tham chiếu chung cho toàn nhóm (dev, design, QA, marketing…):

• Khi cần ra quyết định, ta hỏi: “Lan sẽ dùng tính năng này thế nào?”
• Cả nhóm hiểu “người mà mình đang phục vụ” là ai

4. Thay thế kiểm thử sơ bộ bằng diễn vai (role-play)

Trước khi có người dùng thật để test, ta có thể diễn vai persona để:

• Kiểm tra giao diện, hành vi
• Dự đoán phản ứng
• Phát hiện lỗi logic trong luồng thao tác

Khi nào KHÔNG nên dùng Personas? – Những rủi ro cần tránh

1. Persona dựa trên tưởng tượng, không có dữ liệu

Persona mà chỉ được “nghĩ ra” trong phòng họp thì không đại diện cho ai cả.

→ Điều này khiến:

• Thiết kế đi sai hướng
• Cả nhóm không tôn trọng hoặc sử dụng persona
• Dẫn đến “thiết kế tự thỏa mãn” (self-referential design)

2. Thiếu nghiên cứu, dễ tạo ra định kiến

Nếu không nghiên cứu kỹ:

• Persona dễ bị rập khuôn (stereotype): “người già thì không thích công nghệ”
• Thiết kế dễ loại trừ nhóm yếu thế

3. Yêu cầu sự tin tưởng thật sự từ cả nhóm

Một persona chỉ có hiệu quả khi:

• Cả team “tin rằng” nhân vật này đại diện cho người dùng thật
• Persona được nhắc đến trong quá trình ra quyết định

Nếu không, persona chỉ là tài liệu “có cho có”, bị quên lãng.

4. Tài liệu quá dài, không ai đọc

Một persona có thể dày đặc thông tin, nhưng:

• Nếu viết quá dài, khó nhớ
• Nếu thiếu hình ảnh, không truyền cảm hứng
  → Dễ bị bỏ qua, không được dùng đúng cách

Giải pháp cân bằng:

Sai lầm cần tránh	Giải pháp đề xuất
Tạo persona không dựa vào dữ liệu thật	Dùng khảo sát, phỏng vấn, giấy mẫu, hành vi thực
Viết persona dài dòng, khó sử dụng	Trình bày trực quan, ngắn gọn, có hình ảnh
Để persona “chết yểu” sau khi tạo	Tích hợp vào mọi quyết định thiết kế & kiểm thử
Dựa trên cảm tính cá nhân	Có cơ sở thống kê, kiểm tra chéo giữa các nhóm

---

💬 Ghi nhớ: Personas chỉ thực sự hiệu quả nếu được xây dựng từ người dùng thật, được tin tưởng bởi cả nhóm, và được sử dụng xuyên suốt quá trình phát triển.

Kết luận

• Thiết kế lấy người dùng làm trung tâm đặt người dùng vào trung tâm của sản phẩm
• Dựa vào động lực và mô hình tinh thần để hiểu người dùng
• Personas là công cụ mạnh mẽ (nhưng cần dùng cẩn trọng) để thiết kế phù hợp
• Mẫu giấy (paper prototype) sẽ là công cụ giúp ta phát hiện và hoàn thiện personas