לבדוק את האפליקציה שבניתם עם AI כמו זר (לפני שהמשתמשים שלכם ימצאו את הבאגים)

למה באגים צצים רק כשמישהו אחר משתמש באפליקציה שלכם?

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

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

עמית לעבודה מנסה: בוחר תאריך, רואה שאזור הזמן שגוי. בלבול. הוא עוזב.

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

חבר שלכם בנייד: בורר התאריכים לא עובד (הוא לא מצליח להקיש על השדה).

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

איך בודקים אפליקציה כמו שזר היה בודק?

תנו את האפליקציה שלכם למישהו שלא יודע שהיא בכלל קיימת, צפו בו מנסה אותה “קר”, ורשמו מה נשבר או מבלבל אותו. אתם לא צריכים צוות QA. אתם צריכים אדם אחד ו-10 דקות.

שיטה ראשונה: לשאול אדם אמיתי (לוקח 15 דקות)

שלחו הודעה לחבר: “אתה יכול לנסות את זה ממש מהר ולהגיד לי מה דעתך?” תנו לו את הקישור, תנו לו לחטט בערך 5–10 דקות, ואז תשאלו:

• מה ניסית לעשות?
• זה עבד כמו שציפית?
• מה בלבל אותך?
• מה היית משנה?

תקבלו הפתעות. “לא מצאתי את כפתור השליחה” (כי הסתרתם אותו בחלון קופץ). “לא ידעתי שאני צריך למלא את האימייל” (כי לא סימנתם אותו כשדה חובה). “למה ההזמנה שלי אמרה יום שלישי כשבחרתי יום רביעי?” (בעיית אזור זמן שלא שמתם לב אליה).

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

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

שיטה שנייה: לבדוק במכשיר שאתם לא רגילים אליו (לוקח 5 דקות)

אם בניתם מהמחשב, בדקו מהטלפון. אם בניתם מהטלפון, בדקו מטאבלט.

פתחו את האפליקציה. נסו:

• להקיש על כפתור שקרוב לקצה (אולי הוא חתוך)
• לגלול בלי לחשוב (זה עובד?)
• למלא תאריך (יש בורר תאריכים אמיתי, או שהיא מצפה להקלדה?)
• לצלם תמונה אם האפליקציה שלכם מטפלת בתמונות (איזה פורמט, איזה גודל, כמה מהר?)

רוב בוני ה-AI בונים פריסות רספונסיביות די טוב, אבל תתפלאו מה נשבר ברוחב של 375 פיקסלים או בחיבור איטי.

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

הקאץ’: זה טוב רק כמו הסבלנות שלכם. בדקו זרימה אחת, מההתחלה ועד הסוף, במכשיר. אל תעשו סיור; תבצעו את המשימה.

שיטה שלישית: מבחן רשימת הבדיקה (לוקח 10 דקות)

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

1. פתחו את האפליקציה. אל תזכרו מה בניתם. מה לדעתכם האפליקציה הזו עושה?
2. בחרו את הדבר הראשון שנראה לחיץ. אל תחשבו על מה שרציתם שהוא יעשה. הוא עושה את מה שהייתם מנחשים?
3. נסו להשלים את המשימה המרכזית (להזמין משהו, למלא טופס, ליצור פוסט) בלי להסתכל בטקסט העזרה. זה עבד בניסיון הראשון?
4. חפשו שדות חובה. הם מסומנים בבירור? (צבע בלבד לא נראה לכולם.)
5. עשו טעות (השאירו משהו ריק, הזינו נתונים לא תקינים). האפליקציה אומרת לכם מה לא בסדר?
6. נסו מהטלפון. אתם מצליחים לקרוא את הטקסט? להקיש על הכפתורים?

זה לא תחליף לבודקים אמיתיים, אבל זה עדיף על שחרור של משהו שלא נבדק בכלל.

למה כדאי לשים לב כשמישהו בודק את האפליקציה שלכם?

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

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

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

מצב השגיאה: אם משהו נכשל — שגיאת רשת, שגיאת ולידציה, timeout — האפליקציה אומרת להם מה לעשות בקשר לזה? או שהיא סתם מציגה תיבה אדומה כועסת?

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

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

הבונה שלכם יכול לתקן את הבאגים שהזרים מוצאים?

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

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

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

מבחן הזר, בכל פעם

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

תגלו:

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

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

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