כל סטארטאפ שאנחנו נכנסים אליו אחרי סבב A נראה אותו דבר: שבעה גוונים של כחול, ארבעה סוגי כפתור ראשי, ורכיב מודאל שקיים בשלוש גרסאות שונות כי כל מפתח בנה אותו מחדש. אף אחד לא החליט על זה. זה פשוט מה שקורה כשבונים מהר בלי שכבת החלטות משותפת.
design system סטארטאפ הוא לא פרויקט עיצוב. הוא החלטה תשתיתית — מתי אתם מפסיקים לשלם ריבית על חוסר עקביות ומתחילים לשלם קרן. השאלה האמיתית היא לא "האם" אלא "מתי", וכמה קטן אפשר להתחיל.
הבעיה בלי סיסטם: אתם משלמים עליה כבר עכשיו
העלות של היעדר סיסטם לא מופיעה בשורה נפרדת בתקציב. היא מתחלקת לחמישה מקומות שבהם היא נראית כמו משהו אחר:
זמן פיתוח שנשרף על החלטות שכבר התקבלו. מפתח מקבל מסך חדש בפיגמה. הוא צריך padding של 18px? 20px? הוא הולך לבדוק מסך אחר, מוצא 16px, שואל בסלאק, מחכה. כפול חמישים פעם בחודש. זה לא באג — זו שחיקה.
QA שמזהה "באגים" שהם בעצם חוסר החלטה. הכפתור באונבורדינג כתום, בהגדרות הוא כחול. מי צודק? נפתח טיקט, עובר בין דיזיינר למפתח, נסגר בתור "won't fix". הטיקט הבא זהה.
חוב עיצובי שמצטבר בקוד. ברגע שיש שלוש גרסאות של אותו רכיב, כל שינוי גלובלי — נגיד, הוספת מצב disabled — הופך לעבודה כפולה שלוש. בחצי שנה זה כפול שבע.
גיוס שנעשה איטי. מפתח פרונט חדש בלי סיסטם מגיע לתפוקה מלאה אחרי שישה-שמונה שבועות. עם סיסטם מתועד — שלושה. בצוות שמגייס ארבעה מפתחים בשנה זה חודשי עבודה שנעלמו.
המוצר נראה זול. זה החלק שמשקיעים ולקוחות מרגישים בלי לדעת להסביר. חוסר עקביות ויזואלית נקרא במערכת העצבים כחוסר אמינות. Nielsen Norman Group מצביעים על עקביות כאחד מעשרת ההיוריסטיקות הבסיסיות של שימושיות מאז 1994 — ולא בגלל אסתטיקה, אלא בגלל שהמשתמש בונה מודל מנטלי מהמסך הראשון ומשלם קוגניטיבית על כל סתירה.
המדד המדויק ביותר הוא לא מספר המסכים ולא גודל הצוות — הוא מספר האנשים שיכולים לקבל החלטה ויזואלית בלי לשאול אף אחד. בחברה של שני אנשים זה מספר אחד ואין בעיה. ברגע שהמספר הזה מגיע לשלושה ומעלה, יש לכם שלוש מערכות עיצוב מתחרות בראשים של שלושה אנשים, והן מתנגשות בקוד. תבדקו את זה מחר: קחו שלושה מפתחים ותשאלו כל אחד בנפרד מה ה-border-radius של כרטיס. שלוש תשובות שונות = אתם באיחור.
מתי להתחיל: שלושה טריגרים, לא תאריך
אנחנו רואים שתי טעויות סימטריות. הראשונה: סטארטאפ בן שלושה חודשים שבונה סיסטם עם 40 קומפוננטות לפני שיש לו PMF — ואז זורק אותו כשהמוצר מסתובב. השנייה: חברה עם 25 מפתחים שעדיין מעצבת כל מסך מאפס.
אל תעבדו לפי שלב גיוס. תעבדו לפי טריגרים:
טריגר 1 — יותר ממפתח פרונט אחד. אדם אחד הוא סיסטם בפני עצמו; העקביות שמורה בראש שלו. שני אנשים הם שתי מערכות. זה הרגע לטוקנים, גם אם לא לרכיבים.
טריגר 2 — המוצר עבר את ה-PMF ואתם בונים פיצ'רים שיישארו. לפני PMF כל מסך הוא זמני, וסיסטם על גבי מוצר זמני הוא בזבוז. אחרי PMF כל מסך שאתם בונים ייערך עוד חמש פעמים — ושם הסיסטם מחזיר את עצמו.
טריגר 3 — פלטפורמה שנייה. ברגע שיש ווב + מובייל, או אפליקציה + אתר שיווקי, אין דרך לשמור עקביות ידנית. הטוקנים הם התשתית היחידה שעוברת בין סביבות.
סיסטם שנבנה מוקדם מדי הוא נטל. סיסטם שנבנה מאוחר מדי הוא פרויקט מיגרציה.— RAMS Studio
ה-MVP של סיסטם: ארבעה שבועות, לא ארבעה חודשים
הנה מה שאנחנו בונים כשלקוח אומר "אנחנו צריכים סיסטם אבל אין לנו זמן". זה המינימום שעובד — וכן, זה בכוונה קטן.
שכבה 1: טוקנים (שבוע 1)
לפני רכיב אחד. טוקנים הם ההחלטות האטומיות: צבע, מרווח, טיפוגרפיה, רדיוס, צל. בלי זה, כל רכיב שתבנו מקודד בתוכו החלטות שאי אפשר לשנות גלובלית.
שכבה 2: שמונה רכיבי ליבה (שבועות 2-3)
לא ארבעים. שמונה: Button, Input, Select, Card, Modal, Toast, Table Row, Navigation Item. אלה מכסים בין 70% ל-80% מהמסכים במוצר SaaS טיפוסי. כל השאר — Date Picker, Tabs, Accordion — נבנה כשצריך אותו, לא לפני.
שכבה 3: דף תיעוד אחד (שבוע 4)
לא Storybook עם 200 סטוריז. דף אחד: מה הטוקנים, מה הרכיבים, מה כן ומה לא. Notion מספיק. הקריטריון היחיד הוא שמפתח חדש יפתח אותו ויבין בעשר דקות.
מה לא נכנס ל-MVP: מצבי אנימציה מלאים, תמות מרובות, דארק מוד (אלא אם הוא דרישת מוצר), אייקון-סט מותאם, וכל רכיב שמופיע פעם אחת במוצר. רכיב שמופיע פעם אחת הוא לא רכיב, הוא מסך.
בדיקת בריאות של המוצר שלכם — טוקנים, רכיבים, נקודות חוב — עם מפרט מדויק של מה לבנות קודם.
טוקנים: איפה 90% מהסטארטאפים טועים
הטעות היא לא במספר הטוקנים. היא בשמות. סטארטאפ מגדיר $blue-500, $blue-600, $gray-100 ומרגיש מסודר. חצי שנה אחר כך המוצר עובר רברנד לסגול, ועכשיו $blue-500 הוא סגול בקוד. זה לא בדיחה — זה קורה בכל חברה שנייה.
הפתרון הוא שתי שכבות:
שכבה פרימיטיבית — הפלטה הגולמית. $blue-500: #007AFF. זו השכבה שאף רכיב לא נוגע בה ישירות.
שכבה סמנטית — מה הצבע עושה. $color-action-primary: $blue-500. $color-surface-raised. $color-text-muted. זו השכבה היחידה שהרכיבים צורכים.
ברברנד אתם משנים את השכבה הפרימיטיבית בלבד. שינוי של שורה אחת מול מיגרציה של שבועיים.
אותו היגיון במרווחים. אל תגדירו $spacing-18px — הגדירו סקאלה על בסיס 4 או 8 והתחייבו אליה: 4, 8, 12, 16, 24, 32, 48, 64. שמונה ערכים. ברגע שמפתח צריך 18px, התשובה היא שהוא טועה — או ש-16 או ש-24. האילוץ הוא המוצר.
הטעות הנפוצה היא להגדיר טוקני גופן כ-font-size בלבד, ולתת ל-line-height להיקבע במקומות שונים. התוצאה: אותה כותרת בשני מסכים תופסת שני גבהים שונים, והריתמוס האנכי נשבר. טוקן טיפוגרפי צריך להיות אובייקט קומפוזיטי אחד — size, line-height, weight, letter-spacing — שנצרך כיחידה. בכותרות גדולות (32px ומעלה) הוסיפו letter-spacing שלילי של כ-0.02em; בעברית זה קריטי אפילו יותר מבאנגלית, כי גופני Heebo ו-Assistant נוטים להיראות רופפים בגדלים גדולים.
תחזוקה: החלק שמחליט אם הסיסטם ישרוד
סיסטם מת לא כשמפסיקים לבנות אותו — הוא מת כשמפתח שצריך רכיב לא מצא אותו, בנה גרסה מקומית, ואף אחד לא שם לב. זה קורה תוך שבועות, לא שנים. שלושה מכניזמים מונעים את זה:
בעלות מוגדרת — אדם, לא צוות. "הצוות אחראי" פירושו שאף אחד לא אחראי. צריך שם אחד שמאשר תוספות ושינויים, גם אם זה 10% מהזמן שלו. בסטארטאפ זה בדרך כלל ה-Lead Frontend, לא הדיזיינר — כי הקוד הוא מקור האמת שהמשתמש רואה.
נתיב קליט לתוספות. אם התהליך להוספת רכיב לוקח שבועיים ואישור בשלושה ערוצים, מפתחים יעקפו אותו. תעשו את זה תהליך של PR אחד עם ריוויו אחד. חסם נמוך הוא תנאי הישרדות.
אכיפה אוטומטית, לא שיטור ידני. ESLint או Stylelint שחוסמים ערכי צבע ומרווח hardcoded עושים יותר מכל דוקומנטציה. אם ערך שלא מהסקאלה נכשל ב-CI, לא צריך שיחות על זה.
מדד אחד לעקוב אחריו: אחוז ערכי העיצוב בקוד שמגיעים מטוקנים מול hardcoded. תריצו את זה פעם ברבעון. אם המספר יורד, הסיסטם מתפורר — גם אם פיגמה נראה מושלם.
סיסטם נמדד בקוד, לא בפיגמה. אם הם לא זהים, הסיסטם האמיתי הוא הקוד.— RAMS Studio
הגרסה הקצרה
אם אתם סטארטאפ עם שני מפתחי פרונט ומעלה שעבר PMF — התחילו. ארבעה שבועות: טוקנים בשתי שכבות, שמונה רכיבים, דף תיעוד אחד, ובעלות בשם של אדם אמיתי. לא יותר. כל דבר שגדול מזה בשלב הזה הוא פרויקט שייזנח לפני שיחזיר את עצמו.
מה שכן ישתלם: כל מסך שתבנו מכאן והלאה ייבנה ב-40% פחות זמן, וכל רברנד עתידי יהיה שינוי של קובץ אחד.
אנחנו בונים Design Systems לסטארטאפים — טוקנים, רכיבים וקוד שמפתחים באמת משתמשים בו. ארבעה שבועות ממיפוי לאימפלמנטציה.
