ابزارهایی برای تعریف مسئله

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

توسعه‌ی پرسونای کاربر

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

نقشه‌ی همدلی

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

تدوین صورت‌مسئله

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

نقشه‌برداری از سفر مشتری

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

تکنیک ۵ چرا

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

تحلیل SWOT

تحلیل SWOT یه روش منظم برای بررسی نقاط قوت و ضعف داخلی تیم و فرصت‌ها و تهدیدهای بیرونی محیطه.
برای شروع، باید ببینیم چه مهارت‌ها، منابع و تجربه‌های مثبتی داخل تیم وجود داره. این‌ها نقاط قوت هستن. معمولاً از بازخورد اعضای تیم یا ذی‌نفع‌ها کمک می‌گیریم.
بعد باید ضعف‌ها رو پیدا کنیم؛ جاهایی که منابع کم داریم، مهارت کافی نیست یا قبلاً مشکل ایجاد شده. این قسمت نیاز به صداقت بالا داره.
در بخش فرصت‌ها، تمرکز روی چیزهای بیرون تیمه؛ مثل روندهای جدید بازار، تکنولوژی‌های تازه یا نیازهای نوظهور کاربرها.
در نهایت، تهدیدها رو بررسی می‌کنیم؛ مثل رقبا، تغییر قوانین، شرایط اقتصادی یا انتظارات جدید مشتری‌ها.
این تحلیل یه تصویر کلی از وضعیت فعلی بهمون می‌ده و کمک می‌کنه بفهمیم کجا باید بیشتر وقت و انرژی بذاریم.

نمودارهای افینیتی

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

نقشه‌برداری ذی‌نفعان

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

نقشه‌برداری فرضیات

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

استوری‌بوردینگ

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