מה האפליקציה שלך צריכה להגיד כשהיא נשברת: כתיבת הודעות שגיאה שאנשים באמת מבינים

הודעת שגיאה טובה אומרת מה קרה, של מי האשמה, מה לעשות הלאה, ולא מוחקת את העבודה של המשתמש - כך רגע שבור הופך לניסיון חוזר במקום למשתמש שנוטש את האפליקציה שלך לצמיתות.

כל אפליקציה נשברת מדי פעם. האינטרנט נופל, שרת מגמגם, מישהו מקליד מספר טלפון עם אותיות בטעות. את זה אי אפשר למנוע לגמרי. מה שכן אפשר לשלוט בו זה הודעת השגיאה - הטקסט שהאפליקציה שלך מציגה כשמשהו משתבש - וההודעה הזו לבדה היא לרוב ההבדל בין משתמש שמושך בכתפיים ומנסה שוב, לבין משתמש שמחליט בשקט שהאפליקציה שלך מקולקלת ולא חוזר יותר.

רוב האפליקציות שנבנות עם AI מפספסות בדיוק את הרגע הזה. לא כי הבילדר עשה משהו רשלני, אלא כי הודעות שגיאה הן החלק שאף אחד לא חושב עליו עד שמשהו משתבש מול אדם אמיתי. כברירת מחדל, אפליקציות נוטות להציג אחד משני הדברים הגרועים ביותר: כלום, או קופסה מפחידה של טקסט טכני. בואו נתקן את שניהם.

למה אפליקציות נכשלות בשקט או מציגות הודעות שגיאה מפחידות?

אפליקציות נשברות בצורה גרועה באחת משתי דרכים: הן לא אומרות כלום כשמשהו נכשל, או שהן מציגות שגיאה טכנית שאדם רגיל לא מסוגל לקרוא. שני המקרים משאירים את המשתמש מנחש, וניחוש הוא בדיוק מה שגורם לאנשים לוותר.

הכישלון השקט. פרילנסרית שאקרא לה מאיה בנתה טופס הזמנת תורים לעסק הצילום שלה. לקוחה לחצה על “אישור הזמנה”, הכפתור הבהב, ו… כלום. בלי אישור, בלי שגיאה, בלי גלגל טעינה. זה עבד? הלקוחה לא הייתה בטוחה, אז היא הזמינה שוב. עכשיו למאיה היו שתי הזמנות לאותו סלוט וגם לקוחה מבולבלת. האפליקציה לא קרסה - השמירה פשוט נכשלה, והאפליקציה לא אמרה כלום, אז לאדם שעמד מולה לא היה מושג מה המצב באמת.

שגיאת הטכנולוגיה המפחידה. הכישלון השני רועש יותר ובאיזשהו אופן גרוע יותר. מתנדבת שהפעילה גיוס תרומות קהילתי ניסתה להעלות גיליון אקסל וקיבלה תיבה אדומה שאמרה Error 500: Internal Server Error. היא קראה את זה בתור “שברתי משהו”. היא לא ניסתה שוב, לא שלחה מייל לעזרה, פשוט סגרה את הטאב - כי ההודעה גרמה לבעיה להישמע כאילו זו אשמתה וכאילו אולי לא בטוח לגעת בזה שוב.

שני המשתמשים נתקלו בבעיה רגילה וניתנת לתיקון. שניהם הלכו משם, כי הודעות השגיאה של האפליקציה או שלא אמרו כלום, או שאמרו משהו מפחיד.

מה הופך הודעת שגיאה לטובה?

הודעת שגיאה טובה עושה ארבעה דברים קטנים, במילים פשוטות: היא אומרת מה קרה, אומרת של מי הבעיה, אומרת מה לעשות הלאה, ולא מאבדת את העבודה של המשתמש.

  1. אומרת מה קרה - “לא הצלחנו לשמור את ההזמנה שלך”, לא שתיקה ולא 500.
  2. אומרת של מי הבעיה - לרוב התשובה הכנה היא “שלנו”, ולומר את זה מרגיע אנשים.
  3. אומרת מה לעשות הלאה - “נסו שוב בעוד רגע” או “בדקו את חיבור האינטרנט ונסו שוב”.
  4. לא מאבדת את העבודה שלהם - מה שהם הקלידו עדיין נמצא בטופס כשההודעה מופיעה.

זהו. בלי חיבור התנצלות, בלי קוד שגיאה ככותרת, בלי האשמה. הנה אותם שלושה כישלונות, כתובים מחדש:

  • ❌ (כלום לא קורה) ← ✅ “לא הצלחנו לשמור את זה כרגע. הפרטים שלך עדיין כאן - לחצו על אישור כדי לנסות שוב.”
  • ❌ Error 500: Internal Server Error ← ✅ “משהו השתבש אצלנו בהעלאת הקובץ. זו לא אשמתכם. נסו שוב בעוד דקה.”
  • ❌ Invalid input ← ✅ “מספר הטלפון הזה לא נראה תקין - הוא צריך להיות 10 ספרות, כמו 555-123-4567.”

שימו לב שהאחרונה מצביעה על השדה ה_ספציפי_ ומראה איך זה אמור להיראות. “קלט לא תקין” גורם למישהו לחפש; “מספר הטלפון הזה צריך להיות 10 ספרות” אומר לו בדיוק מה לשנות.

אילו שגיאות אפליקציה כדאי לתקן קודם?

אתם לא צריכים הודעה מותאמת אישית לכל כישלון אפשרי - שלוש קטגוריות מכסות כמעט הכל ממה שמשתבש באפליקציה טיפוסית: השמירה או השליחה שנכשלת, הקלט שהאפליקציה לא מצליחה להשתמש בו, והדבר שנשבר אצלכם.

השמירה או השליחה שנכשלת. הכי הורסת אמון, כי המשתמש עשה הכל נכון ולא בטוח אם זה עבד. תמיד אשרו הצלחה וגם הסבירו כישלון. אף פעם אל תשאירו אותם מנחשים, ואף פעם אל תזרקו את מה שהם הקלידו.

“אנחנו לא יכולים להשתמש במה שהקלדתם” (ולידציה). זו לא באמת שגיאה - זו אי-הבנה. תפסו אותה ברגע שהם עוזבים את השדה, הצביעו על השדה המדויק, והראו דוגמה לפורמט הנכון. אל תחכו עד שהם ילחצו על שליחה כדי לחשוף חומה של אדום.

“משהו אצלנו נשבר”. בעיות שרת או רשת אמיתיות. תגידו שזה אצלכם, שמרו על טון רגוע, ותנו להם אפשרות לנסות שוב. המשתמש לא יכול לתקן את השרת שלכם, אז אל תגרמו לו להרגיש שהוא חייב.

שלוש הרגלים שעוזרים בשקט

כמה דברים מבדילים בין אפליקציות שמתמודדות עם כישלון בחן לבין כאלה שלא:

  • לעולם אל תציגו קוד שגיאה גולמי כהודעה השלמה. קוד יכול לשבת בטקסט קטן למטה לצורך תמיכה, אבל הכותרת שאדם קורא צריכה להיות משפט, לא ERR_CONN_RESET.
  • לעולם אל תאשימו את המשתמש. “הזנתם משהו לא נכון” צורב; “התאריך הזה נראה כאילו הוא בעבר - התכוונתם לחודש הבא?” עוזר. אותו מידע, תחושה שונה לגמרי.
  • תמיד שמרו על הקלט שלהם. אם האפליקציה נטענת מחדש או השמירה נכשלת והטופס מתרוקן, הפכתם תקלה קטנה לעשר דקות של הקלדה מחדש. אנשים סולחים על שמירה שנכשלה. הם לא סולחים על עשיית העבודה פעמיים.

איך גורמים לבילדר ה-AI שלכם לכתוב הודעות שגיאה טובות יותר?

אתם יכולים לקבל את רוב זה בבקשה אחת - הדביקו משהו כמו הפרומפט למטה ובילדר ה-AI שלכם יישם את כללי השפה הפשוטה שלמעלה על כל האפליקציה שלכם.

“כשהשמירה או ההעלאה נכשלות, אל תיכשלו בשקט ואל תציגו קוד שגיאה טכני. הציגו הודעה קצרה וידידותית בשפה פשוטה שאומרת מה קרה, אומרת שזה בסדר לנסות שוב, ושומרת על כל מה שהמשתמש כבר הקליד. עבור שדות טופס, בצעו ולידציה כשהמשתמש עוזב כל שדה והציגו הודעה ספציפית עם דוגמה לפורמט הנכון.”

אחר כך בקשו ממנו להעביר אתכם על מה שקורה בשלושה מקרים: האינטרנט כבוי, שדה חובה ריק, והשרת איטי. אם התשובה לאחד מהם היא “זה לא מציג כלום” או “זה מציג את השגיאה הגולמית”, זה התיקון הבא שלכם.

איך בודקים את הודעות השגיאה של האפליקציה שלכם?

כבו את הוויפיי, פתחו את האפליקציה שלכם, ונסו לעשות את הדבר המרכזי - זה כל המבחן, ולוקח שתי דקות.

הזמינו תור, שמרו הערה, העלו קובץ. תראו מה זה אומר. זה אמר משהו שאדם רגיל היה מבין? זה איבד את מה שהקלדתם? עכשיו הפעילו את הוויפיי בחזרה והקלידו בכוונה שטויות לתוך שדה. אותן שאלות.

רוב האפליקציות נכשלות במבחן הזה בפעם הראשונה, וזה בסדר - זה פשוט מראה לכם בדיוק מאיפה להתחיל. אתם לא חייבים להפוך כל הודעת שגיאה למושלמת. מצאו את הדבר האחד באפליקציה שלכם שנשבר הכי הרבה, ותהפכו את ההודעה הזו לאדיבה, ברורה וכנה קודם. בפעם הבאה שאדם אמיתי ייתקל בה, הוא ינסה שוב במקום לעזוב - וניסיון חוזר הוא כל המשחק.