סוכן המאמרים של ליאור | 16 במרץ 2026כחלק מהעבודה התמידית שלנו על שיפור תוכניות הלימוד בקריאט, אנחנו עוברים כל שלושה חודשים על משרות בתעשייה במטרה לזהות מגמות ולהתאים את התכנים שלנו. בסריקה האחרונה גדלו באופן משמעותי הדרישות ל- "שיתוף פעולה עם צוותי פיתוח" ו"ניסיון עם כלי AI". ברור לנו שמעצבים שלא מדברים את השפה הטכנית נמצאים בעמדת חיסרון אל מול שתי הדרישות האלה.
וזה לא קורה רק במשרות. בשיחות שלנו עם מעצבים, שוב ושוב עולה אותה תחושה: "אני יושב/ת בפגישה עם מפתחים ולא מבין/ה חצי מהמילים". זה לא נעים, וזה גם פוגע ביכולת שלכם להשפיע על המוצר. מעצב שלא מבין מה זה API, Branch, או Deploy — נאלץ לסמוך על אחרים במקום להוביל וכך אנחנו דוחקים את עצמנו החוצה משולחן מקבלי ההחלטות.
או כשאנחנו מבינים שמעצבים מפחדים להשתמש בכלי ai כי יש שם מחסום טכנולוגי קטן.
המאמר הזה נולד מהצורך הזה. לא ללמד אתכם לכתוב קוד או להשתמש בעוד כלי — אלא לתת לכם את אוצר המילים שיאפשר להיכנס למים ולהבין מה קורה. אספנו 20 מונחים שחזרו שוב ושוב בשיחות שונות עם מעצבים ומגייסים. מקווים שזה יעזור לכם!
AI ועיצוב
למה ומתי תיתקלו במונחים האלה?
כלי AI הפכו לחלק מהשגרה של מעצבים. אם אתם משתמשים ב-ChatGPT לכתיבת מיקרו-קופי, ב-Midjourney להפקת ויזואלים, ב-Figma AI ליצירת variants, או ב-Claude לתכנון ממשקים — אתם כבר עובדים עם AI. המונחים במשפחה הזו הם השפה שתעזור לכם להבין מה קורה מאחורי הכלים האלה, לנצל אותם טוב יותר, ולדבר עליהם בצורה מדויקת עם מפתחים וצוותי מוצר.
Prompt
ההנחיה שאתם כותבים לכלי AI כדי לקבל ממנו תוצאה. Prompt יכול להיות משפט פשוט כמו "תעצב לי כפתור כחול" או הנחיה מורכבת עם הקשר, דוגמאות, ואילוצים. איכות ה-Prompt קובעת את איכות התוצאה — ולכן "Prompt Engineering" הפך למיומנות מקצועית בפני עצמה.
שימו לב: Prompt טוב הוא לא רק "מה אני רוצה" אלא גם "למי, באיזה סגנון, עם אילו מגבלות, ואיזה פורמט". ככל שתתנו יותר הקשר — התוצאה תהיה מדויקת יותר.
דוגמה מעולם העיצוב: במקום לכתוב "תעשה לי לוגו" — כתבו "עצב לוגו מינימליסטי לאפליקציית פיננסים, בגוון כחול כהה, בסגנון flat, מותאם לאייקון אפליקציה בגודל 1024×1024". ההבדל בתוצאה הוא עצום.
LLM (Large Language Model)
מודל שפה גדול — המנוע שמפעיל כלי AI כמו ChatGPT, Claude, ו-Gemini. ה-LLM אומן על כמויות אדירות של טקסט, ולמד לייצר שפה, לענות על שאלות, לכתוב קוד, ולנתח מידע. כל כלי AI שאתם עובדים איתו מבוסס על LLM כזה או אחר.
למה זה חשוב למעצבים? כי כל LLM שונה — יש לו חוזקות, חולשות, ומגבלות שמשפיעות ישירות על מה שהכלי יכול לעשות בשבילכם. Claude, למשל, חזק בניתוח טקסט ארוך. Midjourney (שמבוסס על מודל אחר, לא LLM) חזק ביצירת תמונות.
דוגמה מעולם העיצוב: כשמנהל מוצר אומר "ננסה את זה עם GPT-4 ונראה אם Claude נותן תוצאה טובה יותר" — הוא בעצם אומר: ננסה שני LLMs שונים ונשווה. כמעצבים, כדאי לכם להבין שלכל מודל יש "אישיות" שונה שמשפיעה על התוצאה.
Hallucination
כש-AI ממציא מידע שנשמע אמין — אבל פשוט לא נכון. LLMs לא "יודעים" דברים — הם מייצרים טקסט שנראה סביר על בסיס דפוסים סטטיסטיים. לפעמים הדפוסים האלה מובילים לתשובה שנשמעת מצוינת אבל מבוססת על אוויר.
שימו לב: הזיות (hallucinations) קורות בכל כלי AI, ללא יוצא מהכלל. זה לא באג — זו תכונה מובנית של הטכנולוגיה. ככל שתבינו את זה, תדעו לבדוק את הפלט במקום לסמוך עליו בעיניים עצומות.
דוגמה מעולם העיצוב: ביקשתם מ-AI לכתוב מיקרו-קופי ל-error state ולציין את התקן הרלוונטי. הוא כתב "לפי תקן WCAG 3.1.2, הודעות שגיאה צריכות להיות בצבע אדום". נשמע מקצועי? WCAG 3.1.2 לא עוסק בצבע אדום. ה-AI המציא ציטוט שנשמע אמין. תמיד בדקו מונחים, מספרים ומקורות שה-AI מציג.
Context Window
כמות המידע שכלי AI יכול "לראות" ולעבד בבת אחת. כל שיחה עם AI מוגבלת בגודל — כמו שולחן עבודה שמכיל כמות מוגבלת של דפים. אם נותנים ל-AI יותר מידע ממה שנכנס ב-Context Window, הוא מתחיל "לשכוח" את ההתחלה.
שימו לב: Context Window נמדד ב-tokens (יחידות טקסט — בערך 0.75 מילה ל-token). Claude, למשל, מסוגל לעבד מאות אלפי tokens — מספיק כדי לקרוא ספר שלם. GPT-4o מוגבל יותר. זה משפיע ישירות על מה שתוכלו לעשות בשיחה אחת.
דוגמה מעולם העיצוב: כתבתם brief מפורט עם 20 דפי מחקר, העתקתם אותו ל-ChatGPT, וביקשתם סיכום. אם ה-brief חורג מה-Context Window — ה-AI יתעלם מהחלק האחרון בלי לספר לכם. אם שמתם לב שה-AI "שכח" משהו שאמרתם לו קודם — כנראה שהמידע חרג מה-Context Window.
Multimodal
יכולת של כלי AI לעבד ולייצר סוגים שונים של מידע — טקסט, תמונות, שמע, וידאו — באותה שיחה. במקום כלי AI שמטפל רק בטקסט או רק בתמונות, כלי multimodal מבין את כולם יחד.
למה זה חשוב למעצבים? כי זה אומר שאפשר לשלב ויזואלים ושפה באותה שיחה עם AI. להעלות צילום מסך ולשאול "מה אפשר לשפר כאן?" — זה multimodal.
דוגמה מעולם העיצוב: העלאתם צילום מסך של ממשק ל-Claude ושאלתם "מה הבעיות בנגישות של העמוד הזה?" — וקיבלתם ניתוח טקסטואלי של בעיות ויזואליות. או: שלחתם ל-GPT-4o תמונה של wireframe מצויר ביד וביקשתם שיתרגם אותו ל-HTML. זה multimodal בפעולה.
Fine-tuning
תהליך שבו לוקחים מודל AI קיים ומאמנים אותו על מידע ספציפי — כדי שייתן תוצאות מותאמות לצורך מסוים. במקום מודל כללי שיודע "קצת מהכל", Fine-tuning יוצר מודל שיודע הרבה על תחום מסוים.
שימו לב: Fine-tuning דורש נתונים ומשאבים טכניים. ברוב המקרים, מעצבים לא יעשו fine-tuning בעצמם — אבל חשוב להבין את המושג כי הוא עולה בשיחות עם צוותי פיתוח ומוצר. כשמישהו אומר "נעשה fine-tune למודל על ה-design system שלנו" — הוא מתכוון להתאים את ה-AI לעבוד לפי השפה העיצובית של החברה.
דוגמה מעולם העיצוב: חברה שרוצה שכלי AI ייצר קופי בטון הספציפי של המותג — יכולה לעשות fine-tune למודל על דוגמאות של טקסטים קיימים. התוצאה: AI שכותב "כמו המותג" ולא "כמו AI גנרי".
Agentic UX
חוויית משתמש שבה ה-AI לא רק מגיב לפקודות — אלא יוזם פעולות בעצמו. במקום "המשתמש מבקש, AI מבצע", ב-Agentic UX ה-AI מבין הקשר, מזהה צרכים, ופועל באופן עצמאי — לפעמים בלי שביקשתם.
זה שינוי תפיסה עמוק למעצבים: עד עכשיו עיצבתם ממשקים שבהם המשתמש תמיד יוזם ותמיד מחליט. ב-Agentic UX האתגר הוא הפוך — איך מעצבים ממשק שבו ה-AI פועל ברקע, והמשתמש עדיין מרגיש שליטה ואמון?
דוגמה מעולם העיצוב: Gmail Smart Compose שכותב לכם את ההמשך. Google Photos שמארגן אלבום מטיול שחזרתם ממנו. Notion AI שמסכם לכם מסמך ארוך — בלי שביקשתם. כל אלה דוגמאות ל-Agentic UX. האתגר שלכם כמעצבים: לאזן בין אוטומציה מועילה לבין תחושת שליטה — שהמשתמש ירגיש שהוא עדיין מחליט, גם כש-AI פועל ברקע.
API וחיבורים
למה ומתי תיתקלו במונחים האלה?
כמעט כל ממשק שאתם מעצבים תלוי ב-API. כל פעם שעיצבתם מסך שמציג מידע דינמי — רשימת מוצרים, פרופיל משתמש, מזג אוויר, התראות — המידע הזה מגיע דרך API. כשמפתח אומר "ה-API לא מחזיר את השדה הזה" — הוא מסביר למה המסך שלכם לא יכול להראות מה שעיצבתם. כשהוא אומר "נצטרך API חדש בשביל זה" — הוא אומר שהפיצ'ר שעיצבתם דורש עבודת פיתוח שלא תוכננה. להבין APIs זה להבין את האילוצים האמיתיים של העיצוב שלכם.
API
Application Programming Interface — ממשק שמאפשר לתוכנה אחת לבקש מידע או פעולה מתוכנה אחרת. התוכנה שולחת בקשה, מקבלת תשובה, וממשיכה. כל אפליקציה מודרנית בנויה מעשרות ולפעמים מאות APIs שמדברים אחד עם השני.
המנגנון פשוט: בקשה ותשובה. "תן לי את רשימת המוצרים" → API מחזיר רשימת מוצרים. "תשמור את הכתובת של המשתמש" → API שומר ומחזיר אישור.
דוגמה מעולם העיצוב: כש-Figma טוען פונטים מ-Google Fonts — זה API. כשאפליקציית מזג אוויר מציגה נתונים — היא קוראת ל-API של שירות מזג אוויר. כשאתם רואים מפה באפליקציה — זה API של Google Maps. כשעיצבתם dropdown עם רשימת ערים — המידע הזה בדרך כלל מגיע מ-API, לא קשיח בקוד.
API Key / Token
מפתח ייחודי שמזהה מי פונה ל-API. בלי מפתח — אין גישה. זה גם מאפשר לבעל ה-API לדעת מי משתמש בשירות שלו, כמה, ולחסום שימוש חריג. תחשבו על זה כמו כרטיס כניסה אישי — בלעדיו הדלת לא נפתחת.
שימו לב: API Key הוא סוד. לא משתפים אותו ב-email, לא מעלים אותו ל-GitHub, ולא שמים אותו בצד הלקוח של הקוד. אם מישהו מקבל את ה-Key שלכם — הוא יכול להשתמש בשירות על חשבונכם, ובמקרים מסוימים לגשת למידע רגיש.
דוגמה מעולם העיצוב: כדי להשתמש ב-Figma API (למשוך design tokens לקוד), נכנסים ל-Figma Settings > Personal Access Tokens ויוצרים מפתח. המפתח הזה הוא ה-API Key שלכם. כלי כמו Token Studio משתמש ב-Key הזה כדי לסנכרן את ה-design tokens מ-Figma לקוד — אוטומטית.
Figma API
ה-API הספציפי של Figma. מאפשר למשוך מידע מהקבצים שלכם בצורה אוטומטית — צבעים, פונטים, מרווחים, רכיבים, טקסטים — ולהשתמש בהם בקוד או בכלים אחרים. זה הגשר שמחבר בין מה שאתם מעצבים ב-Figma לבין מה שנבנה בפועל.
מאחורי כל פלאגין ב-Figma יש שימוש ב-Figma API. כל כלי שמסנכרן עיצוב לקוד — משתמש בו. ככל שתבינו מה Figma API יכול לספק, תבינו טוב יותר מה אפשרי באוטומציה של תהליכי design-to-dev.
דוגמה מעולם העיצוב: כלים כמו Token Studio משתמשים ב-Figma API כדי לסנכרן design tokens ישירות מ-Figma לקוד. שינוי צבע ב-Figma → עדכון אוטומטי בקוד. גם כלים כמו Storybook יכולים לשלוף רכיבים מ-Figma ולהציג אותם לצד הגרסה בקוד — כדי לוודא שהעיצוב והפיתוח מסונכרנים.
MCP
Model Context Protocol — פרוטוקול שמאפשר לכלי AI לדבר עם תוכנות חיצוניות. אם API מחבר תוכנה לתוכנה, MCP מחבר AI לתוכנה. זה תקן פתוח שפותח על ידי Anthropic (היוצרים של Claude) ומאפשר ל-AI לגשת לכלים חיצוניים — Figma, GitHub, מסדי נתונים — בצורה סטנדרטית ומאובטחת.
למה MCP חשוב למעצבים? כי הוא מאפשר לכלי AI לעבוד ישירות עם הקבצים שלכם — בלי שתצטרכו לייצא, להעתיק, או להסביר מה עיצבתם. ה-AI קורא את הקובץ בעצמו.
דוגמה מעולם העיצוב: דרך MCP, כלי AI יכול לגשת ישירות ל-Figma שלכם, לקרוא את העיצוב, ולייצר קוד. אתם אומרים "תבנה לי את ה-component הזה מ-Figma" — וה-AI קורא את הקובץ, מבין את המבנה, הצבעים, המרווחים, ובונה את הקוד. בלי ייצוא, בלי צילום מסך, בלי הסברים ידניים.
Git
למה ומתי תיתקלו במונחים האלה?
כל צוות פיתוח משתמש ב-Git. כשאתם שואלים "מתי הפיצ'ר שלי עולה?" — התשובה קשורה ל-Git. כשמפתח אומר "אני ב-branch אחר" — הוא מסביר למה הוא לא רואה את השינוי האחרון. כשמישהו אומר "יש קונפליקט ב-merge" — הוא מסביר למה שתי גרסאות לא מסתדרות ביחד. Git הוא מערכת ניהול גרסאות — ה-Ctrl+Z של עולם הפיתוח, אבל הרבה יותר חכם. הוא שומר את כל ההיסטוריה של כל שינוי, מאפשר עבודה מקבילית, ומגן מפני אובדן קוד. GitHub הוא האתר שמאחסן את הפרויקטים האלה בענן.
להבין Git זה להבין את הקצב של הפיתוח — מתי דברים משתנים, למה דברים נשברים, ואיך חוזרים אחורה כשצריך.
Repository (Repo)
תיקיית פרויקט שמנוהלת על ידי Git. כל ההיסטוריה של כל שינוי — מי שינה, מה שינה, ומתי — שמורה בתוכה. Repo יכול לשבת על המחשב שלכם (local) או על GitHub (remote).
כל פרויקט תוכנה חי ב-Repo. כשמפתח אומר "תסתכלי על ה-Repo" — הוא אומר: תיכנסי לתיקייה שבה הכל קורה.
דוגמה מעולם העיצוב: כמו Figma file עם version history — אבל הרבה יותר מדויק. אפשר לחזור לכל נקודה בזמן, לא רק ל-30 הימים האחרונים. ויש שליטה מלאה על מי רואה מה ומתי.
git commit
שמירת "תמונת מצב" של הפרויקט. כל commit כולל הודעה שמסבירה מה השתנה. שרשרת ה-commits היא ההיסטוריה המלאה של הפרויקט — כל שורה שנוספה, כל באג שתוקן, כל פיצ'ר שנבנה.
שימו לב: commit טוב מלווה בהודעה ברורה. צוותי פיתוח טובים מקפידים על הודעות commit מדויקות — כי ככה מבינים מה קרה כשמחפשים באג או רוצים לחזור אחורה.
דוגמה מעולם העיצוב: כמו Save Point במשחק. הודעת commit טובה: "תיקון מרווח בכפתור CTA בדף נחיתה". הודעת commit גרועה: "fix stuff". כשמפתח אומר "אני עושה commit ואעלה" — הוא אומר: אני שומר את מה שעשיתי ואעביר את זה הלאה.
git branch
יצירת "ענף" — עותק מקביל של הפרויקט שאפשר לשנות בלי להשפיע על הגרסה הראשית (main). כשהעבודה על ה-branch מוכנה ונבדקה, אפשר למזג אותה חזרה. ככה כמה מפתחים יכולים לעבוד במקביל על פיצ'רים שונים בלי לדרוס אחד את השני.
דוגמה מעולם העיצוב: כמו שב-Figma אתם יוצרים page נפרד כדי לנסות כיוון חדש — בלי לגעת בעיצוב הראשי. אם הניסוי מצליח, מעבירים אותו ל-main. ב-Figma אפילו יש branching מובנה שעובד בדיוק לפי הלוגיקה הזו — והוא קיבל את השם מ-Git.
git push
דחיפת השינויים מהמחשב שלכם לשרת המרוחק (GitHub). עד שלא עושים push, השינויים שלכם רק על המחשב שלכם — אף אחד אחר לא רואה אותם. push הוא הרגע שבו העבודה הפרטית הופכת לציבורית לצוות.
דוגמה מעולם העיצוב: כמו ההבדל בין "שמרתי לעצמי" ל"העליתי ל-Figma". Push = עכשיו כל הצוות רואה. כשמפתח אומר "עשיתי push" — אפשר לבדוק את העבודה שלו. כשהוא אומר "עוד לא עשיתי push" — השינויים עדיין רק אצלו.
git revert
ביטול של commit ספציפי. אם שינוי מסוים שבר משהו, revert יוצר commit חדש שמבטל את השינוי — בלי למחוק את ההיסטוריה. זה כמו "אני רוצה לבטל את מה שעשיתי בשלב 5, בלי לאבד את מה שעשיתי בשלבים 6, 7, 8".
דוגמה מעולם העיצוב: כמו version restore ב-Figma — אבל ממוקד יותר. לא חוזרים לגרסה שלמה, אלא מבטלים שינוי ספציפי. אם מפתח שבר את הלייאאוט של דף מסוים, הוא יכול לעשות revert רק לשינוי הזה — בלי לגעת בכל מה שקרה מאז.
Pull Request (PR)
בקשה רשמית למזג branch לתוך הגרסה הראשית. מפתח מסיים לעבוד על פיצ'ר, פותח Pull Request, וחברי הצוות בודקים את הקוד לפני שהוא נכנס ל-main. זה תהליך ביקורת — Code Review — שמבטיח שקוד חדש עובר עיניים נוספות לפני שהוא עולה לאוויר.
שימו לב: הרבה צוותים מזמינים מעצבים לבדוק PRs שנוגעים לממשק. לא צריך לקרוא קוד — צריך לבדוק שהתוצאה הוויזואלית תואמת את העיצוב.
דוגמה מעולם העיצוב: מפתח בנה את ה-modal שעיצבתם. הוא פותח PR ומתייג אתכם. אתם נכנסים, רואים screenshot של התוצאה, ומוודאים שהמרווחים, הצבעים והטיפוגרפיה תואמים. אם לא — כותבים הערה, והוא מתקן לפני שה-PR מתמזג. זו נקודת הבקרה האחרונה שלכם לפני שהדברים עולים לאוויר.
תשתיות
למה ומתי תיתקלו במונחים האלה?
המונחים שעולים כשהפרויקט עובר מ"עובד על המחשב שלי" ל"עובד לכולם באינטרנט". כמעצבים, המונחים האלה עולים כשאתם שואלים "מתי זה יהיה באוויר?", כשמפתח מסביר למה פיצ'ר מסוים "מורכב יותר ממה שנראה", או כשצריך לבחור טכנולוגיה לפרויקט חדש. להבין את המונחים האלה זה להבין את האילוצים שמפתחים חיים בתוכם — ולעצב בצורה שמתחשבת במציאות הטכנית.
Frameworks
"שלד מוכן" לבניית אפליקציה. במקום לבנות הכל מאפס, framework נותן מבנה, כלים, ומוסכמות — כמו template מקצועי שממנו מתחילים. כל framework מביא איתו כללים, יתרונות, ומגבלות.
שימו לב: כמעצבים, חשוב שתדעו באיזה framework הצוות עובד. זה משפיע ישירות על מה קל לפתח ומה מורכב. Framework מסוים יכול להפוך אנימציה פשוטה למשימה מורכבת — או להפך.
דוגמה מעולם העיצוב: React, Next.js, Vue — כל אחד framework שונה עם חוזקות שונות. אם הצוות שלכם עובד ב-React, יש component libraries מוכנות כמו MUI או Chakra UI שכדאי להכיר — כי הן משפיעות על מה שהמפתחים יכולים לבנות מהר ומה ידרוש פיתוח מותאם. כששואלים את המפתח "באיזה framework אנחנו?" — אתם למעשה שואלים "מה הכלים שעומדים לרשותנו?".
Dependency
ספרייה או כלי חיצוני שהפרויקט תלוי בו כדי לעבוד. פרויקט ממוצע יכול להכיל עשרות ואפילו מאות dependencies. כל dependency זה קוד שמישהו אחר כתב ואתם משתמשים בו — אנימציות, טיפול בתאריכים, ניהול טפסים, ועוד.
היתרון: לא צריך להמציא את הגלגל מחדש. החיסרון: אם dependency נשבר, מתעדכן, או נפסק — הפרויקט שלכם מושפע.
דוגמה מעולם העיצוב: אם האתר משתמש בספריית אנימציות כמו Framer Motion — היא dependency. אם מסירים אותה, כל האנימציות נשברות. כמו פלאגין ב-Figma שבלעדיו הקובץ לא עובד כמו שצריך. כשמפתח אומר "יש בעיה ב-dependency" — הוא אומר: משהו שהפרויקט תלוי בו השתנה או נשבר, ואנחנו צריכים לטפל בזה.
Deploy
העלאת הפרויקט מהמחשב המקומי לשרת חי שכולם יכולים לגשת אליו. ברגע שעושים deploy, השינויים נראים למשתמשים האמיתיים. זה הרגע שבו קוד הופך למוצר חי.
Deploy יכול להיות ידני (מישהו לוחץ על כפתור) או אוטומטי (כל push ל-main מפעיל deploy). צוותים מודרניים בדרך כלל עושים deploy כמה פעמים ביום — כל פיצ'ר קטן עולה בנפרד.
דוגמה מעולם העיצוב: "הפיצ'ר עשה deploy" = "הפיצ'ר עלה לאוויר ומשתמשים רואים אותו". "עוד לא deploy" = "עדיין רק על מחשב המפתח". כשמפתח אומר "נעלה deploy ביום רביעי" — הוא מתכוון שהגרסה החדשה תהיה באוויר ביום רביעי. כשהוא אומר "נעשה rollback" — הוא מתכוון שנחזור לגרסה הקודמת כי משהו נשבר.
אנחנו מקווים שזה עזר לכם לעשות קצת סדר בכל המונחים החדשים שאנחנו נחשפים אליהם בתקופה האחרונה.
הפוסט הזה נכתב בשיתוף פעולה ליאור יאיר וסוכן כתיבת התוכן של create.
אהבתם את הפוסט? אולי תאהבו גם את הפייסבוק, הטיק טוק, האינסטגרם שלנו. אנחנו מעלים טיפים יומיים על נושאים שמרגשים אותנו.
