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