איך כותבים הודעות שגיאה יעילות ואנושיות

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

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

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

ועכשיו, בואו נצלול לפרקטיקה. 

מבנה ההודעה

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

בהירות ופשטות 

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

זה יכול להיראות ככה לדוגמה:

מינימום טרמינולוגיה וז'רגון מקצועי 

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

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

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

הומור בהודעות שגיאה

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

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

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

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

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