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