نویسندگان: Rikke Friis Dam و Yu Siang Teo · منبع: بنیاد طراحی تعامل (IxDF) · ترجمهٔ آزاد: سپنتا پویا · تیر ۱۴۰۵ · زمان مطالعه: حدود ۱۰ دقیقه

مرحلهٔ دوم تفکر طراحی؛ تعریف مسئله و تفسیر نتایج

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

در فرایند پنج‌مرحله‌ای تفکر طراحی، مرحلهٔ دوم — تعریف (Define) — جایی است که انبوه یافته‌های مرحلهٔ همدلی به یک «بیانیهٔ مسئلهٔ» روشن و قابل‌اقدام تبدیل می‌شود. اگر همدلی دربارهٔ جمع‌کردن قطعه‌های پازل بود، تعریف دربارهٔ کنار هم چیدن آن‌هاست تا تصویر واقعی مسئله پیدا شود.

این مرحله شاید کم‌سروصداترین بخش تفکر طراحی باشد، اما سرنوشت‌سازترینش هم هست: مسئله‌ای که بد تعریف شود، حتی با بهترین اجرا هم به راه‌حل بد می‌رسد.

تحلیل و سنتز

دو مفهوم مکمل، موتور این مرحله‌اند:

• - تحلیل (Analysis): شکستن مسئلهٔ پیچیده به اجزای کوچک‌تر و قابل‌فهم. این کار عمدتاً در مرحلهٔ همدلی اتفاق می‌افتد — وقتی مشاهدات کاربران را تک‌تک ثبت می‌کنید.
• - سنتز (Synthesis): کنار هم گذاشتن خلاقانهٔ همان اجزا برای رسیدن به بینش‌های منسجم. این هستهٔ مرحلهٔ تعریف است.

البته این دو، مراحل جدا و پشت‌سرهم نیستند؛ طراح در طول کل فرایند مدام بین ریزبینی و کلان‌نگری رفت‌وآمد می‌کند — یک‌بار در جزئیات فرو می‌رود و بار دیگر عقب می‌ایستد تا الگوها را ببیند.

بیانیهٔ مسئلهٔ خوب چه ویژگی‌هایی دارد؟

بیانیهٔ مسئله قطب‌نمای پروژه است: تلاش تیم را جهت می‌دهد و جرقهٔ ایده‌پردازی را می‌زند. سه ویژگی، بیانیهٔ خوب را از بد جدا می‌کند:

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

یک ترفند ساده: بیانیه را با فعل‌های کنشی شروع کنید — «بسازیم...»، «تعریف کنیم...»، «تطبیق دهیم...». فعل، ذهن را به‌سمت اقدام هل می‌دهد.

چگونه بیانیهٔ مسئله را تعریف کنیم؟

روش‌های کاربردی متعددی برای رسیدن از دادهٔ خام به بیانیهٔ مسئله وجود دارد. مهم‌ترین‌هایشان:

اشباع فضا و گروه‌بندی؛ دیاگرام قرابت

در روش «اشباع فضا و گروه‌بندی» (Space Saturate and Group)، همهٔ دارایی تحقیق‌تان — عکس‌ها، یادداشت‌ها، مشاهده‌ها، نقل‌قول‌های مصاحبه، تجربه‌ها — را یک‌جا روی دیوار یا میز می‌چینید تا فضایی سرشار از اطلاعات ساخته شود (همان «اشباع»). بعد تیم شروع می‌کند به پیداکردن ارتباط بین تکه‌ها: کدام مشاهده‌ها با هم هم‌خانواده‌اند؟ چه الگویی تکرار می‌شود؟

این خوشه‌بندی دیداری — که در قالب «دیاگرام قرابت» (Affinity Diagram) هم انجام می‌شود — پلی است از مشاهدات جدا-جدا به فهم سنتزشده از مسئلهٔ کاربر.

نقشه‌کشی همدلی

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

دیدگاه (POV)؛ قالب بیانیهٔ مسئله

«دیدگاه» (Point of View) بینش خام را به چالشی هدفمند و قابل‌اقدام تبدیل می‌کند. قالبش سه جزء دارد:

• - کاربر: توصیفی مشخص از اینکه برای چه کسی طراحی می‌کنیم.
• - نیاز: با فعل بیان می‌شود — کاربر باید بتواند چه کاری انجام دهد؟
• - بینش: «چرا»ی قانع‌کننده‌ای که از تحقیق بیرون آمده.

کنار هم: «[کاربر...] نیاز دارد [نیاز...] زیرا [بینش...]». مثلاً: «نوجوانِ اهل تغذیهٔ سالم نیاز دارد به غذای مقوی دسترسی آسان داشته باشد، زیرا سلامت بدنش مستقیماً بر تمرکز درسی و اعتمادبه‌نفسش اثر می‌گذارد.» همین یک جمله، هم مسیر می‌دهد و هم الهام.

پرسش‌های «چطور می‌توانیم؟»

وقتی دیدگاه‌تان آماده شد، آن را به پرسش‌های باز «چطور می‌توانیم...؟» (How Might We) تبدیل کنید — پلی از تعریف مسئله به جست‌وجوی راه‌حل. پرسش HMW خوب باید تعادل داشته باشد: آن‌قدر گسترده که راه‌حل‌های متنوع را مجاز کند، و آن‌قدر مشخص که بشود واقعاً رویش کار کرد.

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

نردبان چرا-چطور

آخرین ابزار، «نردبان چرا-چطور» (Why-How Laddering) است که بین سطح‌های انتزاع جابه‌جایتان می‌کند: هر بار که می‌پرسید «چرا؟» یک پله بالا می‌روید و به گزاره‌ای انتزاعی‌تر اما معنادارتر می‌رسید؛ هر بار که می‌پرسید «چطور؟» یک پله پایین می‌آیید و به راهکاری مشخص‌تر و اجرایی‌تر.

قاعدهٔ سرانگشتی: در مرحلهٔ تعریف بیشتر «چرا» بپرسید تا به عمق مسئله برسید؛ در مرحلهٔ ایده‌پردازی بیشتر «چطور» بپرسید تا به راه‌حل‌های ملموس برسید.

بیانیهٔ مسئله‌ای که مسئله را خراب می‌کند

این بخش افزودهٔ مترجم است، چون در عمل بیشتر بیانیه‌های مسئله به یکی از این چند شکل خراب می‌شوند — و هرکدام بقیهٔ فرایند را با خودش خراب می‌کند:

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

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

چقدر داده کافی است؟

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

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

و خطای متقارنش هم واقعی است: جمع‌کردن داده تا بی‌نهایت، شکل محترمانهٔ به‌تعویق‌انداختن تصمیم است. اگر بعد از هر دور پژوهش، مسئله همان‌قدر مبهم می‌ماند، مشکل کمبود داده نیست؛ مشکل این است که کسی جرأت بستن مسئله را ندارد. بیانیهٔ مسئله را با دادهٔ موجود بنویسید، تاریخ بازبینی‌اش را مشخص کنید، و جلو بروید.

تعریف مسئله در بافت کاری ایران

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

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

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

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

محدودیت را در بیانیه بیاورید، نه بعد از آن. اگر می‌دانید اینترنت بخشی از کاربران ناپایدار است، پیامک تنها کانال قابل‌اتکاست، یا فرایند نیاز به احراز هویت رسمی دارد، این‌ها را در همان مرحلهٔ تعریف بنویسید. مسئله‌ای که بدون محدودیت‌های واقعی تعریف شود، راه‌حل‌هایی تولید می‌کند که در مرحلهٔ نمونه‌سازی یکی‌یکی حذف می‌شوند و وقت تیم را می‌سوزانند.

یک مسئله یا چند مسئله؟

این بخش افزودهٔ مترجم است، چون خروجی مرحلهٔ همدلی تقریباً همیشه چند مسئلهٔ موازی است و تیم‌ها یا همه را با هم برمی‌دارند یا بی‌معیار یکی را انتخاب می‌کنند.

سه معیار عملی برای انتخاب: تکرار (چند نفر و چند بار با آن روبه‌رو می‌شوند)، شدت (کاربر می‌تواند دورش بزند یا کار زمین می‌ماند)، و اختیار شما (آیا در توان تیم است که حلش کند). مسئله‌ای که پرتکرار و شدید است ولی حلش از اختیار شما بیرون است، باید مستند شود و به کسی که اختیارش را دارد منتقل — نه اینکه ماه‌ها روی آن کار شود.

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

جمع‌بندی

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