منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا · مرداد ۱۴۰۵ · زمان مطالعه: حدود ۱۱ دقیقه

طراحی مشارکتی (Participatory Design) چیست؟

💡 این متن «بازنویسی آزاد» است: ایده‌ها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثال‌های تازه بازگو شده‌اند و ترجمهٔ کلمه‌به‌کلمه نیست. بخش‌های افزودهٔ مترجم در جعبهٔ منبع مشخص شده‌اند.

طراحی مشارکتی (Participatory Design) رویکردی است که در آن کاربران نهایی نه فقط موضوع پژوهش، بلکه عضو فرایند طراحی‌اند: در جلسهٔ ایده‌پردازی حاضرند، روی گزینه‌ها نظر می‌دهند، و در بهترین شکلش در تصمیم سهم دارند.

تفاوتش با آنچه بیشتر تیم‌ها انجام می‌دهند در یک حرف اضافه خلاصه می‌شود: طراحی برای کاربر در برابر طراحی با کاربر. در حالت اول — که همان طراحی کاربرمحور است — کاربر در ابتدا مصاحبه می‌شود و در انتها روی نمونهٔ اولیه آزمون می‌دهد؛ بین این دو، اتاق در اختیار تیم است. در طراحی مشارکتی، کاربر در همان اتاق است.

و یک نکتهٔ مهم که معمولاً گم می‌شود: طراحی مشارکتی در اصل یک تکنیک پژوهشی نبوده، یک موضع دربارهٔ قدرت بوده است — این ایده که هرکس از یک سیستم اثر می‌گیرد باید در ساختنش حرفی داشته باشد. اگر این هسته را برداریم، آنچه می‌ماند یک کارگاه برگهٔ چسبان است که اسم قشنگی رویش گذاشته‌اند.

طراحی برای کاربر در برابر طراحی با کاربر

هر دو رویکرد کاربر را جدی می‌گیرند، اما در اینکه کِی او را در اتاق می‌بینند فرق دارند:

مرحله‌ای که این دو را از هم جدا می‌کند مرحلهٔ سوم است. مصاحبه‌کردن با کاربر و آزمون‌گرفتن از او کار سختی نیست و تقریباً همه انجامش می‌دهند؛ چیزی که تیم‌ها بی‌صدا از آن عبور می‌کنند، سهیم‌کردن کاربر در تصمیم است — اینکه چه چیزی ساخته شود، چه چیزی صبر کند، و چه چیزی حذف شود.

یک تفکیک لازم دیگر هم هست: طراحی مشارکتی با گروه کانونی یکی نیست. در گروه کانونی از مردم نظر می‌پرسید؛ در طراحی مشارکتی با آن‌ها چیز می‌سازید. اولی داده تولید می‌کند، دومی طرح. و برخلاف پژوهش زمینه‌ای که در آن شما ناظرِ کار کاربر در محیط خودش هستید، اینجا نقش‌ها عوض می‌شود: کاربر به محیط شما می‌آید تا در ساختن سهم داشته باشد.

ریشه‌ها: اسکاندیناوی و دههٔ ۱۹۷۰

منبع اشاره می‌کند که این رویکرد از کار پژوهشگران اسکاندیناوی در دهه‌های ۱۹۷۰ و ۱۹۸۰ می‌آید. ارزش دارد که این تاریخ کمی بازتر شود، چون بدون آن انگیزهٔ اصلی روش گم می‌شود.

در آن سال‌ها رایانه‌ها داشتند به کارخانه‌ها و چاپخانه‌ها می‌آمدند و پرسش این بود که چه کسی تعیین می‌کند این سیستم‌ها چه شکلی باشند. در نروژ، کریستن نیگارد — از سازندگان زبان Simula — در اوایل دههٔ ۱۹۷۰ با اتحادیهٔ کارگران فلز همکاری کرد تا کارگران بتوانند بر سیستم‌هایی که کارشان را تغییر می‌داد اثر بگذارند. بعدتر پروژهٔ UTOPIA (میانهٔ دههٔ ۱۹۸۰) در سوئد و دانمارک با اتحادیهٔ کارگران گرافیک انجام شد: ابزارهای صفحه‌بندی به‌جای آنکه برای حروف‌چین‌ها طراحی شود، با خودشان طراحی شد.

پس این روش از دل بحث حقوق کار بیرون آمده، نه از دل بازاریابی محصول. همین ریشه توضیح می‌دهد چرا در طراحی مشارکتی اصیل، بحث «چه کسی تصمیم می‌گیرد» این‌قدر مرکزی است. نسخهٔ امروزی‌ترش در محصولات دیجیتال معمولاً «هم‌طراحی» نامیده می‌شود و ملایم‌تر است، اما اگر عنصر سهیم‌شدن در تصمیم را از آن برداریم، از طراحی کاربرمحور معمولی تفکیک‌ناپذیر می‌شود.

نردبان مشارکت: از تزئین تا قدرت واقعی

این بخش افزودهٔ مترجم است و به‌نظرم کاربردی‌ترین ابزار برای صادق‌بودن با خودمان است. شری آرنستاین در ۱۹۶۹ برای مشارکت شهروندی «نردبانی» پیشنهاد کرد که پله‌هایش از مشارکت تصنعی تا قدرت واقعی بالا می‌رود. همان نردبان را می‌شود به طراحی محصول آورد:

• - ۱. اطلاع‌دادن: تصمیم گرفته شده و به کاربر خبر می‌دهید. این مشارکت نیست، اعلان است.
• - ۲. نظرخواهی: نظر می‌گیرید و بعد در پوشه می‌گذارید. همان نظرسنجی‌ای که نتیجه‌اش هیچ‌جا اثر نمی‌گذارد.
• - ۳. حضور در اتاق: کاربر در جلسهٔ ایده‌پردازی هست و به گزینه‌ها شکل می‌دهد، ولی در تصمیم نهایی رأی ندارد. بیشتر تیم‌ها همین‌جا می‌ایستند.
• - ۴. تصمیم مشترک: اختیار واقعی روی سازش‌ها تقسیم می‌شود. معیار سادهٔ این پله این است که کاربر بتواند «نه» بگوید و آن «نه» بماند.
• - ۵. هدایت به‌دست کاربران: جامعهٔ کاربران دستور کار را تعیین می‌کند و تیم مهارت فنی را می‌آورد. کم پیش می‌آید و کند است، اما تنها پله‌ای است که بعد از سردشدن علاقهٔ تیم هم زنده می‌ماند.

فایدهٔ این نردبان تشخیص است، نه قضاوت. پلهٔ سه برای بسیاری از پروژه‌ها انتخاب درست و کافی است؛ مشکل وقتی شروع می‌شود که پلهٔ دو را «طراحی مشارکتی» بنامیم. رایج‌ترین سوءاستفاده از این اصطلاح همین است: برگزاری یک کارگاه برای مشروعیت‌دادن به تصمیمی که از قبل گرفته شده. اگر پیش از کارگاه می‌دانید نتیجه چه خواهد بود، شما مشارکت را اجرا نمی‌کنید، صحنه‌سازی‌اش می‌کنید.

روش‌ها و ابزارها

ابزارهای این کار پیچیده نیستند؛ سختی‌اش در اجرای درست جلسه است:

• - کارگاه هم‌طراحی: ستون اصلی روش. کاربران و تیم با هم روی یک مسئلهٔ مشخص طرح می‌سازند — با کاغذ، اسکچ، یا قطعه‌های آمادهٔ رابط.
• - جعبه‌ابزار مولد: به شرکت‌کننده مصالح می‌دهید (کارت، برچسب، شکل‌های آماده) تا چیزی بسازد که نمی‌تواند در قالب حرف بیانش کند. برای موضوعاتی که کاربر واژه‌اش را ندارد بهترین راه است.
• - نمونهٔ اولیهٔ کم‌هزینه: هرچه ابزار خام‌تر باشد، شرکت‌کننده راحت‌تر نقدش می‌کند. طرح تمیز و رنگی، نقد را خفه می‌کند چون به‌نظر «تمام‌شده» می‌آید.
• - دسته‌بندی کارت و نقشه‌کردن تجربه: برای اینکه ساختار و مسیر از زبان خود کاربر بیرون بیاید.
• - دفترچهٔ روزانه: پیش از کارگاه به شرکت‌کننده‌ها بدهید تا با مشاهدات دست‌اول بیایند، نه با حافظهٔ کلی.
• - تخته‌های اشتراکی آنلاین: جلسهٔ دورکار را ممکن می‌کنند، به‌شرط اینکه ابزار برای شرکت‌کنندهٔ غیرمتخصص سبک باشد. اگر ده دقیقهٔ اول جلسه صرف آموزش ابزار شود، بخشی از انرژی مشارکت را همان‌جا سوزانده‌اید.

مهم‌تر از انتخاب ابزار، کسی است که جلسه را می‌گرداند. تسهیل‌گر در طراحی مشارکتی سه کار دارد که هیچ ابزاری جای‌شان را نمی‌گیرد: نگه‌داشتن تمرکز روی مسئله وقتی بحث به راه‌حل‌های دلخواه می‌پرد، بازکردن فضا برای کسی که ساکت مانده — چون در هر گروهی دو سه نفر طبیعتاً بیشتر حرف می‌زنند — و صریح‌کردن سازش‌ها. جملهٔ کلیدی تسهیل‌گر خوب این است: «اگر این را اضافه کنیم، کدام‌یک از اینها باید برود؟» بدون این پرسش، هر کارگاهی به فهرست آرزو ختم می‌شود؛ فهرستی که همه رویش توافق دارند و هیچ‌کس نمی‌تواند بسازدش.

و یک نکتهٔ اجرایی که کیفیت خروجی را تعیین می‌کند: بعد از کارگاه، انبوهی برگه و طرح خام دارید که خودشان تصمیم نیستند. برای رسیدن از آن‌ها به چند تم قابل‌تصمیم، نمودار خویشاوندی ابزار درستی است؛ و برای اینکه جلسهٔ تولید ایده به بحث ارزیابی نلغزد، همان تفکیک واگرایی و همگرایی که در طوفان فکری گفته شد اینجا هم لازم است.

چه وقت به کارش ببریم و چه وقت نه

طراحی مشارکتی گران است — از نظر زمان، هماهنگی و انرژی — و برای هر پروژه‌ای صرف نمی‌کند. جاهایی که بیشترین بازده را دارد:

• - وقتی دانش کار دست کاربر است، نه شما. برای ابزار پرستار، حسابدار، یا اپراتور انبار، فاصلهٔ دانش بین تیم و کاربر آن‌قدر زیاد است که هیچ مصاحبه‌ای پرش نمی‌کند.
• - وقتی تصمیم پرهزینه و برگشت‌ناپذیر است. بازطراحی سامانه‌ای که هزاران نفر روزانه با آن کار می‌کنند، جای آزمون‌وخطای بعد از انتشار نیست.
• - وقتی پذیرش مهم‌تر از خودِ طرح است. کاربری که در ساختن سهم داشته، مقاومتش در برابر تغییر کمتر است. در سامانه‌های سازمانی این معمولاً مهم‌ترین سود روش است.
• - وقتی با گروه‌های کم‌نمایان کار می‌کنید — سالمندان، کاربران کم‌بینا، مردم مناطق محروم — که تجربه‌شان در داده‌های معمول شما دیده نمی‌شود.

دربارهٔ مقیاس هم یک انتظار واقع‌بینانه لازم است. طراحی مشارکتی روش کمّی نیست و با جمعیت زیاد کار نمی‌کند: کارگاه مؤثر معمولاً پنج تا هشت شرکت‌کننده دارد و بیش از این، جلسه به سخنرانی چند نفر تبدیل می‌شود. برای پوشش‌دادن گروه‌های مختلف کاربر، چند کارگاه کوچک جداگانه بهتر از یک جلسهٔ بزرگ است — و اگر گروه‌ها منافع متضاد دارند (مثلاً کارمند باجه و مدیر شعبه)، جدا برگزارکردن‌شان تقریباً الزامی است. در عوض، آنچه از این روش بیرون می‌آید عدد نیست که به حجم نمونه نیاز داشته باشد؛ فهم و طرح است، و برای اعتبارسنجی کمّی‌اش باید بعداً سراغ آزمون کاربردپذیری یا آزمون درختی بروید.

و جاهایی که سراغش نروید: وقتی تصمیم عملاً گرفته شده؛ وقتی مسئله کاملاً فنی است و کاربر مبنایی برای قضاوت ندارد؛ و وقتی نمی‌توانید نتیجه را عملی کنید. این آخری مهم‌ترین است: دعوت‌کردن مردم به مشارکتی که خروجی‌اش اجرا نمی‌شود، از دعوت‌نکردن بدتر است، چون اعتماد را هم می‌سوزاند.

جاهایی که شکست می‌خورد

این بخش هم افزودهٔ مترجم است و از الگوهای تکرارشونده در پروژه‌های واقعی می‌آید:

• - سوگیری خودانتخابی. کسانی که به کارگاه می‌آیند نمایندهٔ کاربران شما نیستند؛ نمایندهٔ کاربرانی‌اند که وقت، انگیزه و اعتمادبه‌نفس کافی برای آمدن داشتند. کاربر خموش و ناراضی معمولاً همان کسی است که نمی‌آید — و مسئلهٔ اصلی را او دارد.
• - عدم توازن قدرت در اتاق. اگر مدیر ارشد و کاربر عادی دور یک میز باشند، مشارکت واقعی رخ نمی‌دهد. همان‌طور که در طوفان فکری هم گفته شد، دور اول را نوشتاری و بی‌نام کنید تا رتبه از معادله بیرون بیاید.
• - خواستن راه‌حل از کاربر. کاربر متخصص مسئلهٔ خودش است، نه متخصص راه‌حل. اگر بپرسید «چه دکمه‌ای می‌خواهید؟» جوابی می‌گیرید که ارزش طراحی ندارد. بپرسید کارش را چطور انجام می‌دهد، کجا گیر می‌کند، و چه چیزی را دور می‌زند.
• - مشارکت استخراجی. وقتی چند ساعت از وقت و دانش مردم را می‌گیرید و هیچ‌چیز — نه خبر نتیجه، نه جبران مالی، نه اعتبار — به آن‌ها برنمی‌گردد. حداقل کار این است که بعد از تصمیم به شرکت‌کننده‌ها بگویید چه شد و کدام ایده‌شان کجا رفت.
• - گم‌شدن مسئولیت. «همه با هم تصمیم گرفتیم» می‌تواند به این معنا باشد که هیچ‌کس پاسخگو نیست. مشارکت، مسئولیت طراح را حذف نمی‌کند؛ ورودی‌اش را غنی‌تر می‌کند.

طراحی مشارکتی در محصولات فارسی‌زبان

این بخش هم در منبع نیست و از کار روی محصولات فارسی‌زبان می‌آید.

تعارف، مانع اصلی. بزرگ‌ترین مشکل اجرای این روش در بافت ما ادب اجتماعی است: شرکت‌کننده نمی‌خواهد با نقدِ روشن، میزبان را ناراحت کند. اگر بپرسید «نظرتان دربارهٔ این طرح چیست؟» جواب مثبت می‌گیرید و بی‌فایده. راه دورزدنش این است که جای نقدِ طرح، از او بخواهید کار واقعی‌اش را با آن انجام دهد و بلند فکر کند؛ گیرکردن را خودتان می‌بینید و لازم نیست کسی صریحاً چیزی را بد بخواند. یک ترفند دیگر: طرح را به‌عنوان کارِ «یک تیم دیگر» معرفی کنید تا نقدکردنش بی‌ادبی به حساب نیاید.

ذی‌نفع سازمانی به‌جای کاربر. در پروژه‌های سازمانی و دولتی، آنچه «کاربر» نامیده می‌شود اغلب نمایندهٔ کارفرماست نه کسی که واقعاً با سامانه کار می‌کند. اگر می‌خواهید طراحی مشارکتی معنا داشته باشد، اپراتور و کارمند باجه باید در اتاق باشند — و این معمولاً نیاز به اجازهٔ صریح دارد، چون حضور کارمند در جلسهٔ نقد سامانه، در بسیاری از سازمان‌ها امر عادی‌ای نیست.

ترس از پیامد شغلی. کارمندی که در حضور مدیرش از سامانه ایراد می‌گیرد، ممکن است بعداً هزینه بدهد. اگر جلسه را با حضور مدیر برگزار می‌کنید، این را جدی بگیرید: خروجی را بی‌نام گزارش کنید و از اول بگویید که هدف نقد سامانه است نه ارزیابی افراد.

جبران وقت. فرهنگ پرداخت به شرکت‌کنندهٔ پژوهش در ایران هنوز جا نیفتاده و همین باعث می‌شود نمونه به کسانی محدود شود که رابطهٔ قبلی با تیم دارند. حتی جبران کوچک — کارت هدیه یا اعتبار در محصول — کیفیت و تنوع نمونه را به‌شکل محسوسی بالا می‌برد.

دورکاری و پهنای باند. کارگاه آنلاین در جاهایی که اینترنت پایدار نیست، خودش یک فیلتر است: مشارکت را به کاربران شهرهای بزرگ محدود می‌کند. برای موضوعاتی که تجربهٔ شهرستان اهمیت دارد، جلسهٔ صوتی ساده با ابزار سبک بهتر از تختهٔ اشتراکی سنگین جواب می‌دهد.

جمع‌بندی

طراحی مشارکتی وعده می‌دهد که کاربر را از موضوع پژوهش به هم‌سازندهٔ محصول ارتقا دهد، و وقتی درست اجرا شود دو چیز هم‌زمان می‌دهد: طرح بهتر، و پذیرش بهتر. اما همان نردبان نشان می‌دهد که فاصلهٔ نسخهٔ واقعی و نسخهٔ تشریفاتی‌اش کم است و از بیرون هم شبیه‌اند.

و اگر یک جمله بماند، همین باشد: معیار مشارکت واقعی این است که کاربر بتواند «نه» بگوید و آن «نه» بماند. اگر خروجی جلسه نمی‌تواند تصمیم شما را عوض کند، آنچه برگزار کرده‌اید کارگاه نبوده، تأییدیه بوده.