ספריית פיגמה חכמה: קומפוננטות ווריאנטים לבניית כפתור אחד לכל המסכים
כפתור נראה כמו רכיב קטן, אבל בתוך ספריית פיגמה הוא אחד המקומות שבהם מתגלה מיד אם מערכת העיצוב מסודרת או מאולתרת. כפתור שמופיע במסך הרשמה, בתשלום, בדשבורד, במובייל ובטופס תמיכה צריך להתנהג באותה שפה: אותו היגיון, אותם מצבים, אותה טיפוגרפיה, אותו יחס לאייקונים, ואותה התאמה לעברית ול־RTL.
כשבונים כפתור אחד טוב בפיגמה, לא בונים רק מלבן עם טקסט. בונים החלטה מוצרית: מתי הכפתור ראשי, מתי משני, מתי הוא מושבת, מה קורה כשהפעולה מסוכנת, איך הוא נראה במסך צפוף, ואיך הוא נשאר ברור גם למי שפוגש את הממשק בפעם הראשונה. זה בדיוק המקום שבו קומפוננטות ו־Variants בפיגמה חוסכים עבודה, מצמצמים טעויות ומחזקים את חוויית המשתמש.
לפני שנכנסים לבנייה עצמה, כדאי לזכור: קומפוננטה טובה אינה נמדדת רק בכך שהיא “נראית יפה”. היא נמדדת בכך שמעצבים אחרים יכולים להשתמש בה בלי לנחש, שמאפיין UX יכול להבין מה כל מצב אומר, ושצוות מוצר יכול לדבר עליה באותה שפה. אם צריך לחזור בכל פעם לקובץ המקורי כדי להבין איך להשתמש בכפתור, כנראה שהקומפוננטה עוד לא גמורה.
למה דווקא כפתור הוא המקום הנכון להתחיל ממנו
כפתור הוא אחד הרכיבים החוזרים ביותר בממשק. הוא מופיע כמעט בכל זרימה: פתיחת חשבון, שמירת פרטים, מעבר לשלב הבא, שליחת טופס, ביטול פעולה או אישור תשלום. לכן, אם הכפתורים אינם אחידים, כל המוצר מתחיל להרגיש פחות צפוי.
בממשקים בעברית זה בולט במיוחד. כפתור עם אייקון, למשל, חייב להתחשב בכיוון הקריאה. אם האייקון מייצג המשך, חזרה או פתיחה, הכיוון שלו עשוי להשתנות בין LTR ל־RTL. גם יישור הטקסט, מרווחים, סדר אייקון וטקסט, ורוחב הכפתור במסכים צרים — כולם משפיעים על התחושה הכללית.
כפתור אחד מסודר בפיגמה עוזר לענות על שאלות כמו:
- האם “המשך” ו“שמור” הם אותו סוג כפתור?
- איך נראה כפתור ראשי במצב טעינה?
- האם כפתור מושבת עדיין צריך להיות קריא?
- מה ההבדל בין כפתור משני לכפתור טקסטואלי?
- האם כפתור עם אייקון בלבד מותר בכל מקום?
- מה קורה כשהטקסט ארוך, למשל “שליחת בקשה לבדיקה”?
היתרון הגדול של Variants הוא שהשאלות האלה לא נשארות בהערות מפוזרות. הן הופכות לחלק מהרכיב עצמו.
מה צריך להכין לפני שבונים קומפוננטה
לפני שפותחים את פיגמה ומתחילים לשכפל מצבים, כדאי לעצור לרגע. רוב הבעיות בקומפוננטות לא מתחילות בטכניקה, אלא בחוסר החלטה. אם לא ברור אילו סוגי כפתורים יש במוצר, גם הקומפוננטה הכי מסודרת תהפוך במהירות למגירה עמוסה.
רשימת החלטות בסיסית
לפני הבנייה, הגדירו:
- סוגי כפתורים: ראשי, משני, טקסטואלי, הרסני, אייקון בלבד.
- גדלים: קטן, בינוני, גדול — לא יותר מדי, אלא אם יש סיבה אמיתית.
- מצבים: רגיל, ריחוף, לחיצה, מושבת, טעינה.
- תוכן פנימי: טקסט בלבד, אייקון לפני הטקסט, אייקון אחרי הטקסט, אייקון בלבד.
- רוחב: לפי תוכן, רוחב מלא, או רוחב קבוע במקרים מסוימים.
- התנהגות RTL: מיקום אייקון, כיוון חצים, יישור וטקסטים.
אם עדיין אין לכם בסיס ברור, שווה לקרוא קודם על יסודות UX כדי להבין איך רכיבי ממשק מתחברים להחלטות שימושיות ולא רק לעיצוב חזותי.
דוגמה יומיומית
נניח שיש מוצר עברי לניהול הזמנות. במסך אחד יש כפתור “המשך לתשלום”, במסך אחר “שמירת טיוטה”, ובמסך שלישי “ביטול הזמנה”. שלושת הכפתורים דומים בצורתם, אבל לא במשמעות שלהם. “המשך לתשלום” הוא פעולה ראשית. “שמירת טיוטה” עשויה להיות פעולה משנית. “ביטול הזמנה” דורש טיפול זהיר יותר, אולי צבע אחר או ניסוח ברור שמונע טעות.
אם כל אחד מהם יעוצב ידנית, ההבדלים יגדלו עם הזמן: פעם הפינות יהיו 8, פעם 10, פעם הטקסט יהיה מודגש מדי, ופעם המרווח מהאייקון יהיה קטן מדי. קומפוננטה אחת עם Variants מונעת את הזחילה הזו.
ספריית פיגמה טובה מתחילה במבנה שמות ברור
אחד הדברים הכי פחות נוצצים — והכי חשובים — הוא שמות. כאשר שמות הקומפוננטות והווריאנטים לא ברורים, הספרייה הופכת למקום שאנשים מפחדים לגעת בו. לעומת זאת, שמות עקביים מאפשרים חיפוש מהיר, החלפה קלה והבנה מיידית.
מבנה מומלץ לכפתור
אפשר לחשוב על הכפתור כעל מערכת של מאפיינים:
| מאפיין | דוגמאות | למה זה חשוב |
|---|---|---|
| Type | Primary, Secondary, Text, Danger | מגדיר את חשיבות הפעולה |
| Size | Small, Medium, Large | מתאים למסכים והקשרים שונים |
| State | Default, Hover, Pressed, Disabled, Loading | מתאר התנהגות לאורך שימוש |
| Icon | None, Leading, Trailing, Only | מאפשר גמישות בלי קומפוננטות נפרדות |
| Width | Hug, Full | פותר מסכים צרים וטפסים |
גם אם בפיגמה המאפיינים עצמם באנגלית, אפשר לתעד בעברית מה המשמעות של כל אחד. למשל: Primary הוא “הפעולה העיקרית במסך”, ולא סתם “כחול”. כך נמנעת טעות נפוצה: שימוש בצבע כתחליף להיררכיה.
אל תקראו לכפתור לפי צבע
שמות כמו “Blue Button” או “Green CTA” נראים נוחים בהתחלה, אבל הם מתיישנים מהר. מה יקרה כשמחליפים צבע מותג? מה יקרה כשכפתור ירוק כבר לא מייצג פעולה חיובית? עדיף לקרוא לפי תפקיד: Primary, Secondary, Danger, Link או Text.
העיקרון הזה קרוב מאוד לחשיבה של עיצוב ממשק (UI): המראה חשוב, אבל הוא צריך לשרת מבנה, היררכיה והבנה.
שלב אחר שלב: בניית כפתור בסיסי בפיגמה
השלב הראשון הוא לבנות את הכפתור הפשוט ביותר — ורק אז להרחיב אותו. טעות נפוצה היא להתחיל מכל המצבים בבת אחת. זה יוצר בלגן, במיוחד כשעוד לא ברור מהו המרווח הפנימי, מה גודל הטקסט, ואיך האייקון מתיישב.
1. הגדירו את השלד
הכפתור צריך לכלול:
- מסגרת או רקע לפי סוג הכפתור.
- טקסט מרכזי וברור.
- מרווח פנימי אופקי ואנכי.
- רדיוס פינות עקבי.
- אפשרות להוספת אייקון.
- Auto Layout מסודר, כך שהכפתור יתאים לתוכן.
בכפתורים בעברית, מומלץ לבדוק כבר עכשיו טקסטים באורכים שונים. “שמור” נראה נהדר כמעט בכל מצב. “שליחת בקשה לבדיקה” חושף בעיות אמיתיות: רוחב, שבירה, צפיפות ומרווחים.
2. קבעו גודל ברירת מחדל
במקום להתחיל משלושה גדלים, התחילו מגודל אחד — בדרך כלל בינוני. זה יהיה הכפתור הנפוץ ביותר במסכים. אחרי שהוא יציב, צרו גדלים נוספים לפי צורך.
בדקו:
- האם הגובה נוח למגע במובייל?
- האם הטקסט קריא במסכים צפופים?
- האם הכפתור נראה כבד מדי בתוך טבלה או כרטיס?
- האם הוא נראה קטן מדי במסך פתיחה?
3. הוסיפו מצבים
כפתור אינו תמונה סטטית. גם אם בפיגמה אתם עובדים על עיצוב, צריך לחשוב על התנהגות. המצבים הנפוצים:
- Default — המצב הרגיל.
- Hover — מתאים בעיקר לדסקטופ.
- Pressed — משוב בזמן לחיצה.
- Disabled — פעולה שאינה זמינה.
- Loading — פעולה שנשלחה וממתינה לתגובה.
מצב Disabled הוא אחד המקומות שבהם מעצבים נוטים להחליש יותר מדי את הכפתור. גם אם הכפתור מושבת, המשתמש צריך להבין מה הוא רואה. אם יש סיבה לכך שהפעולה אינה זמינה, כדאי לחשוב גם על מיקרו־קופי, טקסט עזר או הודעה סמוכה.
4. הפכו לווריאנטים
אחרי שיש לכם כמה גרסאות יציבות, אפשר לאגד אותן לקומפוננטה אחת עם Variants. הרעיון הוא לא ליצור אוסף של כפתורים נפרדים, אלא רכיב אחד שניתן לשנות דרך מאפיינים.
במקום לבחור ידנית בין “כפתור כחול גדול עם אייקון”, “כפתור כחול קטן בלי אייקון” ו“כפתור אפור מושבת”, המשתמש בספרייה בוחר מאפיינים: Type, Size, State, Icon.
זה ההבדל בין קובץ עיצוב לבין מערכת עיצוב.
איך מטפלים באייקונים בלי לשבור את הרכיב
אייקונים מוסיפים בהירות, אבל גם מכניסים מורכבות. בכפתור עברי, חשוב במיוחד להבין מה תפקיד האייקון. אייקון של הורדה, שמירה או מחיקה אינו תלוי בכיוון הקריאה. אבל חץ שמייצג מעבר קדימה או אחורה בהחלט תלוי בו.
אייקון לפני או אחרי הטקסט?
בעברית, אייקון שמסמן את הפעולה עצמה יכול להופיע לפני הטקסט או אחריו, אבל צריך להיות עקביים. אם הכפתור “המשך” כולל חץ שמאלה או ימינה, ההחלטה צריכה להתאים לכיוון הזרימה של המוצר. בממשק RTL, “קדימה” עשוי להרגיש טבעי יותר שמאלה בהקשרים מסוימים, אך לא תמיד. לכן בודקים לפי הזרימה בפועל, לא לפי כלל אוטומטי.
מתי להשתמש בכפתור אייקון בלבד
כפתור עם אייקון בלבד מתאים בעיקר לפעולות מוכרות מאוד או לשטח צפוף, למשל בתוך טבלה או סרגל כלים. אבל גם שם צריך להיזהר. אייקון של עיפרון עשוי להיות “עריכה”, אבל לא תמיד. אייקון של פח ברור לרבים, אבל עדיין כדאי לוודא שההקשר תומך בו.
בפיגמה, כדאי להגדיר Variant נפרד ל־Icon Only, ולא לאלתר על ידי מחיקת הטקסט בכל מופע. כך שומרים על גודל, ריווח ואיזון חזותי.
כפתורים במובייל: אותו רכיב, התנהגות אחרת
במובייל, כפתור צריך לעבוד בתנאים שונים: מסך צר, אגודל, מקלדת שנפתחת, שדות טופס ארוכים, ואזורי פעולה בתחתית המסך. לכן לא מספיק לבדוק את הכפתור על קנבס רחב.
מה לבדוק במובייל
- האם הכפתור מספיק גבוה ונוח ללחיצה?
- האם טקסט ארוך נשאר קריא?
- האם כפתור ברוחב מלא מתאים למסך?
- האם יש מספיק מרווח בין כפתור ראשי למשני?
- האם מצב טעינה לא גורם לקפיצה ברוחב?
- האם הכפתור נשאר ברור כשהמקלדת פתוחה?
במסכי הרשמה, למשל, נפוץ לראות כפתור “יצירת חשבון” ברוחב מלא בתחתית הטופס. לעומת זאת, במסך עריכת פרופיל, ייתכן שכפתור “שמירה” יהיה בחלק העליון או התחתון, בהתאם לתבנית המוצר. הקומפוננטה צריכה לאפשר את שני המצבים בלי לייצר גרסאות פרועות.
UX Writing בעברית בתוך הכפתור
טקסט הכפתור הוא חלק בלתי נפרד מהעיצוב. כפתור עם ניסוח מעורפל יוצר חוסר ביטחון, גם אם הוא מעוצב היטב. בעברית, כדאי להעדיף פועל ברור שמתאר את הפעולה.
ניסוחים טובים יותר
| פחות ברור | ברור יותר |
|---|---|
| אישור | אישור הזמנה |
| המשך | המשך לתשלום |
| שליחה | שליחת הטופס |
| סיום | סיום הרשמה |
| מחיקה | מחיקת הקובץ |
לא תמיד צריך טקסט ארוך. לפעמים “שמור” מספיק. אבל בפעולות משמעותיות, טקסט מדויק מוריד ספק. זה חשוב במיוחד במסכים שבהם יש כמה פעולות סמוכות: שמירה, ביטול, חזרה, מחיקה או דילוג.
כדאי גם להימנע מכפתורים שמדברים בשפה פנימית של המוצר. המשתמש לא תמיד מכיר את המונחים של הצוות. אם שם הפעולה ברור רק למי שהיה בישיבת אפיון, הוא כנראה לא מספיק ברור.
טעויות נפוצות בבניית קומפוננטת כפתור
גם מעצבים מנוסים נתקעים באותם מקומות. החדשות הטובות: רוב הטעויות ניתנות למניעה אם מזהים אותן מוקדם.
יותר מדי Variants
קל להיסחף וליצור עשרות שילובים. כפתור ראשי, משני, גדול, קטן, עם אייקון, בלי אייקון, טעינה, מושבת, דסקטופ, מובייל, כהה, בהיר — ומהר מאוד אי אפשר להבין מה מותר להשתמש.
הפתרון: לא כל הבדל צריך להיות Variant. חלק מההחלטות שייכות לתיעוד, חלק למיקום במסך, וחלק בכלל לא צריכות להתקיים. אם יש Variant שאף אחד לא משתמש בו, ייתכן שהוא מיותר.
שימוש ב־Detach במקום לפתור בעיה
כשמופע של כפתור לא מתאים למסך, הפיתוי הוא לנתק אותו מהקומפוננטה ולשנות ידנית. זה נראה פתרון מהיר, אבל הוא יוצר חוב עיצובי. בפעם הבאה שהספרייה תתעדכן, הכפתור המנותק יישאר מאחור.
במקום לנתק, שאלו:
- האם חסר Variant אמיתי?
- האם הטקסט ארוך מדי?
- האם המסך דורש תבנית אחרת?
- האם צריך להוסיף אפשרות רוחב מלא?
- האם זו חריגה חד־פעמית שאפשר לפתור ברמת layout?
מצב Loading שלא תוכנן
כפתור טעינה הוא לא קישוט. הוא אומר למשתמש: הפעולה התקבלה, נא להמתין. אם לא מתכננים אותו, נוצרים פתרונות מאולתרים: טקסט שנעלם, ספינר שלא מיושר, רוחב שקופץ, או כפתור שנראה עדיין לחיץ.
כדאי להחליט מראש אם במצב טעינה הטקסט נשאר, משתנה ל“שולח…”, או מוחלף באינדיקציה חזותית. בכל מקרה, המצב צריך להיות חלק מהרכיב.
איך מתעדים את הכפתור בתוך ספריית פיגמה
קומפוננטה בלי תיעוד היא חצי פתרון. התיעוד לא חייב להיות ארוך, אבל הוא צריך לענות על השאלות המעשיות שמופיעות בזמן עבודה.
מה כדאי לכלול בתיעוד
- מתי להשתמש בכפתור Primary.
- כמה כפתורים ראשיים מותרים במסך אחד.
- מתי להשתמש בכפתור Danger.
- אילו מצבים קיימים ומה משמעותם.
- איך מתייחסים לאייקונים ב־RTL.
- דוגמאות לטקסטים טובים ולא טובים.
- כללי רוחב במובייל ובדסקטופ.
- מה לא לעשות.
לדוגמה: “במסך אחד מומלץ להשתמש בכפתור ראשי אחד לפעולה המרכזית. פעולות משניות יוצגו כ־Secondary או Text, בהתאם להיררכיה.” משפט כזה חוסך עשרות דיונים קטנים בהמשך.
מסירה לצוות מוצר ופיתוח בלי להיכנס לקוד
גם באתרי עיצוב שמתרחקים מקוד, יש חשיבות למסירה מסודרת. המטרה אינה להסביר איך לממש את הכפתור טכנית, אלא להבהיר מה ההתנהגות והכללים שלו.
במסירה טובה מציינים:
- שמות המצבים והמשמעות שלהם.
- ערכי צבע כטוקנים עיצוביים, לא כהחלטות נקודתיות.
- גדלים, ריווחים ורדיוס.
- התנהגות במובייל.
- אופן הופעת מצב טעינה.
- יחס לאייקונים וכיוון ב־RTL.
- דוגמאות שימוש במסכים אמיתיים.
כך נמנעת פרשנות חופשית מדי. במקום “הכפתור הזה כמו במסך ההוא”, יש מפרט ברור שמחבר בין אפיון UX, עיצוב ממשק ותהליך מוצר.
שאלות שקוראים באמת שואלים
האם צריך כפתור נפרד לכל מסך?
ברוב המקרים לא. אם הכפתור מייצג אותה שפה עיצובית ואותה התנהגות, הוא צריך להגיע מאותה קומפוננטה. מסך חריג אינו סיבה מיידית לרכיב חדש. קודם בודקים אם אפשר לפתור אותו באמצעות Variant, רוחב שונה או ניסוח מדויק יותר.
כמה סוגי כפתורים מספיקים?
לרוב המוצרים מספיקים ארבעה או חמישה סוגים: ראשי, משני, טקסטואלי, הרסני ואייקון בלבד. אם יש יותר, כדאי לבדוק אם כולם באמת משרתים תפקיד שונה או שחלקם נוצרו בגלל החלטות נקודתיות.
האם כדאי להתחיל מספריית כפתורים מלאה?
עדיף להתחיל קטן ומדויק. כפתור אחד טוב, עם מבנה נכון ותיעוד ברור, עדיף על ספרייה מלאה אך מבולגנת. אחרי שהעיקרון עובד, אפשר להרחיב לשדות טופס, כרטיסים, תפריטים, טאבים ורכיבים נוספים.
מה עושים אם כבר יש הרבה כפתורים קיימים?
לא מוחקים הכול ביום אחד. מתחילים במיפוי: אוספים דוגמאות, מזהים כפילויות, מגדירים את הסוגים המרכזיים, ורק אז מחליפים בהדרגה. אפשר לסמן רכיבים ישנים כלא מומלצים לשימוש ולהציע חלופה מהספרייה החדשה.
סיכום: כפתור אחד שמחזיק מערכת שלמה
קומפוננטת כפתור טובה בפיגמה היא לא רק חיסכון בזמן. היא דרך לייצר עקביות, להקטין טעויות, לשפר תקשורת בין צוותים ולשמור על חוויית משתמש ברורה לאורך כל המוצר. ברגע שהכפתור בנוי עם Variants נכונים, שמות מסודרים, מצבים ברורים והתאמה לעברית ול־RTL, הוא מפסיק להיות עוד שכבה בקובץ והופך לחלק אמיתי ממערכת העיצוב.
הדרך הנכונה היא להתחיל מהשימושים האמיתיים: טפסים, תשלום, הרשמה, דשבורד, פעולות מסוכנות ומסכי מובייל. משם מגדירים סוגים, מצבים, גדלים ואייקונים. לא בונים הכול כדי להרשים, אלא כדי שאפשר יהיה להשתמש בזה מחר בבוקר בלי לשאול יותר מדי שאלות.
בסוף, ספריית פיגמה טובה מורגשת דווקא כשהיא לא דורשת תשומת לב. הכפתורים פשוט עובדים, המסכים מרגישים עקביים, והצוות יכול להתמקד בהחלטות החשובות באמת: מה המשתמש צריך לעשות, איך עוזרים לו להבין את זה, ואיך הופכים את הפעולה הבאה לברורה ובטוחה.
