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

مرحلهٔ پنجم تفکر طراحی؛ آزمایش (Test)

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

در فرایند پنج‌مرحله‌ای تفکر طراحی، مرحلهٔ پنجم — آزمایش (Test) — جایی است که راه‌حل‌های ساخته‌شده را در برابرِ واقعیت می‌گذاریم. در این مرحله، طراحان روش‌هایی از دلِ تفکر طراحی، تعاملِ انسان و رایانه (HCI) و طراحیِ کاربرمحور را به‌کار می‌گیرند تا نمونه‌های ساخته‌شده در مرحلهٔ نمونه‌سازی را با کاربرانِ واقعی بیازمایند و ببینند آیا واقعاً کار می‌کنند یا نه.

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

آزمایش در سراسرِ فرایند جریان دارد

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

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

پنج راهنمای عملی برای اجرای یک آزمون

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

۱. نشان بده، توضیح نده

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

۲. از کاربر بخواه بلندبلند فکر کند

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

۳. شرکت‌کننده را با دقت تماشا کن

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

۴. سؤال‌های تکمیلی بپرس

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

۵. بازخوردِ منفی، بهترین معلم است

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

هدفِ نهایی: راه‌حلی مطلوب، شدنی و پایدار

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

• - مطلوب‌بودن (Desirability): آیا مردم واقعاً این راه‌حل را می‌خواهند؟ راه‌حل باید با نیازها، احساسات و رفتارهای کاربرانِ هدف جور باشد. این ضلع، ضلعِ انسانیِ ماجراست و کاربر را در مرکز نگه می‌دارد.
• - شدنی‌بودن (Feasibility): آیا از نظرِ فنی ساختنش ممکن است؟ راه‌حل نباید به فناوری‌ای تکیه کند که هنوز وجود ندارد؛ باید با امکاناتِ امروز قابل‌تحقق باشد.
• - پایدار‌بودن (Viability): آیا مدلِ کسب‌وکارش می‌ماند؟ راه‌حل باید فراتر از عمرِ پروژه هم بتواند روی پای خودش بایستد و خودش را حفظ کند.

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

چند نفر، و چه کسانی؟

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

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

اما این عدد برای ادعای کمّی کافی نیست. اگر می‌خواهید بگویید «۴۰ درصد کاربران این دکمه را پیدا نمی‌کنند»، پنج نفر چنین جمله‌ای را پشتیبانی نمی‌کند؛ آن ادعا به نمونهٔ بزرگ‌تر و روشی مثل آزمون A/B یا آزمون درختی نیاز دارد. تفکیک این دو مهم است چون خیلی از بی‌اعتمادی‌ها به پژوهش کیفی از همین‌جا می‌آید: کسی با پنج نفر عددی درصدی می‌سازد، بعد آن عدد در جلسه رد می‌شود، و کل روش بی‌اعتبار می‌شود.

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

خطاهایی که نتیجهٔ آزمون را بی‌اعتبار می‌کنند

این بخش هم در منبع نیست و از جاهایی می‌آید که آزمون برگزار می‌شود ولی چیزی از آن در نمی‌آید:

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

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

آزمون در بافت کاری ایران

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

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

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

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

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

جمع‌بندی

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