עיצוב מסך קטלוג המוצרים של אפליקציית מובייל

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

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

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

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

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

מה משנה עיבוד מחדש של הניווט והכרטיסים

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

את המיקומים והמחוות אנו מצליבים עם Apple Human Interface Guidelines — אין צורך להסביר מחדש אלמנטים מוכרים.

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

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

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

פורמטי תצוגה: רשימה, אריחים, פיד, היברידי

פורמט התצוגה הוא החלטה על צפיפות, ולא על עיצוב: כמה פריטים רואה האדם על המסך וכמה נגיעות נדרשות עד הכרטיס. רשימה מכילה 6–8 פריטים עם שם, מחיר וכפתור פעולה, אריחים — 4–6 עם תמונה גדולה, פיד — 2–3 עם תמונה ברוחב מלא.

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

במה נבדלים המצבים

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

שלבי העבודה על ממשק הויטרינה

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

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

תארו את המשימה — נחזור עם הערכה ותוכנית לפי שלבים.

מוקאפים, מצבי מסך וכללי פריסה

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

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

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

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

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

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

מה שינו

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

מדדים לפני ואחרי

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

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

מה לעשות אם הויטרינה כבר בנויה על תבנית מוכנה?

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

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

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

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

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

ספקות טכניים לפני תחילת העבודה

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

אפשר לשחרר שינויים בחלקים?

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

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

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

נדון במשימה: מה לשלוח לשם הערכה

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

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

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