Mở đầu — vì sao bài này quan trọng
Trong hầu hết các dự án UX, chúng ta quen với vai trò "người dùng là đối tượng nghiên cứu": ta phỏng vấn họ, quan sát họ, test sản phẩm với họ. Người dùng cung cấp dữ liệu, còn nhà thiết kế mới là người ra quyết định. Participatory Design (Thiết kế có sự tham gia, hay còn gọi là Co-design/Co-creation) lật ngược mối quan hệ đó một cách căn bản: người dùng không còn là "đối tượng" mà trở thành đồng thiết kế viên — ngồi cùng bàn, cầm bút, dán giấy nhớ và trực tiếp định hình giải pháp.
Đây không phải là một phương pháp "cho vui" hay để làm màu marketing. Với những sản phẩm phục vụ nhóm người dùng có bối cảnh rất đặc thù mà nhà thiết kế khó lòng thấu hiểu hết — bác sĩ trong phòng cấp cứu, nông dân dùng app nông nghiệp, người khiếm thị, công nhân vận hành máy — thì việc mời họ vào quá trình thiết kế thường là con đường ngắn nhất để tránh những sai lầm ngớ ngẩn mà cả một đội design giỏi ngồi trong văn phòng máy lạnh cũng không bao giờ nghĩ ra.
Trong khóa học này, bạn đã học nhiều phương pháp để lắng nghe và quan sát người dùng (phỏng vấn, contextual inquiry, diary study...). Participatory Design là bước tiến xa hơn: bạn cùng làm với họ. Hiểu đúng bản chất và biết khi nào nên dùng nó sẽ giúp bạn trở thành một nhà nghiên cứu UX trưởng thành hơn, biết cách chia sẻ quyền lực thiết kế thay vì độc quyền nó.
Khái niệm cốt lõi
Nguồn gốc: từ nhà máy Scandinavia những năm 1970
Participatory Design ra đời ở Bắc Âu (Scandinavia) vào thập niên 1970, trong bối cảnh khá đặc biệt: các công đoàn lao động lo ngại rằng làn sóng máy tính hóa nơi làm việc sẽ tước đi quyền tự chủ và kỹ năng của công nhân. Thay vì để giới quản lý và kỹ sư áp đặt hệ thống mới từ trên xuống, các nhà nghiên cứu như Kristen Nygaard và các dự án nổi tiếng như UTOPIA (hợp tác giữa các nhà nghiên cứu và công nhân ngành in) đã đưa chính người lao động vào quá trình thiết kế công cụ mà họ sẽ dùng hàng ngày.
Nền tảng tư tưởng ở đây mang tính dân chủ tại nơi làm việc (workplace democracy): những người bị ảnh hưởng bởi một quyết định thiết kế có quyền tham gia vào quyết định đó. Đây là điểm khác biệt triết học quan trọng — Participatory Design không chỉ là một kỹ thuật thu thập dữ liệu, mà mang trong mình một quan điểm về quyền lực và sự công bằng.
Tiền đề cốt lõi: người dùng là chuyên gia trong bối cảnh của họ
Trái tim của Participatory Design nằm ở một niềm tin đơn giản mà sâu sắc: người dùng là chuyên gia số một về chính bối cảnh, công việc và cuộc sống của họ. Bạn — nhà thiết kế — có thể là chuyên gia về giao diện, về công nghệ, về nguyên tắc thẩm mỹ. Nhưng bạn sẽ không bao giờ hiểu rõ bằng một y tá trưởng về việc chị ấy phải xoay xở thế nào giữa 30 bệnh nhân trong ca trực đêm, hay bằng một tiểu thương chợ Bến Thành về cách chị ấy quản lý sổ nợ khách quen.
Vì vậy, thay vì cố "khai thác" kiến thức đó qua phỏng vấn (vốn dễ bị thất thoát và diễn giải sai), Participatory Design mời người dùng trực tiếp thể hiện kiến thức đó thông qua hành động thiết kế: vẽ, sắp xếp, dựng mô hình, đóng vai.
Phân biệt với các phương pháp khác (rất quan trọng)
Nhiều học viên nhầm lẫn Participatory Design với usability testing hay phỏng vấn nhóm. Hãy phân biệt rõ:
- Usability testing: người dùng sử dụng một thiết kế đã có sẵn, ta quan sát để đánh giá. Vai trò của họ là người đánh giá.
- Phỏng vấn/Focus group: người dùng nói về nhu cầu, ý kiến. Vai trò của họ là người cung cấp thông tin.
- Participatory Design: người dùng tạo ra giải pháp cùng bạn. Vai trò của họ là đồng tác giả.
Các "công cụ" đặc trưng
Participatory Design cần những công cụ dễ tiếp cận để người không chuyên vẫn tham gia được:
- Toolkit giấy, sticker, thẻ, khối lego, giấy nhớ: để người dùng dựng bố cục màn hình hoặc quy trình mà không cần biết Figma.
- Design games: các "trò chơi thiết kế" có luật lệ, ví dụ phát cho mỗi nhóm một bộ thẻ tính năng và yêu cầu họ ưu tiên, sắp xếp thành một hành trình.
- Velcro modeling / Paper prototyping: người dùng tự ghép các mảnh giao diện lại thành màn hình họ mong muốn.
- Bodystorming / role-play: đóng vai để diễn lại một tình huống dịch vụ, từ đó phát hiện điểm nghẽn.
Tình huống thực tế
Ví dụ 1: Bệnh viện Nhi Đồng và app quản lý lịch tái khám
Một startup HealthTech giả định tên MedCare ở TP.HCM muốn xây app giúp phụ huynh quản lý lịch tái khám cho con tại một bệnh viện nhi. Ban đầu, đội design (5 người, đều dưới 30 tuổi, chưa ai có con nhỏ) thiết kế một app với dòng thời gian đẹp, thông báo push hiện đại, tích hợp lịch điện tử.
Sau 3 vòng usability test mà tỷ lệ hoàn thành tác vụ vẫn dưới 50%, họ quyết định chuyển sang một workshop co-design. Họ mời 8 phụ huynh (đa dạng độ tuổi, có cả các bà mẹ ở tỉnh lên khám) và 3 y tá điều dưỡng vào một buổi 3 tiếng. Trên bàn là giấy, bút màu, và các thẻ giấy in sẵn từng "mảnh" chức năng.
Diễn giải: Khi được yêu cầu tự "dựng" màn hình chính, một điều bất ngờ xuất hiện — phần lớn phụ huynh lớn tuổi bỏ hoàn toàn tính năng thông báo push (họ không tin và thường tắt), thay vào đó họ dán to một mảnh giấy ghi "gọi điện nhắc" và một mảnh ghi "ghi vào sổ giấy để dán tủ lạnh". Một bà mẹ còn vẽ thêm ô "in phiếu hẹn ra giấy" vì "cầm tờ giấy tới quầy cho nhanh, khỏi loay hoay điện thoại lúc bồng con".
Bài học rút ra: Không một buổi brainstorm nội bộ nào của đội design trẻ tuổi có thể nghĩ ra insight "in ra giấy dán tủ lạnh". Participatory Design không tạo ra thiết kế cuối cùng (app vẫn phải do designer chỉnh chu lại), nhưng nó phơi bày những mô hình tinh thần và thói quen thật mà chỉ người trong cuộc mới có. Kết quả: MedCare thêm tính năng xuất phiếu hẹn dạng in/SMS, và tỷ lệ hoàn thành tác vụ ở vòng test tiếp theo tăng lên 78%.
Ví dụ 2: Ngân hàng số cho tiểu thương chợ truyền thống
Một ngân hàng giả định VietBank Digital muốn ra mắt tính năng "sổ nợ điện tử" nhắm vào tiểu thương chợ truyền thống — nhóm khách hàng vốn quen ghi nợ bằng cuốn sổ tay. Thay vì tự thiết kế, đội UX tổ chức 4 buổi co-design tại chính các sạp hàng ở chợ (Hà Nội và Cần Thơ), mỗi buổi 4-5 tiểu thương.
Họ dùng kỹ thuật "thiết kế lại cuốn sổ": đưa cho tiểu thương một cuốn sổ trắng và các sticker, yêu cầu họ tự thiết kế "cuốn sổ nợ trong mơ". Từ đó chuyển hóa dần sang bản giấy màn hình app.
Diễn giải: Một số phát hiện cực kỳ quan trọng nổi lên. Thứ nhất, tiểu thương không muốn gọi khách hàng là "con nợ" hay dùng từ "nợ xấu" — họ coi khách quen như bạn bè và muốn ngôn ngữ nhẹ nhàng ("khách chưa gửi tiền"). Thứ hai, họ cần chức năng ghi nhanh bằng một tay (tay kia đang bán hàng, cân đồ), nên các nút phải to và nằm ở nửa dưới màn hình để ngón cái với tới. Thứ ba, họ tuyệt đối không muốn khách nhìn thấy màn hình lúc ghi — cần một chế độ "kín đáo".
Bài học rút ra: Những yêu cầu này (ngôn ngữ, thao tác một tay, tính riêng tư xã hội) không phải là "tính năng" theo nghĩa kỹ thuật — chúng là giá trị văn hóa và xã hội ẩn trong công việc. Participatory Design giúp phát hiện chúng vì người dùng được tự do định hình giải pháp theo logic của chính họ, thay vì trả lời trong khung câu hỏi mà designer đã đặt sẵn.
Ví dụ 3: Khi Participatory Design "phản tác dụng" — dự án nội bộ ERP
Không phải lúc nào Participatory Design cũng thành công. Một công ty sản xuất giả định ở Bình Dương muốn triển khai phần mềm quản lý kho mới và mời công nhân kho tham gia co-design. Nhưng buổi workshop thất bại: công nhân im lặng, chỉ gật đầu theo ý quản lý ngồi cùng phòng, và cuối buổi họ "thiết kế" ra đúng những gì sếp muốn.
Diễn giải: Vấn đề nằm ở quyền lực và tâm lý. Sự hiện diện của quản lý khiến công nhân không dám nói thật. Ngoài ra, họ được mời tham gia chỉ để "hợp thức hóa" một quyết định đã có sẵn — đây là dạng "participation-washing" (tham gia hình thức).
Bài học rút ra: Participatory Design chỉ hiệu quả khi có sự an toàn tâm lý và ý định chân thành chia sẻ quyền quyết định. Nếu bạn mời người ta vào bàn nhưng thực chất đã chốt xong mọi thứ, bạn không chỉ lãng phí thời gian mà còn tạo ra sự hoài nghi. Trong tình huống này, giải pháp là tách công nhân khỏi quản lý, có người điều phối trung lập, và cam kết rõ ràng rằng ý kiến của họ sẽ thực sự ảnh hưởng đến sản phẩm.
Hướng dẫn từng bước
Dưới đây là quy trình tổ chức một buổi Participatory Design workshop mà bạn có thể áp dụng ngay:
Bước 1 — Xác định mục tiêu và ranh giới rõ ràng. Trước khi mời ai, hãy trả lời: bạn muốn cùng người dùng khám phá vấn đề (generative) hay cùng dựng giải pháp cho một hướng đã có? Xác định rõ điều gì "để ngỏ" cho họ quyết định và điều gì đã cố định (ràng buộc kỹ thuật, ngân sách). Sự minh bạch này là nền tảng của lòng tin.
Bước 2 — Tuyển đúng người tham gia. Chọn người dùng thật, đa dạng về hồ sơ (tuổi, mức độ thành thạo công nghệ, hoàn cảnh). Thông thường 6-8 người là lý tưởng cho một buổi. Cân nhắc kỹ ai không nên ngồi chung (ví dụ cấp trên và cấp dưới) để tránh áp lực quyền lực.
Bước 3 — Chuẩn bị toolkit dễ tiếp cận. Chuẩn bị vật liệu low-fidelity: giấy, bút màu, sticker, thẻ chức năng in sẵn, giấy nhớ, kéo, keo. Nguyên tắc vàng: công cụ càng "thô sơ" thì người không chuyên càng dám dùng. Đừng bao giờ mở Figma trong buổi co-design với người dùng phổ thông.
Bước 4 — Khởi động và tạo an toàn tâm lý. Bắt đầu bằng hoạt động phá băng nhẹ nhàng. Nhấn mạnh: "Ở đây không có câu trả lời đúng/sai, chúng tôi cần chính kiến thức của anh/chị." Khẳng định vai trò đồng thiết kế của họ.
Bước 5 — Chạy hoạt động co-design chính. Dùng một cấu trúc rõ ràng: ví dụ chia nhóm nhỏ, phát toolkit, ra đề bài cụ thể ("Hãy dựng màn hình đầu tiên anh/chị muốn thấy khi mở app"). Người điều phối đi vòng quanh, đặt câu hỏi "tại sao anh/chị đặt cái này ở đây?" thay vì gợi ý giải pháp.
Bước 6 — Chia sẻ và thảo luận. Mỗi nhóm/cá nhân trình bày sản phẩm của mình. Đây là lúc vàng để thu thập lý do đằng sau mỗi lựa chọn — chính phần "tại sao" mới là insight, không phải bản vẽ.
Bước 7 — Tổng hợp và diễn giải (việc của designer). Sau buổi workshop, đội design phải tổng hợp. Lưu ý: đừng bê nguyên bản vẽ của người dùng thành thiết kế cuối. Nhiệm vụ của bạn là diễn giải các mô hình tinh thần, nhu cầu và giá trị ẩn sau đó, rồi biến thành thiết kế chuyên nghiệp.
Bước 8 — Đóng vòng lặp (đạo đức tham gia). Quay lại báo cho người tham gia biết ý kiến của họ đã ảnh hưởng thế nào đến sản phẩm. Điều này thể hiện sự tôn trọng và duy trì mối quan hệ cho những lần sau.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm "để người dùng thiết kế" với "để người dùng quyết định mọi thứ". Người dùng giỏi thể hiện vấn đề và nhu cầu, nhưng họ thường không phải chuyên gia về giải pháp tối ưu. Nếu bạn triển khai y nguyên bản vẽ của họ, kết quả thường lộn xộn. Mẹo: Coi sản phẩm của người dùng là "dữ liệu về mong muốn", không phải "bản đặc tả thiết kế".
Lỗi 2 — Tham gia hình thức (participation-washing). Mời người dùng vào chỉ để hợp thức hóa quyết định đã chốt. Mẹo: Trước buổi workshop, tự hỏi thành thật "nếu người dùng đề xuất hướng khác hẳn, mình có sẵn sàng thay đổi không?". Nếu câu trả lời là không, thì đừng làm co-design, hãy làm usability test cho trung thực.
Lỗi 3 — Trộn lẫn các cấp bậc quyền lực trong cùng một phòng. Như ví dụ ERP ở trên, sự hiện diện của cấp trên bóp nghẹt tiếng nói thật. Mẹo: Tách nhóm theo vai trò, dùng người điều phối trung lập.
Lỗi 4 — Công cụ quá "cao cấp". Đưa laptop, phần mềm thiết kế cho người không chuyên khiến họ e ngại và thụ động. Mẹo: Càng thô sơ (giấy, bút) càng dân chủ hóa được sự tham gia.
Lỗi 5 — Không chuẩn bị người điều phối đủ tinh tế. Facilitator dẫn dắt quá tay sẽ vô tình "mớm" ý mình. Mẹo: Người điều phối chỉ hỏi "tại sao" và "kể thêm đi", tuyệt đối tránh "hay là anh/chị thử làm thế này?".
Mẹo bối cảnh Việt Nam: Với văn hóa Á Đông thường ngại phản biện trực tiếp và nể người có vị thế, hãy đặc biệt đầu tư vào việc tạo an toàn tâm lý. Các hoạt động "làm bằng tay" (vẽ, dán) lại rất hữu ích vì chúng giúp người tham gia thể hiện ý kiến qua hành động thay vì phải nói thẳng — giảm áp lực xã hội đáng kể.
Bài tập thực hành
Bài tập 1 — Thiết kế một buổi co-design mini. Chọn một sản phẩm/dịch vụ số quen thuộc (ví dụ: app đặt đồ ăn, app ngân hàng). Viết một kế hoạch workshop co-design 90 phút: mục tiêu, ai bạn sẽ mời (và ai bạn tránh mời chung phòng), toolkit gì, và 2 hoạt động chính. Nêu rõ điều gì "để ngỏ" cho người dùng quyết định.
Bài tập 2 — Thực hành phân biệt vai trò. Cho 3 tình huống nghiên cứu bất kỳ, hãy xác định: tình huống nào phù hợp Participatory Design, tình huống nào chỉ cần usability test hoặc phỏng vấn? Giải thích lý do dựa trên "người dùng cần đóng vai trò gì".
Bài tập 3 — Diễn giải, không sao chép. Giả sử trong một buổi co-design, người dùng vẽ một màn hình có 12 nút bấm chen chúc. Hãy viết ra 3 nhu cầu ẩn có thể suy ra từ bản vẽ đó, và mô tả bạn sẽ chuyển hóa chúng thành một thiết kế chuyên nghiệp như thế nào (thay vì bê nguyên 12 nút vào sản phẩm).
Bài tập 4 — Tự vấn về đạo đức. Viết một đoạn ngắn trả lời: "Trong dự án gần nhất của tôi, nếu tôi mời người dùng co-design, liệu tôi có thực sự sẵn sàng thay đổi hướng thiết kế theo họ không?" Trung thực với chính mình.
Tóm tắt
Participatory Design (Co-creation) là phương pháp mời người dùng trở thành đồng thiết kế viên, dựa trên tiền đề cốt lõi: người dùng là chuyên gia trong bối cảnh của chính họ. Ra đời từ phong trào dân chủ nơi làm việc ở Scandinavia những năm 1970, nó mang trong mình cả một quan điểm về quyền lực — chuyển từ "thiết kế cho" sang "thiết kế cùng" người dùng.
Điểm khác biệt then chốt so với usability test hay phỏng vấn: người dùng không đánh giá hay cung cấp thông tin, mà trực tiếp tạo ra giải pháp qua các công cụ thô sơ, dễ tiếp cận (giấy, sticker, design games, role-play). Sức mạnh lớn nhất của phương pháp là phơi bày những mô hình tinh thần, thói quen và giá trị văn hóa ẩn mà đội design khó lòng tự nghĩ ra — như insight "in phiếu hẹn dán tủ lạnh" hay "ghi nợ bằng một tay, kín đáo".
Nhưng hãy nhớ ba điều: (1) người dùng giỏi thể hiện nhu cầu, còn diễn giải và tinh chỉnh thành thiết kế vẫn là việc của bạn; (2) phương pháp chỉ hiệu quả khi có an toàn tâm lý và ý định chân thành chia sẻ quyền quyết định — nếu không, nó biến thành "tham gia hình thức" vô nghĩa; (3) luôn đóng vòng lặp, báo lại cho người tham gia rằng tiếng nói của họ đã được lắng nghe. Nắm vững Participatory Design, bạn không chỉ có thêm một phương pháp, mà còn trưởng thành hơn trong tư duy: biết khi nào nên khiêm tốn chia sẻ chiếc bút thiết kế với chính những người sẽ sống cùng sản phẩm của bạn.