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