שירותי עיצוב UX/UI: היכן נשבר מסלול המשתמש
לרוב מסלול המשתמש נשבר לא בנקודת הכניסה, אלא בשלב השלישי-רביעי: האדם כבר התחיל את התרחיש, אבל מאבד את ההקשר ועוזב. הסיבה בדרך כלל אחת — הממשק תוכנן לפי מסכים, ולא לפי מסלול מקצה לקצה אל הפעולה הרצויה. לכן מחקר UX של קהל היעד מתחיל לא בקונספטים ויזואליים, אלא בניתוח של משימות אמיתיות.
מבנה הניווט של האתר נשבר בענפים ללא מוצא: עמוד בלי שלב הבא, מסנן שאחריו נשארת רשימה ריקה, פירורי לחם שמובילים לשום מקום. המשתמש לא מבין איפה הוא ולאן ללכת, וחוזר לחיפוש — ולא אלינו.
טפסים ארוכים מחסלים את התרחיש: שדות חובה שאינם נחוצים לפנייה, מסכת טלפון שמוחקת את מה שהוזן, שגיאת ולידציה שקופצת רק לאחר השליחה. כל שדה מיותר הוא שלב שבו שיעור המגיעים אל הפעולה הרצויה יורד.
קטגוריה נפרדת — מצבים לא עקביים: כפתור נראה פעיל, אבל לא עובד, רמז מבטיח דבר אחד והמערכת עושה אחר, אחרי שגיאה הטופס מאבד את הנתונים שהוזנו. המשתמש מחליט שהאתר נשבר, ועוזב בשקט — בדוחות זה "לא הגיע", בלי סיבה.
מקומות כאלה אנחנו מאתרים באמצעות מפת המסלול וניתוח של תרחישים נטושים: אנליטיקה והקלטות סשנים מראות באיזה שלב אנשים עוצרים ומה בדיוק מפריע. בהמשך — אב-טיפוס של ניווט וטפסים, בדיקה עם משתמשים, ורק אחר כך השכבה הוויזואלית. הפעולה הרצויה הופכת למדידה: שיעור המגיעים, עומק התרחיש, שיעור החזרות לשלב הקודם.
מה משתנה במוצר לאחר עיבוד מחדש של הממשק
האפקט של עיבוד מחדש של הממשק נמדד לא בסקיצות, אלא בהתנהגות של אנשים במוצר. לפני ההתחלה אנחנו קובעים ערכי בסיס: שיעור המגיעים אל הפעולה הרצויה, מספר השלבים הממוצע בתרחיש, הזמן להרכבת מסך חדש ומספר התיקונים לאחר מסירת הסקיצות לפיתוח. לאחר מכן כל שינוי נבחן מול הבסיס הזה, ולא מול העדפות טעם.
- עיצוב קונברסיה לעמוד הבית: המסך הראשון עונה על השאלה "מה אפשר לעשות כאן" לפני גלילה — שיעור המבקרים שעוזבים בלי פעולה יורד, והמעברים אל האזורים הרצויים גדלים.
- עיצוב עמוד השירותים: תרחיש הבחירה נבנה סביב השאלות האמיתיות של הלקוח, ולא סביב מבנה החברה — הזמן עד למגע משמעותי ראשון מתקצר פי כמה.
- צמצום שלבי התרחיש: מסירים שדות שאפשר לשלוף מהפרופיל או לברר מאוחר יותר; המסלול עד לפנייה קצר בשני-שלושה שלבים, והנשירה בטפסי הביניים נמוכה משמעותית.
- ספריית רכיבים אחודה: מצבי כפתורים, שדות, טבלאות וחלונות מודאליים מתוארים פעם אחת — מסך חדש נבנה מבלוקים מוכנים בשעות במקום ימים, והפערים בין האזורים נעלמים.
- מסירת סקיצות לפיתוח: ההתנהגות של אלמנטים, מצבים ריקים, שגיאות וטעינה מתוארות במפרט — מספר התיקונים לאחר הקידוד יורד, והשחרורים לא נדחים.
- יכולת בדיקה: כל תיקון בממשק מקושר למדד, ולכן רואים מה עבד ומה יש להחזיר לאחור.
כל השינויים חיים בספריית רכיבים אחת ב-Figma, מסונכרנת עם הקוד: העיצוב והקידוד לא מתפצלים בעדכון הבא של המוצר. תארו את המשימה — נחזור עם הערכה ותוכנית לעיבוד מחדש של הממשק.
שירותי עיצוב UX/UI: פורמטים של עבודה והמגבלות שלהם
בחירת הפורמט נקבעת לא לפי מספר המסכים, אלא לפי השאלה אם יש תרחישים קבועים ובסיס רכיבים לשימוש חוזר. לכן אנחנו מתחילים בביקורת ממשק: בודקים היכן מצבי התכנון סוטים מהמימוש, אילו ענפי תרחיש אינם מכוסים, ואיפה אותו אלמנט חי בארבע גרסאות עם ריווחים שונים והתנהגות שונה במסכים צרים. לפי התוצאה רואים אם יש צורך בעיבוד נקודתי של מסכים, בתכנון מאפס או במערכת שתשמור על ההסכמות בהמשך.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| עיבוד נקודתי של מסכים | המוצר עובד, התרחישים יציבים, כואב קטע מסוים | לא מבטל פערים בין אזורים: את התיקונים צריך לחזור עליהם בכל מסך דומה |
| תכנון מאפס | מוצר חדש או החלפת מודל, ארכיטקטורת המידע הישנה של האתר אינה בשימוש חוזר | לוקח יותר זמן עד התועלת הראשונה, דורש תרחישים ותפקידים מאושרים לפני תחילת הסקיצות |
| מערכת עיצוב לאפליקציית ווב | כמה צוותים או אזורים, הממשק משתנה כל הזמן | נדרש בעלים למערכת וסדר עדכון, אחרת הספרייה מתפצלת מהקוד תוך כמה איטרציות |
| תמיכה מתמשכת | שחרורים יוצאים בקביעות, יש זרם משימות ממשק | דורש תיעדוף שקוף, אחרת תיקונים קטנים דוחקים את עיבוד התרחישים המרכזיים |
הפורמטים משולבים: עיבוד נקודתי סוגר דברים דחופים, ומערכת עיצוב מסירה את הסיבה שבגללה אותם תיקונים חוזרים כל רבעון. חשוב להבהיר את המגבלות לפני ההתחלה — הן קובעות מה לא נעשה במסגרת המצב הנבחר, ובזכות מה היקף העבודה לא יגדל.
שלבי העבודה: ביקורת תרחישים, סכימה, הרכבה, בדיקה
סדר השלבים בנוי כך שההחלטות מתקבלות על הפורמט הזול ביותר: תיקון של סכימת מסלול לוקח דקות, תיקון של סקיצה מורכבת — ימים, עיבוד מחדש של ממשק מוכן — שבועות. לכן את לוגיקת המעברים ומבנה העמודים אנחנו מקבעים לפני ציור הוויזואל, ומקומות שנויים במחלוקת בודקים על אנשים, ולא בשיחת זום.
-
ביקורת תרחישים והתנהגות. מנתחים אנליטיקה, הקלטות סשנים ופניות לתמיכה: באילו שלבים נוטשים את העגלה או את הטופס, לאן חוזרים, ואילו מסכים בכלל לא רואים. בתוצאה — רשימה של מקומות עם אובדן והשערות מה גורם להם.
-
סכימות של מסלולי משתמש. כל תרחיש פורשים לשלבים עם הסתעפויות, מצבי שגיאה ונקודות יציאה. מאשרים איתכם ועם הפיתוח לפני העיצוב — פער בלוגיקה צץ כאן, ולא בקידוד.
-
אב-טיפוסי שלד לעמודים. פורסים בלוקים וסדרי עדיפויות בלי גרפיקה: רואים מה נכנס למסך הראשון ומה עובר למטה. להתווכח על מבנה על בלוקים אפורים זול יותר מאשר על צבעים.
-
אב-טיפוס קליקבילי. מחברים מסכים במעברים, מוסיפים מצבים ריקים, שגיאות, טעינה — המסלול עובר במלואו. מרכיבים ב-Figma, כדי שתיקונים לא ידרשו ציור מחדש.
-
בדיקת תרחישים עם משתמשים. חמישה-שבעה אנשים מהקהל שלכם פותרים משימות, ואנחנו מסמנים היכן הם מועדים ומה מפרשים אחרת. מתקנים לפני הרכבת הסקיצות, כשזה עוד לא דורש עיבוד מחדש.
-
הרכבת סקיצות וספרייה. מציירים מצבים — ריחוף, שגיאה, אי-זמינות — גרידים אדפטיביים ורכיבים לשימוש חוזר עם משתני עיצוב משותפים.
-
מסירה והשוואה לאחר השחרור. מוסרים סקיצות עם תיאור התנהגות הבלוקים, מלווים את הקידוד עד השחרור ומשווים את התוצאה לאב-הטיפוס.
ערכת מסירה: סקיצות, טוקנים, נהלים
העיצוב לא מסתיים בתמונה בסקיצה, אלא בערכה שלפיה צוות ההרכבה בונה את הממשק בלי שאלות הבהרה למעצב. אנחנו מוסרים הכול בקבצים מקוריים ובצורה שבה הארטיפקטים ממשיכים לחיות: תיקונים נעשים בתוך הצוות שלכם או אצלנו — בלי ציור מחדש מאפס.
- עיצוב אתר אדפטיבי — סקיצות ברוחבי בקרה מוסכמים, עם התנהגות ברורה של הגריד והשבירות, ולא גרסת דסקטופ מתוחה.
- ספריית רכיבים — כפתורים, שדות, טבלאות, מסננים, חלונות מודאליים, התראות; לכל רכיב קבועים מידות, ריווחים וכל המצבים.
- טוקנים של עיצוב — צבעים, טיפוגרפיה, ריווחים, רדיוסים וצללים מוצאים למשתנים: החלפת אקסנט המותג נעשית במקום אחד, ולא במעבר על מאה מסכים.
- ערכת UI לאפליקציית ווב — חלון ראווה של בלוקים מורכבים עם דוגמאות ממסכים אמיתיים, שלפיו מפתח או קבלן חדש נכנס לפרויקט בשעות.
- כללים למצבים ושגיאות — מסכים ריקים, טעינה, כישלון ולידציה, היעדר הרשאות, ניתוק תקשורת: הענפים האלה מתוכננים מראש, ולא מצוירים בחופזה בשחרור.
- מפת התאמה סקיצה → קוד — שמות הרכיבים והשכבות תואמים לשמות בקוד, ולכן פער בין העיצוב לקידוד נתפס בשלב הבדיקה.
- נוהל עדכון הממשק — סדר ההוספה והשינוי של רכיבים, מי מאשר תיקון, איך נקבעת גרסה ומה קורה למסכים שכבר יצאו לאור.
ערכה כזאת מסירה את הסיבה המרכזית להתפשטות הממשק: עמודים חדשים נבנים מבלוקים מוכנים, ולא מתוכננים מחדש לכל מסך.
מקרה בוחן: בנייה מחדש של תרחיש ההזמנה באזור האישי
מה היה
באזור האישי של חברת שירותים תרחיש ביצוע ההזמנה תפס שבעה מסכים, וכל מסך הבא משך נתונים מהקודם. די היה שהמשתמש יחזור שלב אחורה, ירענן את העמוד או יפתח את התהליך מהטלפון — ומה שהוזן אבד, והטופס איפס את הבחירה בשקט. צרה נפרדת — מצבי הממשק: בתגובה איטית הכפתור לא נחסם, וההזמנה יצאה פעמיים.
מה שינינו ומה זה נתן
את התרחיש בנינו מחדש בשלושה שלבים: השירות והפרמטרים שלו, פרטי קשר וכתובת, אישור. ההתקדמות נשמרת באזור האישי כטיוטה, ולכן חזרה לתהליך מכל מכשיר מעלה את מה שכבר מולא. אב-טיפוסים של מצבים הרכבנו והרצנו על תרחישים חיים ב-Figma — לפני שהמשימה עברה לפיתוח.
הוספנו מצבים מפורשים במקום טופס "אילם": טעינה עם חסימת שליחה חוזרת, ולידציה של השדה שורה-שורה עם רמז לפורמט, מצב ריק של רשימת ההזמנות עם פעולה הבאה אחת ברורה, והצלחה חלקית — ההזמנה נוצרה, התשלום לא עבר, עם כפתור לחזור על התשלום בלי ליצור את ההזמנה מחדש.
שיעור הפעולות שהושלמו בתרחיש עלה מ-47% ל-71%: המסלול התקצר, והמשתמש הפסיק להיתקל במסכים לא מובנים. שליחות חוזרות של הזמנות נעלמו לחלוטין, ופניות לתמיכה בנושא ביצוע ההזמנה הפכו נדירות יותר בכשליש בערך.
במה מערכת עיצוב שונה מערכת UI בפועל?
ערכת UI היא אוסף של רכיבים מצוירים: כפתורים, שדות, כרטיסים, חלונות מודאליים. מערכת עיצוב מתחילה במקום שבו מעליהם מופיעים טוקנים — ערכים בשמות לצבע, ריווחים, טיפוגרפיה ורדיוסים — כללים לשימוש בהם ותהליך תמיכה. הערכה חיה בתוך הסקיצה, המערכת קיימת בבת אחת בשני מקומות: בקובץ העיצוב ובקוד.
| מה משווים | ערכת UI | מערכת עיצוב |
|---|---|---|
| בסיס | רכיבים מצוירים | טוקנים ורכיבים, מקור אחד |
| החלפת צבע המותג | תיקון ידני של כל שכבה | ערך טוקן חדש — התעדכן בכל מקום |
| קשר עם הקוד | השוואה ידנית, פערים מצטברים | ערכים משותפים, ביקורת שינויים |
| התפתחות | מתווספת לפי בקשה | מנוהלת בגרסאות, מיושן מוצא |
| היכן מוצדקת | דף נחיתה, קמפיין קצר | אפליקציית ווב עם מחזור ארוך |
ההבדל מתגלה כבר בשינוי הראשון. כל עוד המסכים מעטים, הערכה חוסכת זמן: אין צורך לצייר כפתור פעמיים. ברגע שהמוצר גדל לעשרות מסכים, תיקון ידני הופך למקור של פערים — אותו ריווח בדיוק מופיע בשלוש גרסאות, ומצב "כבוי" מתואר במקום אחד ולא מתואר באחר.
ב-Figma זה נראה בבירור: משתנים וסטיילים נותנים מקור ערכים אחד, ספריית רכיבים — שימוש חוזר, ומצבי תצוגה — מצבים עקביים לערכות נושא. משם מתחיל תהליך: ניהול גרסאות של רכיבים, סימון מיושנים, וביקורת שינויים יחד עם צוות הפיתוח. בלעדיו המערכת תתדרדר תוך כמה איטרציות בחזרה לערכה.
עבור צוות הלקוח זה אומר: הגרסה הראשונה נבנית קצת יותר זמן, אבל כל שינוי ממשק הבא הוא תיקון של ערך אחד, ולא מעבר על חמישים מסכים. מערכת עיצוב מחזירה את ההשקעה לא בהתחלה, אלא למרחק ארוך, כשהמוצר מתפתח כל הזמן.
ספקות נפוצים לפני תחילת העבודה על הממשק
הספקות לפני ההתחלה הם בדרך כלל טכניים: האם אפשר לשפר ממשק קיים בלי לצייר הכול מחדש; מה לעשות עם סקיצות שכבר צוירו; איך לוודא שמבנה המסכים מובן למשתמש; מי אחראי לפערים בין הסקיצה למימוש. בהמשך — תשובות קצרות על האופן שבו אנחנו סוגרים כל אחד מהמקומות האלה.
האם אפשר לשפר ממשק קיים בלי לעשות רידיזיין מלא?
כן, אם הניווט והלוגיקה של הליבה עומדים בעומס. אנחנו מתחילים במיפוי מלאי של מסכים ורכיבים: מה נמצא בשימוש חוזר, היכן ההיררכיה שבורה, ואיפה די בתיקונים בתוך השכבות הקיימות. שיפור הממשק הקיים נעשה באיטרציות, וכל אחת יוצאת לשחרור בנפרד — המוצר לא קופא בזמן העבודה.
יש כבר סקיצות מצוירות — אתם עובדים איתן?
כן. אנחנו מנתחים את הגריד, מצבי האלמנטים, ההתנהגות במסכים צרים, טיפול בשגיאות ומצבים ריקים. שכבות שמישות אנחנו ממחזרים, את החסר מציירים ומובילים לספריית רכיבים אחודה — ואז מסירת הסקיצות לפיתוח נעשית ממקור אחד, ולא בהתכתבות בצ׳אט.
איך בודקים שהמבנה מובן ומי אחראי לפערים?
בדיקת המובנות של המבנה נעשית לפני הציור: סכימת מסכים, אב-טיפוס, הרצה על משימות אופייניות — מיד רואים היכן המשתמש מאבד את המסלול. פערים בין הסקיצה לקידוד מתקבעים בקבלה משותפת: המעצב והמהנדס משווים מצבים וריווחים לפי מפרט אחד, ומקומות שנויים במחלוקת מכריע המעצב המוביל.
נדון במשימה ונחזור עם הערכה ותוכנית
כדי לחזור עם הערכה של פרויקט העיצוב, ולא עם טווח של "מכאן ועד כאן", אנחנו צריכים הקשר של המוצר ונתונים על האופן שבו משתמשים בו היום. שלחו את מה שכבר יש — חלק מהסעיפים יכול להיות חסר, זה לא חוסם את תחילת הפרויקט: את החסרים נסגור בשיחת זום.
- תיאור המוצר והמשימה: מה עושה השירות, מי קהל היעד ואילו תרחישים קריטיים לעסק.
- מסכים נוכחיים: גישה למוצר פעיל או סקיצות בצורת המקור — עם שכבות ורכיבים, ולא רק כתמונות.
- התנהגות נצפית של משתמשים: משפכי המרה באנליטיקה, הקלטות סשנים, מפות חום, אוסף פניות לתמיכה.
- מגבלות: פלטפורמות ומידות מסך, דרישות ספר המותג, בלוקים מחייבים וטקסטים משפטיים.
- מסגרת טכנית: במה הממשק בנוי, אילו אלמנטים כבר הוצאו לספרייה משותפת, מי מבצע את הקידוד.
- קריטריוני קבלה: מה נחשב לתוצאה — שיעור התרחישים שהושלמו, מספר שגיאות קלט, זמן מעבר הטופס.
בהמשך אנחנו פורסים את התרחישים לשלבים, מסמנים את המקומות שבהם משתמשים הולכים לאיבוד, ומרכיבים תוכנית עבודה: סדר השלבים, נקודות אישור, סדר המסירה לפיתוח. הרכב הצוות אנחנו מציינים מיד ולא משנים אותו בהמשך — מעצב אינטראקציה, מעצב ויזואלי, חוקר, מהנדס ממשק. ההערכה מגיעה בפירוט לפי שלבים, כדי שההיקף יהיה גלוי לפני ההתחלה.