ממשק תשובות לפי צורך
ממשק שיחתי יכול לעזור למבקר לשאול שאלה, אך חייב להראות מאיפה הגיעה התשובה ומה הוא עושה כשאין תשובה טובה. אל תסתירו פרטי שירות בסיסיים מאחורי צ׳אט. בדקו מסלול רגיל ללא כלי שיחתי, נגישות מקלדת, אפשרות מעבר לאדם ועדכון תוכן כאשר השירות משתנה.
ממשק שיחתי יכול לסייע בבחירת מסלול, אך לפני הוספתו יש לזהות שאלה שאנשים מתקשים לפתור באמצעות ניווט ותוכן רגיל. אם אדם מחפש שעות פעילות או תהליך פנייה, עמוד ברור עשוי להיות יעיל יותר ממערכת שמבקשת ממנו להקליד שוב את השאלה. אם השירות מורכב ויש כמה תנאים, ממשק שעוזר לבחור נושא יכול להועיל בתנאי שהוא מציג מקורות, מגבלות ודרך להגיע לאדם כאשר אינו בטוח.
תכננו את התשובה הראשונה והאחרונה של המסלול. הראשונה צריכה להבהיר מה הממשק יודע לעשות ואיזה מידע אינו מבקש. האחרונה צריכה להפנות לעמוד, לפעולה או לאיש צוות בלי להציג תשובה שנוצרה אוטומטית כאישור שירות מחייב. בדקו מה קורה בשאלה שאינה מוכרת ובשגיאת הקלדה. שמרו לוגים בהתאם למדיניות פרטיות ולא יותר מן הנדרש לבדיקת איכות. תכונות חדשות של ספקים משתנות לפי אזור וחשבון; אל תבנו הבטחה עסקית על שם מוצר בלי בדיקת זמינות.
בדיקת קבלה יכולה לכלול שאלות אמיתיות שהגיעו לצוות, לאחר הסרת פרטים מזהים. השוו אם המשתמש מוצא תשובה מדויקת מהר יותר דרך חיפוש, תפריט או שיחה. חפשו גם תשובות בטוחות מדי לשאלה שהמידע באתר אינו מכסה. אם הממשק מפנה לעמוד שלא עודכן, הבעיה היא במקור המידע. מדדו השלמת משימה ושאלות שהועברו לאדם, לא רק מספר שיחות שנפתחו.
אתר שמציע תשובה ישירה צריך להציג מה מקור המידע שלה. אם הנתון מגיע מעמוד שירות, קשרו אליו או ציינו מתי עודכן. אם הוא מחושב מנתוני משתמש, הסבירו אילו נתונים שימשו ולמה. אם אין מקור אמין, תשובה חכמה לכאורה עלולה להיות מסוכנת יותר מהיעדר תשובה. תכנון ממשק כולל החלטה מתי לומר "לא ידוע" ומתי להעביר שאלה לאדם.
שכבת שיחה אינה חייבת להחליף ניווט. מי שמעדיף לעיין בתפריט, לסרוק כותרות או להשתמש בחיפוש רגיל צריך להצליח גם ללא בוט. נסו משימה זהה בשלושה מסלולים ובדקו היכן כל אחד מסייע. אם הממשק החדש חוזר על מידע שקיים אך מוסיף שלב ותלות טכנית, אולי כדאי לשפר את העמוד המקורי. יכולת חדשה אינה ערך אם אינה פותרת קושי שנמצא בשימוש.
כאשר מערכת שואלת משתמש שאלות, תכננו מה היא עושה עם התשובות. שדה שמבקש תקציב, מיקום או מצב אישי צריך סיבה ברורה, הגבלת גישה ומדיניות טיפול מתאימה. בקשו רק מידע שנחוץ לשלב הנוכחי. אפשר לתת תשובה כללית בלי פרטים אישיים ואז להציע פנייה כאשר נדרש בירור. כך הממשק נשאר שימושי גם למי שאינו מוכן למסור מידע בתחילת מסע.
מקורות, פרטיות ובדיקה
בדיקת קבלה של ממשק תשובות תכלול שאלות פשוטות, שאלות מורכבות ושאלה שאין לה תשובה באתר. בדקו אם המערכת מצטטת מקור נכון, אם היא מזהה גבול, ואם היא מחזירה משתמש לעמוד או לאיש צוות. אל תסתפקו בדוגמת הדגמה שבה כל השאלות נבחרו מראש. בקשו גם מאדם שאינו מכיר את התחום לנסח שאלה בדרכו, משום ששם מופיעים פערים בין שפה פנימית לשפה של קהל.
לכל פעולה שמערכת מציעה צריך להיות מצב ברור. אם היא ממליצה לקבוע פגישה, הציגו אם נבחר מועד או רק נפתחה בקשה. אם היא מציעה מוצר, ציינו אם מדובר במידע כללי או בהתאמה שנבדקה. אין לייחס לה סמכות מקצועית שאין לה, ואל תבטיחו שהיא פועלת בכל אזור או חשבון בגלל הכרזה של ספק חיצוני. בדקו יכולות זמינות בתנאים של האתר לפני כתיבת הבטחה בעמוד.
אחרי פרסום, תעדו טעויות בסיווג שאלות בלי לשמור פרטים מזהים יותר מן הדרוש. אם אנשים מבקשים שוב ושוב הסבר שהממשק אינו נותן, ייתכן שהתוכן חסר; אם הוא נותן תשובה לא מדויקת, תקנו מקור ומנגנון. מדידה של מספר שיחות אינה מספיקה. השוו אם משימה הושלמה ואם משתמש יודע מה לעשות כשהמערכת אינה בטוחה. זהו מדד עבודה טוב יותר מהצהרה ש"האתר הפך לחכם".
אם מערכת מציעה תשובה ממקורות רבים, בקשו ממנה להציג דרך להגיע למקור המקורי ולזהות מידע סותר. משתמש צריך לדעת אם הוא רואה נתון שמקורו בעסק עצמו, פרשנות של כלי חיצוני או טקסט שנוצר ללא בדיקה. כאשר אי אפשר לספק הבחנה כזו, עדיף להגביל את המערכת לשאלות שבהן המידע פשוט ומתוחזק. תחושת שיחה טבעית אינה ראיה לדיוק.
נוהל עדכון הוא חלק מתכנון הממשק. מי מתקן תשובה כאשר שעות פעילות משתנות, מי בודק קישור שהוסר, ומי מקבל התראה על שאלה שלא נענתה? אם האתר מתעדכן אך שכבת התשובות משתמשת בגרסה ישנה, הקורא יראה סתירה. בדיקת עשן אחרי שינוי תוכן צריכה לכלול גם שאלות שהמערכת עונה עליהן, לצד תפריט וחיפוש רגיל.
בסיכום הפרויקט הציגו גם החלטות שלא ליישם. ייתכן שלא צריך בוט לכל עמוד, שלא נכון לשאול פרטים אישיים בתחילת מסלול, או שאין די מקורות למענה אוטומטי על נושא מקצועי. החלטות אלה אינן כישלון טכנולוגי; הן מצמצמות סיכון ושומרות על מסלול שימוש ברור. בחרו פונקציה אחת שניתנת לבדיקה לפני הרחבה.
בממשק שמסכם מידע, הציגו גבול ידע. אם אין מקור עדכני לשעות פתיחה, זמינות או תנאי שירות, אל תציגו תשובה משוערת כעובדה. אפשר להפנות לעמוד הרשמי או לאדם שיבדוק. כאשר המערכת מציעה פעולה, הראו מה יתבצע לפני אישור ומה עוד דורש השלמה. שקיפות כזו חשובה יותר מהשאלה אם המשתמש הקליד משפט טבעי או לחץ על מסנן.
שאלו גם למי הממשק אינו מתאים. אדם שמשתמש במקלדת בלבד צריך דרך להגיע לכל אפשרות; אדם שאינו רוצה למסור מידע אישי צריך דרך לקבל הסבר כללי; קורא שמעדיף ניווט רגיל צריך למצוא אותו עדיין. אם שכבת שיחה מסתירה את התוכן הקיים, היא עשויה להקשות על חלק מן הקהל. בדיקת קבלה צריכה לכלול מסלולים חלופיים ותרחיש שבו התשובה האוטומטית אינה מספיקה.
שאלות מעשיות
שאלה: האם חיפוש שיחתי חייב להשתמש ב־AI? תשובה: לא. סינון נושאים, שאלות נפוצות וחיפוש באתר יכולים לפתור צורך פשוט. אם משתמשים במודל שמייצר תשובות, נדרשות בדיקות של דיוק, הצגת מקורות, טיפול בשאלה לא מוכרת וגבול מידע אישי. בחרו פתרון לפי משימה שנבדקה, ולא לפי כותרת טכנולוגית.
לרקע נוסף: בניית אתרים לעסקים: מתכנון ברור לאתר שקל להשתמש בו; W3C WAI — Writing for Web Accessibility.
