בואו נדבר רגע רק על הודעות אישור ב-SMS (ספוילר, אנחנו לא מדברים רק על הודעות אישור ב-SMS). בהרבה מאוד שירותים שאנחנו משתמשים בהם מדי פעם תקפוץ הודעה של “הכנס את הקוד ששלחנו לך ב-SMS”. ממש היום זה קרה לי עם האפליקציה של בנק לאומי. וזה בסדר. אי הנוחות הזו היא חלק מהמחיר שאנחנו משלמים על כך ששירותי ה-online שלנו יהיו קצת יותר מאובטחים.
יש הרבה דרכים לכתוב את הטקסט בהודעה שנשלחה. דוגמה אחת היא ההודעה של האפליקציה של עיריית רמת גן: “קוד אימות לאפלקצית עיריית רמת גן : 78xx”. האיש שכתב את הקופי הזה עשה אחלה עבודה. יכול להיות שלא נחשוב ככה לגבי מי שכתב את ההודעה של האפליקציה של לאומי: “1614xx הוא קוד האימות שלך. הקוד ישמש אותך בהמשך התהליך. לאומי דיגיטל.”. למה נחשוב שזה מוזר? כי הניסוח פה הוא מוזר ו-counter intuitive.
מה אם אני אגיד לכם שמי שכתב את הטקסט העקום באפליקציה של לאומי עשה עבודה הרבה יותר טובה?
למה? כי ההודעות הללו נשלחות לנו כאשר אנחנו מול מסך שבו אנחנו נדרשים להקיש קוד. לרוב הטלפונים יש תצוגה מקדימה של הודעות שמגיעות. ב-use case הזה אני יכול לראות את ההודעה ולהקיש את הקוד כשאני נשאר במסך הרלוונטי ולא צריך ללכת לאפליקציית ההודעות שלי.
מתי השימוש הזה זה לא עובד? נכון, כשההודעה ארוכה מדי. ההודעה הקופצת מוגבלת במספר התווים שהיא מציגה על המסך ולכן הקדמה ארוכה מגדילה את הסיכוי שהמשתמש לא יראה את הקוד ויאלץ לעזוב את האפליקציה שהוא משתמש ,בה יעבור לאפליקצית ההודעות, ישנן את מספר האישור, יעבור חזרה לאפליקציה הרלוונטית, ויקיש את המספר. בעוד שככל שנציין את הקוד עצמו כמה שיותר בתחילת ההודעה אנחנו מגדילים את הסיכוי שהקוד יופיע בתצוגה המקדימה. יש גם פתרונות ביניים כמו ההודעה של אלטשולר שחם שמשלבת קצת יותר קריאות עם הקדמת הקוד “שלום, 7757xx הנו קוד האימות החד פעמי שלך לכניסה לאתר אלטשולר שחם.”
אז מה הלקח פה?
הלקח הוא שכשמתכננים מוצר מבלי להבין את ההקשר של השימוש בו יוצרים מוצר פחות טוב. הבעיה פה היא שההודעה ארוכה מדי ולא ניתן לראות את הקוד בתצוגה המקדימה. זו בעיה שהייתי רוצה לחשוב שכל מנהל מוצר היה רואה מייד אם הוא היה משתמש במערכת שהוא אפיין.
מה הפתרון?
לעשות את העבודה, זה אומר:
- לגלות מהו ה-use case הנפוץ של הפיצ’ר שאתם מאפיינים
- לגלות מה עמדת הקצה הנפוצה בשימוש על ידי המשתמשים ומה המגבלות שלה
- לחוות את התהליך בעצמנו על ידי שימוש בפיצ’ר
- לעשות ראיונות עם משתמשים בכדי לגלות איפה הדברים שמפריעים להם
אורי, זה לא עניין ממש קטן? למה להתעכב על זה?
זה לא עניין קטן. להיפך. זה אחד מהדברים שיציקו למשתמשים שלנו בלי שהם ירגישו איפה הבעיה. משתמש כנראה אף פעם לא יגיד “מבאס אותי שכל פעם שאני נכנס לאתר אני צריך לעבור לאפליקציה של ההודעות ובחזרה ולזכור מספר”, הוא פשוט לא ירצה להשתמש באפליקציה שלכם. ויום אחד הוא יעבור למוצר מתחרה אחר וירגיש שיותר קל לו להשתמש במוצר המתחרה מבלי שהוא מעולם יבין מה השתנה. ואז הוא יספר לחברים על זה שהמוצר המתחרה יותר טוב. מבלי בכלל שהוא יבין למה. אז להיפך, בגלל שהבעיה היא “בלתי נראית” למשתמש לא נוכל מאוחר יותר לשכנע את המשתמש שפתרנו אותה, ששווה לו לחזור אלינו. תזכרו, כל חוויות המשתמש הטובות, נוחות באותה הדרך, אבל כל חווית משתמש גרועה, גרועה בדרכה שלה.
