Rapid Prototyping زمانی مفید است که یک سؤال مشخص درباره محصول را با نمونه‌ای محدود بررسی کنیم. اگر سؤال این است که کاربر گزینه مناسب را پیدا می‌کند یا نه، لازم نیست همه حساب کاربری و پرداخت را بسازیم. عنوان قبلی این صفحه ساخت نمونه در یک ساعت را مانند یک مسیر عمومی معرفی می‌کرد. یک ساعت می‌تواند بودجه پیشنهادی برای تمرین کوچک باشد، اما پیچیدگی، داده آماده و مهارت تیم نتیجه را عوض می‌کنند. این راهنما روش محدودکردن نمونه، انتخاب سطح جزئیات و گرفتن بازخورد مرتبط را توضیح می‌دهد، بدون وعده زمان یکسان برای هر پروژه.
سؤال را پیش از ابزار بنویسید
یک سؤال تحقیق قابل پاسخ انتخاب کنید. «آیا طراحی خوب است؟» محدوده کمی دارد. «آیا مشتری تفاوت دو طرح اشتراک را از جدول می‌فهمد؟» روشن‌تر است. سؤال باید با تصمیم بعدی مرتبط باشد؛ اگر پاسخ مثبت یا منفی هیچ تغییری در کار ایجاد نمی‌کند، شاید سؤال اصلی را انتخاب نکرده‌اید. راهنمای ثبت سؤال تحقیق در GOV.UK درباره این برنامه‌ریزی توضیح دارد. نمونه قرار است به سؤال کمک کند، نه اینکه همه خواسته‌های جلسه را یک‌جا نمایش دهد.
فرض‌های مهم را ثبت کنید. ممکن است فرض کرده باشید کاربر اصطلاح محصول را می‌شناسد یا اطلاعات لازم را در دسترس دارد. این فرض‌ها بر مسیر اثر دارند و باید در سناریو دیده شوند. اگر نمونه فقط کاربر آماده و موفق را نشان می‌دهد، بخش مهمی از تجربه پنهان می‌ماند. از میان فرض‌ها، موردی را انتخاب کنید که نادرست‌بودنش تصمیم را تغییر می‌دهد. لازم نیست همه ابهام‌های محصول در یک نمونه حل شوند؛ دامنه محدود امکان یادگیری روشن‌تر می‌دهد.
سطح جزئیات به سؤال وابسته است
برای ترتیب اطلاعات، اسکچ کاغذی یا Wireframe ممکن است کافی باشد. برای درک یک کنترل تعاملی، رفتار کلیک و وضعیت‌ها لازم‌اند. برای خوانایی رنگ یا متن، جزئیات بصری اهمیت بیشتری پیدا می‌کنند. Fidelity بالا به تنهایی نمونه را مناسب‌تر نمی‌کند. اگر سؤال درباره محتواست، انیمیشن دقیق ممکن است زمان بگیرد و بازخورد را به ظاهر منحرف کند. مشخص کنید چه چیزی عمداً ساده شده و چه چیزی باید واقعی باشد تا مشاهده معنی داشته باشد.
نمونه clickable می‌تواند مسیر را نشان دهد، اما بعضی رفتارها را فقط تقلید می‌کند. یک دکمه ممکن است همیشه پاسخ موفق بدهد، حتی اگر ورودی خالی باشد. این محدودیت را در برنامه تحقیق در نظر بگیرید. اگر اعتبارسنجی موضوع اصلی است، باید حالت خطا را قابل مشاهده کنید. اگر سرعت سیستم را می‌سنجید، نمونه نمایشی نمی‌تواند عملکرد backend واقعی را نشان دهد. هر نتیجه را به توان نمونه محدود کنید و از مشاهده یک مسیر فرضی، کیفیت محصول آماده را استنتاج نکنید.
مسیر کوچک با آغاز و پایان بسازید
نقطه شروع باید با زمینه کاربر هماهنگ باشد. اگر کاربر از صفحه محصول می‌آید، نمونه را از dashboard نامرتبط آغاز نکنید. پایان نیز باید نتیجه مشخص بدهد: انتخاب ثبت شده، درخواست آماده ارسال یا اطلاعات مورد نظر پیدا شده است. مسیرهای بن‌بست را عمداً علامت بزنید. اگر صفحه‌ای خارج از دامنه است، شرکت‌کننده نباید آن را خطای واقعی سرویس تصور کند. ساختار نمونه باید اجازه دهد کار مورد نظر انجام شود و محدودیت‌ها نتیجه را بی‌دلیل مخدوش نکنند.
حالت‌های مؤثر را انتخاب کنید: داده خالی، انتخاب ناموجود یا ورودی نامعتبر. لازم نیست هر حالت فنی ممکن حاضر باشد، اما حالت مرتبط با سؤال نباید حذف شود. مثلاً برای انتخاب محصول، دو گزینه نزدیک و یک تفاوت واقعی لازم است؛ یک گزینه واضح با دکمه بزرگ انتخاب را بیش از حد ساده می‌کند. محتوای نمونه باید طول و نوع مناسب داشته باشد. داده فرضی را مشخص معرفی کنید و اطلاعات مشتری واقعی را بدون نیاز وارد نمونه نکنید.
از اجزای موجود با قرارداد درست استفاده کنید
Component Library می‌تواند زمان ساخت را کم کند، چون قواعد ظاهری و بخشی از رفتار آماده‌اند. با این حال، جزء موجود ممکن است برای کاربرد شما مناسب نباشد. اگر کارت محصول را برای جدول مقایسه کش می‌دهید، شاید اطلاعات رابطه خود را از دست بدهند. مقاله Atomic Design درباره مسئولیت اجزا توضیح می‌دهد. استفاده دوباره باید ساخت را روشن‌تر کند و نه اینکه نیاز واقعی را به محدودیت یک قالب نامرتبط تبدیل کند.
در ابزار طراحی، interactionها و نام frameها را قابل فهم نگه دارید. اگر بعداً کسی نمونه را ادامه می‌دهد، باید بداند مسیر اصلی چیست و کدام قسمت به یک فرض وابسته است. نمونه سریع هم به حداقل نظم نیاز دارد. راهنمای Prototyping در GOV.UK Design System یک نمونه از استفاده ساختاریافته از الگوهای موجود است. لازم نیست همان ابزار را انتخاب کنید؛ اصل مفید، ارتباط میان نیاز، جزء و مسیر قابل بررسی است.
بودجه زمانی را به بخش‌های قابل انعطاف تقسیم کنید
برای تمرین کوتاه، ابتدا زمان تعریف سؤال و محتوا را کنار بگذارید. سپس ساخت مسیر و مرور آن را برنامه‌ریزی کنید. تقسیم ثابت ده دقیقه اسکچ و سی دقیقه ظاهر برای همه کارها مناسب نیست. اگر محتوا آماده نیست، ساخت Hi-fi ممکن است فقط ابهام را زیباتر کند. اگر interaction اصلی پیچیده است، زمان بیشتری به رفتار بدهید. Timebox برای کنترل دامنه است؛ نباید باعث شود بخش لازم برای پاسخ به سؤال حذف شود و نمونه بی‌معنا بماند.
وقتی زمان رو به پایان است، قابلیت جانبی را حذف کنید و مسیر اصلی را کامل نگه دارید. یک مسیر کوتاه قابل انجام از چند صفحه نیمه‌کاره مفیدتر است. تصمیم حذف را ثبت کنید تا بعداً درباره نبود بخش برداشت اشتباه نشود. از پرداختن به جزئیات کم‌اثر مانند سایه دقیق یا آیکون تزئینی پیش از تکمیل متن و مسیر پرهیز کنید. کیفیت نمونه از تناسب با سؤال می‌آید و همیشه به شباهت کامل با محصول نهایی وابسته نیست.
بازخورد را به مشاهده کار وصل کنید
از شرکت‌کننده بخواهید یک کار واقعی با زمینه مشخص انجام دهد. نام کنترل یا راه‌حل را در سناریو نگویید، چون ممکن است او را راهنمایی کنید. «می‌خواهید شرایط دو گزینه را مقایسه کنید» بهتر از «روی دکمه مقایسه کلیک کنید» است. هنگام مشاهده، زود مسیر درست را نشان ندهید. توقف، برداشت و دلیل انتخاب را ثبت کنید. نظر کلی درباره زیبایی می‌تواند مفید باشد، اما برای سؤال پیدا کردن اطلاعات جای مشاهده رفتار را نمی‌گیرد.
اگر نمونه محدودیت فنی دارد، زمان توضیح آن را در نظر بگیرید. توضیح قبل از کار ممکن است پاسخ را جهت دهد و توضیح دیرهنگام ممکن است وقت را تلف کند. برنامه کوتاه بنویسید که چه زمانی کمک مجاز است و چگونه در یادداشت ثبت می‌شود. مقاله User Research برای طراحان وب درباره این فرایند ادامه دارد. مشاهده باید میان مشکل نمونه، مشکل طراحی و اطلاعات نامعلوم تفاوت بگذارد تا اصلاح بعدی به علت درست وصل شود.
دسترسی‌پذیری و دستگاه را نادیده نگیرید
اگر کار اصلی روی تلفن انجام می‌شود، نمونه باید همان زمینه را تا حد لازم پوشش دهد. کوچک‌کردن frame رومیزی همیشه کافی نیست. متن فارسی، ورودی ترکیبی و طول عنوان‌ها را واقعی انتخاب کنید. برای صفحه‌کلید و فناوری کمکی، برخی ابزارهای clickable محدودیت دارند؛ این محدودیت را در نتیجه گزارش کنید. مقاله دسترسی‌پذیری سایت فارسی ادامه مرتبطی است. نتیجه یک نمونه غیرقابل استفاده برای گروهی از کاربران نباید به همه مخاطبان تعمیم داده شود.
اگر از کد برای نمونه استفاده می‌کنید، مجوز و داده را از تولید جدا نگه دارید. نمونه نباید ایمیل واقعی ارسال کند یا پرداخت واقعی انجام دهد، مگر اینکه دامنه و فرایند عمداً برای آن تنظیم شده باشد. برچسب آموزشی و محدودیت را روشن کنید. استفاده از کد آماده می‌تواند ساخت را سریع کند، اما امنیت و نگهداری محصول نهایی را ثابت نمی‌کند. نمونه تحقیق برای فهم یک رفتار ساخته شده و ممکن است برای دورریختن باشد؛ این وضعیت باید برای تیم معلوم باشد.
یافته را به تصمیم بعدی تبدیل کنید
یادداشت‌ها را به چند یافته مشخص تبدیل کنید: چه رفتاری مشاهده شد، در کدام مرحله و با چه پیامدی. سپس پیشنهاد اصلاح و دلیلش را بنویسید. اگر شرکت‌کننده عنوان گزینه را اشتباه فهمید، شاید اصلاح متن کافی باشد و بازطراحی همه صفحه لازم نباشد. تعداد محدود مشاهده را به درصد بازار تبدیل نکنید. نتیجه کیفی می‌تواند مانع مهم را نشان دهد، اما اندازه شیوع آن پرسش دیگری است. محدودیت روش را همراه نتیجه نگه دارید.
برای دور بعدی، فقط تغییرهای مرتبط با یافته را وارد کنید و نسخه نمونه را ثبت کنید. این کار امکان مقایسه و یادگیری را حفظ می‌کند. اگر فرض اصلی رد شده، دامنه سؤال را دوباره بررسی کنید و از ساخت سریع نسخه بزرگ‌تر برای پوشاندن آن پرهیز کنید. یک نمونه محدود، سناریوی روشن و تصمیم ثبت‌شده، خروجی قابل استفاده این فرایندند. سرعت زمانی ارزش دارد که به فهم بهتر مسئله برسد و نه فقط به تعداد بیشتری صفحه قابل کلیک.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!