بهترین راه کشف مشکلات طراحی، نه بحث در اتاق جلسه، که دیدنِ یک کاربرِ واقعی در حال استفاده است. شما میتوانید ساعتها دربارهٔ جاییکه دکمه باید باشد استدلال کنید، اما یک نفر که برای اولین بار با محصول کار میکند، در چند دقیقه حقیقت را آشکار میکند. تست کاربردپذیری، همان آینهای است که محصول را آنگونه نشان میدهد که هست، نه آنگونه که تیم آرزو دارد. در این راهنمای وبلاگ پبدپ یاد میگیرید چطور پیش از لانچ، محصول را محک بزنید؛ اجرای این تستها در سرویس تست کاربردپذیری انجام میشود.
۱) چه چیزی را میسنجیم
کاربردپذیری یعنی: چقدر یادگیری آسان است، چقدر سریع کار انجام میشود، چقدر خطا رخ میدهد و کاربر چقدر راضی میماند. این چهار پرسش، هستهٔ هر تستاند. اگر روی یکشان توافق نکنید، بقیه سلیقهای میشود.
۲) کیفی یا کمّی
تست کیفی، «چرا»یِ گیرکردنِ کاربر را روشن میکند و تست کمّی، «چقدر» را: زمان انجام، نرخ موفقیت و تعداد خطا. هر دو لازماند؛ اولی برای فهمیدن، دومی برای اثبات و ردیابیِ پیشرفت.
۳) روش تفکرِ بلند
از کاربر بخواهید حین کار، بلند فکر کند: چه میبیند، چه انتظار دارد و چرا شک کرد. این روش، منطقِ پشتِ رفتار را بیرون میکِشَد و اغلب همانجا ریشهٔ مشکل را میبینید. نکته: سؤالِ جهتدهنده نپرسید؛ فقط بگویید به حرف زدن ادامه بده.
۴) سناریو و وظیفهٔ روشن
بهجای پرسشهای مبهم، وظیفهٔ واقعی بدهید: یک محصول پیدا کن، به سبد اضافه کن و خرید را تمام کن. وظیفه باید هدفمحور باشد نه قدمبهقدمِ دستورگونه؛ وگرنه شما قابلیتمندی را میسنجید نه کاربردپذیری را.
۵) چند کاربر کافی است
یک پژوهش معروف میگوید حدود پنج کاربر، بیشترِ مشکلاتِ جدیِ کاربردپذیری را آشکار میکند. لازم نیست منتظرِ نمونهٔ بزرگ بمانید؛ چند تستِ کوچکِ مکرر، بسیار بهتر از یک تستِ بزرگِ یکباره است. زود و پیوسته تست کنید. هر دورِ کوتاه، شما را زودتر از مسیرِ اشتباه بیرون میآورد و هزینهٔ اصلاح را پایین میآورد؛ چون ایرادی که امروز روی یک نمونهٔ ساده دیده شود، فردا در کدِ نهایی به چند برابرِ تمام میشود.
۶) کاربر درست را جذب کنید
تست روی آدمِ نامرتبط، نتیجهٔ گمراهکننده دارد. کسی را بیاورید که واقعاً مخاطبِ محصول شماست. اگر مخاطب، تازهکار است، متخصص را نفرمایید؛ اگر حرفهای است، تازهکار نتیجه را مخدوش میکند.
۷) بیطرف بمانید
وظیفهٔ شما مشاهده است، نه آموزشِ کاربر. اگر راهنماییاش کنید، دیگر کاربردپذیری را نمیسنجید که مهربانیِ خودتان را. سکوت را تحمل کنید؛ مکث و سردرگمیِ کاربر، خودش دادهٔ باارزش است. پس عجله نکنید که راهنماییاش کنید؛ بگذارید خودش راه را پیدا کند یا نیابد و آن لحظهٔ تردید را دقیق یادداشت نمایید.
۸) ثبت و شواهد
هر گیر و هر جملهٔ کلیدی را ضبط و یادداشت کنید. یک ویدئوی سیثانیهای از درماندگیِ یک کاربر، در جلسه تصمیم، از ده نمودار مؤثرتر است. شواهدِ ملموس، بحثهای سلیقهای را خاتمه میدهد.
۹) متریکهای درست
زمان انجام وظیفه، نرخ موفقیت، نرخ خطا و رضایتِ ثبتشده، چهار عددِ استانداردند. اینها را برای هر نسخه نگه دارید تا تغییرات را مقایسه کنید. بدون عددِ مرجع، بهبود فقط حس است نه اثبات.
۱۰) دورِ کاری و فیلد
تست آزمایشگاهی کنترلشده است و تست میدانی، واقعی. ترکیبشان تصویر کامل میدهد: در آزمایشگاه علت را میفهمید و در میدانی رفتار طبیعی را میبینید. هر دو را در چرخهٔ محصول جا بدهید.
۱۱) روی نمونه، نه فقط محصول نهایی
منتظرِ محصولِ کامل نمانید؛ روی پروتوتایپ تست کنید. ایرادی که روی نمونه پیدا شود، یک فاجعه در کدنویسیشده را جلو میگیرد. هرچه زودتر، ارزانتر.
۱۲) یافته را به تصمیم وصل کنید
گزارشِ تست، وقتی ارزش دارد که به تغییر بینجامد. یافتهها را بر پایهٔ اثر و هزینه اولویتبندی کنید و برای هرکدام یک اصلاح مشخص تعریف نمایید. هر ایرادی را که کاربر روی صفحات فرود میگیرد، به متریکِ تبدیل وصل کنید.
۱۳) اثبات با داده
پس از اصلاح، دوباره بسنجید و با وبآنالیتیکس تأثیرِ واقعی را بر رفتار و فروش ببینید. حلقهٔ تست، اصلاح و سنجش، طراحی را از حدس به دانش تبدیل میکند.
۱۴) اصلاح بر پایهٔ اصول
درمانِ هر ایراد، معمولاً در همان اصولِ طراحی رابط است: سلسلهمراتب روشن، بازخورد فوری و کاهش بار شناختی. بسیاری از مشکلاتِ کاربرد، نشانهٔ نقضِ یک اصلِ بنیادیناند.
۱۵) چرخهٔ بیپایان
تست کاربرد، یک مرحله نیست که تمام شود؛ ریتمِ همیشگیِ تیم است. با تغییر مخاطب و رقابت، آنچه امروز خوب است فردا کافی نیست. پژوهش را به پژوهش کاربر گره بزنید تا محصول همیشه با واقعیت همقدم بماند.
۱۶) چرا میارزد
هزینهٔ چند ساعت تست، در برابر هزینهٔ یک لانچِ پُرشکست، ناچیز است. تست کاربرد، هم محصول را بهتر میکند هم بحثهای بیپایانِ تیم را با شاهدِ واقعی خاتمه میدهد؛ چیزی که در سرویس تست کاربردپذیری ما استاندارد شده است.
سؤالات متداول
هر چند وقت تست کنیم؟ در هر تغییرِ مهمِ طراحی؛ بهتر است چرخهٔ کوتاه و مکرر باشد تا تستِ طولانی و نادر.
آنلاین یا حضوری؟ هر دو مؤثرند؛ آنلاین دامنهٔ گستردهتر و هزینهٔ کمتر میدهد و حضوری، زبانِ بدن و مکثها را.
خودم میتوانم؟ یک تستِ سادهٔ پنجنفره بله؛ اما طراحیِ درستِ وظیفه و تعبیرِ بیطرفانه، تخصصِ تیم است.
برای محکزدنِ محصول پیش از لانچ، پروژهٔ خود را برای ما تعریف کنید و نمونهکارها را در پورتفولیو ببینید.
فارسی
English
دیدگاهها
هنوز دیدگاهی برای این نوشته ثبت نشده است.
دیدگاه خود را بنویسید