NO TRAINING NEEDED · מוצר ותהליך
המערכת שלא צריכה הדרכה — איך מזהים אותה לפני שמשלמים
אין מערכת שנמכרת כ״מסובכת״. כולן פשוטות, כולן אינטואיטיביות, וכולן נראות מצוין בהדגמה. ההבדל מתגלה שבועיים אחרי ההדרכה, כשהעובדת שלא הייתה בה צריכה לעשות משהו לבד — ומתקשרת לשאול. המאמר הזה עוסק ברגע ההוא, ובדרך לראות אותו מראש, לפני שחתמתם.
למה ״קל לשימוש״ בדף מכירה לא אומר כלום
מי שמדגים מערכת לחץ על אותם כפתורים אלף פעם. בידיים שלו כל מערכת זורמת, כי הוא לא מחפש — הוא יודע. השאלה שההדגמה עונה עליה היא ״האם אפשר לעשות את זה״, וכמעט תמיד התשובה חיובית. השאלה שחשובה לכם אחרת לגמרי: האם מי שעושה את הפעולה פעם בחודש ימצא אותה בלי לשאול.
לכן המילים ״פשוט״ ו״אינטואיטיבי״ בדף מכירה אינן מידע. הן הבטחה, וכל הספקים נותנים אותה. כדי לבדוק אותה צריך לעבור מהצד של המוכר לצד של המשתמש — ולא המשתמש המתלהב שבחר במערכת, אלא זה שנאלץ לעבוד איתה.
הדרכה היא סימפטום, לא שירות
ספקים מציגים הדרכה כחלק מהחבילה: שלושה מפגשים, סרטונים, מדריך PDF. זה נשמע כמו שירות טוב. בפועל, הדרכה ארוכה היא לרוב סימן שהידע הדרוש להפעלת המערכת לא נמצא בתוך המערכת — אלא בראש של מי שהשתתף בהדרכה.
וראשים עוזבים. העובד שהודרך יוצא לחופשה, עובר תפקיד או מתפטר, והמחליף לומד מפיו של מי שנשאר — גרסה מקוצרת, עם קיצורי דרך ועם פחדים. תוך שנה העסק משתמש בחמישית מהמערכת, ושאר היכולות שעליהן שילם נשכחות.
בעולם השימושיות יש לזה שם פשוט: זיהוי מול היזכרות. מערכת טובה מציגה לפניכם את מה שאפשר לעשות, כך שרק צריך לזהות. מערכת שדורשת הדרכה מצפה שתיזכרו — איזה תפריט, איזה קוד, באיזה סדר. אנשים עסוקים מזהים היטב וזוכרים גרוע, וזו לא חולשה שלהם אלא האופן שבו כולנו עובדים.
חמישה סימנים שאפשר לבדוק בעשרים דקות
1. הפעולה הנפוצה נמצאת במסך הראשון. מה שעושים עשרים פעם ביום — קליטת לקוח, רישום תשלום, סגירת משימה — צריך להיות גלוי מיד, בלי תפריט ובלי חיפוש. אם הפעולה היומית מסתתרת שלוש לחיצות פנימה, כל יום יתחיל בחיפוש.
2. המילים הן שלכם. ״ישות״, ״רשומה״, ״סנכרון״, ״פרופיל משתמש״ — אלה מילים של מתכנתים. בעסק שלכם יש ״לקוח״, ״תיק״, ״הזמנה״ ו״תור״. מערכת שמדברת בשפה שלכם חוסכת תרגום בכל לחיצה, ומי שלא טכנולוגי מרגיש שהיא נבנתה בשבילו ולא נגדו.
3. טעות אפשר לבטל. הפחד הגדול של משתמש מהוסס הוא לקלקל משהו. מערכת שמאפשרת לבטל פעולה, ששומרת טיוטה ושואלת ״בטוח?״ רק כשבאמת אין דרך חזרה — מזמינה לנסות. מערכת שבה כל טעות סופית מלמדת את הצוות לא לגעת.
4. המערכת אומרת מה קרה. ״נשמר״, ״נשלח ללקוח״, ״התשלום נקלט״. כשאין אישור ברור, אנשים לוחצים שוב — ואז יש שתי חשבוניות — או מתקשרים לוודא. אחד מעקרונות השימושיות הוותיקים הוא בדיוק זה: המשתמש צריך לדעת בכל רגע מה מצב המערכת.
5. מעט שדות חובה. טופס עם עשרים שדות מסומנים בכוכבית הוא הזמנה לנתונים מומצאים: אנשים ממלאים ״1111״ כדי לעבור הלאה. מה שהמערכת יכולה לנחש — תאריך, העובד המחובר, הלקוח מהמסך הקודם — היא צריכה להשלים לבד.
| מה אומרים בהדגמה | מה לבדוק בפועל |
|---|---|
| ״זה אינטואיטיבי״ | עובד שלא ראה את המערכת מבצע משימה יומית לבד |
| ״יש לנו הדרכה מלאה״ | כמה זמן לוקח לעובד חדש להתחיל לעבוד בלי הדרכה |
| ״אפשר להתאים הכול״ | מי מתאים, כמה זה עולה, ומה קורה בעדכון הבא |
| ״יש אפליקציה לנייד״ | האם הפעולה הנפוצה עובדת בנייד ביד אחת |
| ״יש תמיכה זמינה״ | כמה פעמים בשבוע צפוי שתצטרכו אותה |
הבדיקה שעושים לפני שמשלמים
זה לוקח פחות זמן מההדגמה, ומלמד הרבה יותר. בחרו שלוש משימות אמיתיות מהעסק: אחת יומית, אחת שבועית ואחת שקורה פעם בחודש, כמו דוח לרואה החשבון. בקשו מהספק גישת ניסיון, רצוי עם נתונים שדומים לשלכם.
אחר כך הושיבו מול המסך את העובד הכי פחות טכנולוגי בצוות, תנו לו את שלוש המשימות בכתב — ושתקו. לא לרמוז, לא להצביע, לא ״תנסה למעלה משמאל״. רשמו איפה הוא מהסס, איפה הוא חוזר אחורה ואיפה הוא שואל. כל היסוס כזה הוא שיחת טלפון עתידית.
לא צריך מחקר גדול. מחקר ותיק בתחום מראה שחמישה משתמשים חושפים את רוב בעיות השימושיות; בעסק קטן גם שניים או שלושה יספיקו כדי לראות דפוס. ואם הספק לא מוכן לתת לכם לנסות לפני שחותמים — גם זו תשובה.
פשוט זה לא ״בסיסי״
קל לחשוב שמערכת פשוטה היא מערכת זולה, שנבנתה בחופזה ובלי הרבה מחשבה. בפועל זה הפוך. כל כפתור שלא מופיע במסך הוא החלטה שמישהו קיבל: מה חשוב, מה יכול לחכות, ומה המערכת תעשה לבד כדי שהמשתמש לא יצטרך. קל להוסיף עוד אפשרות. קשה הרבה יותר לוותר עליה. הרחבנו על המחיר של כל תוספת במאמר על יותר פיצ׳רים ויותר בלגן.
כשבנינו אפליקציית מעקב לאב בן 70, מבחן ההצלחה היה אחד: שישתמש בה בלי להתקשר לשאול. זה הכתיב מסך אחד, כפתור גדול אחד ומילים שהוא עצמו משתמש בהן. אותו עיקרון מנחה אותנו גם במערכות לעסקים: מטרת הפשטות היא שישתמשו במערכת גם אחרי חודש, ולא שהיא תיראה צנועה.
מה לשאול את הספק
ארבע שאלות מפרידות בין הבטחה לבין מערכת. ״כמה זמן לוקח לעובד חדש להתחיל לעבוד?״ — תשובה בשעות היא סימן טוב; תשובה בימים של הדרכה פחות. ״מה קורה כשטועים?״ — בקשו לראות ביטול של פעולה. ״תראו לי את המשימה החודשית״ — לא את זו שבהדגמה. ״אפשר לשנות מילים במסך?״ — כי ״רשומה״ צריכה להפוך ל״לקוח״.
אם התשובות מגלות שהמערכת מתאימה לזרימה של העסק רק אחרי הרבה התאמות, כדאי לקרוא גם את המאמר על תבנית מוכנה מול פיתוח מותאם, ואת החשבון המלא בכמה עולה להחזיק אתר או אפליקציה. שעות הדרכה, טלפונים ועבודה כפולה הן עלות אמיתית, גם כשהן לא מופיעות בהצעת המחיר.
איך אנחנו עובדים עם זה. ב-appotto מערכת נחשבת מוצלחת כשמשתמשים בה אחרי חודש, ולא ביום שבו הושקה. לפני מסירה אנחנו יושבים עם העובד שיעבוד עליה בפועל, נותנים לו משימה אמיתית ולא מסבירים כלום. כל מקום שבו הוא נתקע מטופל אצלנו כבאג ולא כ״חוסר הדרכה״. הצעת המחיר סגורה מראש, כך שהזמן שמושקע בפשטות לא מגיע אליכם כהפתעה.
יש לכם מערכת שהצוות עוקף, או מערכת שאתם שוקלים לקנות? כתבו לנו בשתי שורות מה אמור לקרות בה ומה קורה בפועל. נגיד לכם ביושר אם הבעיה בכלי, בהתאמה או בכלל במקום אחר.
שאלות נפוצות
איך יודעים אם מערכת באמת פשוטה לפני שקונים?
לא מההדגמה. בחרו שלוש משימות אמיתיות — יומית, שבועית וחודשית — והושיבו מול גרסת ניסיון את העובד הכי פחות טכנולוגי בצוות, בלי הסבר ובלי רמזים. כל מקום שבו הוא מהסס, חוזר אחורה או שואל הוא שיחת טלפון עתידית. אם הספק לא מאפשר ניסיון לפני חתימה, גם זה מידע.
האם מערכת בלי הדרכה היא מערכת עם פחות אפשרויות?
לא בהכרח. היא מערכת שבה הפעולות הנפוצות גלויות והנדירות לא מפריעות להן. אפשר שיהיו בה הרבה יכולות, כל עוד מי שנכנס לעשות את המשימה היומית שלו לא צריך לעבור דרכן. פשטות היא החלטה על סדר עדיפויות, לא ויתור על יכולות.
מה עושים עם עובד שמתקשה בטכנולוגיה?
משתמשים בו כמבחן. עובד שמתקשה הוא המדד הטוב ביותר לשאלה אם המערכת פשוטה באמת, כי הוא לא יעקוף בעיות בכוח הרגל. אם הוא מסתדר לבד עם המשימה היומית, כולם יסתדרו. אם לא — הבעיה במערכת, ולא בו.
האם מערכת שנבנית במיוחד פשוטה יותר ממערכת מדף?
לא אוטומטית. מערכת מותאמת יכולה להיות פשוטה מאוד כי היא עושה רק את מה שהעסק צריך, בשפה שלו. היא יכולה גם להיות מסובכת אם כל בקשה נכנסת אליה. היתרון שלה הוא שאפשר לבדוק אותה עם הצוות האמיתי לפני המסירה ולתקן את מה שמכשיל.
כמה זמן סביר שייקח לעובד חדש להתחיל לעבוד במערכת?
במשימות היומיות — שעה או שעתיים, לא ימים. עובד חדש צריך להבין את העסק, לא את התוכנה. אם הספק מדבר על כמה ימי הדרכה לפני שאפשר להתחיל, סביר שהידע נמצא בהדרכה ולא במסכים, ושיאבד בכל פעם שעובד עוזב.
מקורות
- Nielsen Norman Group — עשרת עקרונות השימושיות — הרשימה הקלאסית של עקרונות לממשק שאפשר להשתמש בו בלי הסבר, ובהם הצגת מצב המערכת, דיבור בשפת המשתמש ויכולת לבטל טעות.
- Nielsen Norman Group — זיהוי מול היזכרות — מדוע ממשק שמציג את האפשרויות קל יותר מממשק שמצפה מהמשתמש לזכור אותן.
- Nielsen Norman Group — למה מספיק לבדוק עם חמישה משתמשים — הבסיס לבדיקה קטנה ומהירה עם אנשים אמיתיים לפני החלטה.
מערכת שהצוות מסתדר איתה לבד?
ספרו לנו מה העובדים שלכם עושים ביום רגיל ואיפה הם נתקעים היום. נגיד אם אפשר לפתור את זה בכלי קיים, ואם לא — תקבלו כיוון ברור והצעת מחיר סגורה מראש. ייעוץ ראשוני ללא עלות.
שלחו לנו מייל