UX למערכות פנימיות: למה ממשק גרוע עולה לעסק כסף

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

איפה ממשק גרוע עולה כסף בפועל

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

טעויות הזנה

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

זמן הכשרה

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

מעקפים באקסל ובוואטספ

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

שחיקה ותחלופה

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

חישוב קטן להמחשה

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

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

למה דווקא המערכות הפנימיות מקבלות את הממשק הגרוע ביותר

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

יש לזה עוד שלוש סיבות שחוזרות כמעט בכל מערכת שראינו.

המסכים נבנו סביב הטבלאות

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

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

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

"זה פנימי, לא צריך עיצוב"

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

שמונה עקרונות למערכת שעובדים בה כל היום

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

• זרימת משימה (Task flow) - רצף הצעדים שעובד עושה כדי להשלים פעולה שלמה, מההתחלה ועד "נשמר".
• ברירת מחדל (Default) - הערך שהמערכת ממלאת לבד לפני שהעובד נגע בשדה.
• מצבי משוב (Feedback states) - מה המסך מראה בזמן טעינה, אחרי שמירה, כשיש שגיאה וכשאין נתונים להצגה.
• כיווניות (RTL) - פריסה מימין לשמאל, כולל כל מה שנשאר משמאל לימין בתוכה: מספרים, טלפונים, כתובות מייל.
• הרשאות לפי תפקיד (Roles) - מה כל סוג משתמש רואה ומה הוא יכול לשנות.
• נגישות (Accessibility) - היכולת של כל עובד להשתמש במערכת, כולל מי שרואה פחות טוב או לא משתמש בעכבר.

1. לעצב סביב המשימה, לא סביב הטבלה

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

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

2. ברירות מחדל שחוסכות הקלדה

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

3. מקלדת קודם, עכבר אחר כך

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

4. עברית וכיווניות: הפרטים שהופכים מסך לנוח

לפרוס את המסך מימין לשמאל זה הבסיס, ורוב המערכות עוצרות שם. הפרטים שמשנים בעבודה יומיומית: מספרי טלפון, סכומים וכתובות מייל צריכים להישאר משמאל לימין בתוך הטקסט העברי, אחרת ספרות מתחלפות במקומן. עמודות מספרים בטבלה צריכות יישור אחיד. תאריכים בפורמט שמקובל בישראל (DD/MM/YYYY), לא בפורמט אמריקאי. חצים וסמלי "הבא" ו"הקודם" צריכים לפנות לכיוון הנכון. וחיפוש בעברית צריך לסלוח לוריאציות כתיב - עם או בלי יו"ד, עם או בלי גרש - כי אף נציג לא יזכור איך הלקוח נרשם בפעם הקודמת.

5. מובייל אמיתי לאנשי שטח

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

6. הרשאות שמובנות מהמסך עצמו

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

7. מצבי משוב: המערכת אומרת מה קורה

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

8. נגישות היא לא תוספת

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

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

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

קליטת הזמנה טלפונית

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

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

מסך לידים לנציג מכירות

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

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

דיווח טכנאי מהשטח

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

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

מתי לא כדאי לעצב מחדש

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

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

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

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

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

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

1. שבו שעה ליד העובד שעושה הכי הרבה הזנות. אל תעזרו ואל תסבירו. רשמו כל פעם שהוא מהסס, חוזר אחורה, או עובר לכלי אחר.
2. ספרו קליקים. לשלוש הפעולות הנפוצות ביותר, ספרו כמה לחיצות ומעברי מסך נדרשים מההתחלה ועד "נשמר". יותר מחמש לפעולה יומיומית - יש מה לקצר.
3. חפשו את המערכת המקבילה. אקסל, קבוצת וואטספ, מחברת, פתקים על המסך. כל אחד מהם הוא מסך שחסר.
4. בדקו את הטופס העמוס ביותר. כמה שדות יש בו, וכמה מהם מתמלאים בפועל ברוב הרשומות? שדות שמתמלאים לעתים רחוקות צריכים להתקפל.
5. הזינו טעות בכוונה. טלפון עם ספרה חסרה, תאריך בעבר, שדה חובה ריק. המערכת עוצרת אותה בזמן ההזנה, או שומרת ושותקת?
6. קראו את הודעות השגיאה. האם עובד חדש היה מבין מהן מה לעשות עכשיו?
7. עברו על הטופס העיקרי במקלדת בלבד. האם סדר המעבר בין השדות הוא סדר העבודה? האם אפשר לשמור בלי עכבר?
8. פתחו את המערכת בטלפון, ואם יש אנשי שטח - בטלפון שלהם, בחוץ. נסו להשלים דיווח אחד.
9. שאלו עובד שהצטרף בחודש האחרון מה הכי בלבל אותו בשבוע הראשון. הוא עוד זוכר. הוותיקים כבר לא.
10. בדקו את ההרשאות מהצד השני. היכנסו כנציג ונסו לבצע פעולה של מנהל. מתי המערכת עוצרת אתכם - לפני שהתחלתם, או אחרי שמילאתם הכל?

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

שורה תחתונה

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

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