שלב 2: ארכיטקטורת מידע (שבוע)
ארכיטקטורת מידע (IA) היא הדרך שבה מארגנים פיצ׳רים, ניווט ותוכן, כך שמשתמשים מוצאים מה שהם צריכים בלי לחשוב איפה זה נמצא.
למה זה חשוב יותר בארגון
באפליקציה צרכנית יש 10 עד 20 מסכים. במערכת ארגונית יכולים להיות 50 עד 200 מסכים, ולפעמים יותר. בלי ארכיטקטורת מידע מתוכננת, הניווט הופך למבוך: המשתמשים שומרים שלושה מסכים במועדפים ולא מגלים את השאר.
הטעויות הנפוצות
ארגון לפי מחלקות במקום לפי משימות. משתמשים חושבים בתהליכים, לא בתרשים הארגוני. "אני צריך לאשר את הזמנת הרכש הזו" לא מתיישב עם "כספים > רכש > אישורים > ממתינים".
יותר מדי פריטים בתפריט הראשי. אם בתפריט הראשי יש 12 פריטים ויותר, המשתמשים מפסיקים לקרוא אחרי ארבעה. קבצו פונקציות קשורות, וחשפו אפשרויות בהדרגה.
שמות לא עקביים. אם באזור אחד כתוב "לקוחות", באחר "מזמינים" וב-API "חשבונות", המשתמשים מאבדים אמון.
שלב 3: Wireframes ואב טיפוס (שבוע עד שבועיים)
Wireframes בסיסיים
פריסות באפור שמראות היררכיית תוכן, ניווט ותהליכי אינטראקציה. כל מסך, כל סוג משתמש, כל תרחיש מרכזי. כאן תופסים בעיות שזול לתקן: "לאן המשתמש הולך אחרי ששלח את הטופס?", או "התהליך הזה דורש שלוש לשוניות. אפשר לאחד?".
אב טיפוס לחיץ
אב טיפוס לחיץ נראה כמו המוצר האמיתי, אבל אין בו קוד. משתמשים עוברים בו תהליכים שלמים, וחושפים בעיות שמישות ש-Wireframes סטטיים מפספסים.
במערכת התביעות הדיגיטלית המלאה הראשונה של AIG ישראל, שבועות של מחקר עם סוכנים ומיישבי תביעות הובילו להחלטה מרכזית אחת. כל אחד מחמשת סוגי הביטוח (רכב, דירה, בריאות, נסיעות לחו״ל וכללי) דורש מידע אחר. לכן הטפסים מתאימים את עצמם לתביעה: תאונת רכב מציגה שדות אחרים מאשר עיכוב בטיסה. מהבריף ועד מפרט מוכן לפיתוח עברו שלושה חודשים, ורוב התביעות עברו ממוקד השירות לשירות עצמי.
ב-IBI Smart, אב הטיפוס חשף שמשתמשים צריכים לבצע עסקאות ישירות מתצוגת התיק. אף אחד לא ביקש את זה, כי אף אחד לא ראה שזו אפשרות. התובנה הזו לבדה קיצרה את ביצוע העסקה מ-7 צעדים ל-3.
שלב 4: עיצוב ויזואלי (שבוע עד שבועיים)
מערכת עיצוב, ולא אוסף מסכים
מוצר ארגוני צריך מערכת עיצוב: ספרייה של רכיבים לשימוש חוזר, עם התנהגות וסגנון מוגדרים. היא שומרת על אחידות בין יותר מ-50 מסכים ומאיצה את השינויים כשהמוצר גדל. אנחנו בנינו את מערכת העיצוב של ממשלת ישראל: מאות רכיבים נגישים שנבנו מהיסוד לכתיבה מימין לשמאל, ב-React, Angular, JavaScript נקי ו-HTML/CSS, עם ערכת Figma שמשקפת את הקוד. יותר מ-5,000 מפתחים בממשלה עובדים איתה.
ארבעה כללים שכל מסך צריך לעמוד בהם
- המשימות המרכזיות בשלושה צעדים. מפו את חמש המשימות שהמשתמשים מבצעים הכי הרבה. כל אחת מהן צריכה לקחת לכל היותר שלוש הקשות או לחיצות.
- ערך כבר במסך הראשון. מסך ריק או Onboarding ארוך מבריחים משתמשים. מלאו מראש תוכן רלוונטי, ובקשו רק את המידע שצריך כדי להראות משהו שימושי.
- תגובה תוך 100 מילישניות. לפי מגבלות זמן התגובה של Jakob Nielsen, עשירית שנייה היא הגבול שבו תגובה מרגישה מיידית. כל פעולה צריכה תגובה גלויה: כפתור שמשנה מצב, מחוון התקדמות בזמן שהנתונים נטענים.
- מורכבות שגדלה עם המשתמש. משתמשים חדשים צריכים הכוונה. משתמשים מנוסים צריכים קיצורי דרך. עקבו אחרי השימוש בפיצ׳רים וחשפו אפשרויות מתקדמות בהדרגה.
נגישות היא חובה
עמידה ב-WCAG 2.1 ברמה AA היא המינימום. כלומר יחס ניגודיות של 4.5:1 לטקסט רגיל, ניווט במקלדת בכל האינטראקציות, תאימות לקוראי מסך והודעות שגיאה ברורות. בישראל נגישות דיגיטלית היא גם חובה בחוק, לפי תקן ת״י 5568. ועיצוב נגיש הוא פשוט עיצוב טוב יותר לכולם.
שלב 5: בדיקות שמישות (שבוע)
גייסו 5 עד 7 משתמשים שמייצגים את קהל היעד. תנו להם משימות מוגדרות. צפו בהם מנסים לבצע כל משימה, בלי לעזור. תעדו היסוסים, לחיצות שגויות והצלחות מיידיות.
בניתוח הקלאסי של Jakob Nielsen משנת 2000, מחקר עם חמישה משתתפים מוצא כ-85% מבעיות השמישות. לא צריך 50 משתתפים. צריך 5 משתמשים אמיתיים, ואת המשמעת לשבת ולראות אותם מתקשים.
| מדד | מה הוא אומר לכם |
|---|
| שיעור השלמת משימות | המשתמשים מצליחים להשיג את המטרות שלהם? |
| זמן למשימה | כמה העיצוב יעיל? |
| שיעור שגיאות | איפה המשתמשים טועים? |
| System Usability Scale (SUS) | השמישות כפי שהמשתמשים חווים אותה (הציון הממוצע הוא 68) |
| דיוק הלחיצה הראשונה | האינסטינקט הראשון של המשתמש מוביל למקום הנכון? |
הטעויות שחוזרות בכל פרויקט ארגוני
מעצבים לדמו, ולא לשימוש יומיומי. המנכ״ל רואה דמו של 20 דקות. המשתמשים חיים בתוך המערכת 8 שעות ביום. עצבו בשביל 8 השעות: קיצורי מקלדת, העדפות שנשמרות ומינימום לחיצות במשימות הנפוצות.
מתייחסים למובייל כמחשבה שנייה. גם בכלים ארגוניים משתמשים בטלפון, ולהתאים את הפריסה למובייל בדיעבד עולה הרבה יותר מלתכנן אותה מההתחלה. כשעיצבנו מחדש את WeShoes, 70% מהתנועה הגיעה ממובייל, אז עיצבנו קודם לאגודל ורק אחר כך הרחבנו לדסקטופ.
מדלגים על המסירה לפיתוח. העיצוב הכי טוב שווה מעט אם המימוש שלו חלש. מפרטים, קבצים, תיעוד רכיבים ופרטי אנימציה קובעים אם המפתחים יבנו את מה שעוצב.
שאלות נפוצות
כמה עולה עיצוב UX למערכת ארגונית?
במערכת במורכבות בינונית (20 עד 40 מסכים ייחודיים), התהליך המלא מתחיל ב-90,000 ש״ח ויכול להגיע ל-250,000 ש״ח. זה בדרך כלל 15% עד 25% מתקציב הפיתוח, והחלק שהכי קשור להצלחת המוצר. את המחירים של פרויקטים שלמים תמצאו במדריך העלויות שלנו.
אפשר לדלג על המחקר אם אנחנו כבר מכירים את המשתמשים?
אתם חושבים שאתם מכירים אותם. בפועל אתם מכירים את מה שהם אומרים בפגישות. מחקר מראה מה הם עושים בפועל, וזה משהו אחר. לכל הפחות, צפו ב-3 עד 5 משתמשים מבצעים משימות אמיתיות. ההנחה "אנחנו מכירים את המשתמשים שלנו" היא ההנחה היקרה ביותר בתוכנה ארגונית.
איך שומרים על איכות העיצוב אחרי ההשקה?
עם מערכת עיצוב שמתוחזקת כמשאב משותף לצוותי העיצוב והפיתוח. פיצ׳רים חדשים נבנים מהרכיבים הקיימים. כשצריך דפוס חדש, מוסיפים אותו למערכת עם תיעוד. כך נמנעת השחיקה האיטית שבה כל מפתח מפרש את העיצוב קצת אחרת. צריכים עזרה ב-UX של המוצר שלכם? דברו איתנו.
