עיצוב מוצר ו-UI/UX

מערכות עיצוב

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

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

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

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

עקביות שמשותפת למעצבים ולמפתחים שלכם

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

ביקורות בסיוע AI, סטנדרטים באחריות המומחים

איך ה-AI מסייע

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

מה באחריות המומחים שלנו

  • המעצבים והמהנדסים אחראים לארכיטקטורת ה-Tokens, למוסכמות השמות ולאסטרטגיית ערכות הנושא.
  • המהנדסים מגדירים את ה-API, ההתנהגות והמצבים של כל רכיב, וסוקרים כל שינוי שנעשה בסיוע AI.
  • הנגישות מאומתת בכל רכיב: התנהגות מקלדת, מיקוד, תפקידי ARIA, ניגודיות ופלט לקוראי מסך.
  • בני אדם אחראים לניהול המערכת: מה נכנס אליה, ניהול גרסאות, הוצאה משימוש וכללים לתרומה למערכת.

מה כוללת כל שכבה במערכת

שכבות אופייניות למערכת ווב שמשרתת כמה מוצרים; סקירת המצב אצלכם קובעת מה נכנס לכל שכבה.

  • Tokens וערכות נושא

    • ערכי בסיס לצבע, לסולם הטיפוגרפי, לריווח ולרדיוס הפינות
    • כינויים סמנטיים שהרכיבים משתמשים בהם, כמו surface, border ו-danger
    • ערכות נושא בהירה, כהה וממותגת, שנוצרות בהחלפת ערכי הכינויים
    • Tokens של תנועה למשכי זמן ולעקומות האצה, משותפים עם מפרטי האינטראקציה
    • ייצוא למשתני CSS, ולפורמטים של iOS ו-Android היכן שנדרש
  • רכיבים ומצבים

    • כפתורים, שדות קלט, תיבות בחירה, חלונות קופצים וטבלאות שבנויים רק מ-Tokens
    • מפרט אחד לכל רכיב: Props, וריאנטים, מצבים והתנהגות מקלדת
    • שמות וריאנטים ב-Figma שתואמים ל-Props של הרכיב בקוד
    • רכיבים מורכבים כמו בוררי תאריכים ותיבות Combobox, שנבנים מרכיבים קטנים יותר
  • דפוסים, הנחיות וניהול

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

איך אנחנו בונים מערכת עיצוב

  1. 01

    סקירת מצב

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

  2. 02

    יסודות

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

  3. 03

    רכיבים

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

  4. 04

    תיעוד והטמעה

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

שתי דרכים לעבוד עם כלי AI

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

לא בטוחים? נמליץ על אחת מהן בשלב הגדרת ההיקף. השוואת אפשרויות עבודה עם AI

מה תקבלו

מערכת לעיצוב ולקוד

  • סקירת UI ומיפוי

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

  • Design Tokens

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

  • ספריית רכיבים ב-Figma

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

  • רכיבים בקוד

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

  • אתר תיעוד

    Storybook או אתר תיעוד ייעודי עם דוגמאות חיות, הנחיות שימוש, מה לעשות ומה לא, והערות נגישות לכל רכיב.

  • ניהול המערכת וגרסאות

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

בקשות נפוצות למערכות עיצוב

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

  • מיתוג מחדש בכמה מוצרים

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

  • Figma והקוד לא מסונכרנים

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

  • תיקון נגישות לכל המוצרים

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

מה ההתקשרות הזו לא כוללת

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

איך המערכת תומכת בפיתוח, ב-QA ובשחרורים

  • המהנדסים בונים מחלקים משותפים

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

  • QA ברמת הרכיב

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

  • שחרורים מבוקרים של המערכת

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

  • תחזוקה לאורך הצמיחה

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

שאלות ותשובות

שאלות נפוצות

האם אנחנו כבר צריכים מערכת עיצוב?

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

אפשר לבנות על הרכיבים הקיימים שלנו?

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

אתם בונים גם את ספריית הקוד, או רק את הצד ב-Figma?

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

איפה הקוד שלנו מעובד כשה-AI עוזר לבנות רכיבים?

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

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

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