מחולל מוצרי ווקמרס

מעסיק
ONE City

תפקיד
מחקר // אפיון ועיצוב מחדש 

הרקע

מה קורה כשמערכת גנרית מנסה לשרת צרכים עירוניים?

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

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

הבעיה

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

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

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

האתגרים המרכזיים

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

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

מחקר המשתמשים

תצפיות בזמן אמת

צפיתי בתומכים עובדים מול משתמשים במהלך תהליך יצירת מוצרים.

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

ה"בדיחה הפנימית" שהתגלתה כתובנה

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

עבורי זו הייתה תזכורת לכך שצריך לגשר על הפער בין המבנה והחשיבה של המוצר לבין הצרכים וההבנה של המשתמשים בשטח.

ראיונות עומק

ראיינתי מנהלי פרויקטים, ספקים עירוניים, מנהלי מרכזים וספריות.

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

ציטוטים חזקים מהשטח

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

מנהלת ספרייה עירונית

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

עובד עירייה

ניתוח פניות תמיכה

ניתוח כמותי ואיכותני של מעל 4,500 פניות תמיכה שהתקבלו במשך 6 חודשים.

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

תיעוד מסלולי משתמש

בניית "מפות מסע משתמש" (User Journey Maps) מפורטות עבור תרחישי יצירת מוצר שונים.

תיעדתי את התהליך המלא מרגע הכניסה ועד השלמת יצירת מוצר.

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

נקודות כאב עיקריות

העמסה קוגניטיבית מיותרת

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

חוסר התאמת הממשק לתהליכים העירוניים

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

מטרות ועקרונות מנחים

שלושה כיוונים שנבחנו בהרצה, ולמה הם נכשלו

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

כיוון 1

שיפור העיצוב

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

כיוון 2

מדריך בשלבים (Wizard)

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

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

הבנתי שכשהמסך עצמו לא אינטאטיבי, צריך פתרון עמוק יותר…

כיוון 3

ספריית תבניות (Template Library)

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

הפתרון

מחולל מבוסס שפה טבעית

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

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

מסכים ממותגים שנוצרו ב-AI לצורך הצגה מוקדמת ובחינת תגובות משתמשים.

התהליך החדש

התהליך העיצובי: אמון ובקרה למשתמש

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

יצירה בשפה טבעית

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

טיוטה חיה

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

שיח אנושי להשלמת מידע

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

עדכון הגדרות בזמן אמת

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

גשר בין חדש למוכר

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

עקרונות מסע המשתמש

בניית אמון ובטחון

שפה טבעית וברורה

אפס מונחים טכניים – רק שפה שהמשתמשים משתמשים בה בחיי היום-יום שלהם.

אמון פסיכולוגי

שקיפות מלאה

התהליך העיצובי

אמון ובקרה למשתמש- איך זה נראה בפועל

בניית אמון פסיכולוגי

הבעיה:
משתמשים נוטים לחשוש מהמעבר לממשק החדש, במיוחד כשהתהליך נתפס כ"שחור קופסה"…

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

הפחתת עומס קוגניטיבי

הבעיה: ריבוי שדות ומסכים מורכבים גורם לבלבול ולנטישה.

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

Impact

הפחתה בפניות תמיכה

מאות פניות שבועיות ירדו לעשרות בלבד – המשתמשים הצליחו לעבוד באופן עצמאי

שיפור דרמטי ביעילות

זמן הקמת מוצר ירד מ-20-25 דקות לפחות מ-5 דקות – חסכון עצום בזמן.

שביעות רצון

שיפור משמעותי בשביעות רצון המשתמשים מהמערכת ומתחושת השליטה

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

ערך מוסף מעבר לציפיות

מוצרים טובים ומורכבים יותר

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

עלייה דרמטית בכמות המוצרים

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

המורכבות שבהטמעת AI

אמון, שליטה ומשתמשים לא טכניים

הימנעות מטעויות קריטיות

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

החשש של המשתמש הלא טכני

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

בניית אמון באמצעות בקרה

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

הצורך בביטחון של 100%

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

איך זה נראה בפעול

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

WooCommerce, במקור

עורר פחד: "מה אם ייגבה כסף? מה אם אעשה טעות?"

אחרי

מרגיע: שום דבר לא יקרה עד שאאשר, אני בשליטה מלאה.

לקחים ותובנות עיקריות שלי

פניות תמיכה אינן "קשר עם לקוחות"

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

אל תתווכחו עם המציאות

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

עיצוב לבד לא פותר הכל

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

המערכת צריכה ללמוד את השפה של המשתמש

פתרון טוב הוא כזה שמבין את שפת היעד ומתאים את עצמו אליה.

מערכת לניהול הפקת מדיה

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

עיצוב אתר עיריית פרדס חנה

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

TopXR – עיצוב מחדש לאתר חברה טכנולוגית

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