עיצוב "סוכני" (Agentic Design): איך מעצבים ממשק למערכות AI שמקבלות החלטות בעצמן?

בעולם שבו מערכות AI לא רק עונות אלא גם מבצעות פעולות, הממשק הופך לשכבת האחריות. 
עיצוב “סוכני” עוסק בשאלה אחת: איך נותנים למערכת חופש לפעול בלי לאבד שליטה.
משתמשים לא צריכים לראות “מוח” של מערכת — הם צריכים להבין מה עומד לקרות עכשיו.
האתגר הגדול הוא להחליף קסם של אוטומציה בשגרה בטוחה שאפשר לסמוך עליה תחת לחץ.
כאן נכנסים עקרונות כמו שקיפות קצרה, בלם נגיש, והעברת אחריות בנקודות נכונות.
ממשק טוב יוצר החלטות מודעות ולא הופך אנשים לחותמת גומי על הצעות של AI.
הוא גם יודע לעצור כשהמידע חסר, כשהסיכון עולה, או כשהפעולה עלולה להיות בלתי הפיכה.
במאמר הזה נפרק איך בונים זרימות, קומפוננטים ושפה שמחזיקים מצבי קצה אמיתיים.
נראה איך מציגים “השלכה לפני אישור” כדי למנוע טעויות ולהעלות אמון.
ונסיים עם כלים מעשיים למעצבים שרוצים להוביל מוצרים שבהם ה-AI באמת פועל, אבל בצורה אחראית.

קישור לקבוצה שמאפשרת לבוגרי לימודי עיצוב גרפי ללא ניסיון בכלל למצוא עבודה בקלות: https://www.facebook.com/groups/SGRAPHICDESIGNONLINE

מה זה עיצוב “סוכני” ולמה הוא שונה מממשק אפליקציה רגילה?

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

• הבדל בין “המלצה” לבין “ביצוע”: מי אחראי על התוצאה בפועל

• מעבר מזרימות קצרות לזרימות מתמשכות עם סטטוסים לאורך זמן

• צורך בייצוג של “כוונות”, “כללים”, “גבולות”, ו“אישורים” בממשק

• חוויית משתמש שמזכירה ניהול עובד/ספק ולא שימוש בכלי

• מקום מרכזי ללוג פעולות, ראיות, ותיעוד החלטות

• תכנון מראש של מצבי כשל, אי־ודאות, והחלפת אסטרטגיה

• שפה שמבדילה בין “מה המערכת יודעת” לבין “מה המערכת מניחה”

איך בונים מודל מנטלי ברור למערכת AI שמקבלת החלטות בעצמה?

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

• משפט פתיחה קבוע שמגדיר תפקיד: “אני עוזר/ת לך ל___ במסגרת ___”

• אזור “מה יש לי כרגע” מול “מה חסר לי” כדי לקבוע יכולת פעולה

• כרטיס “מטרה” עם ניסוח קצר + מדד הצלחה ברור

• תצוגת “תכנית” שמפרקת צעדים בלי להעמיס פרטים

• סטטוס רציף שמסביר מה קורה עכשיו ולמה

• מילון מצבים קטן עם אייקון לכל מצב, עקבי בכל המוצר

• דוגמה מוכנה מראש שנראית כמו שימוש אמיתי, לא דמו שיווקי

איך מגדירים גבולות סמכות והרשאות לסוכן AI בתוך המוצר?

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

• קטלוג הרשאות לפי פעולות: “לקרוא”, “לערוך”, “לשלוח”, “למחוק”, “לרכוש”

• סימון סיכון לכל הרשאה: נמוך / בינוני / גבוה עם הסבר קצר

• אפשרות “רק הפעם” מול “תמיד” מול “למשך שבוע”

• מסך מרכזי לניהול הרשאות עם חיפוש והיסטוריה

• רמות אוטונומיה שניתנות לשינוי באמצע תהליך

• כפתור השהיה גלוי בכל מסך רלוונטי

• התראות כשסף הרשאות משתנה או כשנוספה אינטגרציה חדשה

איך מעצבים שקיפות והסבר החלטות בלי להעמיס על המשתמש?

שקיפות טובה היא לא “לכתוב יותר”, אלא “לחשוף נכון את מה שחשוב ברגע הנכון”. המשתמש לרוב רוצה לדעת שלושה דברים: מה המערכת עומדת לעשות, למה היא חושבת שזה נכון, ומה האלטרנטיבות. כדאי להתחיל בשכבה קצרה מאוד של הסבר בשפה אנושית, ורק אחר כך לאפשר העמקה למי שרוצה. הסבר צריך לכלול גם אילו נתונים שימשו בהחלטה, אבל בלי להפוך את הממשק לדוח טכני. דרך יעילה היא “ראיות תומכות”: כמה נקודות קצרות שמראות סימנים שהובילו למסקנה, כמו “מצאתי X, ראיתי Y, לכן בחרתי Z”. חשוב גם להציג אלטרנטיבה אחת לפחות, כי זה מונע תחושה של “אין לי ברירה” ומאפשר תיקון כיוון. במערכת סוכנית, חלק מהשקיפות היא להסביר למה משהו לא נעשה, כי משתמשים מפרשים שתיקה ככישלון. שקיפות חייבת להיות קשורה לפעולה: אם הסוכן עומד לבצע משהו מסוכן, ההסבר צריך להיות בולט יותר ולהופיע לפני ביצוע. בנוסף, יש מקום להציג “רמת ביטחון” בצורה עדינה ולא דרמטית, כדי שלא תערער אמון בכל צעד קטן. ולבסוף, רצוי לאפשר למשתמש להוסיף כלל או העדפה ישירות מתוך ההסבר, כדי להפוך שקיפות לכלי של שליטה ולא רק מידע.

• שכבת הסבר קצרה: משפט אחד “מה ולמה”

• שכבת העמקה: “על סמך מה החלטתי” עם ראיות קצרות

• הצגת אלטרנטיבה: “אפשר גם לבחור ב___”

• מצב “לא בוצע כי…” עם סיבה קונקרטית ולא ניסוח מעורפל

• רכיב “מה יקרה אם” שמראה תוצאה משוערת לפני ביצוע

• קיצור מושגים: מונחים עקביים שמופיעים בכל המוצר

• כפתור “הוסף כלל” מתוך ההסבר: להפוך ידע לכלל פעולה

איך מציגים אי־ודאות ורמת ביטחון בצורה אמינה ולא מלחיצה?

אי־ודאות היא לא תקלה, היא תכונה טבעית של מערכות שמסיקות מסקנות, ולכן צריך לעצב אותה בלי בושה ובלי דרמה. הצגה טובה של ביטחון נמנעת ממספרים שרירותיים אם אין להם משמעות שימושית, ומעדיפה שפה שמתחברת להחלטה. במקום “73%”, אפשר להציג “בטוח מספיק כדי לבצע אוטומטית” מול “צריך אישור שלך”, כי זה תרגום לעולם הפעולה. חשוב להבחין בין אי־ודאות בגלל מידע חסר לבין אי־ודאות בגלל כמה אפשרויות טובות, כי אלו חוויות שונות. כאשר חסר מידע, הממשק צריך להציע בדיוק מה צריך להשלים, אחרת המשתמש לא יודע איך לעזור. כאשר יש כמה אפשרויות טובות, הממשק צריך להציג את הקריטריון שמבדיל ביניהן, כדי שהמשתמש יוכל לבחור לפי העדפה. כדאי להציג גם “סיכוני צד” בצורה צנועה: מה עלול להשתבש ומה הסימנים לכך, כדי שהמשתמש ירגיש שהמערכת מודעת למגבלות. במוצרים מתמשכים, אי־ודאות משתנה עם הזמן, ולכן חשוב להראות איך הביטחון עלה או ירד בעקבות מידע חדש. בנוסף, רצוי לאפשר למשתמש להגדיר ספים: למשל “תבצע לבד רק כשאתה ממש בטוח” או להפך, כדי להתאים לאופי המשתמש. ולבסוף, חשוב שהשפה לא תישמע מתנצלת מדי, כי התנצלות קבועה מייצרת תחושה של מוצר חלש גם כשהוא עובד טוב.

• תרגום ביטחון להחלטה: “אוטומטי” / “המלצה” / “דורש אישור”

• הבחנה בין “מידע חסר” לבין “כמה אפשרויות טובות”

• שאלות השלמה ממוקדות: שדה אחד או שניים, לא טופס ארוך

• תצוגת קריטריונים: מה שינה את הבחירה בין אפשרויות

• הצגת סיכונים אפשריים עם דרכי מניעה קצרות

• היסטוריית ביטחון: למה עכשיו זה יותר בטוח מאתמול

• הגדרת ספי פעולה לפי המשתמש והמשימה

איך מתכננים זרימת אישורים ועצירה כדי לשמור שליטה בלי להרוס חוויה?

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

• מדרג סיכון לפעולות: נמוך / בינוני / גבוה

• אישור על תכנית עם תקציר צעדים, לא על פעולה בודדת בלבד

• שלוש בחירות קבועות: “אישור”, “עריכה”, “עצירה”

• הצגת השלכות: מיידי / מתמשך / בלתי הפיך

• אישור חריגות: רק אם הסוכן חורג מהגבולות שהוגדרו

• עצירה עם הבהרה: מה נשמר, מה נעצר, מה אפשר להמשיך אחר כך

• מנגנון חזרה אחורה עם תיאור מדויק של מה ניתן לשחזר

איך מעצבים התראות, דוחות ויומן פעולות כדי לא לאבד שליטה?

במערכת סוכנית המשתמש לא תמיד מול המסך, ולכן התראות הן חלק מהותי מהבקרה ולא “פיצ’ר נחמד”. ההתראה צריכה לענות על “מה קרה”, “מה המשמעות”, ו“מה צריך ממני עכשיו”, אחרת היא רק רעש. רצוי לייצר שכבות התראה: מידע, נדרש אישור, וסיכון, כדי שהמשתמש יזהה דחיפות במבט. בנוסף להתראות בזמן אמת צריך דוח מסכם שמראה מה הסוכן השיג בתקופה, כי משתמשים מעריכים תוצאות לאורך זמן. יומן פעולות (Audit Log) חייב להיות אנושי: לא רשימת אירועים טכנית אלא סיפור ברור של החלטות והשלכות. דרך טובה היא לשמור כל פעולה ככרטיס עם “כוונה”, “ביצוע”, “תוצאה”, ו“למה”, כדי שאפשר יהיה להבין גם שבוע אחרי. חשוב לתת יכולת סינון לפי סוג פעולה, לפי מערכת חיצונית, ולפי רמת סיכון, כי אחרת הלוג הופך לים מידע. במקרים של כשל, היומן צריך להציע “תיקון מומלץ” או “נסה שוב עם שינוי”, כדי שהמשתמש ירגיש שהמוצר עוזר. בנוסף, כדאי לסמן פעולות שהיו “אוטומטיות” מול “באישור”, כדי להבהיר אחריות ושקיפות. עוד נקודה היא הימנעות מהצפת התראות: עדיף לאחד אירועים, להציג סיכומים, ולתת שקט כשהכול תקין. ולבסוף, תמיד צריך נתיב חזרה מהתראה למסך הקשר שמראה איפה זה קרה ומה הסטטוס כעת.

• שכבות דחיפות: מידע / צריך תגובה / סיכון גבוה

• התראה עם קריאה לפעולה ברורה: “אשר”, “ערוך כלל”, “השהה”

• דוח שבועי/חודשי עם תוצאות, זמן שנחסך, פעולות שבוצעו

• כרטיסי לוג עם: כוונה, פעולה, תוצאה, סיבה

• סינון וחיפוש בלוג לפי תגיות ומשאבים

• סימון פעולה אוטומטית מול פעולה מאושרת

• איחוד התראות כדי למנוע רעש והתרגלות

• קישור הקשרי: מהתראה ישר למסך שבו אפשר להבין ולשנות

איך מונעים טעויות: עיצוב Guardrails, חוקים, ורמזים שמכוונים את הסוכן?

מערכות סוכניות נכשלות הרבה פעמים לא בגלל “באג”, אלא כי הגבולות לא הוגדרו טוב והמערכת עשתה בדיוק מה שאפשר לה. Guardrails בעיצוב הם שילוב של חוקים, רמזים, וספים שמונעים מהסוכן להיכנס לאזור מסוכן בלי בדיקה. הממשק צריך לעזור למשתמש להגדיר כללים בצורה טבעית, למשל “לעולם אל תעשה X” או “תעשה Y רק אם Z”. חשוב להציג כללים כמשפטים בשפה אנושית ולא כמסך הגדרות קר. בנוסף, כדאי לתת תבניות חכמות לכללים נפוצים כדי שמשתמש מתחיל לא יישאר מול דף ריק. ה-Guardrails צריכים להיות גם בזמן אמת: אם הסוכן עומד לחרוג, הממשק מציף זאת לפני ביצוע ומאפשר לבחור. יש צורך גם ב“אזור ניסוי” או “מצב בטוח” שבו הסוכן יכול לתרגל בלי להשפיע על העולם האמיתי, כדי לבנות אמון. עיצוב מניעתי כולל גם הגבלות משאבים כמו תקציב, זמן, ומספר פעולות, כי זה מצמצם נזק מצטבר. חשוב להבחין בין כלל קבוע לבין חריגה חד־פעמית, כדי שהמשתמש יוכל “להרשות” משהו בלי לשנות מדיניות כללית. ולבסוף, כל Guardrail צריך להיות נראה: המשתמש חייב לדעת שהוא קיים, אחרת הוא ירגיש שהמערכת מתנהגת באקראיות.

• כללים בשפה אנושית: “תמיד”, “לעולם לא”, “רק אם”, “עד סכום”

• תבניות לכללים נפוצים שמתחילים יכולים לבחור ולהתאים

• התראה לפני חריגה + אפשרות אישור חד־פעמי

• מצב ניסוי/סימולציה לפני הפעלה אמיתית

• מגבלות משאבים: זמן, תקציב, כמות פעולות, תחומי פעולה

• הבחנה בין מדיניות קבועה לבין חריגה חד־פעמית

• מסך מרכזי שמראה את כל הכללים הפעילים וההשפעה שלהם

איך מעצבים “העברת שליטה” בין אדם לסוכן בלי בלגן?

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

• אינדיקציה תמידית: מי שולט עכשיו ומדוע

• מסך העברה שמציג: יעד, הרשאות, גבולות, משך זמן

• סיכום מהיר כשחוזרים לשליטה אנושית: מה נעשה ומה נשאר

• שינוי כלל באמצע תהליך בלי לאפס הכול

• תצוגת “השלב הבא” אחרי שינוי שליטה

• חלונות פעולה: הסוכן פועל ואז מדווח בנקודות קבועות

• שאלת אימות קצרה לפני המשך כשמשנים כיוון

• חזרה מיידית: כפתור “קח שליטה” בולט ונגיש

איך בונים ממשק היברידי: שיחה + לוחות עבודה + הקשר, ולא רק צ’אט?

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

• חלוקה לשיחה / אזור עבודה / אזור הקשר

• שיחה שמייצרת אובייקטים: משימות, כללים, תכניות, אישורים

• לוח מצב עם סטטוסים, תלויות, וחסימות

• הקשר עם מקור נתונים, זמן עדכון, ורמזי איכות

• מעבר מהודעה לאובייקט בלחיצה אחת בתוך המוצר

• זיכרון תפעולי: מטרות, כללים פעילים, והחלטות אחרונות

• תצוגת ציר זמן להיסטוריית החלטות והתקדמות

• מצב שקט שמראה שהכול רץ בלי להציף הודעות

איך מעצבים מערכות מרובות סוכנים ותזמור בלי לבלבל משתמשים?

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

• לכל סוכן: תפקיד, שם, תיאור קצר, וסימן זיהוי עקבי

• הצגת סוכנים לפי הקשר, לא כולם תמיד

• שרשרת עבודה: מי תכנן, מי ביצע, מי החזיר תוצאה

• סדר עדיפויות גלוי למטרות כדי למנוע התנגשות נסתרת

• הצגת ויכוח כחלופות עם קריטריונים, לא דיון ארוך

• סוכן ראשי אחד לתקשורת מול המשתמש

• מסך בריאות: תקיעות, תורים, חיבורים שנפלו

• כיבוי זמני לסוכן בודד + חזרה פשוטה

• כללים גלובליים שחלים על כולם למניעת חריגות

איך מודדים אמון, עומס קוגניטיבי והצלחה במערכת סוכנית?

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

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

• שינוי רמת אוטונומיה כמדד אמון התנהגותי

• זמן להבנת מצב: כמה מהר מבינים “מה קורה עכשיו”

• נקודות התערבות אנושית: איפה ולמה המשתמש לקח שליטה

• שיעור אישורים מהירים מדי כסימן לעייפות וסיכון

• ביטולים אחרי ביצוע: החלטות שעברו ואז התבררו כלא רצויות

• יחס “פעולות מועילות” מול “פעולות סרק” של הסוכן

• משוב רגעי אחרי החלטות גדולות במקום סקר כללי בלבד

איך משלבים פרטיות, אתיקה וציות בתוך חוויית המשתמש של סוכן?

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

• הסבר פרטיות קצר ותפעולי: מה נאסף, למה, לכמה זמן

• גבולות מידע לפי מקורות: מותר/אסור/דורש אישור

• הרשאות לפי תפקיד בארגון: אישי, צוותי, ארגוני

• שקיפות קריטריונים כדי לצמצם הטיות ולהגביר הוגנות

• הצגת “למה לא” במצבי סיכון, לא רק “למה כן”

• תצוגה מוקדמת: “מי יקבל/יראה” לפני שליחה או שיתוף

• מחיקת היסטוריה וניהול עקבות בפשטות

• מניעת מניפולציה: הצעות שמסומנות כעדיפות משתמש, לא עדיפות מוצר

איך בונים Design System לממשקי Agentic עם מצבים, טוקנים, וקומפוננטים עקביים?

במוצרים סוכניים, העקביות חשובה אפילו יותר כי המשתמש מנסה לבנות תחושת “צפיות” להתנהגות המערכת. Design System צריך להתחיל ממודל מצבים ברור שמגדיר מה זה “ממתין”, “מבצע”, “נעצר”, “נכשל”, “דורש אישור”, ו“הושלם”. אחרי זה מגדירים קומפוננטים שחוזרים בכל מקום: כרטיס משימה סוכנית, כרטיס החלטה, חלונית אישור, כרטיס סיכון, וכרטיס ראיות. כדאי להגדיר גם טוקנים של דחיפות ומצב, כדי שכל הצוות ישתמש באותה שפה ויזואלית, ולא ימציא צבע/אייקון בכל פעם מחדש. במערכת סוכנית יש צורך בסטייטים ייחודיים כמו “מבצע ברקע” או “מושהה עקב חריגה”, ולכן צריך להגדיר אותם מראש ולא לאלתר. בנוסף, כדאי לתכנן תבניות ל“סיכום פעולה” ול“סיכום תקופה”, כי אלה מסכים קריטיים לאמון. מערכת קומפוננטים צריכה לכלול גם טיפוגרפיה שמעדיפה קריאות והיררכיה, כי המשתמש קורא הסברים והחלטות ולא רק כותרות. מיקרו־אינטראקציות חייבות להיות מרוסנות: אנימציה יכולה להעביר “עובד עכשיו” או “נעצר”, אבל אם היא מוגזמת היא תרגיש כמו צעצוע מול החלטות רציניות. חשוב להגדיר גם שפת כתיבה (Voice): איך המערכת מדברת כשהיא בטוחה, כשהיא לא בטוחה, וכשהיא לא יכולה לבצע. כדאי להגדיר דפוסי שגיאה שחוזרים, כולל הצעות תיקון, כי כשל במערכת סוכנית הוא חלק מהמציאות. ולבסוף, ה-Design System צריך לכלול הנחיות להנגשה, כי החלטות אוטונומיות חייבות להיות מובנות לכל משתמש, גם תחת עומס.

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

• קומפוננטים בסיסיים: כרטיס החלטה, כרטיס סיכון, כרטיס ראיות, חלונית אישור

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

• תבניות מסך לסיכום פעולה ולסיכום תקופה

• טיפוגרפיה היררכית שמדגישה “מה יקרה” לפני “למה”

• מיקרו־אינטראקציות שמשרתות מצב ולא קישוט

• שפת כתיבה עקבית לפי רמת ביטחון ומדיניות

• דפוסי כשל עם מסלול תיקון ברור

• הנחיות הנגשה למצבי עומס וקריאה של מידע חשוב

אילו פרויקטים בתיק עבודות מוכיחים יכולת בעיצוב סוכני ולא רק UI יפה?

תיק עבודות בתחום סוכני צריך להראות חשיבה מערכתית ולא רק מסכים יפים, כי האתגר הוא התנהגות לאורך זמן. פרויקט טוב מתחיל בבעיה אמיתית שמערבת החלטות רבות, כמו ניהול תהליך, קבלת החלטות חוזרת, או עבודה מול משאבים וסיכון. חשוב להציג את מודל האצלת הסמכות: מה המשתמש קובע, מה הסוכן מחליט, ומה דורש אישור. כדאי להראות איך עיצבת שקיפות: מה הסוכן מציג לפני פעולה, ואיך המשתמש מבין “למה”. רצוי לכלול תרחישי כשל מפורטים, כי זה מה שמבדיל מוצר רציני מדמו שיווקי. הפרויקט צריך להראות מנגנוני בקרה: לוג, דוחות, התראות, וספי פעולה, כדי להמחיש שליטה. בנוסף, חשוב להציג החלטות כתובות: למה בחרת בממשק היברידי או בצ’אט, ומה בדקת כדי להחליט. כדאי להראות גם ניסויים קטנים: גרסאות שונות של אישור, או ניסוחי הסבר שונים, ומה למדת. לתחום הזה יש חשיבות לכתיבה ולמיקרו־קופי, ולכן תיק עבודות טוב יראה גם שפה עקבית ולא רק ויזואל. רצוי להציג גם Design System קטן: קומפוננטים ומצבים ייעודיים, כדי להוכיח שאתה חושב לטווח ארוך. ולבסוף, חשוב לסיים במדדים שהיית מודד וההשערות שלך, גם אם זה פרויקט לימודי, כי זה מראה בגרות מוצרית.

• בעיה שדורשת רצף החלטות, לא פעולה אחת

• תרשים האצלה: מה אדם מחליט, מה סוכן מחליט, ומה דורש אישור

• תרחישי כשל: חריגות, מידע חסר, התנגשות מטרות, פעולה בלתי הפיכה

• לוג פעולות ודוחות שמראים שליטה לאורך זמן

• מסכים שמציגים שקיפות: “מה/למה/אלטרנטיבה”

• וריאציות וניסוי: שתי גרסאות לאישור או להסבר והשוואה ביניהן

• שפה כתובה עקבית למצבי ביטחון וכשל

• סט קטן של קומפוננטים ומצבים כחלק ממערכת עיצוב

• מדדים והנחות: מה היית מודד כדי לדעת שזה עובד

אילו כלים ותוכנות עוזרים לעצב ממשקים סוכניים, ומה כל אחד משרת בתהליך?

כדי לעצב מערכת סוכנית צריך כלים שמכסים גם מסכים וגם התנהגות, ולכן שילוב כלים חכם הוא יתרון. Figma מצוינת לבניית זרימות, קומפוננטים, ופרוטוטייפים שמדגימים מעבר בין מצבים, במיוחד כשיש הרבה סטייטים ואישורים. בפרוטוטייפים של מערכת סוכנית חשוב לדמות גם זמן, ולכן כדאי להשתמש באינטראקציות שמראות “ריצה ברקע” ו“התראות”, ולא רק קליקים. Adobe יכולה לשרת יצירת אייקונים, אילוסטרציות, ושפה ויזואלית נקייה שמבדילה מצבים וסיכון בלי עומס, במיוחד כשצריך עקביות גבוהה. כלי עריכת תמונה יכולים לעזור לבנות הדמיות ריאליסטיות של דאשבורדים, דוחות, וסיכומים שיכולים להופיע במוצר. כלי אנימציה שימושיים כשצריך להמחיש “מעבר שליטה” או “עצירה” בצורה אינטואיטיבית, אבל צריך להשתמש בהם במינון כדי לא להיראות משחקיים. במסמכים ומצגות תהליך, כלי עימוד יכולים לעזור להציג Case Study ארוך וברור, כולל תרשימים, החלטות, וממצאי ניסוי. בנוסף, חשוב להשתמש בכלי שיתופי לתיעוד החלטות ועקרונות, כי מערכות סוכניות מערבות צוותים רחבים. עבור בדיקות, כדאי לבנות תרחישים כתובים (Scripts) ולחבר אותם לפרוטוטייפ, כדי שהבדיקה תמדוד הבנה ושליטה ולא רק “יפה/לא יפה”. גם יצירת ספריית טקסטים עקבית היא “כלי” בפני עצמו: משפטי מצב, אישור, שגיאה, וחוסר ודאות, שעוברים בין מסכים. ולבסוף, מומלץ לבנות קיטים של קומפוננטים למצבי סיכון ואישור, כי אלה חוזרים שוב ושוב ומקצרים עבודה.

• Figma: קומפוננטים, סטייטים, פרוטוטייפים של זרימות אישור והחלפת שליטה

• Adobe: שפה ויזואלית, אייקונים, אילוסטרציה, ועקביות גרפית למצבי מערכת

• כלי אנימציה: הדגמת “ברקע”, “עצירה”, “העברה”, ומעבר בין סטטוסים

• כלי עימוד/מסמכים: Case Study ברור עם תרשימים ותיעוד החלטות

• כלי שיתופי תיעוד: עקרונות מערכתיים, מדיניות, וכללים גלובליים

• תרחישי בדיקה כתובים שמודדים הבנה, אמון, ושליטה

• ספריית מיקרו־קופי עקבית למצבים קריטיים

• קיט קומפוננטים לסיכון/אישור/ראיות שמאיץ פיתוח

מה אפשרויות העבודה למעצב מתחיל שרוצה להתמחות במערכות Agentic, ומה חשוב ללמוד?

שוק העבודה למערכות AI סוכניות מחפש שילוב של UX עמוק, חשיבה מוצרית, ויכולת לתקשר עם צוותים טכניים בלי להיבהל. תפקידים נפוצים כוללים Product Designer למוצרי AI, UX Designer שמתמחה בזרימות אישור ובקרה, ו-Conversation/Interaction Designer לממשקים היברידיים. יש גם מסלולים של Trust & Safety Design שבהם מתכננים מנגנוני הגנה, שקיפות, ומדיניות בתוך מוצר. כדי להיכנס לתחום, חשוב ללמוד איך מערכות מקבלות החלטות ברצף, ואיך לתכנן חוויה שמתמודדת עם אי־ודאות וכשל. מעצב מתחיל צריך להראות יכולת להסביר החלטות עיצוב, לבנות מודל מצבים, ולתכנן לוג ודוחות, כי אלה רכיבי בסיס במוצר סוכני. חשוב גם להבין עקרונות של חוויית משתמש במוצרים מורכבים: היררכיה, קריאות, הקשר, והפחתת עומס. בנוסף, יכולת כתיבה טובה היא יתרון עצום כי הממשק מלא בהסברים, אישורים, ושאלות השלמה. כדאי לפתח גם מיומנות של מחקר משתמשים שמתמקד באמון ובהבנת מערכת, לא רק בנוחות שימוש. למעצב בתחילת הדרך חשוב לבחור נישה קטנה ולהעמיק, למשל “עיצוב אישורים” או “עיצוב שקיפות החלטות”, כדי לבדל את עצמו. ולבסוף, כדאי ללמוד לעבוד עם צוותים: איך לכתוב ספציפיקציה ברורה, איך להגדיר התנהגות, ואיך להעביר עיצוב למפתחים בלי אובדן משמעות.

• תפקידים: Product Designer AI, UX למערכות אוטונומיות, Conversation/Interaction, Trust & Safety Design

• יכולות בסיס: מודל מצבים, זרימות אישור, שקיפות, ולוג פעולות

• חוויה במוצרים מורכבים: היררכיה, קריאות, הקשר, ועומס קוגניטיבי

• כתיבה ומיקרו־קופי כמקצוע: ניסוחים למצבי ביטחון, כשל, וסיכון

• מחקר משתמשים שמודד אמון, שליטה, והבנה של “מה קורה עכשיו”

• בניית התמחות: לבחור רכיב אחד ולהיות “חזק בו” בתיק עבודות

• ספציפיקציה: לתאר התנהגות מערכתית ולא רק מסכים

• עבודה צוותית: תקשורת עם פיתוח, מוצר, ותמיכה סביב מקרי קצה

איך מפתחים יצירתיות וחשיבה עיצובית כשמערכת AI מבצעת החלטות במקומך?

במערכות סוכניות קל להיתקע בתבניות טכניות ולשכוח שעיצוב הוא גם חשיבה יצירתית על יחסי אדם־מערכת. יצירתיות כאן היא לא קישוט, אלא המצאת מטאפורות חדשות לשליטה, שקיפות, והאצלה. חשיבה עיצובית מתחילה בהגדרת הבעיה: מה המשתמש מפחד לאבד, מה הוא רוצה לחסוך, ואיפה הוא צריך מעורבות. כדי לפתח יצירתיות, כדאי לשרטט כמה מטאפורות שונות לאותו מוצר, למשל “עוזר אישי”, “מנהל פרויקט”, “טייס אוטומטי”, ואז לבדוק איזו מטאפורה מייצרת הכי מעט הפתעות. תרגיל חזק הוא לעצב את אותו פיצ’ר בשלוש רמות אוטונומיה שונות, כדי להבין איך הממשק משתנה כשכוח עובר מהאדם למערכת. עוד תרגיל הוא לכתוב את “חוקי העולם” של הסוכן ב-10 משפטים, ואז לראות אם המסכים שלך באמת מממשים אותם. כדאי גם להמציא דפוסי אינטראקציה שמאפשרים תיקון מהיר: עריכת כלל מתוך התראה, או שינוי יעד מתוך כרטיס פעולה. יצירתיות מתבטאת גם בבחירת מה לא להראות: אילו פרטים טכניים רק יבלבלו, ואילו שני פרטים יאירו את כל התמונה. חשוב לעבוד עם סקיצות ידניות מוקדמות כדי לא להינעל על פתרון אחד מהר מדי, כי במערכות סוכניות הפתרון הראשון לעיתים “נשמע נכון” אבל נכשל בשטח. בנוסף, כדאי לחשוב על חוויית המשתמש ברגעי לחץ: כשל, חריגה, או פעולה מסוכנת, כי שם נמדד עיצוב אמיתי. ולבסוף, יצירתיות בתחום הזה היא גם אומץ לקבוע גבולות ולומר “כאן הסוכן לא פועל בלי אדם”, כי לפעמים הפתרון הטוב הוא לעצור.

• מטאפורות שונות: עוזר, מנהל פרויקט, טייס אוטומטי, שומר סף

• עיצוב אותו פיצ’ר בשלוש רמות אוטונומיה כדי להבין השלכות

• ניסוח “חוקי עולם” של הסוכן ולבדוק התאמה למסכים

• מנגנוני תיקון מהיר מתוך הקשר: כלל מתוך התראה, יעד מתוך כרטיס

• בחירה מודעת של מידע מינימלי שמייצר הבנה מקסימלית

• סקיצות ידניות מוקדמות כדי לא להינעל על פתרון אחד

• תכנון רגעי לחץ: כשל, חריגה, סיכון, הפסקה

• החלטה מודעת איפה חייבים אדם, גם אם זה פחות “אוטומטי”

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

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

• כרטיס פעולה: תקציר, סטטוס, השלכות, כפתורי שליטה

• מסך סיכון: מה הפעולה, למה עכשיו, מה עלול לקרות, ומה אפשר לבטל

• מסך בקרה: מה רץ, מה ממתין, מה חריג, ומה נדרש מהמשתמש

• מסך כשל: סיבה, השפעה, צעדי תיקון, וניסיון חוזר בטוח

• מסך תכנית: צעדים עתידיים + נקודות אישור + אפשרות עריכה

• מסך ראיות בשכבות: קצר ואז העמקה לפי צורך

• מסך יומן עם חיפוש, סינון, וסימוני אוטומטי/באישור

• יציאה קבועה לשליטה: השהיה, שינוי כלל, לקיחת שליטה

צ’ק-ליסט לפני השקה של ממשק סוכני: מה חייב להיות ברור למשתמש

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

• מפת יכולות ברורה: מה הסוכן עושה ומה לא

• הבנת מצב מהירה: “מה קורה עכשיו” תוך שניות ספורות

• הרשאות מבוססות פעולות + השהיה מיידית

• נקודות אישור לפי סיכון ולא לפי כמות צעדים

• לוג פעולות קריא + חיפוש וסינון

• התנהגות טובה במידע חסר/סותר/ריבוי חלופות

• שפה עקבית למצבי ביטחון, כשל, וסיכון

• סטייטים מוגדרים היטב בלי אזורי “לא ברור מה קורה”

• התראות לא מציפות + קריאה לפעולה ברורה

• יכולת שינוי כללים והתאמה אישית כחלק מרכזי מהחוויה

סוכן שמנהל כסף, תקציב ורכישות בלי להפוך את המוצר למסוכן

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

• תקציב קשיח + תקציב גמיש: גבול מקסימום מול יעד מומלץ

• מגבלת תדירות: כמה רכישות/התחייבויות מותרות בפרק זמן

• אישור כפול לפעולות בלתי הפיכות: התחייבות, שדרוג, רכישה חוזרת

• הצגת עלות כוללת צפויה ולא רק מחיר נקודתי

• הפרדת שלבים: חיפוש והשוואה → סיכום → אישור → ביצוע

• כפתור “ביטול מיידי” שמופיע בכל מסך שמוביל להתחייבות

• תיוג הצעות: שמרני / מאוזן / אגרסיבי כדי למנוע הפתעות

• תיעוד החלטה קצר לכל פעולה כספית בתוך יומן הפעולות

סימולציה ומצב “יובש” לפני ביצוע כדי לבנות אמון אמיתי

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

• מתג מצב ברור: סימולציה / ביצוע אמיתי, עם סימון עקבי בכל המסכים

• תצוגת תכנית עם נקודות אישור מסומנות מראש

• תצוגת טריגרים: “מתי אתה מתקדם לבד” מול “מתי אתה מחכה לי”

• הדמיית זמן: מה קורה מיד, מה קורה בעוד שעה, ומה קורה בסוף היום

• תרחיש כשל מובנה: מה יקרה אם חסר מידע או אם אינטגרציה נופלת

• עריכת כללים בתוך הסימולציה + תוצאה מעודכנת מיידית

• השוואת שתי תכניות תחת כללים שונים כדי לבחור רמת סיכון

• מעבר מבוקר לביצוע: סיכום, אישור, ויכולת חזרה אחורה

מערכת לומדת ומשתנה לאורך זמן בלי לבלבל את המשתמש

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

• “מה חדש בהתנהגות”: כרטיס קצר שמופיע אחרי שינוי משמעותי

• הפרדה ברורה: העדפות משתמש מול יכולות מערכת

• אפשרות ביטול התאמה אישית: חזרה להתנהגות קודמת בלחיצה

• הצגת “כלל שנלמד” במשפט פשוט + דוגמה קצרה

• אזור “עדיין לא בטוח” כדי למנוע ציפיות שווא

• סף למידה: מתי שינוי דורש אישור ומתי לא

• בקרת הסתגלות: נמוכה / בינונית / גבוהה לפי המשתמש

• תיעוד שינוי ביומן פעולות כדי לשמור עקיבות לאורך זמן

אינטגרציות לכלים חיצוניים: איך מעצבים חיבור, הרשאות והקשר בלי לאבד שליטה

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

• תיאור תפעולי לפני חיבור: “עם זה אפשר ___” ולא הסבר טכני

• הרשאות מפורקות לפעולות: לקרוא / לערוך / לשלוח / למחוק

• מקור וזמן עדכון לכל נתון שמשפיע על החלטה

• בדיקת חיבור: תקין / חסר הרשאה / נפל חיבור + מסלול תיקון

• ציון חשבון פעיל בכל פעולה חיצונית כדי למנוע טעויות זהות

• פעולות בטוחות כברירת מחדל: טיוטה לפני שליחה, הכנה לפני ביצוע

• תצוגה מוקדמת לפני כל פעולה חיצונית משמעותית

• מסך מרכזי לניהול חיבורים וניתוק עם השפעה ברורה

• Slack, Microsoft, Google כדוגמאות נפוצות לעולמות שבהם חשוב להבדיל בין טיוטה, אישור, וביצוע

עיצוב נגד מניפולציות, “הטיות”, ולחץ חברתי שמנסים לגרום לסוכן לעשות משהו מסוכן

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

• דגל חשד קצר שמסביר “למה זה נראה לא בטוח”

• הצגת מקור והקשר: ערוץ, שולח, זמן, ורמזי אמינות

• אימות נוסף לפעולות מסוכנות: שיתוף, מחיקה, התחייבות, שינוי הרשאות

• מצב התנהגות שמרני אוטומטי כשמזוהה דפוס חשוד

• תצוגת “מי יראה את זה” לפני שיתוף מידע או שליחה

• “הוסף כלל בטיחות” מתוך אירוע כדי למנוע חזרה

• כפתור “סמן כחשוד” שמייצר היסטוריה אישית של חריגות

• שימוש בטיוטות והשהיות כדי לשבור רצפים אוטומטיים מזיקים

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

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

• תפקידים ברורים: בעל מטרה / מאשר / צופה / מבצע

• שרשרת אישור קצרה: מי אישר, מי חסר, ומתי זה דחוף

• הצגת סיבת חשיפה: “אתה רואה כי אתה אחראי על ___”

• העברת משימה עם הקשר מלא: סטטוס, כללים פעילים, והחלטות קודמות

• כרטיס תקציר מנהלים לפני פירוט עמוק

• מסלול אי־הסכמה: הצגת חלופות + קריטריונים + החלטה

• רמת אוטונומיה שונה לפי צוות/פרויקט

• יומן פעולות עם “מי עשה מה” כדי לשמור אחריות ושקיפות

RTL, טיפוגרפיה, והנגשה בממשקי Agentic כדי שהשליטה תהיה מובנת גם בלחץ

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

• היררכיה טיפוגרפית חזקה: תקציר לפני פירוט, תמיד באותו סדר

• עקביות RTL מלאה בכל רכיב: טבלאות, ציר זמן, תפריטים, ושדות

• סימון מצב בלי להסתמך רק על צבע: אייקון + טקסט + מבנה

• מרווח נשימה סביב נקודות אישור וסיכון כדי למנוע טעויות

• ניסוחים קבועים למצבי מערכת שמייצרים זיהוי מהיר

• הסברים קצרים בהקשר למונחים מורכבים בלי “לזרוק” את המשתמש החוצה

• קיצורי דרך למתקדמים שלא מסתירים מידע חיוני למתחילים

• אנימציות מרוסנות שמסמנות מצב בלי להוסיף לחץ

חוקי עיצוב גרפי שמקבלים משמעות חדשה כש-AI פועל בשמך

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

• ניגודיות כדי להבחין סיכון/שגרה במבט אחד

• יישור ועקביות כדי לבנות תחושת יציבות וצפיות

• קיבוץ חכם: פעולה + הסבר + ראיות + השלכות באותו אזור

• חזרתיות בדפוסים כדי ללמד משתמש בלי מדריך

• היררכיה שמציגה השלכות לפני כפתורים כדי להפחית טעויות

• חלל ריק להורדת עומס קוגניטיבי בזמן החלטה

• רכיבי גשטאלט שמייצרים “אובייקטים” ברורים בתוך המוצר

• צבע מצבי במינון נמוך כדי לשמור אמון

• טיפוגרפיה שמדגישה ספים, תאריכים, ומשאבים קריטיים

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

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

• מחקר פחדים והעדפות האצלה: מה אסור בלי אישור ומה כן

• תרחישי קצה מוגדרים מראש: חריגה, חוסר מידע, התנגשות מטרות, סיכון

• פרוטוטייפ של רצף זמן שלם, לא רק מסכים בודדים

• בדיקות שמודדות הבנת מצב ומהירות שליטה

• בדיקת שפה: “מה/למה/מה עכשיו” בכל נקודת החלטה

• משוב בתוך הזרימה אחרי רגעים קריטיים, לא רק בסקר כללי

• מסמך התנהגות: מצבים, טריגרים, נקודות עצירה, וחזרה אחורה

• מקרי קצה כתובים כדי למנוע אלתורים בפיתוח

• מבנה תיק עבודות שמציג החלטות, סיכונים, והמדדים שהיית בודק

כשדברים משתבשים: עיצוב אירוע חריג, עצירת חירום, ושחזור אמון אחרי תקלה

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

• מסך חריג שמבדיל: כשל חיבור מול כשל החלטה

• הסבר מיידי: מה קרה, מה ההשפעה, ומה הסטטוס עכשיו

• פעולה אחת-שתיים ברורות: נסה שוב / שנה כלל / השהה

• עצירת חירום זמינה + פירוט מה ייעצר ומה ימשיך

• הצגת אפשרויות תיקון כשפעולה כבר בוצעה, בלי הבטחות שווא

• סיכום “מה השתנה בעקבות האירוע” לשיקום אמון

• יומן אירוע שמספר רצף: טריגר → החלטה → פעולה → תוצאה

• אפשרות הקשחת כללים והורדת אוטונומיה לאחר תקלה

• חזרה הדרגתית לפעולה במצב שמרני במקום “חזרה מלאה”

סוכן שמנהל תוכן וקמפיינים: איך מעצבים מערכת שיוצרת, מתזמנת ומפרסמת בשם המשתמש

כשסוכן AI מנהל תוכן הוא לא רק “כותב”, אלא מקבל החלטות על סדר עדיפויות, מסרים, טון, ותזמון, ולכן הממשק חייב להפוך את זה לגלוי ובר־שליטה. הדבר הראשון הוא להפריד בין יצירה לבין הפצה, כי יצירה אפשר לתקן בשקט אבל הפצה יכולה לגרום נזק אם יצאה מוקדם מדי. הדבר השני הוא לבנות “שפת מותג” כמבנה חי: ערכים, מילים מותרות/אסורות, קהלים, ודוגמאות כתיבה, ולא רק מסמך טקסט שאף אחד לא פותח. הדבר השלישי הוא להציג בקדמת המסך “מה הולך לצאת” בשבוע הקרוב, כדי שהמשתמש ירגיש שליטה בלי להיכנס לכל פריט. הדבר הרביעי הוא להכניס נקודות אישור לפי סיכון: פוסט פנימי יכול לצאת אוטומטית, אבל הודעה ללקוח גדול או קמפיין בתשלום חייבים אישור ברור. הדבר החמישי הוא להראות מקור השראה או ראיות לתוכן, כדי שהמשתמש יבין מאיפה הגיע ניסוח ולא ירגיש שזה שרירותי. הדבר השישי הוא לנהל גרסאות כמו מוצר: טיוטה, גרסה מאושרת, גרסה שפורסמה, ומה השתנה ביניהן, כי אחרת קשה לדעת “מה באמת יצא”. הדבר השביעי הוא לתת כפתור שינוי כיוון מהיר שמתרגם ביקורת לכלל, למשל “יותר רשמי”, “פחות מבטיח”, “יותר קצר”, כדי שהמשתמש לא יערוך ידנית כל פעם. הדבר השמיני הוא להציג “הערכת סיכון תוכן” עדינה: רגישות משפטית, רגישות מותגית, רגישות תרבותית, כדי שהמשתמש יבין איפה כדאי לעצור. הדבר התשיעי הוא לדאוג שגם כשלא מפרסמים, יש ערך: דוח קצר מה הסוכן למד מהתגובות ומה הוא מציע לשנות בפעם הבאה.

• לוח שבועי שמציג תוצרים קרובים + אפשרות לעצירה נקודתית

• תבנית שפת מותג: ערכים, טון, דוגמאות, ומילים רגישות

• הפרדת מסכים: יצירה/עריכה מול הפצה/אישורים

• גרסאות לכל פריט: טיוטה → מאושר → פורסם → תיקון

• נקודות אישור לפי סיכון: תשלום, לקוחות רגישים, התחייבויות

• פעולת “הפוך להנחיה קבועה” מתוך ביקורת על ניסוח

• תצוגת מקור השראה פנימית: מה הוביל למסר, בלי להציף פרטים

• דוח תובנות תקופתי שמחבר תגובות לשינויי כללים והתנהגות

סוכן שמנהל משימות מורכבות עם תלויות: איך מציגים “תכנית חיה” בלי להפוך ללוח מסובך

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

• תצוגת תכנית כשלבים עם סטטוס לכל שלב, לא רק רשימת משימות

• תגיות תלויות: חוסם / נחסם / אפשר במקביל, עם מינימום רעש

• הצעת תכנון מחדש עם תקציר “מה השתנה” ו“מה ההשפעה”

• סימון יציבות של שלבים: סגור / משוער / תלוי באחרים

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

• מסלול קריטי מוצג בפשטות: מה רגיש לעיכוב ומה לא

• חלופות בקונפליקט: אפשרות א’ מול ב’ עם מחיר תפעולי לכל אחת

• עיכוב הופך לפעולה: שאלה ממוקדת או בקשת פריט חסר

• עיקרון נעוץ שמיישר החלטות עתידיות בלי עריכה חוזרת

עיצוב Multi-Modal לסוכנים: טקסט, מסמכים ותמונות באותה זרימה בלי לאבד הקשר

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

• כרטיס משאב: מקור, זמן עדכון, הרשאות, ומצב שימוש בתכנית

• תקציר מסמך + תצוגה מקדימה ממוקדת במקום הצפה של קבצים

• הפרדה ברורה: עובדות שנשלפו מול מסקנות שהוסקו

• ניהול גרסאות מסמכים והצגת השפעת שינוי גרסה על החלטות

• תיקון הבנה על ידי סימון אזור רלוונטי במסמך/תמונה

• שימוש בתמונות כראיה תפעולית: מה רואים ומה זה משפיע

• תצוגה מוקדמת לפני שיתוף: מה בדיוק יוצא החוצה

• קשר דו־כיווני: מצעד בתכנית למשאב ולהפך כדי לשמור הקשר

“דיבאג” של החלטות: איך מעצבים למשתמש יכולת לבדוק, לשחזר ולהבין בלי להיות מפתח

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

• מבנה החלטה קבוע: מטרה → קלט → כללים → בחירה → תוצאה

• שחזור רגע: מצב נתונים, הרשאות, וכללים כפי שהיו בזמן אמת

• השוואת החלטות לאורך זמן כדי להבין שינוי התנהגות

• בדיקת “מה אם”: שינוי כלל והדמיית תוצאה בלי ביצוע אמיתי

• סימון ניחוש: מה חסר כדי להגיע לביטחון גבוה יותר

• מסלול תיקון קצר שמייצר כלל חדש מתוך טעות

• תצוגת תורים והמתנות כדי למנוע פירוש שגוי של “תקוע”

• הבחנה ברורה בין כשל פנימי לכשל חיבור חיצוני

• ניקוי היסטוריה עם הסבר מה נשמר ומה נעלם

Onboarding שמכוון אמון: איך מציגים סוכן אוטונומי למשתמש בלי להפחיד ובלי להבטיח יותר מדי

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

• משימת פתיחה בטוחה שמדגימה ערך בלי סיכון

• שלושה עקרונות התנהגות קבועים שמופיעים בהתחלה ובמקומות קריטיים

• יצירת כללים ראשוניים יחד עם המשתמש, קצרה ומעשית

• דוגמה מלאה של תהליך כולל עצירה ותיקון, לא רק “הצלחה”

• מתג רמת אוטונומיה עם המלצה שמרנית להתחלה

• הרשאות בהדרגה לפי צורך ולא “בבת אחת”

• שאלות השלמה קצרות שמגדירות גבולות מידע

• אזור קבוע למצב נוכחי כדי למנוע תחושת “מאחורי הקלעים”

• סיום עם שלושת העוגנים: כללים, עצירה, היסטוריה

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

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

• הודעות פעולה שמפרטות: מה בוצע, מה לא, ומה השלב הבא

• שפה שמדגישה סמכות משתמש: הצעה, אישור, עריכה, עצירה

• הבחנה מילולית בין ודאי למשוער כדי למנוע בלבול

• שאלות השלמה קצרות וממוקדות כדי לשמור זרימה

• ניסוח אישור שמציג השלכות לפני פעולה כדי להפחית טעויות

• מילון ניסוחים קבוע למצבי מערכת שמופיע בכל המסכים

• טון מקצועי בלי “קסם” ובלי האנשה מוגזמת

• ניסוח עצירה שמסביר מה חסר ואיך ממשיכים

• ניסוח שינוי כלל כמנגנון למידה מתמשך

כלי עבודה למעצב שמפתח מוצר Agentic: איך משתמשים בכלי גרפיקה כדי לשרת החלטות, מצבים והסברים

עבודה על ממשק סוכני דורשת ארסנל כלים שמשרת לא רק ויזואל, אלא בעיקר מצב, עקביות, והדמיית התנהגות לאורך זמן. Adobe יכולה לשמש כבסיס ליצירת אייקונים ומטאפורות ברורות למצבי מערכת, למשל הבדל עדין בין “ממתין” ל“נעצר” מבלי להסתמך על צבע בלבד. כלי וקטור מאפשר לבנות סט אייקונים עקבי, כי במערכת סוכנית אייקון לא רק מקשט אלא עוזר לזהות סיכון והקשר בשניות. כלי עריכת תמונה עוזר ליצור הדמיות של תרחישים מורכבים: דוח שבועי, יומן אירועים, והתראה במובייל, בלי לבנות הכול בקוד כדי לבדוק רעיון. כלי אנימציה נותן דרך להמחיש “ריצה ברקע” ו“העברת שליטה” באופן שמוריד חרדה, אבל צריך לשמור על תנועה מינימלית כדי לא לשדר קלילות מול החלטות רציניות. כלי עימוד מסייע לבנות תיעוד ו־Case Study שנראה מקצועי: מודל מצבים, תרחישי קצה, ודפוסי אישור, כי בתחום הזה הצגת החשיבה חשובה כמו התוצר. כלי ניהול מסמכים וצוות מאפשר לשמור ספריית ניסוחים וכללים לצד רכיבי עיצוב, כדי שהשפה והוויזואל לא יתפצלו. בנוסף, כדאי לבנות תבניות מוכנות של מסכי סיכון/אישור/כשל כדי לא להמציא מחדש בכל פרויקט ולהישאר עקבי. חלק מהעבודה הוא גם יצירת ערכת טקסטים למצבים בעברית ו־RTL, כי אפילו טקסט קצר יכול לשנות תחושת שליטה. ולבסוף, כלי עבודה טוב הוא תהליך: ספרייה של תרחישים מוכנים לבדיקה, כך שכל שינוי בעיצוב נבחן מול אותם רגעים קריטיים ולא רק מול מסך יפה.

• סט אייקונים עקבי למצבי מערכת וסיכון, עם הבדלים עדינים וברורים

• הדמיות מסכים מורכבים (יומן, דוחות, התראות) כדי לבדוק רעיונות מהר

• אנימציות מינימליות שמסבירות מצב: ברקע, עצירה, העברה

• מסמכי Case Study מסודרים שמציגים מודל מצבים ותרחישי קצה

• ספריית ניסוחים וכללים שמתחברת לקומפוננטים כדי לשמור עקביות

• תבניות מוכנות למסכי אישור/סיכון/כשל כדי לאלף את המערכת

• ערכת טקסטים בעברית שמדגישה שליטה והשלכות במינימום מילים

• סט תרחישי בדיקה קבועים שמלווה כל פרויקט ומשווה בין גרסאות

פרויקטים לתיק עבודות שמראים מומחיות ב-Agentic Design: איך להציג חשיבה מערכתית ולא רק מסכים

כדי להוכיח יכולת בעיצוב סוכני, תיק עבודות צריך להראות שאתה מבין אחריות, בקרה, וניהול סיכון, ולא רק קומפוזיציה. פרויקט מוצלח יתחיל בהגדרת תפקיד הסוכן במדויק ובמפת גבולות, כדי שלא ייראה כמו “AI כללי” בלי שליטה. כדאי להציג תרשים מצבים שמראה ממתין/מבצע/דורש אישור/נעצר/נכשל, כי זה הלב של מוצר אוטונומי. חשוב להראות איך עיצבת שקיפות: מה הסוכן מציג לפני פעולה ומה הוא מציג אחרי, כדי שהמשתמש יבין את הסיבה והתוצאה. בנוסף, פרויקט טוב יראה תרחישי קצה, כי במערכות סוכניות מקרי קצה הם השגרה ולא החריג. כדאי להציג איך בנית מנגנון תיקון: שינוי כלל מתוך טעות, חזרה אחורה, והשהיה, כי אלה תכונות שמייצרות אמון. מומלץ להראות גם דפוסי כתיבה: ניסוח אישור, ניסוח אי־ודאות, ניסוח עצירה, כי אלה כמעט תמיד נעלמים מתיק עבודות רגיל אבל כאן הם קריטיים. כדי להיראות מקצועי, כדאי להוסיף מדדים שהיית בודק בהשקה: זמן להבנת מצב, מספר אישורים עיוורים, נקודות התערבות, וביטולים אחרי ביצוע. חשוב גם להציג למה לא בחרת בחלופה אחרת, כי זה מוכיח שיקול דעת ולא צירוף מקרים. ולבסוף, תיק חזק מסיים בסט של קומפוננטים/טוקנים שהגדרת, כי זה מראה שאתה חושב על מערכת ולא על מסך בודד.

• פתיחה שמגדירה תפקיד סוכן, גבולות סמכות, ורמות אוטונומיה

• תרשים מצבים ברור + תרחישי מעבר בין מצבים

• מסכי שקיפות שמראים מה/למה/אלטרנטיבה לפני ביצוע

• תרחישי קצה: חוסר מידע, התנגשות מטרות, חריגה, כשל חיבור

• מנגנוני תיקון: שינוי כלל, השהיה, חזרה אחורה, ואישור נקודתי

• דוגמאות ניסוח למצבי סיכון ואי־ודאות כחלק מהעיצוב

• מדדי הצלחה שהיית בודק בהשקה כדי להראות חשיבה מוצרית

• הצגת חלופות שנשקלו ולמה נפסלו כדי להוכיח שיקול דעת

• סט קומפוננטים/טוקנים שמראה מערכת עיצוב מלאה

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

כשסוכן AI מטפל בשירות לקוחות הוא נכנס לאזור שבו טעות אחת יכולה להפוך לשיחה ויראלית, ולכן הממשק חייב לנהל רגישות כמו מוצר “מוניטין”. הדבר הראשון הוא להבחין בין מענה לבין התחייבות, כי תשובה אפשר לשפר אבל התחייבות (החזר, זיכוי, שינוי תנאים) היא פעולה עם השלכות. הדבר השני הוא לתת לסוכן “מדיניות שירות” במבנה חי: מה מותר להציע, מתי חייבים להעביר לאדם, ומה דורש אישור מנהל. הדבר השלישי הוא לעצב תצוגת הקשר עשירה: היסטוריית לקוח, מצב הזמנה, תקלות קודמות, ושפה מועדפת, כדי שהסוכן לא יישמע תלוש. הדבר הרביעי הוא להציג למשתמש האנושי (נציג/ה) לא רק את הטקסט שהסוכן הציע, אלא גם את הסיבה והסיכון, כדי שאישור לא יהיה עיוור. הדבר החמישי הוא לעצב “מצבי רגש”: לקוח כועס, מבולבל, לחוץ, או אגרסיבי, כי טון המענה משתנה והסוכן צריך להתאים את עצמו בצורה עקבית. הדבר השישי הוא להגן מפני “הבטחות יתר” על ידי הצגת ניסוחים בטוחים כברירת מחדל והסברים קצרים למה ניסוח מסוים מסוכן. הדבר השביעי הוא לעצב מסלול הסלמה ברור: מתי עוברים לנציג, למנהל, למחלקה משפטית, או לתמיכה טכנית, בלי שהלקוח ירגיש שמסמסים אותו. הדבר השמיני הוא להציג התקדמות טיפול בפנייה כמו תהליך: “נאסף מידע”, “נבדק”, “הוצע פתרון”, “בוצע”, כי זה מוריד לחץ. הדבר התשיעי הוא להוסיף שכבת איכות שמסבירה אם המענה נשען על נתונים עדכניים או על הנחות, כדי למנוע תשובות “יפות” אך שגויות.

• מצבי פעולה ברורים: טיוטה, מענה מוצע, ממתין לאישור, נשלח, הועבר לאדם

• מדיניות שירות כמסך קצר: מה מותר להציע, מה אסור, ומה דורש אישור

• הצגת הקשר חובה לפני ניסוח: נתוני לקוח, מצב הזמנה, היסטוריה, חריגים

• סימון סיכון ניסוח: התחייבות, הבטחה, משפטיות, פרטיות, רגישות תרבותית

• כפתורי תגובה מהירים לנציג: “שפר טון”, “קצר”, “הוסף אמפתיה”, “הסר התחייבות”

• מסלול הסלמה מוצג מראש עם סיבות, לא רק “העברתי הלאה”

• תיעוד קצר: מה הוצע, מה אושר, ומה נשלח בפועל

• דוח איכות שבועי: איפה נדרש תיקון, ואיזה כללים כדאי להקשיח

סוכן שמנהל גיוס ו-HR: איך מעצבים החלטות רגישות בלי להכניס הטיות וסיכונים

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

• פירוק התהליך: סינון ראשוני → בדיקת התאמה → שאלות ראיון → החלטת המשך → הצעה

• קריטריונים גלויים עם אפשרות לעריכה: מה חשוב, מה ניטרלי, ומה אסור לשקלל

• פעולות רגישות עם אישור כפול: דחייה סופית, הצעת שכר, שינוי סטטוס

• הצעת שאלות ראיון שמקושרות לכישורים ולא לסגנון אישי

• מסלול חריגים: “לבדיקה נוספת” במקום “כן/לא” קשיח

• יומן החלטות שמסביר אילו פרטים השפיעו ואילו לא

• סימון חוסר מידע והצעה מה להשלים כדי להגיע להחלטה טובה יותר

• דוח תהליך: עקביות, זמן להבנה, נקודות התערבות, ושיעור תיקונים

סוכן שפועל במובייל וברקע: איך מעצבים מינימום תשומת לב עם מקסימום שליטה

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

• סט פעולות קבוע בהתראות: אשר, ערוך, השהה, פתח הקשר

• מדיניות “אם לא תגיב”: ממשיך בזהירות / עוצר / מחכה לאישור

• חלונות שקט ותזמון סיכומים כדי להוריד רעש לאורך היום

• סיכום יומי קצר: מה הושג, מה נחסך, ומה דורש תשומת לב

• נקודות סיכון כסריקה: התחייבות, שיתוף, מחיקה, חריגה מתקציב

• מסך מצב עליון שמראה מה רץ ברקע ומה ממתין לאדם

• טיפול בניתוק: הודעה קצרה, סטטוס המתנה, וניסיון חוזר נשלט

• אפשרות “הורד רמת אוטונומיה זמנית” כשמשתמש עסוק או לחוץ

העברת משימות בין סוכן לאדם בזמן אמת: איך מעצבים Handoff שלא מרגיש כמו נטישה

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

• סיבת העברה אחת ברורה במקום ניסוח מעורפל

• תקציר הקשר: מטרת המשימה, מצב נוכחי, פעולות שבוצעו, חסמים

• הצעת מסלולי המשך עם יתרון/חיסרון בקצרה

• סימון נקודות סיכון קרובות כדי למנוע המשך אוטומטי לא רצוי

• אפשרות “הפוך להנחיה קבועה” מתוך החלטה אנושית

• חלוקת אחריות אחרי העברה: מי מאשר, מי מקבל התראות, מי סוגר

• זמן טיפול משוער או מצב תור כדי למנוע תחושת תקיעות

• סיכום אחרי טיפול אנושי שמחבר מה השתנה למדיניות/כללים

ממשק לניהול מדיניות וכללים בארגון: איך מעצבים Governance בלי להפוך את המוצר למפלצת

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

• שכבות כללים: ארגון / צוות / משתמש, עם סדר עדיפויות ברור

• זיהוי התנגשות בין כללים והצעה לתיקון

• היסטוריית שינויים לכל כלל: מי, מתי, ולמה

• בדיקת השפעה לפני הפעלה כדי להבין תוצאות בפועל

• חריגה חד-פעמית מבוקרת עם נימוק ואישור, במקום שינוי גורף

• תפקידים והרשאות לניהול מדיניות כדי לשמור אחריות

• מדדים לכללים: עצירות, חריגות, ואישורים כדי לכייל מערכת

• ניסוח אחיד למדיניות שמופיע גם באישורים ובהתראות

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

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

• זמן להבנת מצב: כמה שניות עד שהמשתמש יודע מה קורה ולמה

• זמן עד עצירה בטוחה במצב לחץ, והאם העצירה מובנת

• איכות אישור: האם המשתמש מבין השלכות לפני אישור

• יכולת שינוי כלל מתוך אירוע, והאם זה מפחית טעויות בהמשך

• תרחישי מידע חסר/סותר כדי לבדוק עצירה ושאלות השלמה

• תרחישי תקלה חיצונית: חיבור נפל, נתון לא זמין, תור פעולות

• יכולת שחזור החלטה דרך יומן לאחר זמן, בלי עזרה של צוות

• שינוי רמת אוטונומיה לאורך הבדיקה כסמן אמון

• מיפוי התראות: מה מועיל, מה רעש, ומה צריך איחוד

איך משתמשים בתוכנות עיצוב כדי לתכנן Agentic UI בצורה מקצועית ולשפר תיק עבודות

בפרויקטים סוכניים, כלי עיצוב לא נועד רק “לעשות יפה”, אלא לעזור לך להציג התנהגות, מצבים, והחלטות בצורה משכנעת. Illustrator מתאים לבניית אייקונים עקביים למצבי מערכת, כך שברגע שהמשתמש רואה סמל הוא מבין מצב בלי לקרוא הרבה. Photoshop מתאים ליצירת הדמיות ריאליסטיות של דאשבורדים, התראות במובייל, וסיכומי פעילות, כדי שתיק עבודות ייראה אמיתי ולא רק מסכים שטוחים. InDesign מתאים לבניית Case Study ארוך וברור שמראה מודל מצבים, תרחישי קצה, ומדיניות, כי בתחום הזה “סיפור החשיבה” הוא חלק מרכזי מהיכולת שלך. After Effects מתאים להדגמת מיקרו-אינטראקציות כמו מעבר למצב “ברקע”, עצירה, או העברת שליטה, כי תנועה יכולה להסביר מצב מהר יותר מטקסט. Acrobat יכול לשמש להצגת מסמכים אינטראקטיביים עם הערות, שדות, ותצוגות מוקדמות, במיוחד כשפרויקט מערב תהליכים ארגוניים. Firefly יכול לעזור ביצירת נכסים ויזואליים נקיים לדוגמאות מסך ולתרחישים, כל עוד שומרים על עקביות סגנונית ולא הופכים את הפרויקט לקרנבל גרפי. חשוב להשתמש בכלים כדי להראות סטייטים: אותה קומפוננטה במצבים שונים, כי זה מה שמוכיח שאתה חושב מערכתית. בנוסף, בתיק עבודות כדאי להציג גם ספריית ניסוחים קצרה למצבים קריטיים, כי כתיבה היא חלק מהעיצוב הסוכני. ולבסוף, כדאי להוסיף מסמך בדיקות: תרחישים, מטרות מדידה, ומה למדת, כדי להיראות כמו מעצב שמבין מוצר ולא רק מסך.

• Illustrator: סט אייקונים למצבים וסיכון, עקבי ומובחן גם בלי צבע

• Photoshop: הדמיות מציאותיות של דוחות, התראות, ומסכים מורכבים

• InDesign: Case Study מסודר שמציג תהליך, החלטות, ותרחישי קצה

• After Effects: הדגמת מעבר שליטה, עצירה, וריצה ברקע במינימום תנועה

• Acrobat: מסמכי תהליך, טפסים, ותצוגות מוקדמות להקשר ארגוני

• Firefly: יצירת נכסים ויזואליים נקיים לתרחישים ולמסכי דוגמה

• סטייטים: הצגת אותו רכיב בכמה מצבים כדי להוכיח מערכתיות

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

• מסמך בדיקות קצר: מה בדקת, מה מדדת, ומה שינית בעקבות זה

מבנה כרטיס “החלטה” בממשק סוכני: איך הופכים פעולה אוטונומית לדבר שאפשר להבין בשתי שניות

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

• שורת פעולה: “מבצע ___” / “מציע ___” / “נעצר כי ___”

• סטטוס קצר ובולט עם ניסוח אחיד בכל המוצר

• סיבה בשורה אחת: “כי ___” או “על סמך ___”

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

• ראיות קצרות: שתי נקודות מקסימום שמראות בסיס

• פעולה מרכזית אחת: אישור / שינוי / עצירה, ועוד פעולה משנית

• פתיחה לפרטים: תכנית, חלופות, וכללים פעילים

• שורה אחרונה: “השלב הבא” כדי לסגור אי־ודאות

מבנה מסך “סיכון” לפני פעולה: איך מעצבים אישור שמונע טעויות ולא מעייף את המשתמש

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

• כותרת פעולה מדויקת: “שליחה ל___”, “התחייבות ל___”, “מחיקה של___”

• שורת השלכה גדולה וברורה: מי/מה מושפע ומה גודל ההשפעה

• סיבת סיכון קצרה: פרטיות, כסף, בלתי הפיך, שינוי מערכת

• הפיכות: “אפשר לבטל עד ___” מול “אי אפשר לשחזר”

• חלופה בטוחה: טיוטה, סימולציה, בקשת אישור נוסף

• כללים פעילים: למה זה מותר כרגע ואיך לשנות את זה להבא

• כפתורי פעולה: “אשר” מול “עצור” מול “ערוך” בצורה מאוזנת

• מדיניות אי־תגובה: ממשיך בזהירות / עוצר / ממתין

• שפה עקבית כדי להפוך זיהוי לסוג של אינסטינקט

מבנה מסך “דוח שבועי” שמחזק אמון: איך מסכמים עבודה אוטונומית בלי להציף נתונים

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

• פתיחת ערך: תוצאה, חיסכון, ומניעת נזק בשורה אחת

• שלושה הישגים מרכזיים בלבד עם ניסוח תפעולי

• חריגות: מה קרה + מה השתנה כדי למנוע חזרה

• חלוקה: מה בוצע לבד מול מה דרש אישור

• כללים פעילים: הכי שימושיים + הכי חוסמים, עם אפשרות התאמה

• הצעת שיפור אחת לשבוע הבא במקום רשימת מטלות

• אפשרות העמקה ביומן למי שרוצה, בלי להעמיס בדוח עצמו

• סיום עם כפתורי שליטה: כללים, אוטונומיה, מטרות

מבנה מסך “סימולציה” לפני הפעלה: איך מציגים תכנית, טריגרים, ונקודות עצירה בצורה שאפשר לסמוך עליה

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

• מטרה + תוצאה צפויה בראש המסך, בפשטות

• תכנית בשלבים עם זמן משוער וסטטוס יציבות לכל שלב

• טריגרים: מתקדם לבד / ממתין לאישור / נעצר בחריגה

• נקודות אישור מסומנות מראש כדי למנוע הפתעות

• נתונים: מקור, זמן עדכון, והאם חסר משהו

• חריגות צפויות: איפה יש אי־ודאות או סיכון

• עריכת כללים בתוך המסך + שינוי מיידי בתכנית

• תרחישי “מה אם” קצרים לבדיקת יציבות

• מעבר לביצוע עם סיכום קצר ומהיר של “מה יקרה עכשיו”

ניסוחים בעברית למסכים קריטיים במערכת סוכנית: שפה שמייצרת שליטה ולא “קסם”

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

• מילון סטטוסים קבוע: “ממתין לאישור”, “מבצע”, “נעצר”, “הושלם”, “נכשל”, “ברקע”

• ניסוח פעולה: “מכין ”, “מציע ”, “ממתין ל”, “עוצר כי”

• ניסוח השלכות: “זה ישפיע על ___”, “זה בלתי הפיך”, “אפשר לבטל עד ___”

• ניסוח אי־ודאות: “חסר לי ___ כדי להיות בטוח”, “יש שתי אפשרויות טובות”

• ניסוח שליטה: “אשר”, “ערוך”, “השהה”, “קח שליטה”, “צפה בפרטים”

• סיומת קבועה: “מה תרצה שאעשה עכשיו?” כדי לסגור לולאה

איך להפוך את זה לקיט לימודי ולחומר לקורס: תרגילים, משימות ותוצרים שמפתחים מעצב Agentic

כדי ללמד עיצוב סוכני בצורה מעשית, צריך תרגילים שמכריחים לחשוב על מצבים, סיכון, ושקיפות, ולא רק על UI נקי. תרגיל ראשון הוא לבחור בעיה אחת ולנסח תפקיד סוכן ברור בשלושה משפטים, כולל גבולות וסמכות. תרגיל שני הוא לבנות מודל מצבים עם מעברים, כדי להבין איפה דרוש אישור ואיפה אפשר אוטומציה. תרגיל שלישי הוא לעצב כרטיס החלטה ומסך סיכון לאותה פעולה, כדי לתרגל “מה/למה/השלכה/שליטה”. תרגיל רביעי הוא לכתוב ספריית ניסוחים בעברית למצבי מערכת, כדי להראות שהשפה היא חלק מהעיצוב. תרגיל חמישי הוא לבנות סימולציה עם עריכת כללים ולבדוק איך תכנית משתנה, כדי לתרגל שליטה. תרגיל שישי הוא לכתוב תרחיש כשל ולתכנן מסך כשל שמחזיר אמון, כי זה מקום שמבדיל בין מתחיל למקצוען. תרגיל שביעי הוא למדוד: להגדיר שלושה מדדים לבדיקות שימושיות ולנסח איך היית בודק אותם. תרגיל שמיני הוא להכין Case Study קצר שמראה תהליך, החלטות, וחלופות שנפסלו, כדי לתרגל הצגת חשיבה. תרגיל תשיעי הוא להרחיב לתבנית Design System קטנה עם סטייטים וטוקנים, כי סוכנים הם מערכת ולא מסך.

• ניסוח תפקיד סוכן: מטרה, גבולות סמכות, ורמת אוטונומיה

• מודל מצבים עם מעברים ונקודות אישור

• עיצוב כרטיס החלטה + מסך סיכון לאותה פעולה

• ספריית ניסוחים בעברית למצבים קריטיים ב-RTL

• מסך סימולציה עם עריכת כללים והשפעת שינוי

• תרחיש כשל + מסך כשל שמחזיר שליטה

• שלושה מדדי בדיקה: הבנת מצב, איכות אישור, שינוי כללים

• Case Study קצר עם חלופות שנפסלו ולמה

• מיני Design System: סטייטים, קומפוננטים, וטוקנים

ניהול מטרות מרובות ועדיפויות כדי שהסוכן לא “יסתבך” בין כוונות סותרות

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

• כרטיסי מטרות עם משקל מוגדר וברור בשפה פשוטה

• עדיפויות מותנות: “כש___ אז תעדיף ___”

• מסך קונפליקט שמציג שתי חלופות + מחיר לכל חלופה

• תצוגת “מה איבדנו” כדי להבין השלכות ולא רק יתרונות

• נקודת שליטה מרכזית: מטרות, משקלים, וחוקים גלובליים

• נעילה למטרות קריטיות שלא ניתנות לעקיפה בלי אישור

• היסטוריה קצרה של שינויי עדיפות כדי להבין למה התנהגות השתנתה

ממשק להגדרת כוונה בצורה מדויקת בלי להפוך את המשתמש לכותב מפרטים

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

• משפט יעד קצר בראש: תוצאה רצויה במשפט אחד

• שאלות השלמה מדורגות לפי צורך, לא טופס אחד גדול

• הבחנה ברורה בין שדות חובה לשדות רשות

• תבניות כוונה מוכנות עם אפשרות התאמה מהירה

• תצוגה חיה: איך הכוונה הופכת לתכנית בשלבים

• המרת מושגים מעורפלים לקריטריון אחד מדיד

• דוגמאות ניסוח “טוב/מסוכן” כדי ללמד בלי עומס

• שינוי כוונה באמצע תהליך בלי להתחיל מאפס

תכנון לטווח ארוך והצגת תכנית חיה כדי שהסוכן לא ייראה כמו “קסם רגעי”

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

• שני אופקים: “היום” ברור + “בהמשך” משוער ומסומן ככזה

• נקודות דיווח קבועות שמחליפות צורך במעקב ידני

• חסימות ותלויות מינימליות שמדגישות מה באמת עוצר

• סיכום תכנון מחדש: מה השתנה ולמה, בשפה קצרה

• רמת יציבות לכל שלב: סגור / משוער / תלוי באחרים

• תצוגת משאבים לשלב: זמן, תקציב, סיכון, ושיתוף

• הערות וכללים מקומיים לשלב ספציפי בתוך התכנית

• חזרה אחורה נקודתית בלי לאפס תהליך

סוכן שמנהל ידע ומסמכים בארגון בלי ליצור בלגן של “זיכרון” ושימוש בנתונים לא נכונים

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

• תעודת זהות לכל מקור: עדכון, בעלות, רגישות, ואמינות

• הבחנה בין מקור אמת להשראה כדי למנוע ערבוב סמכות

• שליפה קצרה לאימות: משפטים/מספרים/דרישות שנשלפו בפועל

• הצגת קונפליקט בין מקורות כבחירה בין חלופות

• סימון מקור כמועדף/לא תקף/רגיש כדי לכוונן התנהגות

• כללי שימוש במקורות: גיל מסמך, דרישת מקור מאושר, ועוד

• הפרדה ברורה בסיכומים: עובדות מול פרשנות

• תיקון מהיר מתוך הסיכום שמייצר שינוי כלל או החלפת מקור

• ניקוי זיכרון שמסביר מה נשאר ומה נעלם

Voice ו־Hands-Free בסוכנים: איך מעצבים שליטה כשאין מסך ואין סבלנות לקרוא

בממשק קולי, משתמשים לא רואים לוגים ותכניות, ולכן השליטה חייבת להופיע כשפה קצרה וקצב נכון. הדבר הראשון הוא להציג “מצב” במשפט אחד בכל רגע: מה אני עושה עכשיו, ומה אני צריך ממך, כדי למנוע בלבול. הדבר השני הוא לצמצם אפשרויות: במקום להקריא חמש חלופות, מציגים שתיים ואז שואלים אם להמשיך, כי קול מתיש מהר. הדבר השלישי הוא להגדיר פקודות שליטה קבועות שקל לזכור, כמו “עצור”, “השהה”, “חזור אחורה”, “שנה יעד”, כדי ליצור ביטחון. במצבי סיכון, קול חייב לדרוש אישור ברור עם חזרה על ההשלכה, אחרת המשתמש יגיד “כן” בלי להבין. חשוב לתת חיווי על פעולות ברקע, למשל “אני ממשיך לבד ואעדכן בעוד 10 דקות”, כדי שהמשתמש לא ירגיש שהכול נעלם. כדאי להוסיף “סיכום קצר” אחרי פעולה משמעותית, כדי לסגור לולאה ולהחזיר תחושת שליטה. בממשק קולי צריך לעצב גם תרחיש של אי־הבנה: איך הסוכן מבקש חידוד בלי להאשים את המשתמש ובלי לחזור על אותו משפט שוב ושוב. כשיש מעבר למסך (אם קיים), צריך להציע אותו כרגע “עשיר”, למשל “שלחתי למסך את התכנית”, כדי לא להעמיס בקול. ולבסוף, מומלץ להגדיר טון מקצועי ולא חברותי מדי, כי קול “מתנצל” או “מתלהב” יכול לפגוע באמון כשמדובר בהחלטות אמיתיות.

• משפט מצב קבוע: מה קורה עכשיו ומה נדרש מהמשתמש

• שתי חלופות ואז “רוצה עוד?” כדי למנוע עומס שמיעתי

• פקודות שליטה קצרות וקבועות שקל לזכור ולהגיד

• אישור קולי לפעולות מסוכנות עם חזרה על ההשלכה

• עדכונים ברקע עם זמן משוער לדיווח הבא

• סיכום קצר אחרי פעולות משמעותיות כדי לסגור לולאה

• מנגנון חידוד שלא מתיש: שאלה אחת ממוקדת בכל פעם

• מעבר לקונטקסט עשיר במסך כשצריך, במקום להקריא הכול

מניעת הזיות והסקת יתר דרך UI: איך גורמים לסוכן “להיצמד” לעובדות בלי להפוך את הממשק למשפטי וקר

במערכת סוכנית, הבעיה המסוכנת היא לא רק טעות, אלא ביטחון־יתר שנראה משכנע, ולכן הממשק צריך להבחין בין ידוע, משוער, וחסר. הדרך הטובה היא להכריח את הסוכן להציג “עוגנים” קצרים: מה אני יודע בוודאות, מאיפה, ומה אני מניח, כדי שהמשתמש יוכל לאמת מהר. חשוב לעצב שכבת “ראיות” שלא מציפה, עם שתי נקודות תומכות בלבד כברירת מחדל, ועמקה למי שרוצה. צריך להציג סתירות וחוסר מידע בצורה פרואקטיבית, כי הסתרת אי־ודאות מייצרת אמון מזויף שמתרסק. בממשק של החלטות, הסוכן לא אמור להציג תוצאה אחת כוודאית אם קיימות חלופות, ולכן כדאי לחייב הצגת חלופה כשיש פער משמעותי. כאשר הסוכן מסכם מידע, צריך להציג סימון ברור למשפטים שמבוססים על מקור מול משפטים שהם מסקנה, כדי למנוע ערבוב. כדאי להוסיף פעולה מהירה למשתמש: “זה לא נכון” או “חסר מקור”, כדי להפוך תיקון לקצר ולא לדיון. במערכות עם ביצוע אוטונומי, מומלץ להגדיר כלל: אם אין מקור מספק לפעולה מסוכנת—עוצרים ומבקשים אישור או מידע, במקום להמשיך. חשוב גם להציג “מה צריך כדי להיות בטוח” כשאין מספיק נתונים, כי זה נותן למשתמש דרך לעזור. ולבסוף, צריך להיזהר לא להפוך הכול לאזהרות, כי אז המשתמש מתרגל ומתעלם; האזהרה חייבת להופיע רק כשיש השפעה אמיתית על החלטה.

• סימון ידע: ודאי / משוער / חסר, עקבי בכל המסכים

• שתי ראיות קצרות כברירת מחדל + אפשרות העמקה

• הצגת חוסר מידע וסתירות לפני החלטה, לא אחרי

• הצגת חלופה כשיש פער משמעותי, כדי למנוע “אמת אחת” מזויפת

• הפרדה בולטת בסיכומים: עובדה מול מסקנה

• פעולה מהירה לתיקון: “לא נכון”, “חסר מקור”, “עדכן כלל”

• כלל עצירה לפעולות מסוכנות כשאין בסיס מספיק

• ניסוח “מה חסר” כדי להפוך אי־ודאות לבקשה מעשית

• מינון אזהרות לפי השפעה כדי למנוע התרגלות

תכנון חוויית ניטור אחרי השקה: איך מזהים שהסוכן מתחיל “לסטות” לפני שמשתמשים מאבדים אמון

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

• דגלי אמון: עצירות, ביטולים אחרי ביצוע, אישורים מהירים מדי

• מדד אישי עדין למשתמש: התערבויות ושינויי כללים לאורך זמן

• זיהוי תהליכים חוזרים עם תוצאה גרועה כדי לתקן שורש בעיה

• מצב שמרני להפעלה מהירה בעת חריגות כדי לצמצם סיכון

• מדיניות איחוד התראות + סיכומים כדי למנוע שחיקה

• הורדת אוטונומיה כשאיכות נתונים יורדת, עם הסבר קצר

• משוב קצר אחרי החלטות גדולות כדי למדוד אמון בזמן אמת

• יומן שחזור מובנה לחקירה בלי ניחושים

• מסך “מה השתנה” אחרי תיקון כדי לשקם אמון

כרטיס “כוונה” שמגדיר תוצאה, גבולות והקשר בלי להפוך למסמך אפיון

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

• שורת יעד: “המטרה: ___”

• גבולות: זמן מקסימלי, תקציב, ערוצים מותר/אסור

• רמת אוטונומיה: ידני / חצי־אוטומטי / אוטומטי

• כלל שלילי קצר: “אל ת___”

• הקשר: חשבון/צוות/פרויקט/לקוח רלוונטי

• “חסר לי”: פריט אחד-שניים להשלמה כדי להתחיל

• תבניות כוונה מוכנות: לבחור ולהתאים

• פעולות מהירות: עריכה, השהיה, שינוי גבולות

כרטיס “מטרה” שמייצג עדיפות, מדד הצלחה ותנאים מיוחדים

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

• שם מטרה תוצאתי: “להקטין טעויות”, “להאיץ טיפול”, “לשפר איכות”

• עדיפות בשפה אנושית: חשוב מאוד / חשוב / נחמד

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

• תנאי מיוחד: “כש___ אז ___”

• משאבים קשורים: תקציב/זמן/סיכון

• הקרבה מוכנה: זמן↔כסף, מהירות↔דיוק, אוטומציה↔בקרה

• נעילה למטרה קריטית

• שינוי מהיר בעדיפות מתוך הכרטיס עצמו

כרטיס “קונפליקט” שמציג שתי חלופות, מחיר לכל חלופה, והמלצה בלי לכפות

כרטיס קונפליקט נועד לרגע שבו הסוכן לא יכול לשרת שתי מטרות יחד בלי מחיר, ולכן הממשק חייב להפוך את המחיר למובן. הדבר הראשון הוא להסביר את הקונפליקט במשפט אחד פשוט: “אי אפשר גם ___ וגם ___ כרגע”. הדבר השני הוא להציג שתי חלופות בלבד כברירת מחדל, כדי לא להעמיס על החלטה. הדבר השלישי הוא להציג לכל חלופה את היתרון המרכזי ואת המחיר המרכזי, כדי שהמשתמש יבין במה הוא מוותר. הדבר הרביעי הוא להציג את ההשפעה על זמן, כסף, וסיכון בצורה קצרה, כי אלה שלושת הצירים שמניעים החלטות. הדבר החמישי הוא להציג המלצה של הסוכן עם הסבר קצר, אבל לא להציג אותה כפקודה או כאמת, כדי לשמור סמכות משתמש. הדבר השישי הוא לאפשר “פתרון שלישי” לפעמים, כמו לדחות או להקטין היקף, אבל רק אם זה באמת שימושי ולא עוד רעש. הדבר השביעי הוא לאפשר להפוך בחירה לכלל: “כשתהיה התנגשות כזו—בחר תמיד בחלופה א’”, כדי לחסוך החלטות חוזרות. הדבר השמיני הוא לשמור עקביות חזותית כך שכרטיס קונפליקט יזוהה מיד כרגע החלטה. הדבר התשיעי הוא לסיים עם פעולה ברורה: בחירה אחת, ולא ארבעה כפתורים שווים.

• ניסוח קונפליקט קצר: “לא ניתן גם ___ וגם ___”

• שתי חלופות ברורות עם כותרת קצרה לכל אחת

• יתרון מרכזי + מחיר מרכזי לכל חלופה

• השפעה קצרה על זמן/כסף/סיכון

• המלצת סוכן עם הסבר קצר ולא כופה

• אופציה לדחייה/הקטנה אם רלוונטי

• “הפוך לכלל” כדי למנוע חזרה על אותה החלטה

• כפתור בחירה ברור לכל חלופה

כרטיס “מקור” שמציג אמינות, עדכון, ורגישות כדי למנוע החלטות על בסיס מידע ישן

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

• שם מקור + תאריך עדכון בולטים

• אחראי מקור/בעלות פנימית

• סטטוס מקור: מאושר / ישן / חסר הרשאה / רגיש

• “מה נשלף”: משפטים/מספרים/דרישות שנלקחו ממנו

• רלוונטיות: ראשי / תומך

• פעולות: העדף, חסום, דרוש אישור לפני שימוש

• הצגת סתירות מול מקורות אחרים במידת הצורך

• רגישות שיתוף: פנימי בלבד / מותר לשיתוף / דורש אישור

כרטיס “חריגה” שמזהה יציאה מגבולות ומציע תיקון במקום להאשים

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

• סוג חריגה ברור: תקציב/זמן/מדיניות/הרשאה/יעד

• סיבה קצרה: מה השתנה שיצר חריגה

• תיקון מומלץ + חלופה אחת

• מדיניות אי־תגובה: עצירה / המשך זהיר

• סימון חד־פעמי מול חוזר כדי להציע שינוי כלל

• “הפוך לכלל” כדי למנוע חזרה על אותה חריגה

• טון לא מאשים: “זיהיתי חריגה” ולא “טעית”

• תיעוד ביומן: חריגה, החלטה, ותוצאה

גרסאות RTL בעברית: איך מנסחים ומעצבים קומפוננטים כך שירגישו טבעיים ולא מתורגמים

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

• סדר קבוע בכרטיסים: פעולה → סטטוס → סיבה → השלכה → שליטה

• פעלים בתחילת משפט כדי להבהיר פעולה מהר

• כפתורים קצרים: אשר, ערוך, עצור, השהה, צפה

• שורה אחת ואז העמקה במקום פסקאות ארוכות

• כותרות קצרות בטבלאות + יישור מספרים עקבי

• טיפול במונחים אנגליים כדי למנוע קפיצות כיוון

• סימון סיכון עם אייקון + טקסט, לא צבע בלבד

• מרווחים נדיבים להפחתת עומס ויזואלי

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

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

• סטטוסים קבועים: “ברקע”, “מבצע”, “ממתין לאישור”, “נעצר”, “הושלם”, “נכשל”

• החלטה על גוף דיבור: גוף ראשון או ניטרלי, בלי ערבוב

• תבנית מסר: מה קורה + למה + מה עכשיו

• חריגה: “זיהיתי חריגה ב___” + תיקון מומלץ

• הצלחה: “הושלם: ___” + תוצאה קצרה

• כשל: “נכשל בגלל ___” + פעולה מומלצת

• יומן: “בוצע ___” + הקשר + תוצאה

• תבניות משתנים כדי לשמור עקביות בלי לייצר טקסט משוכפל

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

מפת סטייטים היא עמוד השדרה של Agentic Design, כי היא הופכת “סוכן שחושב” למערכת צפויה שאפשר לבדוק, ללמד, ולתקן. הדבר הראשון הוא להבין שמצבים הם לא רק “מבצע/הושלם”, אלא רצף של מצבי ביניים שבלעדיהם המשתמש מרגיש שהכול קופץ או נעלם. הדבר השני הוא להגדיר מצבים לפי חוויה למשתמש, לא לפי ארכיטקטורה, כדי שהשפה תהיה אנושית ושימושית. הדבר השלישי הוא להפריד בין מצב משימה לבין מצב מערכת, כי משימה יכולה להיות “ממתינה” גם כשהמערכת עצמה תקינה. הדבר הרביעי הוא להגדיר טריגרים למעבר מצב: מה גורם לשינוי, ומה צריך להופיע בממשק בכל מעבר, כדי למנוע שינוי שקט שמבלבל. הדבר החמישי הוא להגדיר לכל מצב מה המשתמש יכול לעשות עכשיו, כי מצב בלי אפשרויות שליטה מייצר חרדה. הדבר השישי הוא להגדיר מה נשמר ביומן בכל מעבר, כדי שאפשר יהיה לשחזר בדיעבד. הדבר השביעי הוא להגדיר גם מצבי נדירים מראש, כמו “חלקית בוצע”, “התנגשויות”, “השהיה זמנית”, כדי לא לגלות אותם בשטח. הדבר השמיני הוא להגדיר סטייט של “בטיחות” או “שמירה” שבו הסוכן נהיה שמרני בעת חשד או ירידת אמינות נתונים. הדבר התשיעי הוא להגדיר סטייט של “סגירה” שבו המשימה מסוכמת ומביאה המלצה לשינוי כללים או מטרות, כי זה מחזק למידה ואמון.

• מפת סטייטים לפי חוויה: מה המשתמש מרגיש ורואה

• הפרדה בין מצב משימה לבין מצב מערכת

• טריגרים למעבר מצב + תצוגה עקבית לכל מעבר

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

• תיעוד מעבר ביומן לשחזור עתידי

• כיסוי מצבי נדיר מראש כדי לא לאלתר באש

• מצב שמרני/בטיחות בעת חשד או ירידת איכות נתונים

• מצב סגירה עם סיכום והמלצה להמשך

סטייטים של משימה: המצבים שכל תהליך סוכני כמעט תמיד עובר

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

• נוצרה משימה: יעד, גבולות, הקשר, ומה חסר

• איסוף מידע: מקורות, הרשאות, ותצוגת מה נאסף

• תכנון: שלבים, טריגרים, ונקודות אישור

• הצעת החלטה: חלופות קצרות + המלצה לא כופה

• ממתין לאישור: השלכה + מדיניות אי־תגובה

• מבצע: התקדמות, תור פעולות, ומה כבר נעשה

• ברקע: נקודת דיווח הבאה + אפשרות עצירה מהירה

• השהיה: מה נעצר ומה נשמר + חזרה קלה

• חלקית בוצע: מה בוצע, מה לא, ומה אפשר לתקן

• הושלם: סיכום, תוצאה, והמלצה לשיפור

סטייטים של מערכת: מצבים שמסבירים אמון, זמינות ובטיחות

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

• תקין: כמעט לא נראה, רק חיווי מינימלי

• איכות נתונים ירדה: מקור לא עדכני/חסר + השפעה

• חסרות הרשאות: מה חסר + איך מתקנים

• סיכון מוגבר: זיהוי דפוס חשוד + ירידה באוטונומיה

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

• עומס/תור: הסבר המתנה + סדר עדיפות

• תחזוקה/שיבוש: שקיפות מה לא עובד ומה חלופות

• שחזור: “מחזיר יציבות” + צפי חזרה

• שינוי מדיניות: מה השתנה ולמה זה משפיע עליך

• חסימה: אסור לבצע + מסלול אישור/חריגה

סטייטים נדירים אבל קריטיים: איפה מוצרים נופלים בלי עיצוב מראש

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

• ביצוע כפול: זיהוי כפילות + מניעת פעולה חוזרת

• אישור פג תוקף: בקשת אישור מחדש עם הסבר למה

• תוצאה נחותה: תיקון/ביטול + הפקת כלל למניעה

• התנגשות מדיניות: סדר עדיפות ברור בין כללים

• העברה נכשלה: fallback מובנה + הודעה קצרה

• חלקיות לא עקבית: “מה בוצע/מה לא” + כפתורי השלמה

• שינוי יעד באמצע: מה נשמר ומה מתבטל + תכנון מחדש

• מקור הוחלף: למה הוחלף ומה ההשפעה

• שקט מסוכן: תזכורת מצב יזומה + סיבה

• הקפאה אוטומטית: הסבר הגנה + מסלול לפתיחה

לכל סטייט יש “ערכת UI” קבועה: רכיבים שחייבים להופיע כדי לשמור עקביות

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

• סטטוס מילולי קבוע

• “מה קורה עכשיו” במשפט אחד

• “למה” קצר לפי צורך

• “מה עכשיו” פעולה מרכזית אחת

• חיווי השלכה במצבים רלוונטיים בלבד

• אפשרות העמקה ביומן/פרטים בלי להעמיס

• בלם: עצור/השהה במצבי ביצוע

• הקשר: חשבון/פרויקט/יעד פעיל

• חיווי מצב שמרני כשפעיל

תבניות UI לכל סטייט: ניסוחים בעברית שאפשר ממש להדביק בפרוטוטייפ

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

• איסוף מידע: “אוסף מידע מ___ כדי ___”

• ממתין לאישור: “ממתין לאישור לפני ___ (זה ישפיע על ___)”

• ברקע: “ממשיך ברקע ואעדכן ב___”

• השהיה: “השהיתי את התהליך. לא בוצעו פעולות נוספות.”

• חלקית בוצע: “בוצע ___, נותר ___.”

• אישור פג תוקף: “האישור פג תוקף כי התנאים השתנו: ___.”

• מקור הוחלף: “החלפתי מקור כי ___, זה עשוי לשנות ___.”

• הקפאה אוטומטית: “הקפאתי פעולה כי זוהה סיכון: ___.”

• שינוי תכנית: “עדכנתי תכנית: ___ → ___. ההשפעה: ___.”

איך להציג את מפת הסטייטים בתיק עבודות בצורה שמרשימה מעסיקים בלי להעמיס

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

• סיפור קצר של בעיה+סיכון לפני תרשים

• מפת סטייטים מינימלית + הרחבה למצבי קצה נבחרים

• שלושה מצבי קצה עם מסכים מפורטים שמראים מקצוענות

• הצגת נקודות שליטה בכל מצב: עצירה, אישור, שינוי כלל

• דוגמת יומן החלטות שמחובר למפת המצבים

• “לפני/אחרי” של ניסוח כדי להראות חשיבות עקביות

• מדדים: זמן להבנת מצב, שיעור אישורים עיוורים

• סט קומפוננטים שחוזר בכל מצב כדי להוכיח מערכתיות

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

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

• סט טוקנים למצבים: תקין, דורש אישור, חריגה, כשל, הצלחה, ברקע, שמרני

• מינימום צבעים שמייצגים סטטוסים ולא קישוטים

• טיפוגרפיה שמבליטה מספרים, תאריכים, וספים

• טוקנים של מרווחים כדי להבטיח “נשימה” במצבים קריטיים

• רמות הדגשה: רגיל / מודגש / קריטי, עם חוקים ברורים

• סט אייקונים למצבי מערכת, עקבי בכל מקום

• טוקן “מצב שמרני” שמוסיף שכבת סימון קבועה

• חיבור טוקנים לכל קומפוננט כדי למנוע סטיות לאורך זמן

מערכת צבע למצב ולא לעיצוב: איך בונים צבעוניות שמונעת טעויות

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

• ניטרלי לרקע ולרוב הרכיבים

• צבע אחד ל”דורש אישור”

• צבע אחד ל”חריגה/סיכון”

• צבע אחד ל”כשל”

• סימון מינימלי ל”הצלחה”

• סגנון עדין ל”ברקע”

• במצב שמרני: תגית/פס קבוע, לא צביעה מלאה

• גיבוי תמידי לצבע: טקסט + אייקון + מבנה

טיפוגרפיה שמגינה על המשתמש: איך מגדירים היררכיה שתומכת בהחלטות מהירות

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

• כותרת פעולה ברורה בכל כרטיס/מסך

• שורת סטטוס קבועה מיד אחריה

• השלכה מוצגת במספרים גדולים וקריאים

• סגנון אחיד למספרים ותאריכים בכל המערכת

• “למה” קטן יותר אך קריא, כדי להשלים ולא להכביד

• שורות קצרות ב-RTL כדי לשמור על קריאות

• הדגשת מילים בודדות באזהרות במקום צביעת הכול

• אחידות בפיסוק ושילוב אנגלית/מספרים

• ריווח נדיב למניעת עומס ואישורים עיוורים

אייקונים ומטאפורות ויזואליות לסוכנים: איך מעצבים שפה שמסבירה מצב בלי טקסט ארוך

במערכת סוכנית, אייקון טוב חוסך משפטים, אבל אייקון לא ברור יוצר בלבול חמור, ולכן צריך שפה פשוטה ועקבית. כדאי להגדיר אייקון אחד לכל סטטוס מרכזי, ולשמור אותו בכל מקום: כרטיסים, התראות, יומן, ומסכי דוח. חשוב לא להשתמש באייקונים דומים מדי למצבים שונים, כי המשתמש לא יבדיל במבט מהיר. במובייל, אייקון צריך להיות קריא גם בקטן, ולכן עדיף צורות פשוטות ולא קווים דקים. בנוסף, כדאי להפריד בין אייקון של סטטוס לבין אייקון של סוג פעולה, אחרת הכול מתערבב. לדוגמה, סטטוס “ממתין לאישור” צריך סמל קבוע, ואילו פעולה “שליחה” או “רכישה” יקבלו אייקון נפרד. במצב שמרני, אפשר להוסיף אייקון שכבת־על קטנה (Badge) שמסמנת “יותר זהירות” בלי לשנות את כל הוויזואל. חשוב גם שהאייקונים יתאימו לתרבות המקומית: סימנים כמו “אגודל” יכולים להיתפס אחרת, ולכן במוצר רציני עדיף אייקונים ניטרליים. כדאי להחליט מראש על שפה של התקדמות: נקודות/פסים/ספינר, ולחבר אותה למצב “תור” ו“ברקע”. ולבסוף, צריך לבדוק אייקונים בבדיקות שימושיות, כי מה שנראה ברור למעצב לא תמיד ברור למשתמש.

• אייקון קבוע לכל סטטוס מרכזי בכל המוצר

• הבחנה חזקה בין אייקון סטטוס לאייקון פעולה

• צורות פשוטות לקריאות במובייל

• הימנעות מאייקונים דומים למצבים שונים

• Badge למצב שמרני במקום שינוי עיצוב גורף

• אייקונים ניטרליים תרבותית במוצר רציני

• שפת התקדמות עקבית שמתחברת לתור/ברקע

• בדיקות הבנה לאייקונים כחלק מהתהליך

דפוסי Layout שמונעים עומס: איך בונים גריד לכרטיסים, דוחות ומסכי החלטה

ממשק סוכני נוטה להתמלא בטקסט, ולכן Layout נכון הוא קריטי יותר מבכל מוצר אחר. כדאי לבחור גריד פשוט ועקבי, עם אזור קבוע לכותרת פעולה וסטטוס, אזור להשלכה, ואז אזור לשליטה. כאשר המשתמש גולל, חשוב שהדברים הקריטיים יישארו בחלק העליון, כי רוב ההחלטות מתקבלות מהר. כדאי להגדיר רוחב טקסט מוגבל, כי טקסט RTL ארוך ברוחב מלא קשה לקריאה. במסכי דוח, עדיף “כרטיסי סיכום” בראש ואז פירוט בהמשך, כדי שמי שאין לו זמן יקבל ערך מיידי. במסכי סימולציה ותכנית, כדאי להשתמש בבלוקים ברורים לכל שלב, עם סטטוס קטן לכל שלב, כדי להפוך רצף למשהו סריק. חשוב לשמור מקום קבוע לפעולת עצירה/השהיה, כדי שהמשתמש לא יחפש אותו כשהוא לחוץ. בנוסף, כשמופיעים פרטים טכניים או ראיות, עדיף להסתיר אותם מאחורי פתיחה, כדי לא להעמיס על כולם. במובייל, כדאי להשתמש בקיפול תוכן חכם, כי אין מקום להציף, והמשתמש בדרך כלל רוצה “מה עכשיו” קודם. ולבסוף, Layout צריך לשרת עקביות: אם כל מסך נראה אחרת, המוצר מרגיש לא יציב.

• אזורים קבועים בכרטיס: פעולה+סטטוס / השלכה / שליטה

• חוקים לגובה כרטיסים כדי לשמור סריקה מהירה

• רוחב טקסט מוגבל לקריאות RTL

• בדוחות: סיכום בראש + פירוט בהמשך

• בתכנית/סימולציה: בלוקים לפי שלבים עם סטטוס לכל שלב

• מקום קבוע לעצירה/השהיה בכל מסך רלוונטי

• ראיות ופרטים טכניים בקיפול כדי לא להציף

• התאמות מובייל: “מה עכשיו” לפני “למה” למי שממהר

• עקביות Layout כדי לשדר יציבות

איך לכתוב את זה כ-Design System קטן: קומפוננטים, סטייטים וחוקים שאפשר ללמד ולהטמיע

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

• רשימת קומפוננטים חובה למערכת סוכנית

• סטייטים מוגדרים לכל קומפוננטה כדי למנוע אילתורים

• טוקנים משותפים לכל המוצר: מצב, טיפוגרפיה, מרווחים, אייקונים

• מילון ניסוחים אחיד שמחובר לכרטיסים ולהתראות

• כללי תוכן: ראיות, חלופות, ושורת השלכה

• כללי בטיחות: סימולציה/אישור כפול/עצירה כשאין בסיס

• דף בדיקות קבוע עם תרחישים ומדדים

מה נחשב “טעות עיצוב” במערכת סוכנית: רשימת מוקשים שמפיל מוצרים גם אם המסכים יפים

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

• פעולה בלי השלכה ברורה

• ראיות מוגזמות במקום שתי ראיות + העמקה

• אין בלם ברור בכל מצב ביצוע

• שינוי תכנית/מקור בלי הודעה קצרה

• ניסוחים שונים לאותו סטטוס

• צבעוניות שמייצרת התרגלות לאזהרות

• יותר מדי חלופות ברגע החלטה

• תוצאות בלי סימון אי־ודאות ומידע חסר

• מצבי נדיר לא מעוצבים מראש

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

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

• מטרת המסמך: עקביות, בטיחות, ולמידה לאורך זמן

• הגדרת תפקיד הסוכן ורמות אוטונומיה

• מפת סטייטים ושפה קבועה לכל מצב

• ספריית קומפוננטים + כללי שימוש

• טוקנים וסטייל־גייד למצבים

• מילון ניסוחים ותבניות הודעה בעברית RTL

• כללי בטיחות: אישורים, סימולציה, עצירה, מקור

• תרחישי בדיקה ומדדים

• גרסאות והיסטוריית החלטות עיצוביות

עמוד “הגדרת סוכן”: מה הסוכן עושה, מה לא, ואיפה הוא פועל

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

• מטרה על: תוצאה רצויה במשפט אחד

• כן עושה: רשימת פעולות סוכניות מותרות

• לא עושה: רשימת פעולות אסורות

• מרחב פעולה: היכן הוא עובד ובאילו חשבונות/פרויקטים

• רמות סמכות: מציע / מכין טיוטה / מבצע חלקית / מבצע

• קו אדום: פעולות שאסורות תמיד

• חוסר מידע: שואל / עוצר / מציע חלופות

• דיווח: מתי מתריע, מתי מסכם, מתי שקט

• ציפיית זמן: מיידי / ברקע / בתור

עמוד “רמות אוטונומיה”: איך מגדירים שליטה מדורגת בצורה שמובנת למשתמש ולצוות

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

• מציע בלבד: אין ביצוע, רק תכנון והמלצות

• מכין ובונה: טיוטות וקבצים פנימיים, אישור לפני חוץ

• מבצע עם גבולות: ביצוע בתוך תקציב/זמן/מדיניות, עצירה בחריגה

• מפת פעולות לפי רמה: פנימי/חיצוני, יצירה/התחייבות

• מה המשתמש רואה: התראות, סימולציה, נקודות אישור

• הורדת רמה אוטומטית בעת סיכון/ירידת איכות נתונים

• העלאת רמה כהצעה אחרי הצלחות ומדדי אמון טובים

• שינוי רמה עם סיכום “מה השתנה”

עמוד “מפת סטייטים”: רשימת מצבים, טריגרים, ומה ה-UI חייב להציג

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

• לכל סטייט: שם, תיאור, טריגרים, רכיבי UI חובה, פעולות שליטה

• סטייטים נדירים כלולים מראש

• מצב שמרני והשפעתו על כל קומפוננט

• מה נכתב ביומן בכל מעבר מצב

• מדיניות התראות לפי סטייט

• מצב סגירה עם סיכום והמלצות

עמוד “קומפוננטים”: רשימת רכיבים, וריאציות, וכללי שימוש

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

• רשימת רכיבי ליבה למערכת סוכנית

• מבנה קבוע + סטייטים לכל רכיב

• מגבלות תוכן כדי למנוע עומס

• ברירת מחדל מול קיפול לראיות/פירוט

• התנהגות מובייל מול דסקטופ

• קשרים בין רכיבים כדי לשמור הקשר

• איסורים: בלי סטטוס, בלי השלכה, בלי תיקון

עמוד “טוקנים”: צבעי מצב, טיפוגרפיה, מרווחים, אייקונים ורמות הדגשה

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

• טוקנים למצבים: דורש אישור, חריגה, כשל, הצלחה, ברקע, שמרני

• טיפוגרפיה לפי תפקידים: פעולה/סטטוס/השלכה/סיבה

• טוקני מרווחים למניעת צפיפות

• אייקונים: סטטוס מול פעולה + כללי שימוש

• עקרונות RTL לשבירה וקריאות

• סימון מצב שמרני בצורה קבועה

עמוד “מילון ניסוחים”: סטטוסים קבועים ותבניות טקסט לכל מצב

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

• החלטה על גוף דיבור: “אני” או “המערכת”

• סטטוסים קבועים

• תבניות: מה קורה + למה + מה עכשיו

• חריגה: טון לא מאשים + תיקון מומלץ

• עצירה: מה חסר + איך ממשיכים

• כשל: פנימי/חיצוני + פעולה מומלצת

• סיכום: תוצאה + צעד הבא

• תבניות ליומן לשחזור עקבי

עמוד “כללי בטיחות”: מתי חובה סימולציה, מתי חובה אישור כפול, ומתי עוצרים

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

• קטגוריות סיכון: כסף, פרטיות, מחיקה, הרשאות, מחויבות

• לכל קטגוריה: סימולציה/אישור כפול/מגבלות

• כלל עצירה כשאין מקור מספיק לפעולה מסוכנת

• מצב שמרני: טריגרים והשפעה

• חריגה חד־פעמית: תהליך, אישור, ותיעוד

• בדיקות בטיחות: הבנת השלכות, עצירה, שינוי כלל

עמוד “תרחישי בדיקה”: סט קבוע שמונע שבירת אמון לפני השקה

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

• תרחיש שגרה מוצלח

• חריגה תקציבית

• חוסר מידע

• סתירה בין מקורות

• כשל חיבור

• חלקיות ביצוע

• שינוי יעד באמצע

• ניסיון מניפולציה/דחיפות חשודה

• מצב שמרני פעיל

• בדיקת יומן ושחזור

• בדיקת עומס התראות

• בדיקת RTL ושבירות טקסט

עמוד “גרסאות והחלטות”: למה בנינו כך, ומה השתנה לאורך זמן

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

• תיעוד החלטות גדולות ושינויים במערכת

• סיבה לשינוי: מה המדד או הבעיה שגרמו לו

• מה המשתמש ירגיש: פחות התראות, יותר אישורים, יותר שקיפות

• היסטוריית גרסאות קצרה שלא מעמיסה

• בסיס לחקירת בעיות והתנהגות לאורך זמן

טריגרים וכללי הפעלה: איך מגדירים “מתי הסוכן מתחיל לפעול” כדי שלא ירגיש חודרני או עצלן

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

• טריגר זמן: יומי/שבועי/חלון שקט, עם אפשרות להשעיה נקודתית

• טריגר אירוע: פנייה חדשה, שינוי מחיר, חריגה, קובץ עודכן, יעד השתנה

• תנאי סף: סיכון, איכות מקור, הרשאות, תקציב, דחיפות

• הסבר הפעלה קצר: “הופעלתי כי ___”

• כיבוי מקומי: השבת טריגר ספציפי בלי לכבות את הסוכן כולו

• מצב שקט: במקום התראה מיידית → סיכום מרוכז בזמן קבוע

• טריגר עצירה: התנגשות מטרות, סתירה במקורות, או חריגה משמעותית

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

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

• גבולות בסיסיים: זמן, תקציב, פעולות חיצוניות, שיתוף, מחיקה

• קשיח מול גמיש: “עוצר תמיד” מול “מבקש אישור לחריגה”

• גבולות לפי פעולה: שליחה, רכישה, שינוי הרשאות, מחיקה, פרסום

• הצעת תיקון בעת חריגה: הקטנת היקף, דחייה, חלופה בטוחה, אישור חד־פעמי

• הצגת גבול נוכחי בתוך כרטיס החלטה ומסך סיכון

• חריגה חד־פעמית עם נימוק קצר ותיעוד

• יומן שינוי גבולות: “עודכן גבול ___ מ___ ל___”

חוקי עיצוב גרפי בתוך Agentic UI: איך מתרגמים היררכיה, קונטרסט ויישור לשליטה וסיכון

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

• היררכיה: פעולה → סטטוס → השלכה → שליטה → הסבר

• קונטרסט: הדגשת רגעים קריטיים בלבד, בלי “זאב זאב”

• יישור: אזורים קבועים לכרטיסים כדי לייצר סריקה מהירה

• קרבה: סיבה צמודה להשלכה, מקורות צמודים למסקנות

• חזרתיות: אותו ניסוח ואותו מבנה לכל סטטוס בכל המסכים

• מרווחים: “נשימה” סביב כפתורי אישור ועצירה כדי למנוע קליקים מהירים

• טיפוגרפיה: מספרים, ספים ותאריכים במבנה עקבי וקריא

• מינון ראיות: מעט כברירת מחדל, העמקה לפי צורך

חשיבה עיצובית בסוכנים: איך עוברים מ“מסך” ל“מערכת מתנהגת” שמכבדת משתמשים

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

• מיפוי רגעים קריטיים: מחיקה, שיתוף, כסף, הרשאות, התחייבויות

• תרחישים: הצלחה, חריגה, חוסר מידע, סתירה, חלקיות, שינוי יעד

• הבנת פחד משתמש: “מה נעשה בשמי” כנקודת מוצא

• גבולות והעדפות שמקטינים שאלות מיותרות אבל שומרים בטיחות

• דפוסים קבועים: החלטה/סיכון/יומן/סימולציה/דוח

• פרוטוטייפ מצבי מערכת ולא רק קומפוזיציות

• בדיקות הבנה מהירה: מצב, השלכה, ושליטה

• מנגנון למידה: טעות → כלל → שינוי התנהגות

פיתוח יצירתיות במוצר סוכני: איך ממציאים פתרונות חדשים בלי להמציא בלגן חדש

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

• מטאפורות יציבות שחוזרות בכל מקום: תכנית, יומן, בלם, שמרני

• אינטראקציות שמחליפות טקסט: טוגל, תגית מצב, שורת השלכה בולטת

• יצירתיות דרך הפחתה: פחות חלופות, פחות צבע, פחות עומס

• סט תרחישי קצה קבועים שמכוונים את העיצוב מההתחלה

• כתיבה קצרה ואחראית: טון מקצועי, בלי דרמה ובלי הבטחות יתר

• סקיצות שמדמות לוגיקה וזרימה לפני עיצוב “יפה”

• מדד יצירתי אמיתי: יותר שקט, פחות פחד, יותר שליטה

עבודה עם כלי עיצוב כדי לבנות ספריית Agentic UI אמיתית: מה עושים בכל תוכנה ואיך זה משרת את הפרויקט

כדי לבנות מערכת עיצוב סוכנית, צריך לעבוד כמו מערכת: אייקונים, סטייטים, טקסטים, תרחישים, ודוגמאות שימוש, ולא רק מסכים בודדים. Figma הוא מקום מצוין לייצר קומפוננטים עם וריאנטים של סטטוסים, כדי שכל מצב יהיה אותו רכיב ולא עותק ידני. כלי וקטור עוזר לבנות סט אייקונים ברור לסטטוסים, כי סטטוס חייב להיות קריא גם בקטן ובצילום מסך. כלי רסטר עוזר להכין הדמיות של התראות, דוחות, ומסכים “אמיתיים” כדי שהתיק ייראה כמו מוצר ולא כמו תרגיל. כלי אנימציה מאפשר להדגים מעבר מצב, עצירה, וריצה ברקע, כי תנועה קטנה יכולה להסביר מצב יותר טוב מפסקה. כלי עימוד מאפשר לכתוב Case Study עם תרחישים, מדדים, והחלטות עיצוביות, כי במערכת סוכנית “איך חשבת” חשוב כמו “מה יצא”. ניהול קבצים ותבניות חיוני, כי סטייטים מתרבים מהר ואם אין סדר—המערכת תתפרק. כדאי להחזיק “דף תרחישים” שממנו בודקים כל רכיב: חריגה, אישור פג תוקף, סתירה, חלקיות, שינוי יעד. חשוב גם לבנות ספריית ניסוחים בתוך אותו כלי שבו בונים UI, כדי שהשפה והקומפוננטים יזוזו יחד ולא יתפצלו. ולבסוף, בכל כלי שתבחר, המטרה היא אחת: להקטין אילתור ולהגדיל עקביות.

• קומפוננטים עם וריאנטים לכל סטטוס, במקום עותקים ידניים

• סט אייקונים לסטטוסים שנבדק בגדלים קטנים

• הדמיות מסכים “אמיתיים” לתיק עבודות: התראות, דוחות, יומן

• אנימציות קצרות למעברי מצב: ברקע, עצירה, כשל, חזרה

• מסמך Case Study שמציג תרחישים, מדדים, והחלטות שנשקלו

• מבנה קבצים ותבניות כדי לא ללכת לאיבוד בין סטייטים

• דף תרחישים קבוע לבדיקת כל רכיב לפני שמאשרים אותו

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

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

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

• מסלול מוצר: תרחישים, סטייטים, יומן החלטות, ומסכי סיכון

• מסלול Design Systems: קומפוננטים, וריאנטים, טוקנים, ומילון ניסוחים

• מסלול כתיבה למוצר: אישורים, עצירות, אי־ודאות, והסלמה

• מסלול אופרציה/שירות: handoff, תורים, והצגת הקשר לנציגים

• כישורי חובה למתחיל: עצירה, מקור, הורדת אוטונומיה, וניהול חריגות

• עבודה רב־תחומית: מוצר, פיתוח, פרטיות, אבטחה, ותפעול

• מדדים בתיק עבודות: הבנת מצב, איכות אישור, ושיעור תיקונים

• פרויקט אחד עמוק שמראה בגרות עדיף על הרבה מסכים יפים

פרויקט דגל לתיק עבודות: “סוכן שמנהל שירות לקוחות” שמוכיח Agentic Design מההתחלה ועד ההשקה

פרויקט דגל טוב בתחום הסוכני צריך להיות אחד, עמוק, עם הרבה מצבי קצה והחלטות שקופות, ולא אוסף מסכים נוצצים. שירות לקוחות הוא בחירה מעולה כי יש בו דחיפות, רגש, מדיניות, וכסף—כל מה שמכריח עיצוב אחראי. המטרה שלך בתיק היא להראות איך הפכת סוכן מסוכן לכוח עזר אמין: איפה נתת אוטונומיה, איפה עצרת, ואיך הסברת הכול בשפה קצרה. בפרויקט כזה אתה מדגים שלושה סוגי משתמשים: הלקוח, הנציג, והמנהל, וכל אחד צריך UI אחר כדי לסמוך על הסוכן. אתה גם מדגים שהסוכן הוא לא רק צ’אט, אלא תהליך: זיהוי פנייה, איסוף הקשר, תכנון תגובה, בקשת אישור, ביצוע, תיעוד, ושיפור מדיניות. יתרון נוסף הוא שאתה יכול להראות handoff איכותי, כי בעולם אמיתי רוב הפניות לא נסגרות אוטומטית במאה אחוז. כדי שזה יעבוד כתיק עבודות, אתה צריך לתכנן מראש “אירועי שבר אמון” ולבנות להם מסכים, ואז להראות איך בדקת אותם. חשוב גם לכלול מילון ניסוחים בעברית, כי זו יכולת נדירה שמעסיקים מעריכים במוצרים RTL. ולבסוף, פרויקט כזה מאפשר לך להראות Design System קטן, כי אותם קומפוננטים חוזרים לאורך כל הטיפול.

• נושא עם מצבי קצה אמיתיים: כסף, פרטיות, טון רגשי, ומדיניות

• שלושה פרסונות: לקוח, נציג, מנהל

• תהליך מלא, לא רק מסך שיחה

• handoff בין סוכן לאדם כחלק מרכזי

• מסכים לאירועי שבר אמון (חריגה, חלקיות, כשל)

• מילון ניסוחים בעברית RTL

• Design System קטן עם קומפוננטים חוזרים

הגדרת הסוכן לפרויקט: מה הוא עושה, מה הוא לא עושה, ואיפה הוא עוצר

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

• כן עושה: סיכום, הקשר, טיוטה, פתרון לפי מדיניות, פעולות בטוחות

• לא עושה: התחייבות/זיכוי/שינוי תנאים בלי אישור

• שלושה מרחבי UI: לקוח/נציג/מנהל

• עצירה בחריגות: הונאה, משפטי, חוסר מידע, קונפליקט מקור

• קו אדום: כסף ופרטיות דורשים אישור

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

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

• פנייה רגילה נסגרת לבד

• מציע פתרון ודורש אישור

• חריגה תקציבית ותיקון

• מידע חסר או מקור סותר

• לקוח כועס וטון מותאם

• חשד הונאה ומעבר למצב שמרני

• חלקיות ביצוע ושחזור

• שינוי יעד באמצע ותכנון מחדש

מסך “קונסולת נציג”: איך נראה UI שמאפשר לאדם לאשר מהר בלי להיות חותמת גומי

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

• תקציר פנייה: לקוח/בעיה/הזמנה/דחיפות

• כרטיס הצעת סוכן: פעולה + סיבה + השלכה + סיכון

• שתי ראיות קצרות

• מדיניות רלוונטית: כלל, גבול, ואישורים נדרשים

• טיוטת תשובה עם פעולות שיפור טון

• כרטיס חריגה שמציע תיקון

• יומן טיפול נגיש

• handoff למנהל עם סיבה מובנית

מסך “לקוח”: איך מעצבים חוויה אוטונומית שמרגישה אנושית בלי להבטיח הבטחות שווא

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

• סיכום קצר של בקשת הלקוח

• סטטוס פעולה ברור ולא מעורפל

• שקיפות בסיסית על בדיקה/אישור בלי לחשוף מדיניות פנימית

• זמן משוער או נקודת עדכון

• ניסוח אמפתי אבל לא מתחייב

• בקשת מידע קצרה כשחסר, לא טופס ארוך

• סיומת “מה עכשיו” בכל הודעה

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

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

• דשבורד קצר: נסגר לבד / דרש אישור / נעצר מסיכון

• רשימת חריגות עם סיבה ותדירות

• כללים מובילים: הכי שימושיים + הכי חוסמים

• חריגה חד־פעמית עם תיעוד

• שינוי גבולות + סימולציה להשפעה

• דוגמאות הודעות לצפייה בטון

• היסטוריית שינויי מדיניות

תוצרים לתיק עבודות: מה אתה מציג כדי שזה ייראה כמו עבודה אמיתית ולא כמו תרגיל

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

• מפת סטייטים + מצבי קצה מפורטים

• ספריית קומפוננטים עם וריאנטים

• שלושה מסכים מחוברים: לקוח/נציג/מנהל

• מילון ניסוחים בעברית RTL

• יומן החלטות לשחזור

• מסך סימולציה לפעולות מסוכנות/מדיניות

• תרחישי בדיקה + מדדים

• דוגמת “לפני/אחרי” של שיפור אמון

סקיצה טקסטואלית למסכים: איך בונים את הפרויקט מהר בלי להיתקע על “איך לחלק את המסך”

סקיצה טקסטואלית היא הדרך הכי מהירה להפוך רעיון למערכת עקבית, כי היא מכריחה אותך להחליט מה המשתמש רואה קודם, מה בקיפול, ומה הנקודות שבהן הוא מקבל שליטה. במערכת סוכנית, הסדר חשוב יותר מהגרפיקה: פעולה, סטטוס, השלכה, שליטה, ואז הסבר. הסקיצה כאן כתובה כך שתוכל להדביק אותה למסמך או ללוח תכנון ולהפוך אותה למסכים אחד־לאחד. היא גם מתאימה ל-RTL, ולכן כל שורת כותרת בנויה כך שתהיה קצרה ולא תישבר. חשוב לזכור שכל בלוק במסך צריך להופיע גם ביומן, אחרת לא תהיה יכולת שחזור. בנוסף, כל מסך חייב לכלול “בלם” כשיש ביצוע, ודרך handoff כשיש סיכון. ולבסוף, הסקיצה לא מניחה צבעים או סגנון—רק מבנה התנהגותי שמחזיק מוצר.

• סדר קבוע: פעולה → סטטוס → השלכה → שליטה → הסבר

• מה קריטי למעלה, מה בקיפול למטה

• כל בלוק מתחבר ליומן לשחזור

• בלם קבוע במצבי ביצוע

• handoff מובנה למצבי סיכון

מסך “נציג” – מבנה עליון שמאפשר להבין פנייה במבט אחד

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

• כותרת מסך: “טיפול בפנייה: ___” + תגית דחיפות

• תקציר לקוח: שם, סטטוס לקוח, היסטוריית פניות קצרה

• תקציר הזמנה: מספר, סטטוס משלוח, תאריך, פריטים עיקריים

• כרטיס הצעת סוכן: פעולה + סיבה + השלכה + סטטוס

• כרטיס חריגה/סיכון אם רלוונטי

• ראיות קצרות: שני פריטים בלבד

• מדיניות רלוונטית בקיפול: כלל פעיל + גבולות

• טיוטת הודעה ללקוח + כפתורי עריכה מהירים

• יומן טיפול: מה נעשה עד כה

• כפתורי שליטה: אשר / ערוך / העבר למנהל / עצור

כרטיס “הצעת סוכן” לנציג – תוכן מדויק שאפשר ליישם מיד

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

• כותרת: “מציע: ___”

• סטטוס: “ממתין לאישור לפני ביצוע”

• סיבה: “כי ___”

• השלכה: “השפעה: ___”

• ראיות: “מבוסס על: ___, ___”

• סיכון: “סיכון: ___” (אם רלוונטי)

• שליטה: “אשר”, “ערוך”, “עצור”

• אי־תגובה: “אם אין תגובה עד ___ → ___”

טיוטת הודעה ללקוח – ניסוחים קצרים עם פעולות שיפור טון

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

• טיוטה בסיסית: הכרה + פעולה + מה עכשיו

• כפתורים: “קצר”, “שפר טון”, “הסר התחייבות”, “הוסף זמן עדכון”

• תזכורת פנימית לנציג: “אין להתחייב על זיכוי בלי אישור”

מסך “לקוח” – מבנה שמפחית לחץ ומציג טיפול אמיתי בלי לחשוף מדיניות פנימית

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

• כותרת שיחה: נושא + סטטוס נוכחי

• בלוק סיכום: “הבנתי ש___”

• בלוק פעולה: “אני בודק/ת ___”

• בלוק עדכון: “אעדכן אותך ב___”

• בלוק השלמה: בקשת מידע קצרה כשחסר

• בלוק פתרון: הצעה בלי התחייבות מוגזמת

• בלוק סיום: שאלה קצרה/מה עכשיו

ניסוחים מוכנים למסך לקוח לפי סטייטים

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

• בדיקה: “בודק/ת עכשיו ואעדכן בקרוב”

• אישור: “ממתין/ה לאישור כדי להתקדם”

• חוסר מידע: “חסר לי ___ כדי להמשיך”

• העברה: “העברתי לנציג/ה כדי לטפל במדויק”

• פתרון: “אפשרות לפתרון: ___”

• סגירה: “טופל. תרצה/י שאעזור ב___?”

מסך “מנהל” – מבנה שמאפשר לכוון מדיניות בלי ידע טכני

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

• דשבורד: נסגר לבד / דרש אישור / נעצר מסיכון / חלקיות

• חריגות נפוצות: סוג חריגה + תדירות + דוגמה

• כללים מובילים: שימושיים וחוסמים

• עריכת כלל: גבול/אישור/עצירה

• סימולציה להשפעת שינוי כלל

• דוגמאות הודעות שנשלחו

• היסטוריית שינויי מדיניות

ניסוחים קצרים למסך מנהל שמחזקים אחריות ולא מאשימים

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

• “נדרשו ___ אישורים השבוע בגלל ___”

• “נחסמו ___ פניות בגלל ___”

• “הוצעה התאמה לכלל ___ כדי להפחית ___”

• “מצב שמרני פעיל: פעולות ___ דורשות אישור”

מסך “סימולציה לפעולה מסוכנת” – מבנה שמאפשר לאשר מתוך הבנה

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

• מטרה + תוצאה צפויה

• תכנית בשלבים עם זמן משוער

• נקודות אישור ועצירה

• השלכה בולטת: עלות/סיכון

• נתונים ומקורות שנשענים עליהם

• מה חסר אם חסר

• שתי חלופות + המלצה לא כופה

• כפתור מעבר לביצוע + בלם חזרה

יומן החלטות – מבנה לשחזור שמוכיח אחריות ועקביות

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

• טריגר: “פנייה חדשה”

• איסוף: “נאסף מידע מ___”

• הצעה: “הוצעה פעולה ___”

• אישור: “אושר ע”י ___”

• ביצוע: “בוצע ___”

• תוצאה: “נסגר/הועבר/חלקי”

• שינוי: “עודכן כלל/גבול/כוונה”

תרחיש חריגה תקציבית: כשהסוכן מציע זיכוי מעל הגבול והמערכת חייבת לעצור בצורה אלגנטית

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

• לנציג: כרטיס חריגה שמציג גבול, הצעה, ופער, עם תיקון מומלץ אחד

• ללקוח: הודעת סטטוס רגועה שמדגישה טיפול ועדכון בזמן

• למנהל: תדירות חריגות + כלל שמפעיל אותן + אפשרות כיול גבול

כרטיס חריגה לנציג — טקסט מוכן

• כותרת: “חריגה תקציבית בזיכוי”

• מה חריג: “הצעה: זיכוי ___, גבול אוטומטי: ___”

• למה זה קרה: “הלקוח עומד בתנאים ל___, אך סכום הפתרון גבוה מהגבול”

• תיקון מומלץ: “הצע זיכוי בתוך הגבול + הטבה חלופית”

• חלופה: “העבר לאישור מנהל לזיכוי מלא”

• אי־תגובה: “ללא פעולה → התהליך נשאר בהמתנה”

• פעולות: “עדכן להצעה בטוחה”, “העבר למנהל”, “עצור טיפול אוטומטי”

כרטיס הצעת סוכן לנציג — איך זה נראה כשהכול תקין אחרי תיקון

• כותרת: “מציע: זיכוי בתוך הגבול + פתרון משלים”

• סטטוס: “ממתין לאישור לפני ביצוע”

• סיבה: “כדי לסגור את הפנייה מהר בלי חריגה”

• השפעה: “זיכוי ___ + ___ (ללא התחייבות חריגה)”

• מבוסס על: “מדיניות ___”, “היסטוריית לקוח ___”

• שליטה: “אשר”, “ערוך”, “עצור”

הודעת לקוח — טקסט מוכן

• “אני בודק/ת אפשרות לפתרון מתאים ואעדכן אותך בהקדם.”

• “כדי להיות מדויק/ת, אני מאמת/ת את הפרטים מול ההזמנה שלך.”

• “אעדכן עד ___ עם ההצעה הסופית. בינתיים יש עוד משהו שחשוב לי לדעת?”

מסך מנהל — שורה לדשבורד

• “חריגות תקציב השבוע: ___ (עלייה/ירידה מול שבוע קודם)”

• “הכלל שמייצר הכי הרבה חריגות: ___”

• “הצעה לכיול: התאמת גבול אוטומטי מ___ ל___ (דורש סימולציה)”

יומן החלטות — אירועים מוכנים

• “הוצעה פעולה: זיכוי ___ (חריגה מעל גבול)”

• “נדרש אישור: חריגה תקציבית”

• “עודכן פתרון: זיכוי ___ + פתרון משלים”

• “אושר ע״י ___”

• “בוצע: זיכוי ___”

• “נסגר: הלקוח עודכן”

---

תרחיש מידע חסר או סתירה במקורות: כשהסוכן חייב לשאול שאלה אחת ולא להפוך את זה לחקירה

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

• שאלה אחת ממוקדת בכל הודעה ללקוח

• לנציג: תיבת “מה חסר” ברורה + מניעת שאלות כפולות

• סתירה: הצגת שתי אפשרויות + בקשת אימות קצרה

כרטיס עצירה לנציג — טקסט מוכן

• כותרת: “נעצר: חסר מידע להמשך”

• מה חסר: “חסר ___ כדי לאתר הזמנה/לאמת בעלות”

• למה זה קריטי: “בלי זה קיים סיכון לטיפול בהזמנה שגויה”

• מה כבר יש: “יש לנו: ___, ___”

• פעולה מומלצת: “בקש מהלקוח רק את ___”

• חלופה: “העבר לאימות ידני”

• שליטה: “שלח בקשת מידע”, “העבר לנציג בכיר”, “עצור טיפול אוטומטי”

הודעת לקוח — שאלת מידע אחת

• “כדי להמשיך, חסר לי רק ___.”

• “אפשר לשלוח לי את ___? מיד כשאקבל אותו אמשיך בטיפול.”

• “אם אין לך את זה עכשיו, אפשר גם ___.”

סתירה במקורות — ניסוח ללקוח בלי לחשוף פנימיות

• “אני רואה שני פרטים שונים בהזמנה, ורוצה לוודא שאני מטפל/ת נכון.”

• “איזה מהאפשרויות נכון: ___ או ___?”

• “מיד אחרי האימות אעדכן אותך בצעד הבא.”

מסך נציג — בלוק “מה חסר”

• כותרת בלוק: “חסר כדי להתקדם”

• שורה ראשונה: “פריט חסר: ___”

• שורה שנייה: “למה צריך: ___”

• כפתור: “שלח בקשה קצרה ללקוח”

מסך מנהל — אינדיקציה לשיפור זרימה

• “החסרים הנפוצים: ___”

• “השלכה: פניות נעצרות בממוצע ___”

• “הצעה: לבקש ___ מוקדם יותר בתהליך”

יומן החלטות — אירועים מוכנים

• “נעצר: חסר ___”

• “נשלחה בקשת מידע: ___”

• “התקבל מידע: ___”

• “חודשה תכנית: ממשיך לביצוע/להצעה”

---

תרחיש לקוח כועס: כשההחלטה האמיתית היא טון, קצב, וסגירת לולאה

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

• לנציג: תווית “מצב רגשי גבוה” + הצעת טיוטה אמפתית קצרה

• ללקוח: הכרה + פעולה + זמן עדכון, בלי דיונים ארוכים

• למנהל: מדד הסלמות ותבניות טון שעובדות/לא עובדות

כרטיס מצב לנציג — טקסט מוכן

• כותרת: “רגישות גבוהה: מומלץ טון מרגיע”

• למה: “הלקוח מביע תסכול/כעס”

• מה לעשות עכשיו: “שלח הודעת הכרה קצרה + זמן עדכון”

• מה להימנע: “לא להאשים, לא להבטיח זיכוי, לא להיכנס להסברים ארוכים”

• שליטה: “הפק טיוטה מרגיעה”, “העבר לנציג בכיר”, “עצור אוטומציה”

טיוטת הודעה ללקוח — גרסה קצרה

• “אני מבין/ה את התסכול שלך, וזה לגמרי לא נעים.”

• “אני בודק/ת את פרטי ההזמנה עכשיו ואעדכן עד ___.”

• “רק כדי לוודא שאני מטפל/ת נכון, אפשר את ___?”

טיוטת הודעה ללקוח — גרסה עם פתרון ביניים

• “אני מבין/ה אותך. אני מטפל/ת בזה עכשיו.”

• “בשלב הזה אני יכול/ה להציע ___ כפתרון זמני עד שאסיים בדיקה.”

• “אעדכן עד ___ עם הצעד הבא. זה מתאים לך?”

מסך נציג — כפתורי עריכה מהירים לטון

• “קצר”

• “שפר טון”

• “הסר התחייבות”

• “הוסף זמן עדכון”

מסך מנהל — מדדי טון

• “שיחות שהוסלמו לאחר הודעת סוכן: ___”

• “תבניות טון שהורידו הסלמה: ___”

• “הצעה: לחייב זמן עדכון בהודעות רגישות”

יומן החלטות — אירועים מוכנים

• “זוהה רגישות גבוהה: מומלץ טון מרגיע”

• “נשלחה הודעת הכרה + זמן עדכון”

• “התקבל מידע נוסף/המשך טיפול”

---

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

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

• מצב שמרני פעיל באופן בולט בקונסולה

• עצירה אוטומטית של פעולות מסוכנות

• handoff למנהל עם סיכום קצר ולא מאשים

כרטיס הקפאה לנציג — טקסט מוכן

• כותרת: “הקפאה אוטומטית: נדרש אימות”

• סיבה כללית: “זוהה דפוס שמחייב בדיקה”

• מה נעצר: “פעולות כספיות/שינוי כתובת/שיתוף מידע”

• מה מותר: “איסוף מידע, תיעוד, העברה למנהל”

• פעולה מומלצת: “העבר למנהל + בקש מסמך/אימות”

• שליטה: “העבר למנהל”, “שלח בקשת אימות”, “עצור אוטומציה”

הודעת לקוח — ניטרלית ולא מאשימה

• “כדי להמשיך, אני צריך/ה לבצע בדיקה קצרה לאימות הפרטים.”

• “זה נועד להגן על החשבון שלך. אעדכן אותך עד ___.”

• “אפשר לשלוח ___ כדי שנוכל להתקדם?”

מסך מנהל — כרטיס handoff

• כותרת: “נדרש אימות מנהל”

• מה קרה: “הקפאה הופעלה במהלך טיפול בפנייה ___”

• למה בקצרה: “דפוס חריג ביחס ל___”

• מה נעצר: “___”

• מה צריך החלטה: “לאשר המשך/לבקש אימות נוסף/לסגור ללא פעולה”

יומן החלטות — אירועים מוכנים

• “מצב שמרני הופעל: הקפאה אוטומטית”

• “נעצרו פעולות מסוכנות: ___”

• “הועבר למנהל: ___”

• “החלטת מנהל: ___”

• “חזרה למצב רגיל/המשך במצב שמרני”

---

תרחיש חלקיות ביצוע: פעולה בוצעה חלקית והמערכת חייבת להסביר מה כן קרה ומה לא

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

• לנציג: תצוגת “בוצע/לא בוצע” קצרה וברורה

• ללקוח: עדכון תוצאתי + זמן עדכון הבא

• למנהל: תדירות חלקיות לפי סוג פעולה

כרטיס חלקיות לנציג — טקסט מוכן

• כותרת: “חלקית בוצע: נדרש השלמה”

• בוצע: “___”

• לא בוצע: “___ (סיבה: ___)”

• סיכון: “ייתכן ניסיון כפול אם מאשרים שוב”

• תיקון מומלץ: “השלם רק את ___”

• חלופה: “בטל את ___ אם אפשר”

• שליטה: “השלם בבטחה”, “נסה שוב עם אישור”, “העבר לתמיכה”, “עצור”

הודעת לקוח — תוצאה בלי טכניקה

• “עדכנתי חלק מהטיפול, ונשאר עוד שלב קטן כדי לסיים.”

• “אני מטפל/ת בזה עכשיו ואעדכן עד ___.”

• “אם יהיה צורך בפעולה מצידך, אכתוב בדיוק מה צריך.”

מסך מנהל — סיכום חלקיות

• “חלקיות השבוע: ___”

• “הפעולה עם הכי הרבה חלקיות: ___”

• “הצעה: להוסיף נקודת אישור/לשנות סדר צעדים כדי להפחית חלקיות”

יומן החלטות — אירועים מוכנים

• “בוצע: ___”

• “נכשל: ___ (סיבה כללית: ___)”

• “נדרש תיקון: ___”

• “הושלם תיקון/הועבר לטיפול ידני”

---

תרחיש שינוי יעד באמצע: המשתמש משנה החלטה והמערכת חייבת להראות מה נשמר ומה מתבטל

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

• מסך “תכנון מחדש” קצר שמציג לפני/אחרי והשפעה

• אישור מחדש כששינוי יעד משנה סיכון או התחייבות

• תיעוד מלא ביומן של שינוי כוונה

כרטיס תכנון מחדש לנציג — טקסט מוכן

• כותרת: “עודכן יעד: תכנון מחדש”

• לפני: “היעד היה ___”

• אחרי: “היעד כעת ___”

• מה נשמר: “___”

• מה מתבטל: “___”

• השפעה: “זמן: ___, עלות: ___, סיכון: ___”

• נדרש אישור מחדש: “כן/לא (כי ___)”

• שליטה: “אשר תכנון חדש”, “ערוך יעד”, “עצור”

הודעת לקוח — שקיפות קצרה

• “עדכנתי את הטיפול כדי להתאים לבקשה שלך.”

• “אני ממשיך/ה לפי התכנית החדשה ואעדכן עד ___.”

• “רק כדי לוודא: זה הפתרון המועדף עליך?”

מסך מנהל — אינדיקציה לזרימה

• “שינויי יעד במהלך טיפול: ___”

• “נקודת שינוי נפוצה: אחרי ___”

• “הצעה: לשפר ניסוח שאלה בתחילת טיפול כדי לצמצם שינויי יעד”

יומן החלטות — אירועים מוכנים

• “עודכן יעד: ___ → ___”

• “תכנון מחדש בוצע”

• “אישור קודם בוטל/אושר מחדש”

• “המשך טיפול לפי יעד חדש”

תרחיש דחיפות מניפולטיבית: כשהלקוח לוחץ “עכשיו” והמערכת חייבת להישאר רגועה, מדויקת ובטוחה

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

• לנציג: תווית “דפוס לחץ” + תזכורת כללים + הצעת מסלול בטוח

• ללקוח: הכרה + גבול מקצועי + זמן עדכון + פעולה מיידית בטוחה

• למנהל: מדד “שיחות עם לחץ” והשפעה על חריגות

כרטיס מצב לנציג — טקסט מוכן

• כותרת: “דפוס לחץ: מומלץ טיפול זהיר”

• זוהה: “שפה מאיימת/דדליין קיצוני/דרישה מיידית”

• מה חשוב: “לא להתחייב לפיצוי/זיכוי בלי אישור”

• מה לעשות: “הצע צעד מיידי בטוח + זמן עדכון”

• שליטה: “הפק טיוטה רגועה”, “העבר לנציג בכיר”, “עצור אוטומציה”

טיוטת הודעה ללקוח — גרסה מקצועית ומרגיעה

• “אני מבין/ה שזה דחוף ומלחיץ.”

• “כדי לטפל בזה נכון, אני מבצע/ת בדיקה קצרה עכשיו.”

• “אעדכן אותך עד ___ עם התוצאה והצעד הבא.”

טיוטת הודעה ללקוח — עם פעולה מיידית בטוחה

• “אני מבין/ה אותך. אני מטפל/ת בזה עכשיו.”

• “בשלב הזה אני יכול/ה לבצע מיד ___ כדי לקדם פתרון.”

• “אעדכן עד ___ אחרי הבדיקה. זה בסדר?”

כרטיס הצעת סוכן לנציג — מסלולים בטוחים בלבד

• מסלול א’: “פתרון בתוך מדיניות + זמן עדכון”

• מסלול ב’: “העברה מבוקרת לנציג בכיר/מנהל”

• סיבה: “מניעת התחייבות חריגה תחת לחץ”

יומן החלטות — אירועים מוכנים

• “זוהה דפוס לחץ: נבחר טיפול זהיר”

• “נשלחה הודעת הכרה + זמן עדכון”

• “הוצעה פעולה בטוחה: ___”

• “הועבר/נסגר בהתאם”

---

תרחיש בקשת מחיקת נתונים: כשהלקוח מבקש “מחקו הכול” והמערכת חייבת להיות שקופה בלי להבטיח משהו שאי אפשר

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

• לנציג: תהליך מובנה לבקשת פרטיות + עצירה אוטומטית לפעולות מחיקה

• ללקוח: הכרה בבקשה + תהליך אימות + זמן עדכון

• למנהל: מעקב ובקרת סטטוס לבקשות פרטיות

כרטיס פרטיות לנציג — טקסט מוכן

• כותרת: “בקשת פרטיות: מחיקת נתונים”

• סטטוס: “נדרש אימות לפני פעולה”

• מה חובה: “אימות זהות + סיווג בקשה”

• מה אסור: “לא לבצע מחיקה/הסרה מלאה בלי אישור”

• פעולה מומלצת: “שלח בקשת אימות קצרה + פתח בקשת פרטיות”

• חלופה: “העבר לגורם פרטיות/מנהל”

• שליטה: “שלח אימות”, “פתח בקשה”, “העבר”, “עצור”

הודעת לקוח — ניסוח בטוח ושקוף

• “קיבלתי את בקשתך למחיקת נתונים.”

• “כדי להגן על החשבון שלך, אני צריך/ה לבצע אימות קצר לפני המשך.”

• “אעדכן אותך עד ___ עם הסטטוס והצעדים הבאים.”

בקשת אימות ללקוח — שאלה אחת בכל פעם

• “כדי להתחיל, אפשר לאשר לי את ___?”

• “אחרי זה אמשיך לשלב הבא של הבקשה.”

מסך מנהל — בלוק בקשות פרטיות

• “בקשות פרטיות פתוחות: ___”

• “בממתין לאימות: ___”

• “נסגרו השבוע: ___”

• “זמן טיפול ממוצע: ___”

יומן החלטות — אירועים מוכנים

• “נפתחה בקשת פרטיות: מחיקת נתונים”

• “נדרש אימות: ___”

• “התקבל אימות/לא התקבל”

• “בוצעה פעולה: ___”

• “הועבר לגורם פרטיות/נסגר”

---

תרחיש קונפליקט בין מדיניות ארגונית לכלל שהנציג הוסיף: כשהמערכת חייבת להציג סדר עדיפות ברור

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

• סדר עדיפות ברור ומוצהר: מדיניות ארגונית קודמת

• כרטיס התנגשות עם שני הכללים ותיקון מומלץ

• תיעוד ביומן + אינדיקציה למנהל

כרטיס התנגשות לנציג — טקסט מוכן

• כותרת: “התנגשות: כלל מקומי מול מדיניות”

• כלל מקומי: “___”

• מדיניות ארגונית: “___”

• מה סותר: “___”

• מה יקרה עכשיו: “נבחר פתרון לפי מדיניות”

• תיקון מומלץ: “עדכן כלל מקומי ל___”

• חלופה: “החרג את הכלל רק כש___”

• שליטה: “עדכן כלל”, “צפה במדיניות”, “העבר למנהל”, “עצור”

מסך מנהל — תצוגת התנגשויות

• “התנגשויות מדיניות השבוע: ___”

• “הכלל המקומי שמייצר הכי הרבה התנגשויות: ___”

• “הצעה: לעדכן מדיניות/להדריך צוות על ___”

יומן החלטות — אירועים מוכנים

• “זוהתה התנגשות מדיניות”

• “נבחר פתרון לפי מדיניות”

• “עודכן כלל מקומי/הועבר למנהל”

---

תרחיש בקשה להסרת התחייבות שכבר נשלחה: תיקון הודעה בלי לאבד אמון

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

• זיהוי משפט מסוכן והצעת תיקון לנציג

• הודעת לקוח קצרה שמבהירה בלי להתפתל

• תיעוד ולמידה כדי להפחית הישנות

כרטיס תיקון לנציג — טקסט מוכן

• כותרת: “נדרש תיקון: התחייבות לא מאושרת”

• זוהה משפט: “___”

• סיכון: “מייצר ציפייה להתחייבות לפני אישור”

• תיקון מומלץ: “שלח הבהרה קצרה + זמן עדכון”

• שליטה: “שלח תיקון”, “ערוך ניסוח”, “העבר למנהל”

הודעת תיקון ללקוח — ניסוח קצר

• “רק מבהיר/ה: אני בודק/ת את האפשרות לפתרון ומעדכן אותך עד ___.”

• “ברגע שאקבל אישור/אימות, אמשיך בצעד הבא.”

• “תודה על הסבלנות—אני איתך על זה.”

יומן החלטות — אירועים מוכנים

• “זוהה ניסוח התחייבות לא מאושרת”

• “נשלחה הבהרה + זמן עדכון”

• “עודכנו כללי ניסוח/תבנית”

זרימת מסכים אחת רציפה שמחברת את כל התרחישים בלי שירגיש כמו “עץ החלטות” מפחיד

כדי להציג פרויקט סוכני בתיק עבודות בצורה חדה, אתה צריך Flow אחד שמרגיש כמו סיפור טבעי ולא כמו תרשים טכני. הזרימה מתחילה תמיד בנקודת כניסה אחת קבועה: פנייה חדשה נכנסת ומופיע תקציר הקשר לנציג, כדי שהכול יהיה צפוי מהרגע הראשון. משם יש צומת אחד ברור: האם זה סיכון נמוך או סיכון גבוה, כי זו ההבחנה שמכתיבה אוטונומיה ולא “כמה טקסט יש”. אם סיכון נמוך, הסוכן מתקדם למצב “מציע פתרון” ומציג כרטיס הצעה עם השלכה וראיות קצרות, ואז הנציג מאשר או עורך. אם סיכון גבוה, המערכת עוברת למצב שמרני ומציגה כרטיס הקפאה/אימות, ואז מתבצע handoff למנהל עם סיכום קצר. בתוך כל מסלול יש נקודות עצירה אחידות: חריגה תקציבית, מידע חסר, חלקיות, ושינוי יעד, והן חייבות להיראות אותו דבר בכל מקום כדי שהמשתמש ילמד דפוס. בכל צומת, הממשק חייב להגיד “מה קורה עכשיו” ו“מה עכשיו” כדי שלא ייווצר מצב שהכול תלוי בזיכרון הנציג. הסיום של הזרימה חייב להיות תמיד מסך סגירה קצר שמסכם תוצאה ומציע כלל לשיפור, כי זה מה שמראה שהמערכת לומדת ולא רק “מגיבה”. הדבר החשוב ביותר הוא שמסכי הלקוח לא נחשפים לכל הצמתים הפנימיים; הלקוח מקבל רק סטטוס אנושי ועדכון זמן, כדי לשמור על אמון בלי חשיפת מדיניות.

• נקודת כניסה קבועה: תקציר פנייה → הקשר → סטטוס

• צומת על: סיכון נמוך/גבוה שמכתיב אוטונומיה

• מסלול נמוך: הצעה → אישור/עריכה → ביצוע → סיכום

• מסלול גבוה: הקפאה → אימות → handoff למנהל → החלטה → סיכום

• נקודות עצירה אחידות: חריגה, מידע חסר, חלקיות, שינוי יעד

• מסך לקוח מקבל סטטוס ועדכון זמן בלבד, בלי שיח “מדיניות”

“מפה של מצבים” בתוך Flow: איך כל סטייט הופך למסך או כרטיס ולא נעלם ברקע

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

• לכל סטייט יש ייצוג UI: כרטיס/התראה/יומן

• איסוף מידע: מה נאסף + מה חסר, בלי מסך חדש

• ברקע: נקודת עדכון הבאה + אפשרות עצירה

• ממתין לאישור: השלכה בולטת + פעולה אחת מרכזית

• חריגה: תיקון מומלץ + חלופה אחת

• חלקיות: בוצע/לא בוצע + מניעת כפילות

• שינוי יעד: נשמר/מתבטל + אישור מחדש אם צריך

• מצב שמרני: סימון קבוע בכל מסך, לא רק הודעה חד־פעמית

חיבור קומפוננטים לזרימה: איך מוכיחים “מערכת” ולא אוסף מסכים

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

• שימוש חוזר בכרטיסי ליבה בכל המסכים

• כרטיס הצעה: אותו מבנה, פירוט משתנה לפי פרסונה

• כרטיס חריגה: מופיע תמיד באותה צורה, עם תיקון מומלץ

• כרטיס מקור: מופיע רק כשצריך, תמיד באותה היררכיה

• בלם: קבוע בכל ביצוע/ברקע

• העברה למנהל: רק בסיכון גבוה לפי כללים

• שפר טון: קומפוננט עבודה ליד טיוטות

• סיכום סגירה: קומפוננט חובה בסוף כל טיפול

מדדים שמוכיחים הצלחה בעולם אמיתי: מה מודדים בממשק סוכני כדי להבין אם הוא בטוח

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

• זמן להבנת מצב: מה קורה/למה/מה עכשיו

• איכות אישור: צפייה בהשלכה לפני אישור

• שיעור תיקונים אחרי ביצוע

• יחס handoff למנהל לפי סיכון

• תדירות חריגות תקציב

• תדירות חלקיות

• עומס התראות לנציג

• מדדי הסלמה/רגיעה בשיחות לקוח

• חזרתיות “חסר מידע” כסיגנל לשיפור זרימה

תרחיש “בקשת פרטיות מורחבת” בתוך הזרימה: לא רק מחיקה, גם הגבלה ושקיפות במינימום חיכוך

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

• סיווג בקשה: מחיקה/הגבלה/עותק מידע/הפסקת שיווק

• אימות לפני פעולה, תמיד

• מעבר אוטומטי למצב שמרני לפעולות רגישות

• אפשרות מעקב סטטוס ללקוח בלי חשיפת פנימיות

• תיעוד ביומן: סוג בקשה + אימות + תוצאה

איך להפוך את כל זה למסמך Case Study שנראה “אמיתי” ומניע החלטה של מעסיק

Case Study טוב לפרויקט סוכני צריך להיראות כמו סיפור עם אחריות, לא כמו קטלוג מסכים. אתה מתחיל בבעיה עסקית ואנושית: למה צריך סוכן, מה הכאב של לקוח ונציג, ומה הסיכון אם עושים אוטומציה בלי שליטה. אחר כך אתה מציג עיקרון אחד שמוביל את כל הפרויקט, למשל “שקיפות קצרה לפני פעולה”, כדי שהקורא יבין שיש לך קו חשיבה. לאחר מכן אתה מציג את Flow הראשי על עמוד אחד, ואז בוחר שלושה מצבי קצה ומעמיק בהם, כי עומק מנצח רוחב. אתה מראה קומפוננטים חוזרים עם וריאנטים של סטטוסים, כדי להוכיח מערכת ולא איורים. אתה מציג מילון ניסוחים קצר בעברית, כי זה מוכיח שאתה מבין שפה כממשק. אתה מציג יומן החלטות לדוגמה שמראה שחזור, כי זה מה שמבדיל מוצר סוכני רציני. אתה מוסיף בדיקות שימושיות קצרות: מה בדקת, מה נכשל, ואיך שינית מבנה/ניסוח כדי להפחית טעויות. אתה מסיים במדדים שבחרת ובתכנית שיפור, כדי להראות שאתה חושב על החיים אחרי ההשקה. ואם אתה רוצה להראות בשלות, אתה מוסיף עמוד “מה לא עשינו ולמה”, כי גבולות הם חלק מהמקצוע.

• פתיחה: בעיה + סיכון + למה סוכן

• עיקרון מוביל אחד שמחזיק את כל ההחלטות

• Flow ראשי בעמוד אחד + עומק בשלושה מצבי קצה

• קומפוננטים חוזרים עם וריאנטים לפי סטטוס

• מילון ניסוחים קצר בעברית RTL

• דוגמת יומן לשחזור ואחריות

• בדיקות שימושיות: תגלית → שינוי → תוצאה

• מדדים ותכנית שיפור אחרי “השקה”

• גבולות: מה לא נכלל ולמה

עבודה פרקטית בכלי עיצוב כדי להוציא את זה מהר: איך לסגור פער בין רעיון למערכת עקבית

כדי להפיק את כל התוצרים בלי להתפזר, אתה עובד בשכבות: קודם טקסט וזרימה, אחר כך קומפוננטים, ואז מסכים, ורק בסוף עיצוב חזותי. בשלב הראשון אתה בונה וריאנטים לכל כרטיס לפי סטטוס, ומחייב את עצמך לא ליצור עותקים ידניים, אחרת תאבד עקביות מהר. בשלב השני אתה מגדיר טוקנים למצבים ורמות הדגשה, כדי שכל כרטיס יידע “מי אני” בלי המצאות. בשלב השלישי אתה בונה “מסכי שלד” לשלוש פרסונות, ומזריק לתוכם את אותם קומפוננטים, כדי לבדוק שהמערכת מחזיקה בקנה מידה. בשלב הרביעי אתה מוסיף מיקרו־קופי מתוך המילון, ולא כותב מחדש לכל מסך, כדי שהשפה תישאר יציבה. בשלב החמישי אתה מוסיף אינטראקציות מינימליות: פתיחה של ראיות, מעבר למצב שמרני, והשהיה, כדי להדגים התנהגות. בשלב השישי אתה מכין סט אייקונים בסיסי לסטטוסים, ורק אם הוא ברור בקטן אתה מתקדם. בשלב השביעי אתה מייצר עמוד מסודר של תרחישים, כדי שכל שינוי קומפוננטה ייבדק מול אותם תרחישים ולא מול דמיון. בשלב השמיני אתה מכין עמוד סיכום שמדביק יחד Flow, סטייטים, קומפוננטים ומדדים, כי מעסיקים אוהבים לראות “תמונה אחת”. ובשלב התשיעי, אתה מלטש את ההצגה: פחות מסכים, יותר היגיון, כי זה מה שמבדיל תיק מקצועי. אם אתה משתמש בכלי של Adobe, תחשוב על זה ככלי לעזר ויזואלי (אייקונים/הדמיות/תנועה/מסמך), לא כמקור הלוגיקה, כי הלוגיקה נמצאת בסטייטים ובמילון.

• שכבות עבודה: זרימה → קומפוננטים → מסכים → חזות

• וריאנטים לפי סטטוסים, בלי עותקים ידניים

• טוקנים למצבים ורמות הדגשה

• שלדי מסכים לשלוש פרסונות עם אותם רכיבים

• מיקרו־קופי מתוך מילון קבוע

• אינטראקציות מינימליות שמדגימות התנהגות

• סט אייקונים לסטטוסים שנבדק בקטן

• עמוד תרחישים קבוע לבדיקת כל שינוי

• עמוד “תמונה אחת” שמרכז הכול

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

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

• מהירות הבנה במבט אחד לפני כל טקסט עמוק

• פתרון בטוח זמין לפני הסלמה

• מסך לקוח נותן טיפול וזמן עדכון בלי מספרים פנימיים

• מסך מנהל מתרגם חריגות לכיוון מדיניות

• יומן מתעד הצעה, תיקון, אישור, ביצוע ותוצאה

מסך נציג — מבנה מלא (חריגה תקציבית)

• כותרת עליונה: “פנייה פעילה: עיכוב משלוח” + תגית מצב “דורש אישור”

• תקציר הקשר קצר: “הלקוח מתלונן על עיכוב, מבקש פיצוי, זו הפנייה השנייה השבוע”

• בלוק הזמנה: “סטטוס משלוח: מתעכב”, “תאריך יעד חדש: ___”, “פריט מרכזי: ___”

• כרטיס חריגה מרכזי

  • כותרת: “חריגה תקציבית”

  • שורת מצב: “נעצר לפני ביצוע”

  • פער ברור: “הצעה: ___ | גבול: ___ | פער: ___”

  • למה בקצרה: “הפתרון המוצע גבוה מהגבול לפתרון אוטומטי”

  • תיקון מומלץ: “זיכוי בתוך הגבול + פתרון משלים לא כספי”

  • חלופה: “העברה לאישור מנהל לזיכוי מלא”

• כרטיס הצעת סוכן לאחר תיקון (מופיע מיד מתחת)

  • כותרת: “מציע: פתרון בתוך הגבול”

  • סיבה: “כדי לסגור מהר בלי חריגה”

  • השפעה: “זיכוי ___ + ___”

  • ראיות קצרות: “מדיניות ___”, “היסטוריית לקוח ___”

• טיוטת הודעה ללקוח (לשליחה אחרי אישור)

  • משפט הכרה: “אני מבין/ה שזה לא נעים”

  • משפט פעולה: “בדקתי את ההזמנה ומציע/ה פתרון עכשיו”

  • משפט זמן: “אעדכן עד ___ אם נדרש משהו נוסף”

• יומן טיפול בפינה/בתחתית: “נכנסה פנייה → נאסף מידע → זוהתה חריגה → הוצע תיקון”

• פעולות ברורות: “אשר פתרון בטוח”, “ערוך”, “העבר למנהל”, “עצור טיפול אוטומטי”

מסך לקוח — מבנה מלא (חריגה תקציבית)

• פתיח קצר: “הבנתי שיש עיכוב במשלוח וזה מתסכל”

• מצב טיפול: “אני בודק/ת פתרון עכשיו”

• זמן עדכון: “אעדכן עד ___”

• שאלה ממוקדת אם צריך: “אפשר לאשר לי את ___ כדי להתקדם?”

• הודעת המשך אחרי אישור נציג: “מצאתי פתרון שמתאים למצב שלך, ואני ממשיך/ה לבצע אותו עכשיו”

מסך מנהל — מבנה מלא (חריגה תקציבית)

• כרטיס מדד: “חריגות תקציב השבוע: ___”

• פירוט קצר: “הסיבה הנפוצה: עיכוב משלוח מעל ___ ימים”

• כלל מוביל: “הכלל שמוביל לחריגות: ___”

• פעולה מומלצת: “הפעל סימולציה לכיול גבול: ___ → ___”

• דוגמאות אנונימיות בסיכום: “דוגמה של הצעה שנעצרה” + “הפתרון שנבחר”

---

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

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

• סימון מצב שמרני קבוע בכל מסך רלוונטי

• צמצום פעולות מותרות והסבר למה זה מגונן

• ניסוח ללקוח ניטרלי ולא מאשים

• מסלול יציאה מוגדר כדי לא להיתקע

• יומן מתעד מעבר מצב והחלטות

מסך נציג — מבנה מלא (מצב שמרני פעיל)

• פס/תגית קבועה ליד הכותרת: “מצב שמרני פעיל”

• תקציר הקשר: “בקשה לשינוי כתובת + דרישה דחופה + פרטים לא עקביים”

• כרטיס הקפאה מרכזי

  • כותרת: “הקפאה אוטומטית: נדרש אימות”

  • שורת מצב: “נעצר לפני פעולות רגישות”

  • מה נעצר: “שינוי כתובת, פעולות כספיות, שיתוף מידע”

  • מה מותר: “איסוף מידע, תיעוד, העברה למנהל”

  • למה בקצרה: “כדי להגן על החשבון ולמנוע טיפול שגוי”

  • צעד הבא: “שלח בקשת אימות קצרה”

• בלוק “בקשת אימות” מוכן לשליחה

  • נוסח ראשון: “כדי להמשיך, צריך אימות קצר”

  • שאלה אחת: “אפשר את ___?”

  • חלופה אם אין: “אם אין לך את זה עכשיו, אפשר גם ___”

• כפתור handoff בולט: “העבר למנהל לאימות” + שדה סיבה קצר מובנה

• יומן טיפול: “נכנסה פנייה → זוהה סיכון → הופעל מצב שמרני → נשלחה בקשת אימות/הועבר למנהל”

• פעולות זמינות בלבד: “שלח אימות”, “העבר למנהל”, “עצור אוטומציה”

מסך לקוח — מבנה מלא (מצב שמרני)

• פתיח קצר ומכבד: “קיבלתי את הבקשה שלך”

• הסבר ניטרלי: “כדי להמשיך, צריך בדיקה קצרה לאימות פרטים”

• הגנה: “זה נועד להגן על החשבון שלך”

• זמן עדכון: “אעדכן עד ___”

• בקשה אחת בלבד: “אפשר לשלוח לי ___ כדי להתקדם?”

• סיום לולאה: “ברגע שאקבל, אמשיך מיד לשלב הבא”

מסך מנהל — מבנה מלא (החלטת אימות)

• כותרת: “פנייה נעצרה במצב שמרני”

• סיכום קצר: “הופעלה הקפאה במהלך טיפול בבקשה ל___”

• מה נעצר: “___”

• מה הלקוח ביקש: “___”

• החלטות אפשריות כפעולות: “אשר המשך”, “בקש אימות נוסף”, “סגור ללא פעולה”

• תנאי יציאה מוצג: “חזרה למצב רגיל אחרי: אימות הושלם + אין סתירות”

• תיעוד אוטומטי ביומן: “החלטת מנהל נשמרת עם סיבה קצרה”

---

מסכים מלאים לתרחיש חלקיות ביצוע: איך מסבירים כשל חלקי בלי לייצר כפילות ובלי להסתיר

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

• הצהרה ברורה על חלקיות בלי ניסוחים מעורפלים

• לנציג: פירוק תת־פעולות + מניעת כפילות

• ללקוח: עדכון תוצאתי + זמן עדכון הבא

• הורדת אוטונומיה זמנית כדי למנוע ניסיון חוזר לא מבוקר

• יומן מפורט לאירועים ברמת תת־פעולה

מסך נציג — מבנה מלא (חלקיות ביצוע)

• כותרת: “טיפול בפנייה: ___” + תגית מצב “חלקית בוצע”

• כרטיס חלקיות מרכזי

  • כותרת: “חלקית בוצע: נדרש השלמה”

  • מה הושלם: “___”

  • מה לא הושלם: “___”

  • סיבה כללית: “נדרש אישור נוסף/כשל חיבור/מידע חסר”

  • סיכון כפילות: “ניסיון חוזר עלול ליצור כפילות”

  • תיקון מומלץ: “השלם רק את ___”

  • חלופה: “העבר לטיפול ידני/תמיכה”

• בלוק “מצב אוטונומיה”: “הורדתי אוטונומיה זמנית עד השלמה”

• טיוטת הודעה ללקוח (עדכון קצר)

  • “עדכנתי חלק מהטיפול, נשאר עוד שלב קטן”

  • “אני מטפל/ת בזה עכשיו ואעדכן עד ___”

• יומן טיפול מפורק לתת־פעולות

  • “בוצע: ___”

  • “נעצר: ___”

  • “ממתין: ___”

• פעולות: “השלם בבטחה”, “נסה שוב עם אישור”, “העבר לתמיכה”, “עצור”

מסך לקוח — מבנה מלא (חלקיות)

• הודעת מצב תוצאתית: “חלק מהטיפול בוצע, ונשאר עוד שלב כדי לסיים”

• התחייבות זמן עדכון בלבד: “אעדכן עד ___”

• הבטחה מינימלית: “אם אצטרך משהו ממך, אכתוב בדיוק מה צריך”

• סיום לולאה: “בינתיים, יש פרט נוסף שיכול לעזור לי לסיים מהר יותר?”

מסך מנהל — מבנה מלא (חלקיות כמערכת)

• כרטיס מדד: “חלקיות השבוע: ___”

• פילוח קצר: “לפי סוג פעולה: ___”, “לפי ערוץ: ___”

• נקודת כשל נפוצה: “השלב שבו נעצרים הכי הרבה: ___”

• הצעת שיפור: “להוסיף נקודת אישור לפני ” או “לשנות סדר צעדים ל”

• דוגמה אחת מרוכזת: “מה בוצע/מה לא/איך הושלם” כדי להבין בלי לצלול

ספריית קומפוננטים סופית למערכת סוכנית: איך נותנים שמות, וריאנטים וחוקי שימוש כדי שלא תיווצר “ספרייה כפולה”

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

• שמות קומפוננטים לפי תפקיד: הצעה, חריגה, הקפאה, חלקיות, יומן, טיוטה

• וריאנטים לפי מצב: רגיל, ממתין לאישור, נעצר, הושלם, שמרני, חלקי

• מבנה קבוע בכל כרטיס: פעולה → סטטוס → השלכה → שליטה → הסבר

• חובה בכל רכיב החלטה: השלכה + דרך עצירה

• קיפול לראיות/מקורות כברירת מחדל, פתיחה לפי צורך

• מילון ניסוחים אחיד לכל וריאנט

• “אסור” מוגדר: לא מציגים פעולה בלי השלכה, לא מבצעים בלי בלם

---

כרטיס הצעת סוכן: מבנה, וריאנטים וניסוחים קבועים שמאפשרים לאשר מתוך הבנה ולא מתוך לחץ

כרטיס הצעת סוכן הוא הלב של Agentic UI, כי כאן מתקבלת החלטה שמייצרת תוצאה בעולם. לכן הכרטיס חייב להיות “כרטיס החלטה” ולא “כרטיס הסבר”, כלומר הוא מתחיל בפעולה ולא בפרטים. בשורה השנייה הכרטיס חייב להציג סטטוס קצר וקבוע, כדי שהמשתמש יבין אם זה כבר בוצע או עדיין מחכה לאישור. לאחר מכן חייבת להגיע השלכה אחת גדולה וברורה, כי בלי השלכה המשתמש מאשר על אוטומט. רק אחרי זה מגיע “למה” בשורה אחת, כי הסבר ארוך מייצר תירוץ ולא שקיפות. הכרטיס חייב לכלול שליטה מינימלית וברורה: אשר, ערוך, עצור, כדי שהמשתמש לא יחפש מה לעשות ברגע קריטי. אם יש סיכון, הוא מופיע כתגית קצרה ליד הסטטוס ולא כטקסט ארוך, כדי לא להפוך הכול לדרמטי. ראיות ומקורות מופיעים בקיפול עם כותרת קצרה, כדי שמי שצריך יפתח ומי שלא—לא יטבע. בנוסף, הכרטיס צריך לכלול “מה קורה אם לא מגיבים”, כי הרבה תהליכים נתקעים בגלל אי־תגובה ולא בגלל החלטה. ולבסוף, הכרטיס חייב להיות עקבי בין נציג ומנהל: אותו מבנה, רק רמת פירוט שונה, כדי שהמערכת תרגיש אותו דבר בכל מקום.

• אזורי כרטיס קבועים: פעולה, סטטוס, השלכה, שליטה, סיבה, ראיות

• שליטה מינימלית: אשר / ערוך / עצור

• תגית סיכון קצרה כשצריך, בלי נאומים

• ראיות בקיפול, שתי ראיות כברירת מחדל

• שורת אי־תגובה כדי למנוע תקיעות

• אותו מבנה לנציג ולמנהל, פירוט משתנה

וריאנטים של כרטיס הצעה — שמות ותוכן קבוע

• ממתין לאישור

  • סטטוס קבוע: “ממתין לאישור לפני ביצוע”

  • שורת אי־תגובה: “ללא תגובה → נשאר בהמתנה”

• אושר (לפני ביצוע)

  • סטטוס קבוע: “אושר, מוכן לביצוע”

  • שליטה: “התחל ביצוע”, “עצור”

• הושלם

  • סטטוס קבוע: “הושלם”

  • שליטה: “צפה ביומן”, “פתח המשך טיפול”

• נעצר

  • סטטוס קבוע: “נעצר: נדרש ___”

  • שליטה: “השלים ___”, “העבר למנהל”, “בטל הצעה”

---

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

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

• חריגה: גבול/הצעה/פער + תיקון מומלץ + חלופה אחת

• הקפאה: מה נעצר/מה מותר + צעד הבא אחד + handoff

• חלקיות: בוצע/לא בוצע + סיכון כפילות + השלמה בטוחה

• בלם קבוע בכל רכיב סיכון

• רכיב סיכון קודם ויזואלית לכפתורי ביצוע

• ניסוחים ניטרליים ומקצועיים

• מעבר למצב שמרני והחזרה ממנו כתהליך ברור

כרטיס חריגה — וריאנטים קבועים

• חריגה תקציבית: “הצעה ___ | גבול ___ | פער ___”

• חריגה מדיניות: “ההצעה מתנגשת עם כלל ___”

• חריגה זמן: “זמן טיפול חורג מהגבול ___”

• חריגה הרשאות: “נדרש אישור לתפקיד/הרשאה ___”

כרטיס הקפאה — וריאנטים קבועים

• שמרני פעיל: “נעצר לפני פעולות רגישות”

• אימות נדרש: “נדרש אימות לפני המשך”

• העברה למנהל: “נדרש שיקול מנהל”

כרטיס חלקיות — וריאנטים קבועים

• חלקי בוצע: “חלק מהצעדים הושלמו”

• ממתין להשלמה: “ממתין ל___”

• הושלם לאחר תיקון: “הושלם לאחר השלמה בטוחה”

---

רכיבי שפה ושקיפות: טיוטת הודעה, ראיות ויומן שמחזיקים אמון גם כשאין פתרון מיידי

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

• טיוטה קצרה: הכרה → פעולה → זמן עדכון/צעד הבא

• כפתורי שיפור לטיוטה: קצר, שפר טון, הסר התחייבות, הוסף זמן עדכון

• ראיות בקיפול, שתי ראיות כברירת מחדל

• יומן תמיד נוכח, אירועים קצרים וסריקים

• היומן מתעד שינוי יעד/גבולות/מצב שמרני

• הפרדה בין מה שמציגים ללקוח לבין מה שמציגים לנציג

• “מה עכשיו” בסוף הודעות כדי לסגור לולאה

טיוטת הודעה — תבניות קבועות

• תבנית רגילה

  • “הבנתי ש___.”

  • “אני בודק/ת את ___ ומטפל/ת בזה עכשיו.”

  • “אעדכן עד ___.”

• תבנית כשנדרש אישור

  • “אני מטפל/ת בזה עכשיו.”

  • “כדי להתקדם, אני ממתין/ה לאישור קצר.”

  • “אעדכן עד ___.”

• תבנית כשחסר מידע

  • “כדי להמשיך, חסר לי רק ___.”

  • “ברגע שאקבל אותו אמשיך מיד.”

רכיב ראיות — מבנה קבוע

• כותרת קיפול: “על מה זה מבוסס”

• שני פריטים: “”, “”

• שורת אזהרה אם יש אי־ודאות: “חסר מידע: ___”

יומן — שורות קבועות

• “טריגר: ___”

• “נאסף: ___”

• “הוצעה פעולה: ___”

• “נדרש אישור: ___”

• “בוצע: ___”

• “תוצאה: ___”

• “שינוי: יעד/גבול/מצב ___”

---

סרגל שליטה ושומרים: איך מעצבים אשר/ערוך/עצור/העבר כך שהפעולה הבטוחה תמיד תהיה הכי פשוטה

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

• פעולה ראשית אחת בלבד בכל מצב

• “אשר” מופיע רק כשיש השלכה ברורה מעליו

• “עצור” נוכח תמיד בביצוע/ברקע

• “ערוך” לא עוקף גבולות, אלא מציע תיקון בתוך כללים

• “העבר למנהל” רק בסיכון גבוה מוגדר

• מנגנון אי־תגובה אחיד למניעת תקיעות

• סימון מצב שמרני בסרגל כדי להסביר צמצום פעולות

• עקביות סדר כפתורים בכל המסכים

עמוד ספרייה אחד לתיק עבודות: “Agentic UI Kit” שמראה מערכת שלמה במבט אחד

עמוד ספרייה יחיד הוא טריק מקצועי שמעסיקים אוהבים, כי הוא מוכיח שאתה יודע לחשוב בסקייל ולא רק לבנות מסכים. המטרה שלו היא לרכז את כל רכיבי הליבה על עמוד אחד מסודר, כך שאפשר להבין את המערכת בלי לקרוא הרבה. בעיצוב סוכני, עמוד כזה חשוב במיוחד כי הוא מראה עקביות בין מצבים: אותו כרטיס הצעה מופיע בממתין לאישור, באושר, בהושלם ובנעצר, בלי להמציא UI מחדש. בנוסף, הוא מראה שהרכיבים המסוכנים מגיעים עם תיקון ובלם מובנה, ולא רק עם אזהרה. עמוד כזה גם מציג את מילון הסטטוסים והניסוחים, כי זה החיבור בין שפה לבין פעולה. הוא מציג את סרגל השליטה הקבוע, כדי להוכיח שהכפתורים לא משתנים כל מסך מחדש. והוא מציג דוגמת יומן קצרה כדי להראות שחזור ואחריות. חשוב לשמור על מינימום טקסט: תפקיד אחד לכל רכיב, וריאנטים, ושורת “מתי להשתמש” שמונעת שימוש לא נכון. כדאי גם להראות “דוגמת שימוש” אחת לכל רכיב, מתוך ה-Flow הראשי, כדי שהעמוד לא יהיה תיאורטי. ולבסוף, העמוד צריך להיראות כמו כלי עבודה אמיתי: נקי, ריווח נכון, וטיפוגרפיה שמזכירה מוצר, לא מצגת.

• עמוד אחד שמרכז קומפוננטים, וריאנטים, סטטוסים, ושליטה

• מינימום טקסט: תפקיד, וריאנטים, מתי להשתמש, דוגמה קצרה

• הצגה עקבית של מצבי סיכון עם תיקון ובלם

• מילון ניסוחים כחלק מהספרייה

• דוגמת יומן שמוכיחה שחזור

• סרגל שליטה קבוע שמוכיח בטיחות ושגרה

---

מבנה העמוד: איך לסדר את הכול כדי שזה יהיה קריא ומקצועי

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

• פס סטטוסים עליון

• גריד “כרטיסי החלטה” עם וריאנטים

• גריד “כרטיסי סיכון” עם וריאנטים

• גריד “שפה ושקיפות”

• סרגל שליטה מושווה בין מצבים

• אחידות טיפוגרפית ומבנית בכל רכיב

• סימון “מתי להשתמש” לכל רכיב

---

פס סטטוסים עליון: שמות קבועים שמונעים בלבול בין צוותים

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

• ממתין לאישור — “צריך החלטה לפני פעולה”

• אושר — “מוכן לביצוע”

• הושלם — “הפעולה בוצעה”

• נעצר — “חסר מידע/אימות/סיכון”

• חריגה — “יצא מגבול, צריך תיקון”

• חלקית בוצע — “חלק הושלם, חלק לא”

• מצב שמרני פעיל — “פעולות רגישות נעצרות”

---

אזור כרטיסי החלטה: ארבעת הווריאנטים של כרטיס הצעה (כמו שמעסיק רוצה לראות)

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

• ממתין לאישור: אשר / ערוך / עצור

• אושר: התחל ביצוע / עצור

• הושלם: צפה ביומן / פתח המשך

• נעצר: השלם ___ / העבר למנהל / עצור

תבנית טקסט דמה לכרטיס החלטה (להדבקה בכל וריאנט)

• “מציע: ___”

• “סטטוס: ___”

• “השפעה: ___”

• “כי ___”

• “מבוסס על: ___, ___” (בקיפול)

---

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

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

• חריגה: פער + תיקון מומלץ + חלופה

• הקפאה: נעצר/מותר + צעד הבא

• חלקיות: בוצע/לא בוצע + סיכון כפילות

תבניות טקסט דמה (קצרות) לכרטיסי סיכון

• חריגה

  • “נעצר לפני ביצוע”

  • “הצעה: ___ | גבול: ___ | פער: ___”

  • “תיקון מומלץ: ___”

  • “חלופה: ___”

• הקפאה

  • “מצב שמרני פעיל”

  • “נעצר: ___”

  • “מותר: ___”

  • “צעד הבא: ___”

• חלקיות

  • “חלקית בוצע”

  • “בוצע: ___”

  • “לא בוצע: ___”

  • “השלם בבטחה: ___”

---

אזור שפה ושקיפות: טיוטת הודעה, ראיות, ודוגמת יומן שמראים שאתה מעצב אמון

כאן אתה מציג שהמערכת לא רק מחליטה אלא גם מדברת ומסבירה. טיוטת הודעה מוצגת בתוך רכיב עם שלושה כפתורי שיפור: קצר, שפר טון, הסר התחייבות, כי זה מראה כלי עבודה ולא טקסט חופשי. ליד זה אתה מציג רכיב “על מה זה מבוסס” בקיפול, עם שתי ראיות דמה, כדי להראות מינון והעמקה לפי צורך. מתחת או ליד, אתה מציג דוגמת יומן קצרה של 6–7 אירועים שמסבירה טיפול מתחילתו עד סגירה, כי זה ההוכחה החזקה ביותר לאחריות. אתה מקפיד שהיומן כולל גם שינוי מצב: חריגה או מצב שמרני, כדי להראות שהיומן משקף מצבים ולא רק פעולות. אם אתה רוצה להוסיף שכבת מקצועיות, אתה מציג גם “שורת אי־ודאות” ברכיב הראיות, שמופיעה רק כשחסר מידע, כדי להראות שאתה לא מסתיר. כל האזור הזה צריך להיות “שקט” מבחינה ויזואלית, כי תפקידו להעניק יציבות ולא דרמה.

• טיוטת הודעה: הכרה + פעולה + זמן עדכון

• כפתורי שיפור: קצר / שפר טון / הסר התחייבות

• ראיות בקיפול: שתי ראיות בלבד כברירת מחדל

• יומן קצר: טריגר → הצעה → אישור → ביצוע → תוצאה

• שורת אי־ודאות כשחסר מידע

דוגמת יומן דמה קצרה (להדבקה בעמוד)

• “טריגר: פנייה חדשה”

• “נאסף: פרטי הזמנה + היסטוריית פניות”

• “הוצעה פעולה: פתרון ___”

• “נדרש אישור: ___”

• “בוצע: ___”

• “תוצאה: נסגר”

• “שינוי: עודכן גבול/מדיניות ___” (אופציונלי)

---

סרגל שליטה מושווה: שלושה מצבים שמציגים בטיחות בבחירת כפתורים

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

• ממתין לאישור: “אשר” + “ערוך” + “עצור”

• חריגה: “עדכן לפתרון בטוח” + “העבר למנהל” + “עצור”

• מצב שמרני: “שלח אימות” + “העבר למנהל” + “עצור”

---

תיאור קצר מתחת לעמוד (כמו כיתוב בתיק עבודות) שמסביר מה המעסיק רואה

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

• “הספרייה הזו נבנתה סביב עיקרון: השלכה לפני אישור.”

• “כל כרטיס עוקב אחר מבנה קבוע שמקטין טעויות תחת לחץ.”

• “רכיבי סיכון כוללים תמיד תיקון ובלם מובנה.”

• “יומן טיפול הוא רכיב חובה לשחזור ואחריות.”

פיץ’ של 90 שניות לראיון: איך להסביר את הפרויקט כך שמבינים שאתה מעצב מערכות ולא רק מסכים

ב-90 שניות אתה לא מוכר מסכים, אתה מוכר שיקול דעת. אתה מתחיל בכאב: שירות לקוחות נתקע כי יש עומס, והאוטומציה הקלאסית נכשלת ברגע שיש כסף, פרטיות או כעס. אחר כך אתה מציג את הפתרון: סוכן שמטפל בפניות סיכון נמוך ומכין החלטות לפניות מורכבות, עם שקיפות קצרה ובלמים. ואז אתה אומר את העיקרון המוביל שלך: “השלכה לפני אישור” — המשתמש תמיד רואה מה יקרה לפני שהוא מאשר. אחר כך אתה מדגיש את שלושת רכיבי הבטיחות: חריגה (פער + תיקון), מצב שמרני (מה נעצר/מה מותר), וחלקיות (בוצע/לא בוצע + מניעת כפילות). אתה מוסיף את שכבת האמון: יומן החלטות שמאפשר שחזור ומראה מה נעשה ומדוע. ואז אתה מציין איך זה סקייל: אותה ספריית קומפוננטים מופיעה לנציג ולמנהל, עם וריאנטים לפי מצב, ולא מסכים שנבנו ידנית. לסיום אתה זורק שני מדדים: זמן להבנת מצב ואיכות אישור, כדי להראות שאתה חושב על הצלחה אמיתית. ואתה מסיים במשפט שקט: “המטרה לא הייתה להיות חכם, אלא להיות בטוח ושימושי תחת לחץ.”

• כאב: עומס + סיכון + כעס

• פתרון: סוכן לפניות סיכון נמוך + הכנת החלטות למורכבות

• עיקרון: השלכה לפני אישור

• בטיחות: חריגה, שמרני, חלקיות

• אמון: יומן החלטות לשחזור

• סקייל: ספריית קומפוננטים עם וריאנטים

• מדדים: זמן להבנת מצב, איכות אישור

טקסט מוכן לפיץ’ (דיבור טבעי)
“בניתי מערכת עיצוב סוכנית לשירות לקוחות, כי אוטומציה רגילה נשברת בדיוק איפה שהאמון קריטי — כסף, פרטיות ולקוחות כועסים. הסוכן מטפל בפניות סיכון נמוך ומכין הצעות לפניות מורכבות, אבל העיקרון המוביל שלי היה ‘השלכה לפני אישור’: בכל נקודת החלטה הנציג רואה מה יקרה לפני שהוא מאשר. כדי לשמור על בטיחות, בניתי שלושה רכיבי סיכון קבועים: כרטיס חריגה שמציג פער ונותן תיקון, מצב שמרני שמציג מה נעצר ומה מותר, וכרטיס חלקיות שמונע כפילות כשהביצוע לא הושלם. הכול מתועד ביומן החלטות כדי שאפשר לשחזר וללמוד. מבחינת סקייל, זו ספרייה של קומפוננטים עם וריאנטים לפי סטטוס שמופיעה באופן עקבי במסכי נציג ומנהל. בדקתי את זה דרך מדדים כמו זמן להבנת מצב ואיכות אישור, והמטרה הייתה שהמערכת תהיה בטוחה ושימושית תחת לחץ — לא רק ‘חכמה’.”

---

שאלות שמעסיקים שואלים על Agentic Design: תשובות קצרות שמציגות עומק בלי להסתבך

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

• תשובה קצרה + דוגמה מהפרויקט + עיקרון אחד

איך החלטת מתי הסוכן פועל לבד ומתי צריך אישור?
“חילקתי לפי סיכון: כסף, פרטיות ושינוי בלתי הפיך תמיד דורשים אישור. בפניות סיכון נמוך הסוכן מציע פתרון, אבל תמיד מציג השלכה לפני ‘אשר’. כשיש חריגה או חוסר מידע הוא נעצר ומציע תיקון או שאלה אחת.”

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

מה עשית כשאין מספיק מידע?
“הסוכן לא מנחש. הוא עובר למצב ‘איסוף מידע’ ושואל שאלה אחת בכל פעם עם הסבר קצר למה זה נחוץ. לנציג יש בלוק ‘מה חסר’ שמונע שאלות כפולות.”

איך מטפלים בכשל חלקי?
“בניתי כרטיס חלקיות שמפרק ‘בוצע/לא בוצע’ ומדגיש סיכון כפילות. במצב כזה האוטונומיה יורדת זמנית כדי שלא יקרה ניסיון חוזר לא מבוקר, וכל תת־פעולה נרשמת ביומן.”

איך שומרים על אמון מול לקוח כועס?
“מסך לקוח מתחיל בהכרה, אחר כך פעולה, ואז זמן עדכון. לנציג יש כפתורי ‘שפר טון’ ו‘הסר התחייבות’ כדי למנוע ניסוח מסוכן תחת לחץ.”

מה זה ‘מצב שמרני’ אצלך ולמה צריך אותו?
“זה מצב מערכת שמגביל פעולות רגישות ומכריח אימות/העברה. הוא מסומן קבוע בכל מסך, ומציג ‘מה נעצר/מה מותר’ כדי שלא יהיה פחד מהתנהגות נסתרת.”

איך המערכת לומדת ומשתפרת?
“דרך יומן ושכבת ניהול: מנהל רואה חריגות ותדירות, יכול לכייל גבולות, ולהריץ סימולציה. בנוסף, כשמזהים חזרתיות של חסר מידע או חריגות, משנים זרימה או ניסוח.”

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

מה היה הטרייד־אוף הכי גדול?
“בחרתי להסתיר פרטי מדיניות מהלקוח כדי למנוע ויכוחים, אבל להשאיר שקיפות מלאה לנציג ולמנהל. זה שומר על אמון לקוח בלי לאבד אחריות פנימית.”

---

שאלות המשך שאתה יכול לשאול את המראיין: להיראות בוגר, לא מתגונן

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

• “מה אצלכם נחשב ‘פעולה בלתי הפיכה’ שמחייבת אישור?”

• “איך אתם מגדירים גבולות תקציב ואיפה הם מנוהלים היום?”

• “מי אחראי אצלכם על שפה ומיקרו־קופי — מוצר, תמיכה, משפטי?”

• “איפה אתם רואים הכי הרבה חלקיות או תקיעות בתהליכים כיום?”

• “איך אתם מודדים אמון: פחות תלונות, פחות תיקונים, או יותר סגירה עצמאית?”

---

תרגיל בית אפשרי בראיונות: איך לבנות תשובה מהירה אם יתנו לך מסך אחד לעצב

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

• פעולה → סטטוס → השלכה → שליטה → הסבר

• בלם תמיד

• ראיות בקיפול

• אי־תגובה מוגדרת

• כסף/פרטיות → עצירה ואישור

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

כדי להפוך את כל מה שבנינו לתיק עבודות שמרגיש “עבודה אמיתית”, צריך לנהל את ההצגה כמו מוצר: מעט עמודים, הרבה בהירות, ותיעוד של החלטות. המעסיק לא צריך לראות 40 מסכים; הוא צריך להבין שאתה שולט במצבים, בבטיחות, ובשפה. לכן אתה בונה פרויקט עם מבנה קבוע של עמודים: Flow אחד, ספרייה אחת, ושלושה מצבי קצה עמוקים. בכל עמוד אתה מציג צילום־מסך אחד מרכזי, ומתחתיו 3–5 נקודות שמסבירות “למה זה ככה” בשפה פשוטה. אתה מצלם מסכים עם תוכן ריאלי אבל אנונימי, כדי שזה ייראה כמו מוצר ולא כמו טמפלט. אתה שומר על עקביות: אותם כרטיסים, אותם סטטוסים, ואותו סדר כפתורים בכל תמונה, כדי שהצופה יבין דפוס. בנוסף, אתה דואג להראות יומן לפחות פעמיים, כי זה מאפיין שמעסיקים זוכרים. ולבסוף, אתה בוחר “מסגרת סיפור” אחת: שירות לקוחות תחת לחץ, ומחזיק אותה לכל אורך התיק, כדי לא להתפזר.

• פחות עמודים, יותר עומק

• צילום אחד מרכזי לעמוד + הסבר קצר

• Flow + ספרייה + 3 מצבי קצה = שלד מנצח

• תוכן ריאלי ואנונימי

• יומן מופיע לפחות פעמיים

• סיפור אחד עקבי מתחילתו עד סופו

---

מבנה מומלץ לפרויקט: 10 עמודים שמכסים הכול בלי להתיש

הנה מבנה שמחזיק תיק ברמה גבוהה, בלי להאריך סתם. כל עמוד הוא “מסך אחד + מסר אחד”. זה מאפשר למראיין לסרוק מהר, ואז לשאול אותך שאלות עומק. אתה יכול להציג את זה כעמודי תמונות באתר, או כ-PDF נקי. המבנה הבא הוא מספיק עמוק כדי להראות Agentic Design אמיתי, ועדיין קצר מספיק כדי שלא יאבדו אותך.

• עמוד 1: הבעיה והקשר

• עמוד 2: העיקרון המוביל

• עמוד 3: Flow ראשי

• עמוד 4: Agentic UI Kit (עמוד הספרייה)

• עמוד 5: מסך נציג — מצב רגיל (ממתין לאישור)

• עמוד 6: מסך נציג — חריגה תקציבית

• עמוד 7: מסך נציג — מצב שמרני/הקפאה

• עמוד 8: מסך נציג — חלקיות ביצוע

• עמוד 9: מסך לקוח + מסך מנהל (השוואה קצרה)

• עמוד 10: בדיקות, מדדים, ומה השתפר

---

מה להראות בכל עמוד: “צ’ק־ליסט צילום” כדי שלא תפספס את הדברים שמעסיקים מחפשים

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

• תן לכותרות להיות קצרות, כמו כותרות מוצר, לא כמו מאמר

עמוד 1 — הבעיה והקשר

• צילום: מסך שמציג עומס פניות/תור טיפול או דשבורד בסיסי

• חייב להופיע: דוגמה לפנייה “רגילה” מול פנייה “מסוכנת”

• כותרת מומלצת: “אוטומציה נשברת כשיש כסף ופרטיות”

עמוד 2 — העיקרון המוביל

• צילום: כרטיס הצעה עם השלכה מודגשת

• חייב להופיע: השלכה לפני כפתור “אשר”

• כותרת מומלצת: “השלכה לפני אישור”

עמוד 3 — Flow ראשי

• צילום: תרשים זרימה אחד נקי עם 2 מסלולים (נמוך/גבוה)

• חייב להופיע: נקודות עצירה אחידות (חריגה/חסר/חלקיות/שינוי יעד)

• כותרת מומלצת: “שני מסלולים: אוטונומיה מול שמרנות”

עמוד 4 — Agentic UI Kit

• צילום: עמוד ספרייה אחד (סטטוסים + כרטיסים + יומן + סרגל שליטה)

• חייב להופיע: וריאנטים של כרטיס הצעה + כרטיס חריגה/הקפאה/חלקיות

• כותרת מומלצת: “ספרייה שמחזיקה מצבים”

עמוד 5 — מסך נציג (רגיל)

• צילום: קונסולת נציג עם כרטיס הצעה ממתין לאישור + טיוטת הודעה

• חייב להופיע: ראיות בקיפול + כפתור “עצור” זמין

• כותרת מומלצת: “החלטה מהירה בלי חותמת גומי”

עמוד 6 — מסך נציג (חריגה תקציבית)

• צילום: כרטיס חריגה עם פער ברור + תיקון מומלץ

• חייב להופיע: הפעולה הראשית היא “עדכן לפתרון בטוח”

• כותרת מומלצת: “חריגה = תיקון, לא פאניקה”

עמוד 7 — מסך נציג (מצב שמרני)

• צילום: תגית “מצב שמרני פעיל” + כרטיס הקפאה + בקשת אימות

• חייב להופיע: מה נעצר/מה מותר + handoff למנהל

• כותרת מומלצת: “שמרני ברור יותר מבאג”

עמוד 8 — מסך נציג (חלקיות)

• צילום: כרטיס חלקיות עם בוצע/לא בוצע + סיכון כפילות

• חייב להופיע: הורדת אוטונומיה זמנית + יומן מפורק

• כותרת מומלצת: “שקיפות בכשל חלקי”

עמוד 9 — לקוח מול מנהל

• צילום: שני מסכים צד־לצד: לקוח (סטטוס וזמן עדכון) ומנהל (חריגות וכללים)

• חייב להופיע: הפרדת מידע לפי פרסונה

• כותרת מומלצת: “אותה מערכת, שלוש רמות שקיפות”

עמוד 10 — בדיקות ומדדים

• צילום: טבלה/כרטיס מדדים + “לפני/אחרי” של ניסוח או כרטיס

• חייב להופיע: זמן להבנת מצב, איכות אישור, שיעור תיקונים

• כותרת מומלצת: “הוכחה: פחות טעויות תחת לחץ”

---

כותרות קצרות לכל תמונה: טקסט מוכן שמרגיש כמו מוצר ולא כמו הרצאה

כותרות קצרות מעל תמונות הן דרך להיראות בוגר. הן צריכות להסביר “מה רואים” ו“למה זה חשוב” במילה אחת. אל תכתוב פסקאות; תן לכותרות לעבוד.

• “השלכה לפני אישור”

• “חריגה מציעה תיקון”

• “שמרני מצמצם נזק”

• “חלקיות מונעת כפילות”

• “יומן מאפשר שחזור”

• “שאלה אחת בכל פעם”

• “אותה שפה בכל מסך”

• “הדרך הבטוחה היא הקלה”

---

איך לכתוב את הטקסט שמלווה את התמונות: 3–5 נקודות בלבד, בלי משפטים ארוכים

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

• “השלכה מופיעה לפני פעולת אישור כדי למנוע אישור עיוור.”

• “חריגה מגדירה פער ומציעה תיקון במקום להעמיס אפשרויות.”

• “מצב שמרני מסומן קבוע כדי להסביר שינוי התנהגות.”

• “חלקיות מפרקת תת־פעולות כדי למנוע כפילות.”

• “יומן מתעד טריגר→הצעה→אישור→ביצוע→תוצאה לשחזור.”

---

אילו “פרטים קטנים” עושים רושם ענק על מעסיקים בפרויקט סוכני

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

• אי־תגובה מתוכננת

• בלם נגיש

• זמן עדכון ללקוח

• הורדת אוטונומיה זמנית

• שאלה אחת בכל פעם

• תיקון מומלץ אחד

• מסלול יציאה ממצב שמרני

תבנית כתיבה מוכנה ל-Case Study: כותרות פרקים + פתיחות קצרות + משפטי סיום לכל פרק

הנה מבנה Case Study שמוכן להדבקה באתר שלך, כתוב כך שיישמע כמו עבודה אמיתית על מוצר סוכני. כל פרק מתחיל בפתיחה קצרה (8–10 משפטים), ואז שורות קצרות שמחדדות מה הוכחת בפרק. אין כאן קישורים, אין מספור פסקאות, ואין חזרות על אותן פסקאות. אתה יכול להוסיף תמונות בין הפרקים לפי רשימת הצילומים שכבר בנינו. התבנית מכוונת לשפה של מעסיקים: סיכון, שליטה, שקיפות, מדדים, ושגרות עבודה.

---

רקע: למה מערכות AI שמקבלות החלטות דורשות ממשק אחר

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

• עיצוב סוכני הוא עיצוב של אחריות, לא רק של UI

• אמון נבנה דרך שקיפות קצרה ושליטה

• הבעיה האמיתית היא סיכון תחת לחץ, לא חוסר מידע בלבד

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

---

העיקרון המוביל: “השלכה לפני אישור”

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

• השלכה היא שדה חובה לפני פעולה

• כפתור ראשי משתנה לפי סיכון, לא לפי טעם

• העיקרון מתבטא גם בשפה, לא רק בפריסה

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

---

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

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

• צומת אחד ברור: סיכון נמוך/גבוה

• נקודות עצירה אחידות שחוזרות בכל מקום

• לקוח רואה טיפול וזמן עדכון, לא מדיניות פנימית

• מנהל רואה תדירות חריגות וכללים לכיול

---

קונסולת נציג: ממשק החלטה שמכבד עומס ומונע טעויות

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

• סריקה מהירה: תקציר → הצעה → שליטה

• ראיות בקיפול, מדיניות קצרה וזמינה

• טיוטות עם פעולות עריכה בטוחות

• בלם נוכח תמיד במצבי ביצוע

• יומן תמיד נוכח לשחזור

---

מצב קצה: חריגה תקציבית שמתרגמת בעיה לתיקון בטוח

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

• פער מדיד: הצעה/גבול/פער

• תיקון מומלץ אחד + חלופה אחת בלבד

• פעולה ראשית בטוחה במקום “אשר”

• לקוח מקבל סטטוס וזמן עדכון

• תיעוד מלא ביומן + תדירות למנהל

---

מצב קצה: מצב שמרני והקפאה שמסבירים שינוי התנהגות

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

• סימון קבוע: מצב שמרני פעיל

• “מה נעצר / מה מותר” במקום עמימות

• הודעת לקוח ניטרלית ומכבדת

• צעד הבא אחד, לא רשימת אפשרויות

• תנאי יציאה מהמצב כדי לא להיתקע

---

מצב קצה: חלקיות ביצוע שמייצרת שקיפות ומונעת כפילות

חלקיות ביצוע היא תרחיש שבו אמון נבחן, כי המשתמש מרגיש מיד אם המערכת מטשטשת. לכן המסך מצהיר בצורה ברורה שחלק מהפעולות הושלמו וחלק לא, בלי ניסוחים מעורפלים. הנציג מקבל פירוק קצר של “בוצע/לא בוצע” יחד עם סיכון כפילות, כדי שלא ינסה שוב פעולה שכבר רצה. במצב כזה האוטונומיה יורדת זמנית עד להשלמה, כדי למנוע ניסיונות חוזרים לא מבוקרים. המערכת מציעה תיקון מומלץ אחד שמכסה את רוב המקרים, ועוד חלופה אחת של העברה לטיפול ידני, כדי למנוע עומס החלטות. הלקוח מקבל עדכון תוצאתי, לא טכני, עם זמן עדכון ברור שמונע הסלמה. ביומן, כל תת־פעולה מתועדת כאירוע נפרד, כדי לאפשר שחזור אמיתי ולא ניחוש. במסך מנהל, חלקיות מוצגת כתדירות ונקודות כשל נפוצות, כדי שאפשר יהיה לשפר סדר צעדים או נקודות אישור. העיצוב כאן מוכיח שהמערכת מסוגלת להתמודד עם מציאות לא מושלמת בלי לאבד אמון.

• הצהרה ברורה: חלקית בוצע

• פירוק תת־פעולות + סיכון כפילות לנציג

• הורדת אוטונומיה זמנית עד השלמה

• עדכון תוצאתי ללקוח + זמן עדכון

• יומן מפורט + דשבורד תדירות למנהל

---

ספריית קומפוננטים: Agentic UI Kit שמאפשר סקייל בלי לשכפל מסכים

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

• קומפוננטים לפי תפקיד, וריאנטים לפי מצב

• כרטיסי סיכון קודמים לפעולות ביצוע

• שפה כקומפוננטה עם פעולות עריכה בטוחות

• ראיות בקיפול, שתי ראיות כברירת מחדל

• יומן חובה לשחזור

• פעולה ראשית אחת משתנה לפי סיכון

• מילון סטטוסים אחיד בכל המערכת

---

בדיקות ומדדים: איך הראיתי שהעיצוב עובד תחת לחץ ולא רק נראה טוב

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

• זמן להבנת מצב

• איכות אישור (השלכה לפני אישור)

• שיעור תיקונים אחרי ביצוע

• יחס handoff לפי סיכון

• תדירות חריגות וחלקיות

• מדדי הסלמה בשיחות לקוח

---

סיכום: מה המערכת מוכיחה ומה השלב הבא

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

• עיקרון אחד שמחזיק החלטות

• מצבי קצה עם בלמים ותיקונים

• יומן לשחזור ואחריות

• ספרייה לסקייל ועקביות

• מדדים שמראים עבודה תחת לחץ

תקציר קצר לראש ה-Case Study: פסקת פתיחה שמכניסה ישר לסיפור

במוצר סוכני, ה-AI לא רק עוזר למשתמש — הוא מתחיל לפעול בשמו. הפרויקט הזה מציג איך עיצבתי ממשק למערכת שירות לקוחות שבה סוכן AI מציע החלטות, מבצע פעולות סיכון נמוך, ועוצר בצורה בטוחה כשיש כסף, פרטיות או חוסר ודאות. במקום להפוך את הנציג ל“חותמת גומי”, בניתי את הממשק סביב עיקרון אחד: השלכה לפני אישור. לאורך הזרימה יש נקודות עצירה אחידות שמתרגמות חריגה, מצב שמרני או חלקיות ביצוע לצעד הבא ברור, עם בלם נגיש ותיעוד מלא ביומן החלטות. התוצאה היא מערכת שנראית פשוטה ברגע האמת, אבל מחזיקה מצבי קצה ומאפשרת סקייל בעזרת ספריית קומפוננטים עקבית.

• סוכן שמציע ומבצע תחת גבולות ברורים

• החלטות עם השלכה לפני אישור

• עצירות בטוחות במצבי סיכון

• יומן לשחזור ואחריות

• ספרייה שמחזיקה סקייל

---

פסקת סיום חזקה (עם כותרת): סוגרת את הסיפור בצורה מקצועית

כשהמערכת “חכמה”, האחריות חייבת להיות פשוטה

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

• אמון נבנה דרך עקביות ושקיפות קצרה

• בטיחות היא חלק מהזרימה, לא תוספת

• סקייל מגיע מספרייה, לא משכפול מסכים

• “חכם” עובד רק כש“אחראי” עובד קודם

---

“מילון כותרות” לתמונות: משפטים קצרים שמחזיקים את העמוד בלי להסביר יותר מדי

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

• “השלכה לפני אישור”

• “נקודת עצירה אחידה בכל סיכון”

• “חריגה מציעה תיקון, לא תקיעה”

• “שאלה אחת בכל פעם”

• “מצב שמרני שמסביר למה הכול נעצר”

• “חלקיות מפורקת כדי למנוע כפילות”

• “בלם נגיש בכל ביצוע”

• “יומן שמאפשר שחזור”

• “אותה ספרייה בכל מסך”

• “הדרך הבטוחה היא הקלה”

---

משפטי “מיקרו־טקסט” מוכנים שאתה יכול לשתול בתוך המסכים כדי שהכול ירגיש אמיתי

כדי שהמסכים לא ייראו כמו טמפלט, הנה משפטים קצרים שאפשר לשלב כתוויות קטנות ליד רכיבים, בלי להעמיס. הם כתובים ניטרלי ומקצועי, ומתאימים ל-RTL.

• ליד כפתור אשר: “בדוק/י את ההשלכה לפני אישור”

• ליד ראיות בקיפול: “מי שצריך — פותח. מי שלא — ממשיך.”

• ליד בלם: “אפשר לעצור בכל רגע”

• ליד מצב שמרני: “פעולות רגישות נעצרות עד אימות”

• ליד חלקיות: “השלמה בטוחה מונעת כפילות”

• ליד חריגה: “נבחר תיקון בתוך גבולות”

• ליד זמן עדכון ללקוח: “עדכון הבא: ___”

---

סגירת חבילה לתיק: מה נשאר לך לעשות כדי לפרסם את זה מהר בלי להסתבך

כדי להפוך את זה ל-Publish-ready, אתה עושה שלוש פעולות קצרות: בוחר 10 צילומים לפי הצ’ק־ליסט, מחבר כל צילום לכותרת קצרה ול-3 נקודות הסבר, ואז מדביק את תקציר הפתיחה והסיום. אחרי זה אתה עושה מעבר אחד על עקביות ניסוחים: לוודא שכל סטטוס כתוב אותו דבר בכל מקום, ושכל כפתור בסרגלים מופיע באותו סדר. לבסוף, אתה מעביר “ניקוי”: לוודא שאין פרטים מזהים, שאין מספרי לקוח אמיתיים, ושאין תוכן מיותר שמסיח. זה הכול — התיק שלך ייראה כמו מוצר חי, לא כמו תרגיל.

• לבחור 10 צילומים

• לכל צילום: כותרת קצרה + 3 נקודות

• להוסיף תקציר פתיחה + סיום

• לבדוק עקביות סטטוסים וסדר כפתורים

• ניקוי פרטים מזהים ותוכן מיותר

לסיכום

כשה-AI פועל לבד, הממשק חייב להחזיר לאדם שליטה פשוטה

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

פסקת מקורות

Microsoft Research — Guidelines for human-AI interaction design (מאמר הסבר): https://www.microsoft.com/en-us/research/blog/guidelines-for-human-ai-interaction-design/
Guidelines for Human-AI Interaction (PDF מחקרי): https://www.microsoft.com/en-us/research/wp-content/uploads/2019/01/Guidelines-for-Human-AI-Interaction-camera-ready.pdf
Google PAIR — People + AI Guidebook: https://pair.withgoogle.com/guidebook/
PAIR Guidebook — User Needs + Defining Success: https://pair.withgoogle.com/chapter/user-needs/
Google Codelabs — Building Trusted AI Products with the PAIR Guidebook: https://codelabs.developers.google.com/codelabs/pair-guidebook
Nielsen Norman Group — Designing AI Products and Features: Study Guide: https://www.nngroup.com/articles/designing-ai-study-guide/
Nielsen Norman Group — Explainable AI in Chat Interfaces: https://www.nngroup.com/articles/explainable-ai/
UX Magazine — Designing for Autonomy: UX Principles for Agentic AI Systems: https://uxmag.com/articles/designing-for-autonomy-ux-principles-for-agentic-ai-systems
EY Studio+ — How agentic AI enables a new approach to user experience design: https://www.studio.ey.com/en_gl/insights/how-agentic-AI-enables-a-new-approach-to-user-experience-design