עיצוב מצבים ריקים של מסכים באפליקציית מובייל

עיצוב מצבים ריקים: היכן המסך מאבד את המשתמש

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

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

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

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

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

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

מה נותנת עבודה מעמיקה על מסכים: תוצאות מדידות

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

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

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

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

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

גישות לעיצוב מסכים: טבלת השוואה

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

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

שלבי עבודה: ממלאי מסכים ועד מסירה

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

1. מלאי מסכים. עבור כל מסך מתעדים מצבים: הפעלה ראשונה, ריק לאחר סינון, אין תוצאות, שגיאת רשת, סירוב הרשאה, טעינה. התוצאה — טבלה מסכמת, משותפת לעיצוב ולבקלוג.
2. תעדוף מצבים. ממיינים את הענפים לפי תדירות ומחיר הטעות: רשימה ריקה לאחר סינון רואים כולם, סירוב גישה — מעטים, אבל הוא קורע את התרחיש כולו. קודם מטפלים במה ששובר את המסלול העיקרי.
3. סכמות התנהגות. מתארים מה המשתמש רואה, לאן מובילה הפעולה הראשית וכמה צעדים עד לתוכן הראשון; מחליטים היכן מספיק רמז והיכן נדרש הדרכה.
4. תיאום טקסטים. טון, אורך למעבר שורה, פנייה, לוקליזציה ושפות עם כתיבה מימין לשמאל — מתאמים עם המוצר והתמיכה. הטקסט מסביר את הסיבה, ולא מציין את הריקות.
5. מוקאפים. סט אחד של רכיבים: ערכת נושא בהירה וכהה, גופן מערכת גדול, שמות ארוכים, שלדים במקום אינדיקטור. אייקונים ואיורים מוגדרים בטוקנים, כדי שמסך חדש לא יצויר מאפס.
6. בדיקה על נתונים אמיתיים. מריצים את המוקאפים על תגובות חיות: רשימה כמעט ריקה, כותרות חתוכות, שגיאה בלי רשת, הפעלה ראשונה במכשיר נקי. כך צפים ענפים שנראים עובדים על נתוני הדגמה.
7. מסירה לפיתוח. מפת מצבים, כללי תצוגה, טקסטים, טוקנים וקריטריוני קבלה: המפתח רואה מתי המצב מופעל, הבודק — מה נחשב לפגם.

חבילת אספקה: מוקאפים, תיאורים וכללי מסך

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

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

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

מקרה בוחן: איך צמצמנו נטישות בהפעלה הראשונה

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

מה שינינו בהתנהגות המסכים

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

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

חודש לאחר השחרור: נטישות בהפעלה הראשונה — 58% → 31%, עד לפעולה ממוקדת מטרה ראשונה — 23% → 49%, חזרות ביום השלישי — 16% → 29%. פניות לתמיכה "הנתונים נעלמו" הצטמצמו פי שלושה — האפקט נבע מהפרדת מצבי שגיאה ומצבים ריקים.

במה מצב "אין נתונים" שונה משגיאת טעינה?

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

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

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

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

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

ספקות טכניים: מפרקים מקרים מורכבים

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

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

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

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

מי אחראי לטקסטים עבור המסכים?

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

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

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

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

לאחר אבחון המסכים נחזור עם דברים קונקרטיים:

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

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