User Research برای طراح وب راهی است که بفهمد مخاطب چه کاری انجام می‌دهد، چه اطلاعاتی لازم دارد و کجا با مانع روبه‌رو می‌شود. انتخاب ابزار تحقیق باید پس از سؤال انجام شود. Heatmap نمی‌گوید چرا کاربر روی بخش خاصی کلیک کرده و مصاحبه نیز به تنهایی سهم یک رفتار در کل جمعیت را اندازه نمی‌گیرد. متن قبلی چند روش و ابزار را بدون این تفاوت‌ها فهرست می‌کرد. این راهنما از تعریف سؤال تا جذب شرکت‌کننده، مشاهده، تحلیل و تبدیل یافته به تصمیم طراحی را با محدودیت‌های هر مرحله توضیح می‌دهد.
سؤال از تصمیم محصول بیاید
ابتدا تصمیمی را مشخص کنید که نیاز به اطلاعات دارد. آیا نام دو خدمت برای مشتری روشن است؟ آیا کاربر شرایط تحویل را پیش از خرید پیدا می‌کند؟ آیا فرم داده‌ای می‌خواهد که او ندارد؟ سؤال باید محدود و قابل پاسخ باشد. «کاربران چه می‌خواهند؟» برای یک دور کوتاه بسیار گسترده است. راهنمای برنامه‌ریزی یک دور تحقیق در GOV.UK درباره اتصال هدف و فعالیت توضیح دارد. برنامه تحقیق باید روشن کند نتیجه چگونه در تصمیم بعدی استفاده می‌شود.
اطلاعات موجود را هم بخوانید. پیام‌های پشتیبانی، رخدادهای مسیر و تحقیق قبلی می‌توانند سؤال را دقیق‌تر کنند. از تکرار مصاحبه درباره موضوعی که پاسخ معتبرش حاضر است پرهیز کنید، مگر شرایط تغییر کرده باشد. داده قدیمی نیز باید با زمان و مخاطب فعلی سنجیده شود. فرض و شاهد را جدا ثبت کنید. اگر تیم فقط حدس می‌زند، آن را با عبارت «می‌دانیم» معرفی نکنید. روشن‌بودن سطح اطمینان کمک می‌کند تحقیق روی ابهام مهم متمرکز شود.
روش مناسب هر سؤال را انتخاب کنید
مصاحبه برای شناخت تجربه، زمینه و فرایند کار مفید است. پرسش‌نامه می‌تواند داده ساختاریافته از پاسخ‌دهندگان جمع کند، به شرطی که سؤال و نمونه مناسب باشند. Usability Test مشاهده انجام کار روی رابط یا نمونه است. Card Sorting به فهم دسته‌بندی و نام‌گذاری کمک می‌کند. A/B Testing برای مقایسه رفتار در شرایط طراحی‌شده به کار می‌رود. این روش‌ها جای یکدیگر را کامل نمی‌گیرند و انتخابشان از سؤال، مخاطب و محدودیت داده می‌آید.
برای مثال، اگر نمی‌دانید مشتری چه اطلاعاتی پیش از درخواست جمع می‌کند، مصاحبه درباره تجربه گذشته می‌تواند مفید باشد. اگر می‌خواهید ببینید همان اطلاعات را در فرم شما پیدا می‌کند یا نه، مشاهده کار مناسب‌تر است. اگر اندازه اختلاف میان دو نسخه را می‌خواهید، به طراحی مقایسه و داده کافی نیاز دارید. مقاله A/B Testing ادامه این بخش است. تعداد ابزارهای استفاده‌شده معیار کیفیت تحقیق نیست؛ تناسب روش و سؤال مهم است.
شرکت‌کننده مرتبط پیدا کنید
شرکت‌کننده باید با زمینه کار مرتبط باشد. اعضای تیم که همه اصطلاح‌ها را می‌شناسند جای مخاطب تازه را نمی‌گیرند. نقش، تجربه، دستگاه و محدودیت دسترسی را در معیار جذب بیاورید. لازم نیست همه افراد یکسان باشند، اما تفاوت‌ها باید با هدف تحقیق هماهنگ باشند. اگر درباره مدیر سازمان تحقیق می‌کنید، رفتار عضو عادی پاسخ همان سؤال نیست. نمونه کوچک کیفی می‌تواند مانع را آشکار کند، اما نباید بدون روش آماری به نماینده قطعی کل بازار تبدیل شود.
از جذب فقط افراد در دسترس آگاه باشید. دوستان یا مشتریان راضی ممکن است تجربه بخشی از مخاطبان را نشان دهند. این محدودیت را در گزارش بنویسید و برای دورهای بعد راه پوشش گروه‌های دیگر را پیدا کنید. کاربران دارای معلولیت و فناوری کمکی نیز باید متناسب با مخاطب واقعی در نظر گرفته شوند. راهنمای شناخت نیاز کاربران درباره دیدن زمینه و نیاز توضیح دارد. فرض یک کاربر میانگین می‌تواند موانع مهم گروه‌های مختلف را پنهان کند.
رضایت و داده را پیش از جلسه روشن کنید
به شرکت‌کننده بگویید هدف چیست، چه چیزی ثبت می‌شود و چه کسانی به آن دسترسی دارند. ضبط صدا یا تصویر نیاز به توضیح و رضایت مناسب دارد. اطلاعات غیرضروری را جمع نکنید و داده واقعی حساس را از نمونه حذف کنید. اگر او نمی‌خواهد به پرسشی پاسخ دهد، فرایند باید این اختیار را حفظ کند. نگهداری فایل‌ها، مدت و روش حذف را با سیاست تیم هماهنگ کنید. کیفیت تحقیق به اعتماد و مرز روشن داده وابسته است و صرف حضور یک فرم رضایت همه جزئیات را حل نمی‌کند.
یادداشت‌های منتشرشده را بی‌نام کنید. نقل‌قول کوتاه ممکن است با زمینه و اطلاعات دیگر فرد را قابل شناسایی کند، پس فقط حذف نام کافی نیست. برای نمایش نتیجه به مشتری، دامنه مجاز داده را بررسی کنید. ابزار ضبط و تحلیل هم مقصد داده دارند و باید با سیاست سازمان سازگار باشند. اگر از AI برای دسته‌بندی یادداشت‌ها استفاده می‌کنید، حداقل داده و شرایط سرویس را در نظر بگیرید. پاسخ مدل را با یادداشت اصلی تطبیق دهید و نقل‌قول ساختگی نپذیرید.
مصاحبه درباره تجربه واقعی باشد
از رویداد مشخص گذشته بپرسید: آخرین بار چگونه خدمت را انتخاب کردید و چه اطلاعاتی کم داشتید؟ پرسش «آیا از این قابلیت استفاده می‌کنید؟» ممکن است پاسخ خوش‌بینانه فرضی بدهد. سؤال جهت‌دهنده مثل «این فرم ساده‌تر نیست؟» نیز نتیجه را به خواسته طراح نزدیک می‌کند. اجازه دهید شرکت‌کننده توضیح دهد و برای روشن‌شدن جزئیات سؤال بعدی بپرسید. هدف دفاع از طرح نیست. اگر پاسخ با فرض شما تعارض دارد، آن را ثبت کنید و علت را بفهمید.
نظر و رفتار را جدا بخوانید. فرد ممکن است بگوید مقایسه گزینه‌ها آسان است و در عمل چند بار مسیر را عوض کند. هر دو داده ارزش دارند، اما معنی یکسان ندارند. تناقض را با سرزنش شرکت‌کننده حل نکنید. ممکن است زبان سؤال، تجربه گذشته یا تفاوت وضعیت اثر داشته باشد. یادداشت باید مشاهده و تفسیر را جدا نگه دارد. «سه بار به صفحه قبلی برگشت» مشاهده است؛ «سردرگم بود» تفسیر است و بهتر است با شاهد پشتیبانی شود.
در مشاهده کار، مسیر را لو ندهید
سناریو هدف و زمینه بدهد، نه نام دکمه. اگر می‌خواهید پیدا کردن اطلاعات تحویل را ببینید، از کاربر بخواهید پیش از خرید زمان رسیدن را بررسی کند. نگویید بخش ارسال را باز کند. هنگام توقف، فوراً راه درست را نشان ندهید. اگر کمک لازم شد، زمان و نوع کمک را ثبت کنید. نتیجه بدون این اطلاعات ممکن است موفقیت مستقل را بیش از واقع نشان دهد. نمونه نیز باید قابلیت لازم برای انجام سناریو را داشته باشد.
محدودیت نمونه را در نتیجه لحاظ کنید. Prototype نمایشی نمی‌تواند سرعت واقعی server یا اعتبارسنجی کامل را ثابت کند. مقاله Rapid Prototyping درباره انتخاب دامنه و fidelity توضیح دارد. اگر مشکل از لینک قطع‌شده نمونه آمده، آن را با شکست طراحی اصلی برابر نگیرید. اگر همان محدودیت رفتار مورد تحقیق را ناممکن کرده، باید نمونه اصلاح شود. گزارش دقیق از نتیجه بیش از توان محیط ادعا نمی‌کند.
Analytics و Heatmap را با زمینه بخوانید
رخداد باید تعریف و اجرای درست داشته باشد. کلیک، ارسال معتبر و نتیجه نهایی یکسان نیستند. اگر یک رویداد چند بار ثبت شده، آن را تعداد افراد ندانید. منبع ورود و دستگاه می‌توانند رفتار را تغییر دهند. Heatmap محل تعامل را نشان می‌دهد و درباره قصد یا فهم کاربر حکم کامل نمی‌دهد. برای توضیح علت، داده کیفی مرتبط لازم است. نام ابزار به تنهایی کیفیت اندازه‌گیری را تضمین نمی‌کند و تنظیم نادرست می‌تواند گزارش قانع‌کننده اما نامعتبر بسازد.
نبود داده نیز باید گزارش شود. کاربری که ابزار او را ثبت نکرده از محصول استفاده نکرده فرض نمی‌شود. محدودیت حریم خصوصی، اتصال و ابزار می‌تواند روی مشاهده اثر بگذارد. از برآوردهای نامعلوم برای ساختن درصد موفقیت استفاده نکنید. مقاله KPI درباره تعریف شاخص ادامه مفیدی دارد. هدف، اطلاعات متناسب برای تصمیم است و نباید دقت ظاهری عدد از دقت واقعی روش بیشتر جلوه کند.
تحلیل را به یافته مشخص برسانید
بعد از جلسه، مشاهده‌ها را بر اساس سؤال گروه کنید. موارد مشابه را کنار هم بگذارید و اختلاف‌ها را حفظ کنید. یک نقل‌قول جالب نباید همه داده‌های مخالف را کنار بزند. یافته باید رفتار یا نیاز، زمینه و پیامد را توضیح دهد. سپس پیشنهاد اصلاح را جدا بنویسید. ممکن است چند راه‌حل برای یک یافته وجود داشته باشد و تحقیق فقط مسئله را روشن کرده باشد. معرفی یک پیشنهاد به عنوان خواسته مستقیم همه کاربران، بدون شاهد، مرز تحلیل و تصمیم را مخدوش می‌کند.
اولویت را با اثر و دامنه تصمیم تعیین کنید. مانعی که مسیر اصلی را می‌بندد با پسند شخصی درباره رنگ برابر نیست. برای هر یافته، مسئول و اقدام بعدی مشخص کنید: اصلاح متن، ساخت نمونه تازه یا جمع‌آوری داده بیشتر. راهنمای برنامه تحقیق در GOV.UK درباره پیوستگی فعالیت‌ها توضیح دارد. تحقیق نباید به گزارشی برسد که هیچ کس نمی‌داند با آن چه کار کند.
برای شروع، یک تصمیم باز را انتخاب کنید و سؤال، مخاطب، روش و نوع داده لازم را در یک صفحه بنویسید. سپس سناریو و مرز رضایت را آماده کنید و یافته را با محدودیت به تیم برگردانید. در دور بعد ببینید اصلاح چه تغییری ایجاد کرده است. این روال User Research را به بخشی از طراحی تبدیل می‌کند: اطلاعاتی که فرض را روشن می‌کند و اقدام مشخص می‌سازد. فهرست ابزارها و استعاره‌های کلی درباره اهمیت تحقیق جای این ارتباط عملی را نمی‌گیرند.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!