وقتی برنامه‌تان خراب می‌شود باید چه بگوید: نوشتن پیام‌های خطایی که مردم واقعاً می‌فهمند

یک پیام خطای خوب می‌گوید چه اتفاقی افتاده، تقصیر چه کسی است، بعدش باید چه کار کرد، و کار کاربر را پاک نمی‌کند — لحظه‌ای خراب را به یک تلاش دوباره تبدیل می‌کند، نه به این‌که کسی برای همیشه برنامه شما را رها کند.

هر برنامه‌ای گاهی خراب می‌شود. اینترنت قطع می‌شود، سروری دچار مشکل می‌شود، کسی شماره تلفنی را با حروف تایپ می‌کند. این بخش را نمی‌توانید کاملاً پیشگیری کنید. چیزی که می‌توانید کنترل کنید، پیام خطا است — متنی که برنامه‌تان وقتی چیزی خراب می‌شود نشان می‌دهد — و همان یک پیام اغلب فرق است بین کاربری که شانه بالا می‌اندازد و دوباره تلاش می‌کند، و کاربری که آرام تصمیم می‌گیرد برنامه شما خراب است و دیگر برنمی‌گردد.

بیشتر برنامه‌های ساخته‌شده با هوش مصنوعی دقیقاً همین لحظه را اشتباه می‌گیرند. نه به این دلیل که سازنده کاری بی‌دقتانه انجام داده، بلکه چون پیام‌های خطا بخشی هستند که تا وقتی چیزی جلوی چشم یک فرد واقعی خراب نشود، کسی به آن فکر نمی‌کند. به‌طور پیش‌فرض، برنامه‌ها معمولاً یکی از دو بدترین حالت ممکن را نشان می‌دهند: هیچ‌چیز، یا یک بلوک ترسناک از متن فنی. بیایید هر دو را درست کنیم.

چرا برنامه‌ها بی‌صدا شکست می‌خورند یا پیام‌های خطای ترسناک نشان می‌دهند؟

برنامه‌ها به یکی از دو شکل بد خراب می‌شوند: وقتی چیزی شکست می‌خورد هیچ نمی‌گویند، یا خطایی فنی نشان می‌دهند که یک آدم عادی نمی‌تواند بخواند. هر دو کاربر را در حدس‌وگمان رها می‌کنند، و حدس‌زدن همان چیزی است که مردم را وادار به رهاکردن می‌کند.

شکست بی‌صدا. فریلنسری که او را مایا می‌نامم، فرمی برای رزرو کسب‌وکار عکاسی‌اش ساخته بود. مشتری روی «تأیید رزرو» زد، دکمه چشمک زد، و… هیچ اتفاقی نیفتاد. نه تأییدیه‌ای، نه خطایی، نه چرخانکی. آیا کار کرد؟ مشتری مطمئن نبود، پس دوباره رزرو کرد. حالا مایا دو رزرو برای یک بازه زمانی و یک مشتری گیج داشت. برنامه از کار نیفتاده بود — فقط ذخیره‌سازی شکست خورده بود، و برنامه هیچ چیز نگفته بود، پس شخصِ روبه‌روی آن هیچ ایده‌ای نداشت واقعیت چیست.

خطای فنی ترسناک. شکست دیگر پرسروصداتر و به‌نوعی بدتر است. داوطلبی که یک کمپین جمع‌آوری کمک مالی محلی را اداره می‌کرد، سعی کرد یک صفحه‌گسترده آپلود کند و کادری قرمز دید که نوشته بود Error 500: Internal Server Error. او آن را این‌طور خواند که «من چیزی را خراب کردم». دیگر تلاش نکرد، برای کمک ایمیل نزد، فقط تب را بست — چون پیام، مشکل را طوری جلوه می‌داد که انگار تقصیر خودش است و انگار شاید دست‌زدن دوباره به آن امن نباشد.

هر دو کاربر با یک مشکل عادی و قابل‌جبران روبه‌رو شدند. هر دو رفتند، چون پیام‌های خطای برنامه یا هیچ نگفتند یا چیزی ترسناک گفتند.

یک پیام خطای خوب چه چیزی را دارد؟

یک پیام خطای خوب چهار کار کوچک را با کلمات ساده انجام می‌دهد: می‌گوید چه اتفاقی افتاده، می‌گوید تقصیر چه کسی است، می‌گوید بعدش باید چه کار کرد، و کار کاربر را از دست نمی‌دهد.

۱. می‌گوید چه اتفاقی افتاده — «نتوانستیم رزرو شما را ذخیره کنیم»، نه سکوت و نه 500. ۲. می‌گوید تقصیر چه کسی است — معمولاً پاسخ صادقانه «ما هستیم»، و گفتن این باعث آرام‌شدن مردم می‌شود. ۳. می‌گوید بعدش باید چه کار کرد — «چند لحظه دیگر دوباره امتحان کنید» یا «اتصال اینترنت خود را بررسی کنید و دوباره تلاش کنید». ۴. کار آن‌ها را از دست نمی‌دهد — هر چیزی که تایپ کرده بودند، وقتی پیام ظاهر می‌شود، هنوز در فرم نشسته است.

همین. نه یک انشای عذرخواهی، نه کد خطا به‌عنوان تیتر، نه سرزنش. این هم همان سه شکست، بازنویسی‌شده:

  • ❌ (هیچ اتفاقی نمی‌افتد) ← ✅ «الان نتوانستیم آن را ذخیره کنیم. جزئیات شما هنوز اینجاست — برای تلاش دوباره روی تأیید بزنید.»
  • ❌ Error 500: Internal Server Error ← ✅ «هنگام آپلود آن فایل، سمت ما مشکلی پیش آمد. تقصیر شما نیست. یک دقیقه دیگر دوباره امتحان کنید.»
  • ❌ Invalid input ← ✅ «این شماره تلفن درست به نظر نمی‌رسد — باید ۱۰ رقم باشد، مثل ۵۵۵-۱۲۳-۴۵۶۷.»

توجه کنید مثال آخر دقیقاً به فیلد مشخصی اشاره می‌کند و نشان می‌دهد فرمت درست چه شکلی است. «Invalid input» کاربر را وادار به جست‌وجو می‌کند؛ «این شماره تلفن باید ۱۰ رقم باشد» دقیقاً می‌گوید چه چیزی را باید تغییر دهد.

کدام خطاهای برنامه را باید اول درست کنید؟

نیازی نیست برای هر شکست ممکن پیامی سفارشی بسازید — سه مورد تقریباً همه‌چیزی را که در یک برنامه معمولی خراب می‌شود پوشش می‌دهد: ذخیره یا ارسالی که شکست می‌خورد، ورودی‌ای که برنامه نمی‌تواند از آن استفاده کند، و چیزی که سمت شما خراب می‌شود.

ذخیره یا ارسالی که شکست می‌خورد. ویران‌کننده‌ترین مورد از نظر اعتماد، چون کاربر همه‌چیز را درست انجام داده و مطمئن نیست کار کرده یا نه. همیشه موفقیت را تأیید کنید و شکست را توضیح دهید. هرگز آن‌ها را در حدس‌وگمان رها نکنید، و هرگز چیزی را که تایپ کرده‌اند دور نریزید.

«نمی‌توانیم از چیزی که تایپ کردید استفاده کنیم» (اعتبارسنجی). این واقعاً یک خطا نیست — یک سوءتفاهم است. آن را همان لحظه‌ای که کاربر فیلد را ترک می‌کند بگیرید، دقیقاً به همان فیلد اشاره کنید، و نمونه‌ای از فرمت درست نشان دهید. منتظر نمانید تا کاربر روی «ارسال» بزند تا دیواری از قرمز نمایان شود.

«چیزی سمت ما خراب شد». مشکلات واقعی سرور یا شبکه. بگویید که مشکل سمت شماست، آرام باشید، و امکان تلاش دوباره بدهید. کاربر نمی‌تواند سرور شما را درست کند، پس کاری نکنید که احساس کند مجبور است این کار را انجام دهد.

سه عادت که آرام‌آرام کمک می‌کنند

چند چیز برنامه‌هایی را که با شکست به‌خوبی برخورد می‌کنند از بقیه جدا می‌کند:

  • هرگز یک کد خطای خام را کل پیام قرار ندهید. یک کد می‌تواند با فونت کوچک، پایین پیام، برای پشتیبانی بماند، اما تیتری که یک انسان می‌خواند باید یک جمله باشد، نه ERR_CONN_RESET.
  • هرگز کاربر را سرزنش نکنید. «چیزی را اشتباه وارد کردید» آزاردهنده است؛ «این تاریخ به نظر می‌رسد گذشته است — منظورتان ماه بعد بود؟» کمک‌کننده است. همان اطلاعات، حسی کاملاً متفاوت.
  • همیشه ورودی آن‌ها را نگه دارید. اگر برنامه دوباره بارگذاری شود یا ذخیره‌سازی شکست بخورد و فرم خالی شود، یک ناراحتی کوچک را به ده دقیقه تایپ دوباره تبدیل کرده‌اید. مردم یک ذخیره‌سازی شکست‌خورده را می‌بخشند. دوبار انجام‌دادن کار را نمی‌بخشند.

چطور از سازنده هوش مصنوعی خود بخواهید پیام‌های خطای بهتری بنویسد؟

می‌توانید بیشتر این‌ها را در یک درخواست بگیرید — چیزی شبیه پرامپت زیر را بچسبانید و سازنده هوش مصنوعی شما قوانین زبان ساده بالا را در کل برنامه‌تان اعمال می‌کند.

«وقتی ذخیره‌سازی یا آپلودی شکست می‌خورد، نه بی‌صدا شکست بخور و نه کد خطای فنی نشان بده. یک پیام کوتاه و دوستانه به زبان ساده نشان بده که می‌گوید چه اتفاقی افتاده، می‌گوید اشکالی ندارد دوباره تلاش شود، و هر چیزی را که کاربر قبلاً تایپ کرده نگه می‌دارد. برای فیلدهای فرم، در لحظه‌ای که کاربر هر فیلد را ترک می‌کند اعتبارسنجی کن و پیامی مشخص همراه با نمونه‌ای از فرمت درست نشان بده.»

بعد از آن بخواهید توضیح دهد در سه حالت چه اتفاقی می‌افتد: اینترنت قطع است، یک فیلد اجباری خالی است، و سرور کند است. اگر پاسخ به هر کدام از این‌ها «هیچ چیز نشان نمی‌دهد» یا «خطای خام را نشان می‌دهد» باشد، آن نقطه بعدی برای اصلاح شماست.

چطور پیام‌های خطای برنامه‌تان را تست کنید؟

وای‌فای خود را خاموش کنید، برنامه‌تان را باز کنید، و سعی کنید کار اصلی را انجام دهید — کل تست همین است، و دو دقیقه طول می‌کشد.

آن بازه زمانی را رزرو کنید، یادداشت را ذخیره کنید، فایل را آپلود کنید. ببینید چه می‌گوید. آیا چیزی گفت که یک آدم عادی متوجه شود؟ آیا چیزی را که تایپ کرده بودید از دست داد؟ حالا وای‌فای را دوباره روشن کنید و عمداً چیزهای بی‌معنی در یک فیلد تایپ کنید. همان سؤال‌ها.

بیشتر برنامه‌ها بار اول این تست را رد می‌شوند، و اشکالی ندارد — این فقط دقیقاً نشان می‌دهد از کجا باید شروع کنید. لازم نیست هر پیام خطا را کامل کنید. آن یک چیزی را در برنامه‌تان پیدا کنید که بیشتر از همه خراب می‌شود، و اول همان پیام را مهربان، روشن و صادقانه کنید. دفعه بعد که یک آدم واقعی به آن برخورد کند، به‌جای رفتن، دوباره تلاش می‌کند — و دوباره تلاش‌کردن کل بازی است.