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