עיצוב עבור סוכנים אוטונומיים מציג תסכול ייחודי. אנחנו מעבירים משימה מורכבת לבינה מלאכותית, היא נעלמת ל-30 שניות (או 30 דקות), ואז היא חוזרת עם תוצאה. אנחנו בוהים במסך. האם זה עבד? האם זה הזיה? האם זה בדק את מסד הנתונים של התאימות או דילג על השלב הזה? אנו בדרך כלל מגיבים לחרדה זו באחד משני הקצוות. או שאנו שומרים על המערכת ב-Black Box, מסתירים הכל כדי לשמור על הפשטות, או שאנו נכנסים לפאניקה ומספקים Data Dump, ומזרים כל קו יומן וקריאה ל-API למשתמש. אף אחת מהשיטות לא מתייחסת ישירות לניואנסים הדרושים כדי לספק למשתמשים את רמת השקיפות האידיאלית. הקופסה השחורה מותירה למשתמשים תחושת חוסר אונים. ה-Data Dump יוצר עיוורון הודעות, והורס את היעילות שהסוכן הבטיח לספק. משתמשים מתעלמים מזרם המידע הקבוע עד שמשהו נשבר, ובשלב זה חסר להם ההקשר לתקן אותו. אנחנו צריכים דרך מאורגנת למצוא את האיזון. במאמר הקודם שלי, "Designing For Agentic AI", הסתכלנו על רכיבי ממשק הבונים אמון, כמו הצגת הפעולה המיועדת של ה-AI מראש (Intent Previews) ולתת למשתמשים שליטה על כמה שה-AI עושה בעצמו (Autonomy Dials). אבל לדעת באילו אלמנטים להשתמש היא רק חלק מהאתגר. השאלה הקשה יותר עבור מעצבים היא לדעת מתי להשתמש בהם. איך יודעים איזה רגע ספציפי בתהליך עבודה של 30 שניות דורש תצוגה מקדימה של Intent ואיזה ניתן לטפל באמצעות רישום יומן פשוט? מאמר זה מספק שיטה לענות על שאלה זו. נעבור על ביקורת צומת ההחלטה. תהליך זה גורם למעצבים ומהנדסים באותו חדר למפות את הלוגיקה האחורית לממשק המשתמש. תלמדו כיצד לאתר את הרגעים המדויקים שבהם משתמש זקוק לעדכון על מה שה-AI עושה. נסקור גם מטריצת השפעה/סיכון שתעזור לתעדף אילו צמתי החלטה להציג וכל דפוס עיצוב משויך שיתאים להחלטה זו. רגעי שקיפות: דוגמה לחקר מקרה קחו בחשבון את מרידיאן (לא שם אמיתי), חברת ביטוח שמשתמשת ב-AI סוכן כדי לעבד תביעות ראשוניות לתאונות. המשתמש מעלה תמונות של נזק לרכב ודוח המשטרה. לאחר מכן הסוכן נעלם לדקה לפני שהוא חוזר עם הערכת סיכונים וטווח תשלום מוצע. בתחילה, הממשק של מרידיאן פשוט הראה חישוב מצב תביעה. המשתמשים גדלו מתוסכלים. הם הגישו כמה מסמכים מפורטים והרגישו לא בטוחים אם ה-AI בכלל בדק את דו"ח המשטרה, שהכיל נסיבות מקלות. הקופסה השחורה יצרה חוסר אמון. כדי לתקן זאת, צוות התכנון ערך ביקורת צומת החלטה. הם גילו שה-AI ביצע שלושה שלבים ברורים, מבוססי הסתברות, עם מספר שלבים קטנים יותר משובצים:
ניתוח תמונה הסוכן השווה את תמונות הנזק מול מסד נתונים של תרחישי תאונות דרכים טיפוסיות כדי להעריך את עלות התיקון. זה היה כרוך בציון ביטחון. סקירה טקסטואלית זה סרק את דוח המשטרה לאיתור מילות מפתח המשפיעות על אחריות (למשל, תקלה, תנאי מזג אוויר, פיכחון). זה היה כרוך בהערכת הסתברות של מעמד משפטי. הפניות מוצלבות למדיניות זה התאים את פרטי התביעה מול תנאי המדיניות הספציפיים של המשתמש, בחיפוש אחר חריגים או מגבלות כיסוי. זה היה כרוך גם בהתאמה הסתברותית.
הצוות הפך את הצעדים הללו לרגעי שקיפות. רצף הממשק עודכן ל:
הערכת תמונות נזק: השוואה מול 500 פרופילי פגיעת רכב. סקירת דו"ח המשטרה: ניתוח מילות מפתח של אחריות ותקדים משפטי. אימות כיסוי מדיניות: בדיקת אי הכללות ספציפיות בתוכנית שלך.
המערכת עדיין לקחה את אותו פרק זמן, אבל התקשורת המפורשת על פעולתו הפנימית של הסוכן החזירה את אמון המשתמש. המשתמשים הבינו שה-AI מבצע את המשימה המורכבת לה היא תוכננה, והם ידעו בדיוק היכן למקד את תשומת הלב שלהם אם ההערכה הסופית נראית לא מדויקת. בחירה עיצובית זו הפכה רגע של חרדה לרגע של חיבור עם המשתמש. יישום מטריצת ההשפעה/סיכון: מה בחרנו להסתיר לרוב חוויות הבינה המלאכותית אין מחסור באירועים ובצמתי החלטה שעלולים להיות מוצגים במהלך העיבוד. אחת התוצאות הקריטיות ביותר של הביקורת הייתה להחליט מה לשמור על בלתי נראה. בדוגמה של מרידיאן, יומני הקצה האחורי יצרו 50+ אירועים לכל תביעה. יכולנו כברירת מחדל להציג כל אירוע כפי שהם מעובדים כחלק ממשק המשתמש. במקום זאת, יישמנו את מטריצת הסיכון כדי לגזום אותם:
אירוע יומן: שרת פינגWest-2 לבדיקת יתירות. פסק דין מסנן: הסתר. (הימורים נמוכים, טכניות גבוהה).
אירוע יומן: השוואת אומדן תיקון לערך BlueBook. פסק דין מסנן: הצג. (הימורים גבוהים, משפיע על התשלום של המשתמש).
על ידי חיתוך הפרטים המיותרים, המידע החשוב - כמו אימות הכיסוי - היה משפיע יותר. יצרנו ממשק פתוח ותכננו חוויה פתוחה. גישה זו משתמשת ברעיון שאנשים מרגישים טוב יותר לגבי שירות כאשר הם יכולים לראות את העבודה מתבצעת. על ידי הצגת השלבים הספציפיים (הערכה, סקירה, אימות), שינינו המתנה של 30 שניות מזמן של דאגה ("האם זה שבור?") לזמן של הרגשה כאילו נוצר משהו בעל ערך ("זה חושב"). כעת נסקור מקרוב כיצד אנו יכולים לסקור את תהליך קבלת ההחלטות במוצרים שלנו כדי לזהות רגעי מפתח הדורשים מידע ברור. ביקורת צומת ההחלטה השקיפות נכשלת כאשר אנו מתייחסים אליה כאל בחירה בסגנון ולא כדרישה פונקציונלית. יש לנו נטייה לשאול, "איך צריך להיראות ממשק המשתמש?" לפני שנשאל, "מה בעצם הסוכן מחליט?" ביקורת צומת ההחלטה היא דרך פשוטה להפוך מערכות AI קלות יותר להבנה. זה עובד על ידי מיפוי קפדני של התהליך הפנימי של המערכת. המטרה העיקרית היא למצוא ולהגדיר בבירור את הרגעים המדויקים שבהם המערכת מפסיקה לפעול לפי הכללים שנקבעו, ובמקום זאת בוחרת על סמך סיכוי או הערכה. על ידי מיפוי מבנה זה, יוצרים יכולים להראות את נקודות אי הוודאות הללו ישירות לאנשים המשתמשים במערכת. זה משנה את עדכוני המערכת מהצהרות מעורפלות לדיווחים ספציפיים ומהימנים על האופן שבו ה-AI הגיע למסקנה. בנוסף למקרה הביטוח שלמעלה, לאחרונה עבדתי עם צוות בניית סוכן רכש. המערכת בחנה חוזי ספקים וסימנה סיכונים. במקור, המסך הציג סרגל התקדמות פשוט: "בדיקת חוזים." משתמשים שנאו את זה. המחקר שלנו הראה שהם חשים חרדה לגבי ההשלכות המשפטיות של סעיף חסר. תיקנו זאת על ידי ביצוע ביקורת צומת החלטה. צירפתי רשימת בדיקה שלב אחר שלב לביצוע ביקורת זו בסיום מאמר זה. קיימנו פגישה עם המהנדסים ותארנו איך המערכת עובדת. זיהינו "נקודות החלטה" - רגעים שבהם הבינה המלאכותית הייתה צריכה לבחור בין שתי אפשרויות טובות. בתוכנות מחשב סטנדרטיות, התהליך ברור: אם A קורה, אז B תמיד יקרה. במערכות בינה מלאכותית, התהליך מבוסס לרוב על מקריות. ה-AI חושב ש-A היא כנראה הבחירה הטובה ביותר, אבל זה יכול להיות בטוח רק ב-65%. במערכת החוזים מצאנו רגע שבו הבינה המלאכותית בדקה את תנאי החבות מול כללי החברה שלנו. לעתים רחוקות זה היה התאמה מושלמת. ה-AI היה צריך להחליט אם התאמה של 90% מספיק טובה. זו הייתה נקודת החלטה מרכזית.
ברגע שזיהינו את הצומת הזה, חשפנו אותו למשתמש. במקום "בדיקת חוזים", הממשק התעדכן ואמר: "סעיף האחריות משתנה מתבנית סטנדרטית. ניתוח רמת הסיכון". העדכון הספציפי הזה נתן למשתמשים ביטחון. הם ידעו שהסוכן בדק את סעיף החבות. הם הבינו את הסיבה לעיכוב וצברו אמון שהפעולה הרצויה מתרחשת בחלק האחורי. הם גם ידעו היכן לחפור עמוק יותר ברגע שהסוכן ייצר את החוזה. כדי לבדוק כיצד ה-AI מקבל החלטות, עליכם לעבוד בשיתוף פעולה הדוק עם המהנדסים, מנהלי המוצר, האנליסטים העסקיים ואנשי המפתח שלכם שעושים את הבחירות (לעיתים נסתרות) המשפיעות על אופן פעולתו של כלי ה-AI. צייר את השלבים שהכלי נוקט. סמן כל נקודה שבה התהליך משנה כיוון כי מתקיימת הסתברות. אלו המקומות שבהם כדאי להתמקד בלהיות שקוף יותר. כפי שמוצג באיור 2 להלן, ביקורת צומת ההחלטה כוללת את השלבים הבאים:
חברו את הצוות: הביאו את בעלי המוצרים, האנליסטים העסקיים, המעצבים, מקבלי ההחלטות המרכזיים ואת המהנדסים שבנו את ה-AI. למשל, חשבו על צוות מוצר שבונה כלי בינה מלאכותית שנועד לסקור חוזים משפטיים מבולגנים. הצוות כולל את מעצב ה-UX, מנהל המוצר, חוקר ה-UX, עורך דין המתפקד כמומחה לנושא, ומהנדס העורף שכתב את קוד ניתוח הטקסט.
צייר את כל התהליך: תיעוד כל שלב שה-AI עושה, מהפעולה הראשונה של המשתמש ועד לתוצאה הסופית. הצוות עומד ליד לוח ציור ומשרטט את כל הרצף עבור זרימת עבודה מרכזית הכוללת AI המחפש סעיף אחריות בחוזה מורכב. עורך הדין מעלהקובץ PDF בן חמישים עמודים → המערכת ממירה את המסמך לטקסט קריא. → ה-AI סורק את הדפים לאיתור סעיפי אחריות. ← המשתמש ממתין. ← רגעים או דקות לאחר מכן, הכלי מדגיש את הפסקאות שנמצאו בצהוב בממשק המשתמש. הם עושים זאת עבור זרימות עבודה רבות אחרות שהכלי מתאים גם כן.
מצא היכן הדברים אינם ברורים: עיין במפת התהליך עבור כל נקודה שבה ה-AI משווה אפשרויות או תשומות שאין להן התאמה מושלמת אחת. הצוות מסתכל על הלוח כדי לזהות את השלבים המעורפלים. המרת תמונה לטקסט פועלת לפי כללים נוקשים. מציאת סעיף אחריות ספציפי כרוכה בניחושים. כל חברה כותבת את הסעיפים האלה בצורה שונה, כך שה-AI צריך לשקול מספר אפשרויות ולבצע חיזוי במקום למצוא התאמה מדויקת של מילים.
זהה את שלבי 'הניחוש הטוב ביותר': עבור כל נקודה לא ברורה, בדוק אם המערכת משתמשת בציון ביטחון (לדוגמה, האם היא בטוחה ב-85%?). אלו הנקודות שבהן ה-AI עושה בחירה סופית. המערכת צריכה לנחש (לתת הסתברות) איזו פסקה(ות) דומות מאוד לסעיף אחריות סטנדרטי. זה מקצה ציון ביטחון לניחוש הטוב ביותר שלו. הניחוש הזה הוא צומת החלטה. הממשק צריך לומר לעורך הדין שהוא מדגיש התאמה פוטנציאלית, במקום לציין שהוא מצא את הסעיף הסופי.
בחן את הבחירה: עבור כל נקודת בחירה, גלה את המתמטיקה הפנימית הספציפית או ההשוואה הנעשית (למשל, התאמת חלק מחוזה לפוליסה או השוואת תמונה של מכונית מקולקלת לספריית תמונות מכוניות פגומות). המהנדס מסביר כי המערכת משווה את הפסקאות השונות מול מאגר של סעיפי אחריות סטנדרטיים ממקרי פירמה בעבר. זה מחשב ציון דמיון טקסט כדי להחליט על התאמה על סמך הסתברויות.
כתוב הסברים ברורים: צור הודעות עבור המשתמש שמתארות בבירור את הפעולה הפנימית הספציפית המתרחשת כאשר ה-AI עושה בחירה. מעצב התוכן כותב מסר ספציפי לרגע הזה בדיוק. הטקסט קורא: השוואת טקסט מסמך לסעיפים סטנדרטיים של חברה כדי לזהות סיכוני אחריות פוטנציאליים.
עדכן את המסך: הכנס את ההסברים החדשים והברורים האלה לממשק המשתמש, החלף הודעות מעורפלות כמו "בדיקת חוזים". צוות העיצוב מסיר את ספינר הטעינה הגנרי של Processing PDF. הם מכניסים את ההסבר החדש לשורת מצב הממוקמת ממש מעל מציג המסמכים בזמן שה-AI חושב.
בדוק אם יש אמון: ודא שהודעות המסך החדשות נותנות למשתמשים סיבה פשוטה לכל זמן המתנה או תוצאה, מה שאמור לגרום להם להרגיש בטוחים יותר ואמון.
מטריצת ההשפעה/סיכון לאחר שתסתכל מקרוב על תהליך הבינה המלאכותית, סביר להניח שתמצא נקודות רבות בהן היא עושה בחירה. בינה מלאכותית עשויה לעשות עשרות בחירות קטנות עבור משימה מורכבת אחת. הצגת כולם יוצרת יותר מדי מידע מיותר. אתה צריך לקבץ את הבחירות האלה. אתה יכול להשתמש במטריצת השפעה/סיכון כדי למיין את הבחירות האלה על סמך סוגי הפעולות שה-AI נוקט. להלן דוגמאות למטריצות השפעה/סיכון: ראשית, חפש החלטות נמוכות והשפעה נמוכה. הימור נמוך / השפעה נמוכה
דוגמה: ארגון מבנה קבצים או שינוי שם של מסמך. צורך בשקיפות: מינימלי. די בהודעת טוסט עדינה או רישום ביומן. משתמשים יכולים לבטל פעולות אלה בקלות.
לאחר מכן זהה את ההימור וההחלטות בעלות ההשפעה הגבוהה. High Stakes / High Impact
דוגמה: דחיית בקשת הלוואה או ביצוע סחר במניות. צורך בשקיפות: גבוה. פעולות אלו דורשות הוכחת עבודה. המערכת חייבת להפגין את הרציונל לפני או מיד תוך כדי פעולתה.
שקול בוט מסחר פיננסי שמתייחס לכל הזמנות הקנייה/מכירה אותו הדבר. הוא מבצע עסקה של 5$ באותה אטימות כמו מסחר של 50,000$. משתמשים עשויים לתהות אם הכלי מזהה את ההשפעה הפוטנציאלית של שקיפות על מסחר בסכום דולר גדול. הם צריכים שהמערכת תשהה ותציג את עבודתה בעסקאות עם הימור גבוה. הפתרון הוא להציג מצב סקירה לוגיקה עבור כל עסקה העולה על סכום דולר ספציפי, המאפשר למשתמש לראות את הגורמים המניעים את ההחלטה לפני ביצועה. מיפוי צמתים לתבניות: רובריקה לבחירת דפוסי עיצוב לאחר שזיהית את צמתי ההחלטה העיקריים של החוויה שלך, עליך להחליט איזה דפוס ממשק משתמש חל על כל אחד מהם שתציג. ב-Designing For Agentic AI, הצגנו דפוסים כמו Intent Preview (לבקרת הימורים גבוהים) ו- Action Audit (לבטיחות רטרוספקטיבית). הגורם המכריע בבחירה ביניהם הוא הפיכות. אנחנו מסננים כלצומת החלטה דרך מטריצת ההשפעה על מנת להקצות את התבנית הנכונה: הימורים גבוהים ובלתי הפיכים: צמתים אלה דורשים תצוגה מקדימה של Intent. מכיוון שהמשתמש אינו יכול בקלות לבטל את הפעולה (למשל, מחיקה לצמיתות של מסד נתונים), רגע השקיפות חייב להתרחש לפני הביצוע. המערכת חייבת להשהות, להסביר את כוונתה ולדרוש אישור. הימורים גבוהים והפיכים: צמתים אלה יכולים להסתמך על דפוס ה- Action Audit & Undo. אם סוכן המכירות המופעל על ידי AI מעביר ליד לצינור אחר, הוא יכול לעשות זאת באופן אוטונומי כל עוד הוא מודיע למשתמש ומציע כפתור בטל מיידי. על ידי סיווג קפדני של צמתים בצורה זו, אנו נמנעים מ"עייפות התראה". אנו שומרים את התצוגה המקדימה של Intent עם חיכוך גבוה רק לרגעים הבלתי הפיכים באמת, תוך הסתמכות על Action Audit כדי לשמור על מהירות עבור כל השאר.
הפיך בלתי הפיך השפעה נמוכה סוג: Auto-ExecuteUI: טוסט פסיבי / LogEx: שינוי שם של קובץ סוג: ConfirmUI: אפשרות ביטול פשוטה לדוגמה: העברה לארכיון של אימייל השפעה גבוהה סוג: ReviewUI: הודעה + סקירה TrailEx: שליחת טיוטה ללקוח סוג: Intent previewUI: הרשאה מודאלית / מפורשת לדוגמה: מחיקת שרת
טבלה 1: לאחר מכן ניתן להשתמש במטריצת ההשפעה וההפיכות כדי למפות את רגעי השקיפות שלך לדפוסי עיצוב. אימות איכותי: "ההמתנה, למה?" מבחן אתה יכול לזהות צמתים פוטנציאליים על לוח, אבל אתה חייב לאמת אותם עם התנהגות אנושית. עליך לוודא אם המפה שלך תואמת את המודל המנטלי של המשתמש. אני משתמש בפרוטוקול שנקרא "רגע, למה?" מִבְחָן. בקש ממשתמש לצפות בסוכן משלים משימה. הנחו אותם לדבר בקול רם. בכל פעם שהם שואלים שאלה, "רגע, למה זה עשה את זה?" או "זה תקוע?" או "האם זה שמע אותי?" - אתה מסמן חותמת זמן. שאלות אלו מסמנות בלבול של משתמשים. המשתמש מרגיש את השליטה שלו חומקת. לדוגמה, במחקר עבור עוזר תזמון שירותי בריאות, משתמשים צפו בסוכן מזמין תור. המסך היה סטטי במשך ארבע שניות. המשתתפים שאלו בעקביות, "האם זה בודק את היומן שלי או של הרופא?"
השאלה הזו חשפה רגע שקיפות חסר. המערכת הייתה צריכה לפצל את ההמתנה של ארבע שניות לשני שלבים נפרדים: "בדיקת הזמינות שלך" ואחריה "סנכרון עם לוח הזמנים של הספק". השינוי הקטן הזה הפחית את רמות החרדה המובעות של המשתמשים. השקיפות נכשלת כאשר היא מתארת רק פעולת מערכת. הממשק חייב לחבר את התהליך הטכני למטרה הספציפית של המשתמש. מסך המציג את "בודק את הזמינות שלך" מתמוטט כי הוא חסר הקשר. המשתמש מבין שה-AI מסתכל על לוח שנה, אבל הוא לא יודע למה. עלינו לשלב את הפעולה עם התוצאה. המערכת צריכה לפצל את ההמתנה של ארבע שניות לשני שלבים נפרדים. ראשית, הממשק מציג "בודק את היומן שלך כדי למצוא שעות פתיחה." לאחר מכן הוא מתעדכן ל"מסנכרן עם לוח הזמנים של הספק כדי להבטיח את הפגישה שלך." זה מבסס את התהליך הטכני בחייו בפועל של המשתמש. שקול AI מנהל מלאי עבור בית קפה מקומי. המערכת נתקלת במחסור באספקה. ממשק שקורא "יצירת קשר עם ספק" או "בדיקת אפשרויות" יוצר חרדה. המנהל תוהה אם המערכת מבטלת את ההזמנה או קונה חלופה יקרה. גישה טובה יותר היא להסביר את התוצאה המיועדת: "הערכת ספקים חלופיים כדי לשמור על לוח הזמנים שלך למשלוח ביום שישי." זה אומר למשתמש בדיוק מה ה-AI מנסה להשיג. הפעלת הביקורת השלמת את ביקורת צומת ההחלטה וסיננת את הרשימה שלך דרך מטריצת ההשפעה והסיכון. כעת יש לך רשימה של רגעים חיוניים להיות שקופים. לאחר מכן, עליך ליצור אותם בממשק המשתמש. שלב זה דורש עבודת צוות בין מחלקות שונות. אתה לא יכול לעצב שקיפות בעצמך באמצעות כלי עיצוב. אתה צריך להבין איך המערכת עובדת מאחורי הקלעים. התחל עם סקירת היגיון. נפגש עם מעצב המערכת המוביל שלך. הביאו את מפת צמתי ההחלטה שלכם. אתה צריך לאשר שהמערכת באמת יכולה לשתף את המצבים האלה. לעתים קרובות אני מגלה שהמערכת הטכנית לא חושפת את המצב המדויק שאני רוצה להציג. המהנדס עשוי לומר שהמערכת פשוט מחזירה סטטוס "עובד" כללי. עליך לדחוף לעדכון מפורט. אתה צריך שהמערכת תשלח הודעה ספציפיתכאשר הוא עובר מקריאת טקסט לבדיקת כללים. בלי החיבור הטכני הזה, אי אפשר לבנות את העיצוב שלך. לאחר מכן, ערב את צוות עיצוב התוכן. יש לך את הסיבה הטכנית לפעולת הבינה המלאכותית, אבל אתה צריך הסבר ברור וידידותי לאדם. מהנדסים מספקים את התהליך הבסיסי, אבל מעצבי תוכן מספקים את הדרך שבה הוא מועבר. אל תכתוב את ההודעות האלה לבד. מפתח עשוי לכתוב "ביצוע פונקציה 402", וזה נכון מבחינה טכנית אך חסר משמעות למשתמש. מעצב עשוי לכתוב "חשיבה", שהוא ידידותי אך מעורפל מדי. אסטרטג תוכן מוצא את דרך האמצע הנכונה. הם יוצרים ביטויים ספציפיים, כגון "סריקה לאיתור סיכוני אחריות", שמראים שה-AI עובד מבלי לבלבל את המשתמש. לבסוף, בדוק את השקיפות של ההודעות שלך. אל תחכו עד שהמוצר הסופי יבנה כדי לראות אם הטקסט עובד. אני עורך מבחני השוואה על אבות טיפוס פשוטים כאשר הדבר היחיד שמשתנה הוא הודעת המצב. לדוגמה, אני מראה לקבוצה אחת (קבוצה א') הודעה שאומרת "אימות זהות" ולקבוצה אחרת (קבוצה ב') הודעה שאומרת "בדיקת מאגרי מידע ממשלתיים" (אלה דוגמאות מומצאות, אבל אתה מבין את הנקודה). ואז אני שואל אותם איזה AI מרגיש בטוח יותר. לעתים קרובות תגלה שמילים מסוימות גורמות לדאגה, בעוד שאחרות בונות אמון. עליך להתייחס לניסוח כאל משהו שאתה צריך כדי לבדוק ולהוכיח את יעילותו. איך זה משנה את תהליך העיצוב לעריכת ביקורות אלה יש פוטנציאל לחזק את האופן שבו צוות עובד יחד. אנחנו מפסיקים למסור קבצי עיצוב מלוטשים. אנחנו מתחילים להשתמש באבות טיפוס מבולגנים וגיליונות אלקטרוניים משותפים. כלי הליבה הופך למטריצת שקיפות. מהנדסים ומעצבי התוכן עורכים את הגיליון האלקטרוני הזה ביחד. הם ממפים את הקודים הטכניים המדויקים למילים שהמשתמש יקרא. הצוותים יחוו חיכוך במהלך סקירת ההיגיון. תארו לעצמכם מעצב ששואל את המהנדס כיצד ה-AI מחליט לדחות עסקה שהוגשה בדוח הוצאות. המהנדס עשוי לומר שה-backend מוציא רק קוד סטטוס גנרי כמו "שגיאה: נתונים חסרים". המעצב מצהיר שזה לא מידע בר-פעולה על המסך. המעצב מנהל משא ומתן עם המהנדס ליצירת וו טכני ספציפי. המהנדס כותב כלל חדש כך שהמערכת מדווחת בדיוק על מה שחסר, כמו תמונת קבלה חסרה. מעצבי תוכן פועלים כמתרגמים בשלב זה. מפתח עשוי לכתוב מחרוזת מדויקת מבחינה טכנית כמו "חישוב סף ביטחון להתאמת ספקים". מעצב תוכן מתרגם את המחרוזת הזו לביטוי שבונה אמון לתוצאה ספציפית. האסטרטג משכתב את זה כ"השוואת מחירי ספקים מקומיים כדי להבטיח את המשלוח שלך ביום שישי." המשתמש מבין את הפעולה ואת התוצאה. כל הצוות הבין-תפקידי יושב במפגשי בדיקות משתמשים. הם צופים באדם אמיתי מגיב להודעות סטטוס שונות. לראות בהלה של משתמש בגלל שהמסך אומר "ביצוע סחר" מאלץ את הצוות לחשוב מחדש על הגישה שלהם. המהנדסים והמעצבים מיישרים קו לפי ניסוח טוב יותר. הם משנים את הטקסט ל"אימות מספיק כספים" לפני רכישת מניות. בדיקה משותפת מבטיחה שהממשק הסופי משרת גם את ההיגיון של המערכת וגם את השקט הנפשי של המשתמש. זה דורש זמן לשלב את הפעילויות הנוספות הללו בלוח השנה של הצוות. עם זאת, התוצאה הסופית צריכה להיות צוות שמתקשר בצורה פתוחה יותר, ומשתמשים שיש להם הבנה טובה יותר מה הכלים המופעלים על ידי בינה מלאכותית עושים בשמם (ומדוע). גישה משולבת זו היא אבן יסוד בעיצוב חוויות AI מהימנות באמת. אמון הוא בחירת עיצוב לעתים קרובות אנו רואים באמון תוצר לוואי רגשי של חווית משתמש טובה. קל יותר לראות באמון תוצאה מכנית של תקשורת צפויה. אנו בונים אמון על ידי הצגת המידע הנכון בזמן הנכון. אנו הורסים אותו על ידי הכרעת המשתמש או הסתרת המכונות לחלוטין. התחל עם ה-Decision Node Audit, במיוחד עבור כלים ומוצרים של בינה מלאכותית. מצא את הרגעים שבהם המערכת עושה שיחת שיפוט. מפה את הרגעים האלה למטריצת הסיכון. אם ההימור גבוה, פתח את הקופסה. הצג את העבודה. במאמר הבא, נבחן כיצד לעצב את הרגעים הללו: כיצד לכתוב את העותק, לבנות את ממשק המשתמש ולטפל בשגיאות הבלתי נמנעות כאשר הסוכן טועה. נספח: רשימת הביקורת של צומת ההחלטה שלב 1: הגדרה ומיפוי ✅ חברו את הצוות: הביאו את בעלי המוצרים, האנליסטים העסקיים, המעצבים,מקבלי החלטות מרכזיים, והמהנדסים שבנו את הבינה המלאכותית. רמז: אתה צריך שהמהנדסים יסבירו את ההיגיון האחורי בפועל. אל תנסה את הצעד הזה לבד. ✅ צייר את כל התהליך: תיעוד כל שלב שה-AI עושה, מהפעולה הראשונה של המשתמש ועד לתוצאה הסופית. רמז: סשן לוח ציור פיזי עובד לרוב בצורה הטובה ביותר לשרטוט שלבים ראשוניים אלה. שלב 2: איתור ההיגיון הנסתר ✅ מצא היכן הדברים אינם ברורים: הסתכל במפת התהליך עבור כל נקודה שבה ה-AI משווה אפשרויות או תשומות שאין להן התאמה מושלמת אחת. ✅ זהה את שלבי הניחוש הטובים ביותר: עבור כל נקודה לא ברורה, בדוק אם המערכת משתמשת בציון ביטחון. לדוגמה, שאל אם המערכת בטוחה ב-85 אחוז. אלו הנקודות שבהן ה-AI עושה בחירה סופית. ✅ בחן את הבחירה: עבור כל נקודת בחירה, גלה את המתמטיקה הפנימית הספציפית או ההשוואה שנעשית. דוגמה לכך היא התאמת חלק מחוזה לפוליסה. דוגמה נוספת כוללת השוואת תמונה של מכונית שבורה לספרייה של תמונות מכוניות פגומות. שלב 3: יצירת חווית משתמש ✅ כתוב הסברים ברורים: צור הודעות עבור המשתמש המתארות בבירור את הפעולה הפנימית הספציפית המתרחשת כאשר ה-AI עושה בחירה. רמז: לבסס את המסרים שלך במציאות קונקרטית. אם AI מזמין פגישה עם לקוח בבית קפה מקומי, ספר למשתמש שהמערכת בודקת את מערכת הזמנת בית הקפה. ✅ עדכן את המסך: הכנס את ההסברים החדשים והברורים האלה לממשק המשתמש. החלף הודעות מעורפלות כמו סקירת חוזים בהסברים הספציפיים שלך. ✅ בדוק אם יש אמון: ודא שהודעות המסך החדשות נותנות למשתמשים סיבה פשוטה לכל זמן המתנה או תוצאה. זה אמור לגרום להם להרגיש בטוחים ואמון. רמז: בדוק את ההודעות האלה עם משתמשים בפועל כדי לוודא שהם מבינים את התוצאה הספציפית שהושגה.
