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

עיצוב מסך ההזמנה: היכן אובדת המרת הצ'קאאוט

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה אנו מוסרים לצוות שלכם בסיום הפרויקט

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

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

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

מקרה בוחן: פחות סלים נטושים בשלב האחרון

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

מה שינינו

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

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

מה יצא

שיעור הרכישות שהושלמו עלה מ-62% ל-79%, סלים נטושים בשלב התשלום הצטמצמו בשליש, זמן ביצוע ההזמנה הממוצע — מ-3.5 דקות לדקה ו-10 שניות. ניסיונות תשלום חוזרים החזירו 18% מהסירובים שאבדו קודם בשקט.

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

מה לעשות אם הצ'קאאוט כבר בנוי ועובד

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

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

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

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

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

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

שאלות נפוצות על תכנון צ'קאאוט

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

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

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

מה עם תמיכה לאחר ההשקה?

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

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

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

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

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

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

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