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