Multi-step Wizard یک کار را به چند مرحله مرتبط تقسیم می‌کند. کاربر باید بداند اکنون چه چیزی می‌خواهد، چه چیزی باقی مانده و چگونه تصمیم قبلی را اصلاح کند. تقسیم فرم به چند صفحه به تنهایی پیچیدگی را کم نمی‌کند؛ اگر گروه‌ها نامفهوم باشند یا اطلاعات در رفت‌وبرگشت پاک شود، همان کار با هزینه بیشتری انجام می‌شود. پیش از طراحی نوار پیشرفت، مسیر واقعی کار و وابستگی میان داده‌ها را مشخص کنید.
برای مثال فرضی سفارش چاپ، نوع محصول، مشخصات، تحویل و بازبینی گروه‌های قابل فهمی هستند. انتخاب نوع محصول روی مشخصات لازم اثر می‌گذارد و آدرس روی هزینه تحویل. این رابطه باید در مسیر و خلاصه نهایی دیده شود. تعداد مرحله را با گروه‌های منطقی تعیین کنید، نه با هدف رسیدن به سه یا پنج صفحه. گاهی فرم کوتاه در یک صفحه آسان‌تر است و گاهی فرایند طولانی به ذخیره و ادامه در زمان دیگری نیاز دارد.
مراحل را با تصمیم کاربر گروه‌بندی کنید
برای هر مرحله یک خروجی بنویسید: انتخاب محصول، تعیین اندازه یا تأیید روش تحویل. چند فیلد بی‌ارتباط را صرفاً چون در یک قاب جا می‌شوند کنار هم نگذارید. اطلاعات لازم برای یک تصمیم باید در همان مرحله موجود باشد. اگر انتخاب اندازه روی قیمت اثر دارد، قیمت یا روش محاسبه آن باید در دسترس باشد. کاربر نباید چند صفحه جلو برود و تازه بفهمد تصمیم قبلی هزینه‌ای داشته که هنگام انتخاب نشان داده نشده است.
مرحله اختیاری را مشخص کنید و امکان عبور از آن بدهید. عبارت «بعداً تکمیل می‌کنم» باید با واقعیت خدمت سازگار باشد؛ داده‌ای که برای انجام کار ضروری است نمی‌تواند بدون مسیر جایگزین اختیاری معرفی شود. عنوان هر مرحله بهتر است عمل یا موضوع را روشن کند. «اطلاعات تکمیلی» برای مجموعه‌ای از انتخاب‌های حساس عنوان دقیقی نیست. در راهنمای فرم چندصفحه‌ای W3C، گروه‌بندی منطقی و توضیح پیشرفت از اصول پایه معرفی شده‌اند.
پیشرفت را صادقانه نمایش دهید
اگر تعداد مراحل ثابت است، عنوان جاری و جایگاه آن را نشان دهید؛ مثلاً «تحویل، مرحله ۳ از ۴». نوار بدون نام مرحله فقط مقدار بصری ارائه می‌کند. اگر مسیر بر اساس پاسخ‌ها تغییر می‌کند، وعده تعداد قطعی ندهید یا تغییر را توضیح دهید. درصد پیشرفت نیز باید تعریف داشته باشد؛ تقسیم برابر مراحل با حجم کار بسیار متفاوت، انتظار نامناسبی می‌سازد. رسیدن نوار به انتها پیش از دریافت تأیید سرور، انجام شدن کار را تضمین نمی‌کند.
وضعیت‌های جاری، تکمیل‌شده و آینده باید بدون اتکا به رنگ قابل تشخیص باشند. برای مرحله تکمیل‌شده، مسیر اصلاح روشن باشد. باز کردن مرحله آینده وقتی داده پیش‌نیاز موجود نیست ممکن است فقط به خطا منجر شود؛ رفتار آن را مشخص کنید. در موبایل لازم نیست همه عنوان‌ها در یک خط کوچک و ناخوانا فشرده شوند. عنوان جاری و توضیح تعداد، همراه دسترسی به خلاصه مراحل، گاهی اطلاعات روشن‌تری از یک خط بلند از نقطه‌های نامعلوم می‌دهد.
برگشت را بدون مجازات ممکن کنید
دکمه برگشت باید داده‌های واردشده را حفظ کند. برگشت برای اصلاح انتخاب با ترک کامل فرایند یک کار نیست؛ نام و رفتار آن‌ها جدا باشد. اگر کاربر نوع محصول را تغییر دهد و بعضی گزینه‌ها دیگر معتبر نباشند، پیام دقیق لازم است. به جای حذف خاموش همه اطلاعات، فقط داده وابسته را مشخص کنید و توضیح دهید چه چیزی باید دوباره انتخاب شود. این رفتار باید در مدل داده هم تعریف شود تا نمایش و سرور درباره اعتبار انتخاب اختلاف نداشته باشند.
تغییر روش تحویل ممکن است آدرس قبلی را موقتاً غیرلازم کند. حفظ آن برای بازگشت می‌تواند مفید باشد، اما نباید بدون دلیل وارد سفارش نهایی شود. خلاصه باید انتخاب جاری را نشان دهد. حرکت Back مرورگر را هم در طراحی مسیر در نظر بگیرید؛ کاربر آن را با دکمه داخل Wizard اشتباه نمی‌گیرد و انتظار رفتار آشنا دارد. اگر مسیر با صفحه واحد پیاده می‌شود، تاریخچه و بازگشت باید آگاهانه مدیریت شوند و یک کلیک کاربر را ناگهان از فرایند خارج نکند.
اعتبارسنجی را با زمان و زمینه هماهنگ کنید
خالی بودن فیلد ضروری را هنگام تلاش برای ادامه روشن کنید؛ نشان دادن خطا پیش از فرصت ورود داده ممکن است مزاحم باشد. برای قالب و محدودیت، راهنما پیش از خطا مفید است. خطا باید نام مسئله و اقدام اصلاحی داشته باشد. «اطلاعات نامعتبر است» برای مرحله‌ای با چند فیلد کافی نیست. خلاصه خطا می‌تواند به فیلد مربوط لینک بدهد و متن نزدیک فیلد نیز باقی بماند. حذف داده پس از خطا، اصلاح را دشوارتر می‌کند.
اعتبارسنجی مرورگر جای بررسی سرور را نمی‌گیرد. موجودی، اعتبار تخفیف یا امکان تحویل ممکن است بین مراحل تغییر کند. اگر پاسخ سرور دیر می‌رسد، وضعیت انتظار را نشان دهید و ارسال تکراری را کنترل کنید. خطای شبکه را با داده نادرست یکی نکنید. کاربر باید بفهمد آیا اصلاح لازم است یا تلاش دوباره. مقاله طراحی فرم‌های وب درباره توضیح فیلد و وضعیت ارسال ادامه مفیدی برای همین مرحله دارد.
ذخیره موقت را با مرز روشن طراحی کنید
Auto-save به معنی ثبت نهایی درخواست نیست. اگر داده ذخیره می‌شود، پیام وضعیت واقعی مثل «پیش‌نویس ذخیره شد» نشان دهید و زمان آخرین ذخیره موفق را در صورت نیاز مشخص کنید. در حالت قطع ارتباط، وعده ذخیره سرور ندهید. ذخیره محلی، ذخیره در حساب و ثبت سفارش سه سطح متفاوت‌اند. کاربر باید بداند با تغییر دستگاه یا مرورگر چه چیزی باقی می‌ماند. وجود یک آیکون تیک بدون توضیح این تفاوت را روشن نمی‌کند.
برای پیش‌نویس، مدت نگهداری و امکان حذف را تعیین کنید. داده حساس را صرفاً برای راحتی در Local Storage قرار ندهید؛ انتخاب محل ذخیره به نوع داده و مدل تهدید محصول وابسته است. روی دستگاه مشترک، باز شدن دوباره اطلاعات قبلی می‌تواند مسئله حریم خصوصی باشد. اگر ورود لازم است، آن را در زمان مناسب معرفی کنید و داده غیرحساس را در انتقال حفظ کنید. مقاله ورود و ثبت‌نام درباره حفظ کار در مسیر احراز هویت توضیح می‌دهد.
وابستگی‌ها و توقف‌های بیرونی را پیش‌بینی کنید
پرداخت، آپلود فایل یا بررسی هویت ممکن است کاربر را از صفحه خارج کند یا زمان بیشتری بخواهد. این‌ها فقط یک دکمه Next دیگر نیستند. پیش از انتقال، مقصد و نتیجه مورد انتظار را توضیح دهید. پس از بازگشت، وضعیت را از منبع معتبر بررسی کنید؛ رسیدن به نشانی بازگشت به تنهایی تأیید پرداخت نیست. حالت لغو و ناموفق باید راه ادامه یا اصلاح داشته باشد و سفارش تکراری ایجاد نکند. شناسه درخواست به پیگیری همین مسیر کمک می‌کند.
اگر نشست زمان محدود دارد، قبل از پایان هشدار و مسیر تمدید یا حفظ پیش‌نویس را در نظر بگیرید. شمارش معکوس نمایشی بدون ارتباط با زمان واقعی سرور خطر از دست رفتن داده را حل نمی‌کند. در آپلود، وضعیت فایل، محدودیت اندازه و امکان جایگزینی روشن باشد. ادامه مرحله بعد فقط وقتی فعال شود که شرط واقعی تکمیل شده است. طراحی خوش‌بینانه‌ای که همه دریافت‌ها را فوری و موفق فرض می‌کند، در نخستین قطع اتصال از هم می‌پاشد.
خلاصه نهایی باید قابل اصلاح باشد
پیش از اقدام نهایی، انتخاب‌های اثرگذار را با نام قابل فهم نمایش دهید: محصول، تعداد، روش تحویل و هزینه‌های مرتبط. مقدار خام کدهای داخلی برای کاربر معنی ندارد. هر گروه راه ویرایش مشخص داشته باشد و پس از اصلاح به خلاصه بازگردد. تغییر مقدار باید محاسبات وابسته را به‌روزرسانی کند. اگر مبلغ نهایی هنوز قابل تعیین نیست، همین محدودیت را بنویسید و دکمه را به عنوان پرداخت قطعی معرفی نکنید. متن اقدام باید پیامد واقعی را بیان کند.
دکمه نهایی «ثبت سفارش» با «ارسال برای برآورد» یکسان نیست. پس از موفقیت، شناسه و اقدام بعدی نشان داده شود؛ مسیر پیگیری و زمان پاسخ فقط بر اساس فرایند واقعی اعلام شود. اگر درخواست دریافت شده اما بررسی باقی است، وضعیت همین را بگوید. کاربر نباید با صفحه‌ای روبه‌رو شود که فقط تشکر می‌کند و هیچ راهی برای فهم نتیجه ندارد. مقاله صفحه محصول درباره شفافیت قیمت و تعهدات مرتبط با تصمیم خرید مفید است.
دسترسی‌پذیری و سنجش را در تحویل وارد کنید
پس از تغییر مرحله، عنوان و Focus باید زمینه تازه را روشن کنند. انتقال به یک بخش جدید بدون اعلان یا جابه‌جایی منطقی، کاربر ابزار کمکی را در مرحله قبلی نگه می‌دارد. فرم‌های مخفی نباید کنترل‌های فعال در مسیر Tab باقی بگذارند. Label و ترتیب خواندن RTL حفظ شود و پیام ذخیره یا خطا قابل دریافت باشد. اندازه کنترل‌های برگشت و ادامه باید با استفاده لمسی سازگار باشد؛ کم‌رنگ کردن برگشت برای تشویق ادامه نباید آن را ناخوانا کند.
برای سنجش، خروج از یک مرحله را همیشه شکست فرض نکنید؛ کاربر ممکن است اطلاعات لازم را جمع کند و برگردد. زمان، خطای تکراری، بازگشت برای اصلاح و تکمیل نهایی را با تعریف روشن بررسی کنید. User Research می‌تواند علت توقف را روشن کند. پیش از تحویل، یک مسیر موفق، یک اصلاح انتخاب قبلی و یک قطع ارتباط را در شرح رفتار دنبال کنید. برای هر حالت باید معلوم باشد داده کجا مانده، وضعیت چیست و اقدام بعدی کاربر کدام است.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!