למה 80% מהעיצובים נשברים בדרך מפיגמה לוורדפרס

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

זה לא באג. זו שיטת עבודה שבורה.

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

אנחנו בנינו תהליך שמסיר את הניחוש לגמרי. להלן איך הוא עובד.

השורש: פיגמה מדבר בעצמים, וורדפרס מדבר בזרימה

פיגמה הוא קנבס אבסולוטי. אתה גורר מלבן לקואורדינטה X=340, Y=128, והוא נשאר שם. הדפדפן לא עובד ככה. הדפדפן מקבל תוכן וזורם אותו לפי חוקים — flexbox, grid, margin collapse, line-height שמוסיף מרווח שלא ביקשת.

שלוש נקודות השבירה הנפוצות:

1. טיפוגרפיה שמשנה גובה. בפיגמה, טקסט בגודל 48px עם line-height של 100% תופס בדיוק 48 פיקסלים. בדפדפן, גופן עברי כמו Heebo מביא איתו metrics משלו — ascender ו-descender שדוחפים את התיבה. פתאום הכותרת "יורדת" 6 פיקסלים והמרווח שתכננת נהרס.

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

3. ברירות המחדל של התבנית. כל תבנית וורדפרס מגיעה עם CSS משלה. אם לא אפסת אותה בכוונה, היא תילחם בך על כל margin-bottom.

שלב 1: Design Tokens — מקור אמת אחד

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

לפני שורת קוד אחת, אנחנו ממירים את קובץ הפיגמה למערכת משתנים. לא "כחול כהה" אלא --color-surface-primary: #05070A. לא "מרווח גדול" אלא --space-9: 150px. כל צבע, כל גודל טקסט, כל רדיוס, כל משך אנימציה — מקבל שם ומספר.

בפיגמה זה נבנה כ-Variables ו-Styles. בוורדפרס זה נבנה כקובץ CSS גלובלי אחד:

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

עיצוב בלי טוקנים הוא לא מערכת. הוא הצעה.— RAMS Studio

אנחנו מגדירים בדרך כלל ארבע משפחות טוקנים:

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

מרווחים — סולם קבוע (4, 8, 16, 24, 40, 64, 100, 150). אם מפתח צריך ערך שלא בסולם, זה סימן שהעיצוב לא עקבי — ואנחנו חוזרים לפיגמה, לא ממציאים בקוד.

טיפוגרפיה — כל רמה מוגדרת כחבילה: גודל, משקל, גובה שורה, letter-spacing. גודל בלי השאר זה חצי עבודה.

מוֹשן — משכי זמן ועקומות easing. --ease-out: cubic-bezier(0.16, 1, 0.3, 1) ו---duration-slow: 0.7s. אחרת כל מפתח בוחר לעצמו והאתר מרגיש מפורק.

שלב 2: אלמנטור או קוד? התשובה היא "גם"

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

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

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

הכלל שאנחנו עובדים לפיו: אלמנטור אחראי על מה שיש בעמוד. CSS גלובלי אחראי על איך זה נראה.

למה זה קריטי? כי כל הגדרה ויזואלית שאתה מכניס דרך ממשק אלמנטור נשמרת כ-inline CSS בתוך רשומת העמוד במסד הנתונים. עמוד עם 200 הגדרות ידניות מייצר קובץ CSS ייעודי שנטען בנפרד, מנפח את ה-DOM, ושובר כל ניסיון לשנות משהו גלובלית.

בפועל: אנחנו נותנים לרכיבים מחלקות CSS (rams-card, rams-btn-primary) דרך שדה ה-CSS Classes באלמנטור, ומעצבים אותן בקובץ אחד. אלמנטור הופך לשלד. ה-CSS הוא העור.

שלב 3: QA ויזואלי — איפה רוב הסטודיואים מוותרים

"נראה טוב" זו לא בדיקה. זו דעה.

אנחנו מריצים שלוש שכבות בדיקה לפני שמשהו עולה לאוויר:

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

שכבה 2: מטריצת מכשירים. לא "רספונסיבי" כמושג מעורפל, אלא בדיקה מפורשת ב-360px, 390px, 768px, 1024px, 1440px ו-1920px. הנקודה הקריטית בעברית היא 360-390 — שם כותרות ארוכות שוברות שורה במקום לא צפוי.

שכבה 3: תוכן קיצון. ממלאים כל שדה בתוכן הכי ארוך והכי קצר שאפשר. כותרת של מילה אחת וכותרת של 14 מילים. אם הרכיב שורד את שניהם — הוא מוכן.

שלב 4: מושן — החלק ששוכחים להעביר

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

אנחנו מתעדים מושן כטבלה: מה זז, ממה לאן, כמה זמן, באיזו עקומה, ובאיזה טריגר. ארבע שורות לרכיב. בלי זה, המפתח יבחר transition: all 0.3s ease וזה ירגיש זול.

שני כללי ברזל:

רק transform ו-opacity. אנימציה על width, height או top מאלצת את הדפדפן לחשב מחדש את פריסת העמוד בכל פריים. התוצאה היא גמגום, במיוחד במובייל. transform ו-opacity רצים על הכרטיס הגרפי.

Ease-out, לא linear. תנועה שמתחילה מהר ונבלמת בעדינות מרגישה טבעית. תנועה בקצב אחיד מרגישה מכנית.

מה זה שווה בפועל

התהליך הזה מוסיף בערך יומיים לפרויקט. הוא חוסך שבועיים.

בלעדיו, אתה נכנס למה שאנחנו קוראים לו "לולאת ההערות": הלקוח מסתכל, מוצא 30 סטיות קטנות, שולח מייל, המפתח מתקן, נוצרות 12 סטיות חדשות. שלוש-ארבע סבבים כאלה הם נורמה בתעשייה — ותקציב שנשרף על תיקון במקום על בנייה.

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

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

הצ'קליסט לפני שאתם מעבירים קובץ פיגמה למפתח

גם אם אתם לא עובדים איתנו, שבע השאלות האלה יחסכו לכם כאב ראש:

1. האם כל צבע בקובץ מוגדר כ-Variable, או שיש ערכי hex מפוזרים?
2. האם המרווחים נופלים על סולם קבוע, או שיש 23px פה ו-27px שם?
3. האם כל רמת טקסט כוללת גם line-height ו-letter-spacing?
4. האם יש גרסת מובייל מעוצבת, או שהמפתח יאלתר?
5. האם בדקתם את הרכיבים עם התוכן הארוך ביותר שיכול להופיע בהם?
6. האם מצבי hover, active ו-disabled מעוצבים במפורש?
7. האם המושן מתועד בכתב, או שהוא "בראש של המעצב"?

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