Figma מציגה: אבות־טיפוס בקוד עם Code layers והקשר עם Specs
Figma הכריזה על Code layers בבטא פתוחה לבניית אבות־טיפוס בקוד, ועל Specs לשמירת הקשר ב־Markdown. מה מציעים הכלים ומה כדאי לבדוק בממשקים בעברית?
Figma רוצה לצמצם את הפער בין מסך מעוצב, אב־טיפוס שמתנהג כמו מוצר וההסברים שסוכן AI צריך כדי לעבוד עליו. ב־15 באוקטובר 2026 הכריזה החברה על Code layers בבטא פתוחה לבניית אבות־טיפוס מבוססי קוד על הקנבס, ועל Specs לשמירת הקשר ב־Markdown בתוך סביבת העיצוב. לצוותי מוצר בישראל, השאלה המעשית היא אם החיבור הזה יכול להפחית הבהרות ותיקונים בדרך לפיתוח, במיוחד בממשקים בעברית.
מה הוכרז: קוד על הקנבס והקשר לצד העיצוב
שני הרכיבים מטפלים בצרכים שונים. Code layers מיועד לבניית אב־טיפוס מבוסס קוד בתוך הקנבס: לא רק הצגה של מסכים, אלא אפשרות לבחון התנהגות. Specs נועד לשמור את ההקשר בפורמט Markdown בסביבת העיצוב. החיבור המעניין הוא בין מה שהממשק עושה לבין ההסבר מדוע הוא אמור לעשות זאת.
מבחינת עבודה עם סוכני AI, זו הבחנה חשובה. עיצוב של טופס יכול להראות היכן נמצא כפתור השליחה, אבל אינו בהכרח מסביר מה קורה כשחסר שדה, מתי מותר לשלוח שוב ומה צריך להישמר לאחר כישלון. תיעוד כתוב יכול להגדיר את הכללים האלה במפורש, במקום להשאיר אותם לניחוש של מפתח או סוכן.
זו סקירת ההכרזה, לא ביקורת המבוססת על התנסות. Code layers הוכרז בבטא פתוחה; התחקיר אינו מאמת מחירים, זכאות לפי מסלול, תמיכה בעברית, מנגנוני חיבור לסוכנים או התאמה של הקוד לסביבת ייצור.
לכן אין בסיס להציג את העדכון כמסלול אוטומטי מעיצוב למוצר מוכן. גם עצם שמירת ההקשר ב־Specs אינה מוכיחה שכל סוכן יכול לקרוא אותו ישירות. לפני שמבססים עליו תהליך צוותי, צריך לבדוק כיצד ההקשר מגיע לכלי הפיתוח שבו משתמשים, אילו הרשאות נדרשות ומה נשמר במעבר.
למה ההקשר חשוב לא פחות מאב־הטיפוס
בהשוואה תפקודית, Code layers עונה על השאלה איך לבדוק התנהגות, ואילו Specs עונה על השאלה איך לשמר את הכוונה. אב־טיפוס יכול להמחיש מעבר ממצב טעינה להצלחה, אבל בלי דרישה כתובה לא ברור אם זו ההתנהגות היחידה המותרת. מנגד, מסמך דרישות לבדו אינו מראה אם ההודעה בולטת מספיק או אם המשתמש מבין מה לעשות.
הערך האפשרי של השילוב אינו רק קיצור זמן ההקמה. הוא האפשרות לזהות סתירות מוקדם: למשל, כאשר המסמך דורש לשמור את פרטי הטופס לאחר שגיאה, אך אב־הטיפוס מאפס אותם. זו נקודת בדיקה משותפת למעצבת, לאיש המוצר ולמפתח, לפני שההתנהגות הופכת לחלק ממימוש רחב יותר.
אב־טיפוס מראה מה קורה; מפרט צריך להסביר מה חייב לקרות גם כשהכול לא עובד כמתוכנן.
עם זאת, קרבה בין מסמך לעיצוב אינה מבטיחה שהם מעודכנים יחד. כדאי להגדיר מי אחראי לשנות את ההקשר לאחר החלטת מוצר ומי בודק שהאב־טיפוס משקף אותה. אם לא עושים זאת, גם תיעוד נגיש ונוח לקריאה עלול להפוך להנחיה ישנה שסוכן AI יבצע בביטחון.
איך לבחון את הכלים בלי להפוך את הבטא לפרויקט
לניסוי ראשון עדיף לבחור זרימה קטנה עם כללים ברורים, למשל בקשת הצעת מחיר באתר שירותים. המטרה אינה לבנות אתר שלם, אלא לבדוק אם ניתן להציג התנהגות, לתעד אותה ולהעביר את הכוונה הלאה בלי סבב ארוך של הסברים בעל פה. זהו תרחיש בדיקה מוצע, לא תיאור של יכולות שנבדקו בפועל.
- כתבו את הדרישה לפני ההדגמה: אילו שדות חובה, מה נחשב קלט שגוי ומה קורה לאחר שליחה מוצלחת.
- הכינו הקשר ממוקד ל־Specs: מטרת המסך, כללי ההתנהגות, נוסחי הודעות והחלטות שעדיין פתוחות. הפרידו דרישות מחייבות מהצעות.
- נסו לייצג ב־Code layers גם טעינה וכישלון, ולא רק מסלול הצלחה. בדקו אילו חלקים מהתרחיש אפשר לממש במסגרת הבטא.
- בדקו כיצד אפשר להעביר את ההקשר לסוכן שבשימוש הצוות. אם נדרשת העתקה ידנית, תעדו אותה כחלק מעלות התהליך.
- בקשו מאיש צוות שלא השתתף בהקמה להסביר את ההתנהגות הצפויה. פערים בהבנה הם סימן לתיעוד חסר או לאב־טיפוס מטעה.
את התוצאה כדאי להשוות לאותה משימה בתהליך הקיים. האם היה קל יותר להבין את מצבי הקצה? האם נדרשו פחות שאלות הבהרה? האם שינוי בדרישה חייב לתקן מידע בכמה מקומות? אלה מדדים שימושיים יותר מהתרשמות ראשונית מאב־טיפוס שנראה מרשים, אך מסתיר עבודה ידנית מאחוריו.
המבחן הישראלי: עברית, RTL ונתוני לקוחות
לצוות שמפתח מוצר בעברית, המבחן צריך לכלול יותר מיישור לימין. נסו כתובת דוא״ל בתוך משפט עברי, מספר טלפון, מחיר בשקלים והודעת שגיאה ארוכה. בדקו סדר פוקוס במקלדת, מיקום אייקונים והאם התנהגות הממשק נשארת מובנת גם כשהטקסט משתנה. התחקיר אינו מאפשר לקבוע מראש כיצד הכלים החדשים יתמודדו עם המקרים האלה.
בצוות שבו העיצוב בעברית ושיחות הפיתוח באנגלית, כדאי שהתיעוד יבחין בין נוסח הממשק המדויק לבין ההסבר הטכני. למשל, אפשר לנסח את כלל האימות באנגלית ולשמור בנפרד את הודעת השגיאה המאושרת בעברית. זו המלצת עבודה כללית: היא אינה תלויה בהנחה שקיימת בכלים החדשים יכולת תרגום או סנכרון אוטומטי.
לניסוי השתמשו בנתונים מומצאים, לא בפרטי לקוחות שהועתקו ממערכת פעילה. לפני שמוסיפים מידע עסקי להקשר, בדקו מי יכול לגשת אליו ולאילו שירותים הוא עשוי לעבור בתהליך העבודה. מסמך שנועד לעזור לסוכן להבין מוצר אינו צריך להכיל מפתחות API, פרטי תשלום או מידע אישי שאינו נחוץ לבדיקה.
למי כדאי לבדוק עכשיו, ומתי להמתין
העדכון ראוי לבדיקה אצל צוותים שכבר עובדים ב־Figma ומתקשים להעביר לפיתוח את ההתנהגות שמאחורי המסכים. עבורם, ניסוי מוגבל יכול לברר אם אב־טיפוס מבוסס קוד והקשר כתוב מפחיתים אי־הבנות. צוות שהבעיה שלו היא דרישות לא מוסכמות יצטרך קודם להכריע בהן; כלי לתיעוד אינו מחליף החלטת מוצר.
נכון ל־18 באוקטובר 2026, ההמלצה היא לבחון את Code layers ו־Specs על משימה תחומה, לא להתחייב על בסיסם לשינוי תהליך מלא. אם הדרישות נשארות ברורות, ההעברה לפיתוח עובדת ומקרי הקצה בעברית מקבלים מענה, יש סיבה להרחיב את הניסוי. אם ההדגמה מרשימה אבל ההקשר עדיין דורש שחזור ידני, החיסכון עוד לא הוכח.
שאלות נפוצות
מה זה Code layers ב־Figma?
Code layers הוא כלי לבניית אבות־טיפוס מבוססי קוד על הקנבס, שעליו הכריזה Figma ב־15 באוקטובר 2026. לפי ההכרזה הוא בבטא פתוחה; אין בתחקיר אימות להתאמת הקוד לשימוש במוצר פעיל.
מה ההבדל בין Specs ל־Code layers ב־Figma?
Code layers מיועד לבניית אב־טיפוס מבוסס קוד, ואילו Specs מיועד לשמירת הקשר בפורמט Markdown בתוך סביבת העיצוב. ההבחנה היא בין התנהגות הממשק לבין התיעוד שמסביר את הדרישות וההחלטות שמאחוריו.
האם Code layers ו־Specs מתאימים לעבודה בעברית?
התחקיר אינו כולל בדיקה של עברית או RTL בכלים החדשים. לפני אימוץ מומלץ לבחון אב־טיפוס עם טקסט דו־כיווני, הודעות שגיאה בעברית וניווט במקלדת, ולא להסתפק במראה המסך.
דרגו את הכתבה
הדירוג עוזר לנו לדעת מה שווה לכם.
תגובות