چه زمانی تحقیق کنیم؟
Jeanette Fuccella
یکی از چالش برانگیزترین سوالات اینه که آیا ما در پروژه‌های طراحی تجربه کاربری همیشه باید تحقیق کنیم؟ چه زمانی اینکار را انجام بدیم چه زمانی انجام ندیم؟
کجاها نیاز داریم حتما تحقیق انجام بشه و چه زمانی نیاز نیست و تمرکز کنیم روی دیزاین؟
تو این نوشته میخوام یکبار این موضوع رو کامل توضیح بدم که کی و چطور تحقیق انجام بدیم؟
اغلب ما تو پروژه‌ها و سازمان‌ها زمان و بودجه کمی داریم و بنا به این شرایط باید بهترین تصمیم رو بگیریم. البته که خواسته‌ها و اهداف ممکنه متفاوت باشه ولی ما به عنوان طراح بهتره بین این خواسته‌ها و منابع موجود تعادل ایجاد کنیم.
اینکه چه زمانی تحقیق کنیم و چه زمانی نکنیم را
ریسک و میزان شفافیت مساله تعیین میکنه!
این موضوع رو خانم ژانت فوچلا (Jeanette Fuccella) مدیر تحقیقات شرکت Pendo ارائه داده. ایشون یه ماتریکس ۲x۲ پیشنهاد داده که کمک میکنه منابع و انرژی خودمون رو مدیریت کنیم.
این فایل خلاصه و ترجمه‌ای از این مقاله برای راهنمایی بچه‌هایی هست که میخوان طراحی محصول و تحقیق تجربه کاربری رو انجام بدن.
مطالعه اصل مقاله به زبان انگلیسی
این چهارچوب روی دو محور میزان شفافیت مساله و ریسک سوار شده و بر این اساس نوع برخورد ما به پروژه رو تو فاز تحقیق مشخص میکنه.
حالا بریم این چهارتا دسته بندی رو باهم مرور کنیم ببینیم داستان چیه!
الف. طراحی کن بره
ب. ریسرچ سطحی
ج. تمرکز عمیق روی دیزاین
د. ریسرچ عمیق
الف. طراحی کن بره (مشکل واضح، ریسک کم)
این موضوع زمانی اتفاق میوفته که شما و ذینفعان پروژه دید واضحی از کار دارید و انجامش هم ریسک خاصی نداره. یا اینکه نظراتتون براساس یکسری تحقیق قبلی و یا نمونه‌های واقعی تو بازار باشه که داره کار میکنه. و یا مشتری تعریف دقیق و درستی از مشکل ارائه داده.
موضوع بعدی ریسک کار هست که تو این شرایط خیلی بالا نیست و یا اینکه خیلی دور از انتظار نیست و ما پیش بینی درستی از میزان خطرات کار داریم. مثلا میزان تغییرات تو پروژه ممکنه حداکثر ۲٪ روی خروجی تاثیر منفی بزاره که قابل پذیرش هست.
و همچنین زمانی که ما یک راه حل مشخص برای یک مشکل مشخص داریم فقط تمرکز میزاریم روی دیزاین. در کل تو این وضعیت همه چیز بدیهی هست.
چه اقداماتی بکنیم:
- بیخیال تحقیق میشیم
- دلو به دریا میزنیم و با فرضیه‌های اولیه طراحی میکنیم
- میتونیم قبل لانچ یه بررسی هم داشته باشیم و یا مثلا A/B تست کنیم تا خیالمون راحت باشه.
- بعد از لانچ بررسی میکنیم ببینیم دیزاین چطور کار میکنه و همیشه حواسمون به خروجی دیزاین باشه.
ب. ریسرچ سطحی (مشکل مبهم، ریسک کم)
وقتی شما و ذینفعان پروژه خیلی دید واضحی از چیزی که داره اتفاق میوفته ندارید و یا خیلی اطلاع ندارید که چه باید بکنید یه تحقیق اولیه میتونه کمکتون کنه که چه مسیری رو طی کنید.
یکی از نکات مهم تو این شرایط اینه که ما حتی سوالات دقیقی هم نداریم و نمیدونیم دنبال چی باشیم!
اما خب این موضوع خیلی ریسک خاصی هم واسمون نداره و پروژه داره راه خودش رو میره.
چه اقداماتی بکنیم:
- تلاش برای رسیدن به تعریف درستی از مشکل/مساله. تو این وضعیت با تیم‌ها حداکثر همکاری رو میکنیم تا به یک تعریف و دید واضحی از مساله برسیم. از جمله روشهایی که میتونه تو این فاز بهمون کمک کنه گوریلا تست (guerilla test)، تحقیق رومیزی (desk research)[۱]، نظرسنجی‌ها و پرسش و پاسخ‌ها. تا بتونیم سریع جمع بندی کنیم و بریم سراغ طراحی و راه حل ارائه بدیم.
- وقتی یکسری اطلاعات کافی (کمی و کیفی) از طریق تحقیقات سریع، بدست آوردیم با بررسی اونها میتونیم دید واضحی از مساله داشته باشیم و اقدام کنیم.
ج. تمرکز عمیق روی دیزاین (مشکل واضح، ریسک زیاد)
وقتی شما و ذینفعان پروژه دید واضحی از پروژه و فرضیه درستی از علل مساله دارید. مشتری و مشکلاتش رو میشناسید و تقریبا مسیر براتون مشخصه، تمرکز رو میزاریم رو دیزاین اصولی.
(این اطمینان معمولا از نتایج تحقیقات قبلی، بررسی رفتار کاربر و تحلیل اطلاعات میاد)
یعنی در حقیقت ما میدونیم مشکل چیه و از کجا آب میخوره و باید روی راه حل تمرکز کنیم. تو این شرایط یک راهکار اشتباه میتونه نتایج بدی به دنبال داشته باشه و ضرر زیادی به ما و شرکت بزنه. پس همه تمرکز میره واسه ساخت یک راه‌حل درست.
چه اقداماتی بکنیم:
- همه بخش‌ها و تیم‌ها دست به دست هم میدیم تا به یک طراحی یا راه حل درست و اصولی برسیم. این کار هم به شیوه‌های مختلف انجام میشه. مثلا طوفان فکری، استفاده از نتایج تحقیقات اولیه، جلسات ایده‌پردازی و…
- تست‌های قبل لانچ یا پیاده سازی محصول میتونه اطمینان بیشتری برامون درست کنه. یجوری سعی میکنیم تا بقیه تیم‌ها این اطمینان رو بدیم که دیزاین فعلی، پاسخ درستی واسه اون مشکل هست تا همگی خیالمون از بابت راهکار مطمئن باشه. جوری که انتظارات بعد لانچ با داده‌های زمان تست طراحی خیلی فاصله نداشته باشه.
بر فرض ما تو طراحی یک محصول بررسی کردیم دیدیم پروسه‌های اصلی برنامه در ۸۰٪ مواقع درست کار کرده و اگر بعد از لانچ محصول هم بین ۷۰ تا ۸۰ درصد درست از آب در بیاد پس دیزاین مناسبی ارائه دادیم.
د. ریسرچ عمیق (مشکل مبهم، ریسک زیاد)
وقتی شما و ذینفعان پروژه نمیدونید چه اتفاقی داره میوفته و دانش و دیتای درستی از کار ندارید و نمیتونید یه فرضیه درست از مساله بسازید.
از طرفی ریسک کار هم بسیار بالاست و اگر راه حل خوبی ارائه ندیم ممکنه درگیر مشکلات پیچیده‌ای بشیم و ضرر و زیان زیادی هم متحمل بشیم. اینجور مواقع هم راه حل‌های سریع، اوضاع رو پیچیده تر میکنه!
تو این فاز باید زمان و هزینه مناسبی واسه تحقیق در نظر بگیریم.
چه اقداماتی بکنیم:
- برای درک درست مساله، زمان کافی واسه تحقیق اختصاص میدیم تا به دید واضحی از مشکل برسیم. هرچقدر مشکل مبهم تر باشه نیاز به تحقیق عمیق‌تری داریم. بر همین اساس میشه نقشه‌هایی مثل User journeys از کل پروسه تهیه کرد تا به دید بهتری برسیم.
- همه تیم‌ها رو درگیر میکنیم تا به کمک اونها راه حل هارو بررسی کنیم. چون هر تیمی درک و شناختی متفاوت و عمیق از محصول دارن. مثلا تیم پشتیبانی باتوجه به نظرات مشتری‌ها، دید خوبی از دغدغه‌های اونها بدست آورده و میتونه خیلی بهمون کمک کنه.
- مصاحبه‌های عمیق، نظرسنجی‌ها و استفاده از ابزارهای آنالیز دیتا مثل گوگل آنالیتیکس خیلی بهمون کمک میکنه.
معمولا تیم‌های طراحی محصول همزمان که به دنبال پیدا کردن مسائل مختلف هستن، راهکار هم براش ارائه میدن و تو تایم‌های کم باید بتونن هم فیچرهای جدید و هم سولوشن‌های خوبی ارائه بدن.
درک اینکه ما همیشه نیاز نیست درباره هر موضوعی تحقیق کنیم و از طرفی زمان و سرمایه کافی هم واسش نداریم، میتونه تو مدیریت منابع بهمون خیلی کمک کنه و از طرفی این سردرگمی که اغلب طراحهان محصول دارن (چه زمانی تحقیق کنیم و چه زمانی نکنیم) رو حل میکنه.
این چارت دو در دو جواب مناسبی واسه این موضوع هست.
از طرفی ارزش‌گزاری تحقیق هم مشخص میشه. یعنی تعیین میکنه که آیا تحقیقی که کردیم به خروجی کار میارزه یا نه!
برای مثال میتونستیم باتوجه به دانش قبلی، مساله رو حل کنیم و کلی زمان و انرژی صرف پیدا کردن یه چیز بدیهی نمیکردیم.
—————————-
[۱]. تحقیق رومیزی یعنی استفاده از اطلاعات و نتایجی که قبلا توسط دیگران به دست اومده.