מנקודת המבט של המשתמש, מערכות AI הן מטבען לא ודאיות. הם יכולים להפיק תוצאות לא עקביות ולטעות באופן קבוע. ממשק המשתמש מציע הרבה הזדמנויות להבין את המגבלות של ה-AI, לסנן אותן ולצמצם את התסכול שעלול להיגרם מהן. למפתחים יש תפקיד מרכזי בעיצוב חוויות משתמש מבוססות-AI, כי יש להם תובנות מעמיקות לגבי האופן והמקום שבהם מערכת AI עלולה להיכשל.
שיקול חשוב בתכנון הוא מידת השליטה של המשתמשים ב-AI. חלק מהההזדמנויות לא גלויות למשתמשים, ואחרות דורשות אינטראקציה מפורשת. חשיפה רחבה יותר פירושה גמישות רבה יותר, אבל גם סיכון ומורכבות גדולים יותר שצריך לנהל.
במודול הזה נלמד על שיטות מומלצות לעיצוב דפוסי חוויית משתמש (UX) לשלושה סוגים של חשיפה: ברקע, מוגבלת ופתוחה. לכל סוג, אנחנו מדגישים איך בחירות טכניות וארכיטקטוניות משפיעות על חוויית המשתמש במערכת ה-AI.
רקע מבוסס-AI
אפשר להשתמש ב-AI כדי לשפר חוויה קיימת בלי להוסיף תכונות חדשות. כך מצמצמים את הסיכון לשיבושים ולכשלים. במקרה כזה, האחריות למידת התועלת, לאמינות ולשדרוג חלק מוטלת כולה על המוצר. המשתמשים לא צריכים ללמוד איך ה-AI פועל, או אפילו לדעת שהוא מעורב, כדי ליהנות ממנו.
השימוש ב-AI ברקע מתאים במקרים הבאים:
- המשימה היא ברמת סיכון נמוכה.
- הוספת אפשרות שליטה למשתמשים לא תשפר באופן משמעותי את התוצאות.
- המוצר עדיין יכול לספק את הערך העיקרי שלו, גם אם תכונת ה-AI נכשלת או לא זמינה.
יש הרבה דוגמאות ל-AI ברקע בכל רחבי האינטרנט, ממסנני ספאם ועד המלצות לבידור, או אפילו דוגמאות מורכבות, כמו תגובות בזרם הכדורים של BILIBILI. יכול להיות שחלק מהתכונות האלה לא נראות לכם כמו "AI".
דוגמה: סיכומים והדגשים של ביקורות שנוצרו על ידי AI
זוכרים את חנות הדוגמה? עד עכשיו שיתפנו שני תרשימי מערכת, לתכונות שונות מבוססות-AI, כולל תכונה לתמיכה בלקוחות וחיפוש משופר של מוצרים. עכשיו אנחנו משיקים פיצ'ר שלישי: סיכומי ביקורות. כדאי לעיין בתוכנית של מערכת AI.
דפי מוצרים מכילים לרוב מאות ביקורות. למשתמשים קשה להעריך את המאפיינים שחשובים להם.
אתם יכולים להשתמש ב-AI כדי להציע נושאים חוזרים בחיפושים שלהם, כדי לספק סיכומים והדגשות של ביקורות בהתאמה אישית. בממשק לדוגמה, המשתמש מחפש אוזניות, ולכן מודגשים נושאים שקשורים לאיכות הצליל ולחיי הסוללה. כך העומס הקוגניטיבי פוחת והלקוחות יכולים לקבל החלטות רכישה מהר יותר.
הסיכומים הם ייחודיים לכל אדם, ולכן חשוב לתת עדיפות לפרטיות ולמהירות כשבוחרים את הפלטפורמה. כדאי לבחור ב-AI מובנה וב-Summarizer API, כדי שהחישוב יתבצע ישירות במכשיר של המשתמש.
שיטות מומלצות
כדי שהתכונה מבוססת ה-AI תשתלב בצורה חלקה בחוויית המשתמש הקיימת, חשוב לפעול בהתאם להנחיות הבאות:
- מספקים שקיפות קלה: כש-AI משנה או מצטבר תוכן שנוצר על ידי משתמשים, רמזים עדינים עוזרים למשתמשים להבין מה קורה. אפשר להשתמש בתוויות ניטרליות כמו 'סיכום' או 'תובנות מרכזיות', ולהוסיף חשיפה הדרגתית באמצעות תיאורי כלים או רכיבים אחרים בממשק המשתמש.
- אפשרות ביטול ההסכמה: לאנשים יש גישות שונות לגבי AI. יש אנשים שעלולים להגיב ל-AI כאל דבר פולשני, מציף או מעצבן. צריך לספק דרך ברורה להשבתת התכונות האלה.
- שימו לב לניסוח: השפה היא חלק חשוב בכל חוויית משתמש, כולל טקסט שנוצר על ידי AI. בדוגמה שלנו, הסיכומים צריכים לשקף מגמות, ולא טענות. כדי לצמצם או להסיר מהסיכום שפה שמשקפת ביטחון מוגזם, מוסיפים כללים להנחיית המערכת.
- תכנון מעבר חלק לפתרון חלופי: כשזה אפשרי, כדאי לספק ערך בלי להשתמש ב-AI. אם הסיכום לא זמין מסיבות טכניות, כמו מודל לא זמין, המערכת עדיין צריכה להציע ביקורות ללא סיכום. אחרי שהמודל יורד, האפליקציה יכולה לחשוף באופן אוטומטי את הסיכום החדש.
- מזעור ההפרעה במהלך ההגדרה: ההורדה הראשונית של מודל בצד הלקוח עלולה ליצור חיכוך. קודם צריך להדגים את הערך של התכונה. אפשר להוסיף חלופה מוגבלת בצד השרת או להעביר את ההורדה לסוף מסלול המשתמש, כדי שההפרעה תהיה מינימלית. תזמון נכון ובניית הקשר עוזרים להתאים את המוצר לסדרי העדיפויות של המשתמש.
AI מוגבל
בעוד ש-AI ברקע פועל באופן אוטומטי, תכונות AI מוגבלות מופעלות באופן מפורש על ידי המשתמש, לרוב באמצעות קישור או לחצן. הנחיית מערכת קובעת את המשימה, הכוונה, האילוצים ופורמט הפלט. בניגוד לסמן של הנחיה פתוחה, למשתמשים יש אפשרויות מוגבלות או שאין להם אפשרויות בכלל מלבד להתחיל את המשימה ולקבל פלט. המערכת שומרת על יכולת החיזוי על ידי הגבלת הפעולות שה-AI יכול לבצע.
בדומה ל-AI ברקע, תכונות AI מוגבלות משתלבות היטב עם מודלים בצד הלקוח שמותאמים למשימה הספציפית.
דוגמה: יצירת שם
יצירת כותרות יכולה להיות משימה מאתגרת במיוחד. BlogBuddy משתמש ב-AI כדי לעזור לכותבים להציע כותרות מתחשבות והקשריות, במינימום מאמץ. כדאי לעיין בתוכנית הפעולה של מערכת ה-AI של התכונה הזו.
המשתמש יכול ללחוץ על הצגת כותרות כדי ליצור כמה טיוטות להערכה ולשיפור.
הסברנו איך אפשר להטמיע את זה באמצעות Prompt API במאמר בנושא הנדסת הנחיות. יוצרים הנחיית מערכת שמקודדת את המשימה, את האילוצים הסגנוניים ואת מבנה הפלט. רק התוכן של פוסט בבלוג מועבר באופן דינמי מממשק המשתמש. כשמטמיעים את התכונה בצד הלקוח, היא עוברת אופטימיזציה כדי לבצע איטרציות ללא עלות הגדרה.
שיטות מומלצות
היעד שלכם הוא לעודד את המשתמשים להשתמש בתכונות חדשות. כדי לעשות את זה, צריך להציג ערך ולתת להם שליטה בתוצאה:
- הקפידו על בהירות ועל ניסוח בטוח: תמיד עדיף להשתמש בתוויות ברורות של פעולות במקום בשפה כללית, כמו "שאלת AI". המשתמש צריך להבין מה קורה, מעבר לאיך זה קורה. אם זמן האחזור של התכונה נמוך, כדאי להוסיף תוויות שמציינות שהתוצאה כבר זמינה. לדוגמה, במקום יצירת הצעות לשמות, מופיעה האפשרות הצגת הצעות לשמות.
- לעדכן את המשתמשים: כדאי להוסיף חיכוך קוגניטיבי קל כדי שהמשתמשים יהיו ערניים. אם תציעו כמה אפשרויות, תוכלו למנוע מצב שבו המשתמשים ירגישו שהם תקועים עם תוצאה שהם לא אוהבים. המשתמשים צריכים להיות מסוגלים לאשר או לערוך את התוצאות באופן מפורש לפני שהן נשמרות.
- אם אפשר, כדאי להכין את התוצאה מראש: במיוחד במשימות בצד הלקוח, כדאי לשקול חישוב מראש של התוצאה, כדי שהיא תהיה זמינה באופן מיידי.
- תמיכה בשיפור מהיר: צריך שיהיה קל לבצע יצירה מחדש, לבטל אותה ולעשות אותה בזול. למשתמשים צריכה להיות אפשרות לבטל את הפעולות שלהם. כדאי לאסוף את אותות המשוב האלה כדי לכוונן את התכונה לריצות עתידיות.
- אם צריך, מספקים אמצעי בקרה מפורטים יותר: אפשר להשתמש ברכיבים מובנים נוספים כמו תגי טון, בוררי אורך או סגנונות מוגדרים מראש כדי לשפר את התוצאות. במקרים רבים, הצורך בשליטה נוספת מתעורר עם הזמן, ככל שהדרישות של המשתמשים משתנות והביטחון שלהם גדל. כדאי להגדיר לולאות משוב שיאפשרו לכם לעקוב אחרי ההתפתחויות האלה.
איך בוחרים בין AI ברקע לבין AI מוגבל
אפשר להטמיע חלק מהתכונות כ-AI ברקע או כ-AI מוגבל, בהתאם לאופן שבו אתם מציגים אותן ולמועד שבו אתם מציגים אותן. ההבדל הזה מושפע מחשיפה, מעומס קוגניטיבי ומזמן, ולא מהיכולות הזמינות. לדוגמה, במקום לדרוש לחיצה מפורשת על כפתור, אפשר להכין כותרות באופן יזום ברקע בזמן שהמשתמש כותב. כשמשתמש מתמקד בשדה של שם הסרטון, אתם יכולים להציג הצעות.
הגישה הזו מתאימה במיוחד במקרים הבאים:
- הקלט שנדרש לתכונה זמין כברירת מחדל
- מספר התכונות שמבוססות על AI קטן
- העלות של החישוב המוקדם נמוכה
- אפשר לשלב את ההצעות בלי להסיח את דעתו של המשתמש מהמשימה
לעומת זאת, עדיף להשתמש ב-AI מוגבל במוצרים עם כמה תכונות או פעולות שמבוססות על AI. טריגרים מפורשים עוזרים להימנע מחישובים מיותרים, ונותנים למשתמשים תחושה חזקה יותר של כוונה וסוכנות.
AI פתוח
ממשקי AI פתוחים מאפשרים למשתמשים לשלוט ישירות בהתנהגות של מערכת AI באמצעות קלט חופשי. במקום להפעיל פעולה שנקבעה מראש, המשתמשים יכולים לספק הקשר בשפה טבעית. אחרי השליחה, מערכת ה-AI מפרשת את הכוונה, מוסיפה הקשר חסר ומנסה לנחש מה צריך לעשות בשלב הבא.
הקלט משתנה מאוד בין משתמשים ולעתים קרובות הוא בלתי צפוי, ומערכת ה-AI צריכה להיות מסוגלת להתמודד עם השונות הזו. הסוג הזה מציע את הגמישות הכי גבוהה, אבל גם את הסיכון הכי גבוה לחוויית המשתמש:
- קלט משתמש לא ברור או לא שלם
- פלט בלתי צפוי
- סבירות גבוהה יותר לתשובות שגויות או מטעות
- סיכון מוגבר של אמון מוגזם
- ניסיונות לפגוע במערכת, למשל על ידי יצירת תוכן בלתי הולם
דוגמה: סוכן תמיכת לקוחות מבוסס-AI
בחנות לדוגמה, תמיכת הלקוחות כוללת מגוון רחב של בעיות: מעקב אחר הזמנות, החזרות, שאלות לגבי מוצרים, בעיות במשלוח ומקרים חריגים שלא מתאימים לתהליכי עבודה ברורים. כדאי לרענן את הזיכרון לגבי תוכנית האב של מערכת ה-AI, מהמודול Platform.
אחרי שמוסיפים תכונות מבוססות-AI מוגבלות לפעולות הנפוצות ביותר, יכול להיות שהממשק יהיה עמוס. במקום זאת, נציג תמיכה מבוסס-AI עם תשובות פתוחות יכול לספק גמישות.
- פתרון מהיר של בעיות נפוצות.
- קיצור זמני ההמתנה וצמצום עלויות התמיכה.
- לקבל עזרה מיידית במגוון נושאים, בלי תהליכי תמיכה מורכבים.
הערך של נציג התמיכה הוא בטיפול בשינויים בהיקף גדול. בסופו של דבר, צריך לבנות מערכת שיכולה לטפל בקלט הזה בצורה אחראית. אמנם אתם מקווים ומצפים שהמשתמשים יפעילו שיקול דעת ויבצעו כיול של האמון, אבל אתם עלולים להיות אחראים לתשובות לא נכונות שהמודל מספק.
המשתמשים פותחים צ'אט עם הנציג ושואלים: "איפה ההזמנה שלי?" או "חויבתי פעמיים, אפשר עזרה?" הסוכן מפרש את הכוונה, שואל שאלות הבהרה, מאחזר מידע רלוונטי ומציע שלבים או פעולות לביצוע.
רוב מערכות ה-AI עם יכולות בלתי מוגבלות מסתמכות על מודלים בצד השרת. אפשר לשלב אותם עם רכיבים אחרים, כמו מסדי נתונים, כלים חיצוניים ולוגיקה עסקית, כדי ליצור מערכת AI מורכבת. מומלץ לספק נתיבי העברה לסוכני תמיכה אנושיים.
שיטות מומלצות
התמקדו בשקיפות, בכיול האמון ובמנגנוני בקרה:
- הנחיית המשתמשים להביע כוונה בצורה ברורה: כדאי לספק הצעות להנחיות (למשל, "אני רוצה להחזיר הזמנה") והצעות להמשך שיחה כדי לצמצם את אי הבהירות.
- הצגת מצב המערכת וההנחות: הסוכן צריך להבהיר מה הוא מבין ("נראה ששאלת על הזמנה 12345") ואיזה מידע הוא משתמש.
- לשאול לפני שפועלים: לפני ביצוע פעולות רגישות, כמו החזרות, החזרים כספיים, שינויי כתובת, הנציג צריך לסכם את הפעולה ולבקש אישור מהמשתמש.
- עיצוב לאימות ולתיקון: המשתמשים צריכים להיות מסוגלים לתקן אי הבנות, לנסח מחדש בקשות או להריץ אחורה את השיחה, בלי להתחיל מחדש.
- שילוב עם תכונות מבוססות-AI מוגבלות: שיחה עם יותר מדי תגובות הלוך ושוב עלולה להרתיע משתמשים. מוסיפים רכיבים מובנים כקיצורי דרך. לדוגמה, מספר הזמנה משוער יכול להיות מוצג כרכיב שאפשר ללחוץ עליו כדי לחפש אותו, לבחור אותו או להחליף אותו, במקום לדרוש מהמשתמש לנסח מחדש את הבקשה בטקסט.
- הצגת אי-ודאות ומגבלות: הסוכן צריך להודות באי-ודאות, לציין מידע חסר ולהעביר את השיחה לאיש תמיכה אנושי כשהביטחון נמוך.
בסוג הזה של חוויית AI, המשתמשים צריכים להעריך את התשובות באופן ביקורתי ולהבין מתי צריך להעביר את הטיפול לרמה גבוהה יותר.
מסקנות עיקריות
במודול הזה סקרנו סוגים שונים של ממשקי משתמש מבוססי-AI:
- ה-AI ברקע מאפשר לכם להוסיף ערך או הנאה נוספים למסלול הקיים של המשתמש.
- אפשר להשתמש בתכונות מבוססות-AI מוגבל כדי לבצע מקרים ספציפיים ומוגדרים היטב, שמומלץ לבצע באמצעות AI.
- נדרש AI עם יכולות פתוחות לדומיינים עם שונות גבוהה. מומלץ להשתמש רק בשאלות פתוחות אם אתם בטוחים מאוד בביצועים הטכניים של המערכת שלכם.
בטבלה הבאה מפורטים דפוסי חוויית המשתמש המומלצים לכל סוג של AI:
| UX theme | UX pattern | רקע | מוגבלת | שאלה פתוחה |
| שקיפות | סימון ברור של תוכן שנוצר על ידי AI | |||
| הסבר קצר על התנהגות ה-AI | ||||
| מצב המערכת וההנחות גלויים | ||||
| הנחיות | הצעות להנחיות | |||
| קלט מובנה (תגים, הגדרות קבועות מראש) | ||||
| בקרה | טריגר AI מפורש | |||
| תצוגה מקדימה לפני החלת הפלט | ||||
| כמה חלופות | ||||
| יצירה מחדש | ||||
| ביטול | ||||
| כיול של הרשאות שיתוף | ניסוח שמרני | |||
| אינדיקטורים של מהימנות | ||||
| ניהול סיכונים וכשלים | חיכוך מכוון ושערים לבדיקה | |||
| העברה לטיפול אנושי / העברת בעיה לטיפול ברמה גבוהה יותר | ||||
| מעבר חלופי חלק בלי AI |
קריאה נוספת
כדי להמשיך ללמוד על דפוסי UX, אנחנו ממליצים על מקורות המידע הבאים:
- מומלץ לקרוא את המדריך של Google בנושא אנשים + AI.
- ערכת הכלים של מיקרוסופט HAX, ובמיוחד ההנחיות שלה לאינטראקציה בין בני אדם ל-AI.
- The Shape of AI מאת אמילי קמפבל.
- פרק 10 בספר The Art of AI Product Development (אומנות פיתוח מוצרים מבוססי-AI).
בדיקת ההבנה
איזה סוג של תבנית UX הוא טשטוש הרקע בשיחות וידאו?
מתי כדאי להשתמש ב-AI עם קלט חופשי כדפוס UX?