הנחה מוטעית
כשבונים מוצר SaaS B2B, ובמיוחד בתחום הסייבר, הנטייה הטבעית היא להתמקד בפונקציונליות של המוצר - סט היכולות הטכניות והפיצ׳רים. לרוב, הדרישות מגיעות מהשוק, מצוותי המכירות, מהלקוחות או מול המתחרים - עוד יכולת, תמיכה בתרחיש נוסף, קונפיגורציה חדשה, או עוד צ׳ק בוקס שאפשר לסמן. ככל שמוסיפים יותר פונקציות, המוצר נוטה להפוך למסובך ומורכב יותר לשימוש. לעיתים זה נתפס כפשרה לגיטימית - להתעלם במידת מה מהשימושיות והפשטות לטובת ריבוי יכולות, במיוחד כאשר קהל היעד הוא אנשי מקצוע טכניים.
הניסיון שלנו הראה שגם במוצרי B2B, ובמיוחד בסייבר, מורכבות יתר פוגעת באימוץ. אם תהליך ה-deployment נמשך זמן רב, אם המוצר קשה להבנה, ואם משתמשים נדרשים לפנות לתמיכה כדי לבצע פעולות בסיסיות – הם פשוט לא ימשיכו להשתמש בו. התוצאה עלולה להיות לא רק אכזבה, אלא גם שימוש שגוי שמגדיל סיכונים, או מוצר שנשאר על המדף ואינו מספק ערך אמיתי.
ב-Mind החלטנו להתמודד עם האתגר הזה על ידי הגדרה של פשטות ויוזביליות כעיקרון יסוד במוצר, לא כפרמטר משני. המטרה היתה לספק ערך אמיתי כבר מהרגע הראשון, out of the box, ללא צורך בפרויקט הטמעה, בלי לקרוא דוקומנטציה, ובלי להסתמך על צוות מומחים שיתפעל את המערכת.
ההיצמדות לעיקרון הזה רחוקה מלהיות טריוויאלית, בעיקר כאשר לקוחות חשובים מעלים דרישות פונקציונליות חדשות. בכל שלב קיים מתח מתמיד בין הרחבת היכולות לבין שמירה על פשטות.
הצעה לפתרון
בפועל, יישמנו את הגישה בכמה דרכים: ראשית, באמצעות שימוש ב-defaults חכמים. הנחנו שרוב המשתמשים כמעט ולא משנים הגדרות ולכן הקפדנו שברירת המחדל תספק ערך גבוה ותישאר בטוחה לשימוש. שנית, בכל פיצ’ר חדש בחנו האם הוא מוסיף מורכבות או friction מיותר, והאם הוא באמת חיוני ל־80% מהלקוחות ולא רק למיעוט. בנוסף, הקפדנו לבחון שימושיות מול הלקוחות עצמם - באמצעות שימוש בפרוטוטייפים של פיצ׳ר חדש ללא הנחיה, כדי להבין האם החוויה אינטואיטיבית וכיצד ניתן לפשט אותה עוד יותר.
השיח סביב שימוש בכלי AI לעבודת הפרודקט ובכלל אולי נשמע לעיתים שחוק, אבל בפועל שילוב של AI agent וב-LLM באופן כללי מעניק פתרון ממשי לפער שבין מוצר עשיר ביכולות וקונפיגורציות לבין חוויית שימוש פשוטה ונגישה.
הצבת agent כשכבת ממשק מעל המוצר מאפשרת למשתמשים לבטא את מה שהם רוצים להשיג במילים שלהם - והמערכת מתרגמת את הבקשה לשפה הטכנית של המוצר ומבצעת אותה בפועל.
כך המשתמשים אינם צריכים להכיר לעומק את כל הממשקים, הפקודות או ההגדרות - הם פשוט מתארים את המטרה, והמערכת דואגת לשאר. עם זאת, חשוב לשמור על איזון: פתרון מופשט או חופשי מדי עלול לבלבל ולגרום לאובדן שליטה. כשבונים את זה נכון, בצורה מדויקת ומבוססת הקשר, מתקבלות יכולות שלא היו אפשריות בעבר - שילוב של עוצמה טכנית עם חוויית שימוש פשוטה באמת.
טיפים שימושיים
אם אתם מפתחים מוצר טכני למשתמשים טכניים - הנה כמה עקרונות שעזרו לנו בפועל:
- כוונו ל-80% מהמשתמשים, לא ל-100%
- הגדירו 3-5 יוז קייסים ראשיים שהם הליבה של המוצר שלכם
- צרו חוויה דיפולטית פשוטה שעובדת out of the box - ללא צורך בהגדרות נוספות
- תמיכה ביוז קייסים מתקדמים והרחבות - דרך הגדרות מתקדמות, איזורים נפרדים במוצר וכו׳
- מדדו usability באופן אנליטי. כמה דוגמאות (אפשר לחשוב על רבות נוספות):
- נתחו time to value - כשכמובן ההגדרה של value תלויה ביוז קייס של הלקוח
- אחוז הלקוחות המשתמשים בתצורה הדיפולטית בהצלחה (לא משנים הגדרות)
- אחוז הטיקטים הנפתחים על ה-core flows במוצר
- עצבו סביב ה-workflow, לא סביב הפיצ’ר
- עבור כל יוז קייס, חישבו על המסלול של המשתמשים בתוך המוצר - מהי נקודת ההתחלה ומהם הצעדים שמובילים אותם אל הסיום/ההצלחה בביצוע המשימה
- המנעו כמה שניתן מגרימת context switching למשתמש, קפיצה בין איזורים שונים וכו׳
- תצפו במשתמשים נכשלים - שם תגלו איפה אתם נופלים
- קיימו סשנים וראיונות עם משתמשים ברמה שבועית
- צפו במשתמשים מנסים להשלים flow מסוים - במהלך שיחה או בהקלטה
- לפיצ׳רים בשלב העיצוב - תנו למשתמשים להתנסות ולחשוב בקול כדי לאתר פערים
- אל תתנו ל-AI להיות האסטרטגיה כולה
- זו שכבת ממשק, לא תחליף לחשיבה מוצרית אמיתית
- תכננו שימוש בAI סביב הוראות ברורות ופלואים מוגדרים במוצר
- ייצרו אמון של המשתמשים ב-AI ע״י מידע מפורט של הסיבות להמלצה או פעולה מסוימת, ואפשרו להם לקבל את ההחלטות הסופיות
לסיכום, יוזביליות זה לא וויתור - זו מקפצה. כשמוצר קל לשימוש, הוא מוטמע מהר יותר, נשאר פעיל לאורך זמן, ומייצר ערך אמיתי - בלי תלות בצוותי התמיכה או בהטמעה. בעולם של סטארטאפים וצוותים קטנים שרצים מהר, זה ההבדל בין מוצר שמתאים לשוק, לבין כזה שנשאר ב-MVP לנצח. בסופו של דבר, לקוחות לא מחפשים עוד פונקציונליות, הם מחפשים תוצאה - כמה שיותר מהר, בכמה שפחות מאמץ.