עיצוב דשבורד ל-SaaS: 7 עקרונות שמורידים churn

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

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

למה משתמשים נוטשים דשבורד

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

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

הנטישה מגיעה בשלושה תסריטים חוזרים:

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

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

עיקרון 1: היררכיה של נתונים – מדד אחד שולט

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

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

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

עיקרון 2: Empty states שמייצרים את הפעולה הראשונה

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

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

הטריק שעובד הכי טוב: הצגת דוגמת נתונים (sample data) עם שכבת שקיפות וכיתוב ברור שזו תצוגה מקדימה. המשתמש רואה מה הוא עומד לקבל, והרצון לראות את המספרים שלו במקום המספרים המדומים הוא המנוע שמזיז אותו לפעולה. Empty state שמעוצב כך מוריד את זמן ההגעה לערך הראשון ב-30-50% בפרויקטים שמדדנו.

עיקרון 3: Onboarding בתוך המוצר, לא לידו

סיור מודרך של תשע בועות שקופצות אחת אחרי השנייה הוא הדרך המהירה ביותר ללמד משתמש ללחוץ "דלג". Onboarding אפקטיבי לא מלמד את הממשק, הוא מוביל למשימה הראשונה שמייצרת ערך.

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

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

דשבורד שדורש הסבר הוא דשבורד שנכשל. משתמש שמבין מה לעשות תוך שלוש שניות לא מבטל מנוי.— RAMS Studio

עיקרון 4: מהירות תפיסה לפני מהירות טעינה

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

מה שעובד בפועל:

• Skeleton screens במקום ספינרים. הם מציגים את מבנה המסך מיד ומורידים את תחושת ההמתנה.
• טעינה לפי עדיפות. המדד הראשי נטען ראשון, גרפים היסטוריים אחריו, טבלאות פירוט אחרונות.
• ערכי השוואה מובנים. 4,230 המרות זה מספר. "4,230 המרות, +18% מהחודש הקודם" זו תובנה. כל מדד ראשי חייב לבוא עם הקשר.

עיקרון 5: דשבורד לפי תפקיד, לא דשבורד אחד לכולם

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

הפתרון לא חייב להיות שלושה דשבורדים נפרדים. מספיקה תצוגת ברירת מחדל לפי תפקיד שנבחר ב-onboarding, עם אפשרות להתאמה. שאלה אחת בהרשמה ("מה התפקיד שלך?") מספיקה כדי להציג לכל משתמש את המסך שהוא באמת צריך מהיום הראשון.

עיקרון 6: צפיפות מבוקרת ומערכת עיצוב עקבית

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

צפיפות היא כלי, לא מטרה. טבלת נתונים יכולה להיות צפופה, בתנאי שהאזור שמעליה נושם. אנחנו עובדים עם מערכת מרווחים על בסיס 8px, שבה כרטיסי מדדים מקבלים ריפוד של 24-32px וטבלאות מקבלות שורות בגובה 40-48px. ההבדל בין השניים אומר למשתמש בלי מילים: זה לסריקה מהירה, זה לעבודה מעמיקה.

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

עיקרון 7: CTA – כל מספר מוביל לפעולה

דשבורד שמציג נתונים בלבד הוא דוח. דשבורד שמוריד churn מציג נתונים ואומר מה לעשות איתם. זה ההבדל בין "שיעור הנטישה בעגלה עלה ל-72%" לבין "שיעור הנטישה בעגלה עלה ל-72%. 80% מהנטישות בשלב המשלוח. בדוק את דמי המשלוח".

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

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

שורה תחתונה

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

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