אתם במצב מצוין למצוא הזדמנויות בעלות ערך גבוה לשימוש ב-AI. אתם יכולים להעריך את ההיתכנות הטכנית של רעיון מסוים ואת ההשפעה שלו על חוויית המשתמש. אלה שני היבטים שצריכים להתקיים יחד כדי שתכונות מבוססות-AI יצליחו. אל תיצרו תכונות מבוססות-AI רק כי הן חדשניות או מרשימות, אלא כי הן באמת מקלות על המשתמשים, חוסכות להם זמן או משפרות את חוויית השימוש שלהם.
במודול הזה מתוארת שיטה מובנית ואיטרטיבית ליצירת רעיונות לתרחישי שימוש ב-AI במוצר, להגדרתם וליצירת אבות טיפוס שלהם.
הסבר על הערך של AI
בעץ ההזדמנויות הבא לשימוש ב-AI מוגדרות הקטגוריות הגדולות של הערך ש-AI יכול לספק:
ריכזנו כאן קטגוריות של ערך שיעזרו לכם להגדיר את הפתרונות שלכם. ככל שמתקדמים ברשימה, המורכבות, הסיכון וההשפעה הפוטנציאלית על המשתמשים נוטים לגדול:
- תובנות: שיפור תהליך קבלת ההחלטות.
- נוחות: צמצום החיכוך.
- אוטומציה: החלפת עבודה שחוזרת על עצמה.
- הגדלה: עזרה למשתמשים במשימות מורכבות או יצירתיות.
- התאמה אישית: התאמת המוצר לצרכים ולהעדפות של משתמשים ספציפיים.
קודם כדאי לנסות לפתור תרחישי שימוש עם השפעה נמוכה יותר. לדוגמה, אפשר לאסוף תובנות טובות יותר לגבי המוצר באמצעות מערכת AI פנימית, כדי לשפר את המוצר מבפנים. לאחר מכן, כדאי לבדוק את חוב ה-UX הקיים ולהשתמש ב-AI כדי להפחית את החיכוך ואת העומס הקוגניטיבי של המשתמשים. ככל שתצברו יותר ביטחון וניסיון, תוכלו לעבור לתרחישי שימוש מורכבים יותר ולהגדיל את החשיפה ל-AI.
עם זאת, יכול להיות שתגלו הזדמנויות להשפעה משמעותית, כמו התאמה אישית קלה, שהן נגישות באופן מפתיע, לא מסוכנות ומשמעותיות.
זיהוי הזדמנויות במוצר
כדי להבין איזו רעיון מתאים לכם, כדאי שתהיה לכם תמונה ברורה של המשתמשים שלכם. כדאי לעבוד עם צוות חוויית המשתמש או ללמוד על פרסונות כדי להגדיר מי הם המשתמשים האלה. כדאי לאמץ גישה שמתמקדת במשתמשים (או באנשים) ולמפות את ההזדמנויות לשימוש ב-AI שאתם מוצאים לתרחישי שימוש קונקרטיים במוצר שלכם.
לדוגמה:
- מבוסס על צרכים מפורשים של משתמשים או על בעיות שבהן הם נתקלים.
- ההצעות מגיעות מחברי הצוות או מעצמכם. במקרה כזה, אימות מהיר עם משתמשים הוא חיוני כדי להימנע מהמלכודת של 'AI לשם AI'.
- אפשר לקבל השראה מהמתחרים, אבל צריך לעשות את זה בזהירות. הקהל וההקשר של המתחרים שלכם יכולים להיות שונים משלכם. כדאי לבצע אימות מוקדם כדי לבדוק אם יוזמות מוצלחות של המתחרים משפיעות על המוצר שלכם.
לדוגמה, בטבלה הבאה יש רעיונות לאתר להזמנת טיסות:
בכל שלב במסע הלקוח, אפשר לזהות הזדמנויות שונות להוספת ערך באמצעות AI.
התאמת הפתרון
עד עכשיו מיפיתם כמה רעיונות לשימוש ב-AI לאורך מסלול המשתמש. השלב הבא הוא לתת להם צורה ולצבור מספיק ביטחון כדי להחליט אילו רעיונות לפתח קודם. זהו מאמץ משותף של הצוות, ובדרך כלל מנהל המוצר מוביל אותו. כמפתחים, האחריות העיקרית שלכם היא להעריך את העלות, המאמץ והסיכונים של פתרון ה-AI המתוכנן.
מפרטים את הרעיונות
קודם כל, כדאי לתעד כל רעיון במפרט מהיר ומקיף. אפשר להשתמש בתוכנית הפעולה של מערכת ה-AI מהמבוא שלנו. בדרך כלל, המפתחים מתמקדים בחלק של הפתרון, ומנהל המוצר מציין את ההזדמנות. התרגיל הזה מאפשר לכולם להגיע להסכמה ולדון לפני שממשיכים.
הערכת המאמץ והעלות
בשלב הבא, מעריכים כמה קשה להטמיע את הרעיון. לדוגמה, כדי להוסיף מסננים חכמים, יכול להיות שיהיה צורך רק בניתוח מבוסס-הנחיות באמצעות LLM API, שקל ומהיר ליצור אב טיפוס שלו ולהריץ אותו, וגם קל לבצע בו שינויים. לעומת זאת, כדי ליצור עוזר אישי לקביעת פגישות צריך צינורות נתונים מותאמים אישית, ממשקי API לקביעת פגישות ומנגנונים מורכבים של אימות אנושי, וזה כבר הרבה יותר מסובך.
כדאי לבדוק את המאמץ והעלות בכמה מאפיינים:
- מוכנות הנתונים: האם כבר יש לכם את הנתונים שאתם צריכים? כמה ניקוי, עיבוד מקדים או תיוג צריך לבצע כדי שהנתונים יהיו מוכנים לשימוש ב-AI?
- בשלות המודל: האם קיים כבר מודל מתאים שעבר אימון מראש, או שצריך לאמן מודל מאפס?
- זמן אחזור: כמה מהר המודל צריך להגיב כדי שהתכונה תהיה חלקה ומועילה?
- מורכבות השילוב: כמה מערכות צריך לחבר? האם יש קצה עורפי, ממשקי API, ממשק משתמש או כלים של צד שלישי? ככל שיש יותר נקודות מגע, כך העלות והסיכון גבוהים יותר.
- עלות תפעולית: מה העלות של כל קריאה או הסקה של מודל? אומדן של השימוש החודשי והתקציב לצורך הרחבת הפעילות. תכונה שנחשבת ל"זולה" בשלב אב הטיפוס יכולה להיות יקרה כשאלפי משתמשים מחוברים.
כדאי לחשוב על העלויות הנסתרות למשתמש. AI יכול להוסיף אי ודאות ולגרום לטעויות קבועות במוצר. כשמשתמשים ב-AI בצד הלקוח, התכונות פועלות במכשיר של המשתמש, וזה צורך רוחב פס, נפח אחסון ואנרגיה. התכונה צריכה להיות מספיק שימושית כדי שהמשתמשים ירגישו שהיא שווה את העלות.
אם תעריכו את המאמץ בשלב מוקדם, תוכלו להתמקד בשיפורים בעלי ערך גבוה שקל להשיג, ולדחות את הרעיונות המורכבים יותר עד שהנתונים, התשתית והניסיון שלכם יהיו מבוססים יותר.
הערכת מצבי כשל
לפעמים המודל טועה והתכונות לא פועלות כמו שציפיתם. חשוב להסביר למשתמשים מה קורה ואיפה התרחשה השגיאה, כדי שהם יוכלו לשנות את הקלט שלהם ולקבל את התוצאות שהם מחפשים.
לדוגמה, נניח שאתם מנהלים סוכנות נסיעות. החברה שלך רוצה להציע השראה מותאמת אישית למטיילים. המשתמשים שלכם ביקשו כלי שיאפשר להם לעשות את זה בעצמם, וצוות המוצר שלכם רוצה להטמיע אותו. עם זאת, אתם יודעים שהתאמה אישית דורשת אותות רבים מהמשתמשים לגבי תחומי העניין שלהם, ולא הגדרתם מסד נתונים לאיסוף אותות כאלה. התוצאה היא התאמה אישית לא מוצלחת שמציעה השראה לא רלוונטית, ולכן המשתמשים מפסיקים להשתמש בתכונה. ההבנה שלכם לגבי הזמינות של נתונים בהתאמה אישית צריכה לשמש את הצוות שלכם להערכת הערך.
הנה מצבי כשל קריטיים נוספים של AI שכדאי להביא בחשבון:
- הזיה: המודל יוצר פלט שנראה סביר, אבל הוא לא אמיתי (למשל, המודל ממציא טיסה שלא קיימת).
- הטיה: המודל מציג או מגביר הכללות לא הוגנות שמבוססות על נתוני האימון, ומובילות לתוצאות מפלות או לא שוויוניות. לדוגמה, יכול להיות שהמודל יניח שמשתמשים מסוימים רוצים טיסות במחלקה ראשונה ומשתמשים אחרים רוצים טיסות במחלקת תיירים, על סמך המגדר או הגזע שהמודל מזהה.
- בעיית התנעה קרה: המערכת לא יכולה לספק ערך למשתמשים או לפריטים חדשים בגלל חוסר בנתונים ראשוניים, כפי שמוצג בדוגמה של כלי הנסיעות בהתאמה אישית.
- ירידה בביצועים: רמת הדיוק של המודל יורדת עם הזמן כשהנתונים בעולם האמיתי משתנים ומתרחקים מההתפלגות המקורית, תופעה שנקראת גם סחף מודל.
אב טיפוס
הנתונים שתזינו לגבי עלות, מאמץ ומצבי כשל יהיו ברמת דיוק נמוכה בהתחלה. כדי להיות בטוחים, הדרך הכי טובה לאמת תכונת AI ספציפית היא ליצור אב טיפוס שלה. אב טיפוס מאפשר לכם לבדוק במהירות הנחות טכניות מרכזיות (מוכנות הנתונים, זמן האחזור, הדיוק) לפני שאתם מתחייבים לבנייה מלאה. במיוחד כשמדובר בטכנולוגיה חדשה כמו AI, שלא נחקרה לעומק, לומדים מהר יותר כשמתנסים בה מאשר כשחוקרים ומנתחים אותה.
בעזרת כלים ליצירת קוד מבוססי-AI, כמו Vertex AI ו-Replit, אפשר להאיץ באופן משמעותי את תהליך יצירת האב טיפוס ולצמצם את הסיכונים.
כדאי לאמץ את הגישה הבאה: לשחרר משהו קטן, לבדוק איך הוא מתנהג ולשפר אותו באופן מתמשך.
כדאי לפעול לפי השיטות המומלצות הבאות:
- כדאי לבנות את התהליך מקצה לקצה מוקדם ככל האפשר. חשוב לבדוק את כל התהליך שמוגדר בתוכנית של מערכת ה-AI (נתונים, מודיעין, חוויית משתמש), ולא רק את הדיוק של המודל. הגרסה הזו צריכה לשקף כל חלק בחוויית המשתמש עם ה-AI, אבל היא לא צריכה לייצג כל תכונה של האפליקציה.
- מתחילים עם קיצורי דרך. שימוש בממשקי API ובמודלים שעברו אימון מראש כדי לאמת את הערך במהירות.
- רישום כל הפעולות ביומן. לעקוב אחרי נתוני קלט, פלט ועריכות של משתמשים כדי לראות מצבי כשל נפוצים ולהעריך בעיות פוטנציאליות שעלולות להפריע לתהליך.
- בדיקה עם נתונים אמיתיים. בבדיקות הראשונות צריך לתעד התנהגות טבעית ולא מסודרת של המשתמשים.
- הוספת מנגנוני משוב ובקרה. כדאי להקל על המשתמשים לסמן שגיאות או לשנות את התוצאות, ולאפשר להם לאשר או לתקן את התוצאות.
ברוב המקרים, יצירת אב טיפוס מתבצעת במקביל לעבודת ההערכה והגדרת המפרט.
העיקריים מהשיחה
למדתם איך להפוך את הפוטנציאל המופשט של ה-AI לרעיונות קונקרטיים למוצרים בעלי ערך גבוה. כמפתחים, היתרון שלכם הוא היכולת לשלב בין היתכנות טכנית לבין חוויית משתמש. למדתם איך AI יכול ליצור ערך בקטגוריות שונות, מיפיתם את ההזדמנויות האלה למסלול המשתמש במוצר שלכם, ולמדתם איך לציין, להעריך ולתעדף אותן באמצעות מסגרות עבודה מובנות.
חשוב לזכור ש-AI מצליח באמצעות איטרציה בלתי פוסקת. כדאי להשיק מוקדם, להקשיב למשתמשים ולצפות בהם, ולשפר את המוצר במהירות. כל אב-טיפוס הוא שלב לקראת הבנה של האופן שבו AI יכול להגדיל את הערך של המוצר ולשפר את חוויית השימוש בו.
משאבים
- Getting AI Discovery Right, מדריך ליצירת רעיונות, לאימות ולתעדוף של תרחישי שימוש ב-AI.
- AI Radar, כלי לגילוי ולתמיכה בהחלטות, שמיועד לזיהוי ולתעדוף של תרחישי שימוש בתעשיות שונות.
בדיקת ההבנה
באיזו קטגוריה של הזדמנויות לשימוש ב-AI נכללת העזרה למשתמשים במשימות מורכבות או יצירתיות?
כשמעריכים את המאמץ והעלות של רעיון לשימוש ב-AI, למה מתייחסים כשמציינים את "מורכבות השילוב"?
מהי בעיית ההתנעה הקרה בהקשר של מצבי כשל ב-AI?
מה הגישה המומלצת ליצירת אב טיפוס של תכונות מבוססות-AI?
למה חשוב לשמור יומן כשיוצרים אב טיפוס?