אב-טיפוס אינטראקטיבי ב-Figma: היכן נשבר אישור הפרויקט
מסכים סטטיים מאושרים במהירות: המסכים נראים שלמים, הלקוח מאשר, המעצבים מעבירים אותם לבנייה. הבעיה היא שמסך מאושר מתאר מראה חיצוני, ולא התנהגות — הוא אינו עונה מה יקרה לאחר לחיצה, מאיפה המשתמש יחזור ומה יראה אם אין עדיין נתונים. ההבדל מתגלה כבר בהדגמה הראשונה של אפליקציה עובדת.
אב-טיפוס אינטראקטיבי ב-Figma בודק בדיוק את מה שמסך סטטי מסתיר: היגיון המעברים בין מסכים, מצבי כפתורים בזמן טעינה, חזרות וביטול פעולות. כאן גם צפים תרחישים ללא מוצא — מסך שאין ממנו יציאה מלבד הפעלה מחדש — ומצבים ריקים: רשימה ריקה, אובדן רשת, כניסה ראשונה ללא היסטוריה. באישור מסכים החורים האלה אינם נראים, כי כל מסך נבחן בנפרד, ולא כחלק ממסלול המשתמש.
המחיר של טעות כזו עולה בשלבים. תיקון ניווט באב-טיפוס הוא כמה קשרים בין שכבות; אותו תיקון באפליקציה בנויה נוגע בגרף הניווט, בטיפול בשגיאות, במסכי דמה ובבדיקות חוזרות. בדרך כלל צפה לא מעבר אחד שהוחמץ, אלא ענף שלם שאין מי שיסגור אותו בלי לבחון מחדש את התרחיש.
לכן אב-טיפוס נבנה לא כהדגמה יפה, אלא כרשימת תרחישים עם מצבים מפורשים. נבחן איך זה נסגר בפועל ומה מתועד באב-טיפוס לפני תחילת הבנייה.
אפקט מדיד: פחות תיקונים, אישור קצר יותר
אב-טיפוס אינטראקטיבי ב-Figma — זה לא אוסף מסכים סטטיים, אלא תרחיש עם מעברים, מצבים והסתעפויות. הלקוח עובר את מסלול המשתמש כולו: הרשמה, שחזור גישה, תשלום, חזרה להזמנה שלא הושלמה. נקודות המחלוקת מתגלות כאן, כשהתיקון אורך דקות במסך, ולא ימים בקוד מוכן.
האפקט המדיד העיקרי — שיעור התיקונים לאחר הפריסה. כל עוד היגיון התרחיש מאושר, השינויים נוגעים בטקסטים, בריווחים ובהצגה, ולא במבנה המסכים והניווט.
עיבודים מחדש עוברים לתחילת הפרויקט: תיקון ברמת האב-טיפוס נוגע בשכבה אחת, בעוד באפליקציה בנויה — בממשק, בהחלפת נתונים ובטיפול במצבים בבת אחת.
אישור המסכים נעשה לפי תרחישים, ולא לפי תמונות. לכל שלב מתוארת התנהגות: מה המשתמש רואה בהצלחה, בשגיאה, בניתוק תקשורת ובכניסה חוזרת. האישור מואץ, כי דנים בהתנהגות, ולא בהעדפות טעם לגבי צבע הכפתור.
בנפרד נעלם סוג כשלים שהיקר ביותר לחפש בפרודקשן: מצבים ריקים, שליחה חוזרת של טופס, כשל תשלום, פג תוקף הפעלה. כל זה נראה באב-טיפוס לחיץ — לפני שורת הקוד הראשונה.
מה משתנה בפרויקט:
- תיקונים לאחר פריסה — בודדים, ולא זרם;
- אישור המסכים עובר בסבב אישור אחד;
- תרחישים עם שגיאות ומצבים ריקים סגורים לפני הפיתוח;
- עיבודים מחדש לא צפים בשלב בדיקות הבנייה.
פורמטים של אב-טיפוס: מסך לחיץ, תרחיש, קומפוננטות
פורמט האב-טיפוס נבחר לא לפי יופי, אלא לפי סוג אי-הוודאות שצריך להסיר לפני תחילת הפיתוח. אב-טיפוס אינטראקטיבי ב-Figma נבנה בעומקים שונים: ממעברים בין מסכים ועד ספריית קומפוננטות עם מצבים ווריאציות.
טעות אופיינית היא לרדוף אחרי עומק במקום שבו מספיקים מעברים סטטיים, או להפך: להציג מסך לחיץ במקום שבו צריך לבדוק את היגיון התרחיש כולו.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| מסך לחיץ | לאשר מבנה מסכים, ניווט והיררכיה ויזואלית, לבדוק מסלול בעמודים העיקריים | אינו בודק היגיון: הסתעפויות, שגיאות רשת, מצבי טעינה ומסכים ריקים נשארים מחוץ לתמונה |
| אב-טיפוס תרחישי | יש קטע שנוי במחלוקת — הרשמה, תשלום, שחזור גישה; צריך לעבור מסלול עם ענפים וחזרות | דורש תנאי מעברים מתוארים מראש, חלק מההיגיון משוחזר באופן מותנה, בלי צד שרת |
| ספריית קומפוננטות | מסכים רבים והמוצר גדל; צריך להעביר מסכים לפיתוח בלי פערים בין מצבים | אינו מחליף בדיקה על נתונים אמיתיים: התנהגות בנפחים גדולים ובכשלים נראית רק בבנייה עובדת |
בפועל הפורמטים נבנים זה על גבי זה. תחילה מסך לחיץ מקבע את השלד ואת ההסכמות לגבי ניווט, אחר כך אב-טיפוס תרחישי מממש ממשק בקטעים שנויים במחלוקת, וספריית קומפוננטות הופכת את ההחלטות למערכת לשימוש חוזר — לפיה הפיתוח בונה מסכים בלי "לפי העין". כדאי להפריד ביניהם לפי השאלה שצריך לענות עליה, ולא לפי היקף העבודה.
הגבול של כל אב-טיפוס הוא אחד: הוא מתאר הסכמות לגבי הממשק, אך אינו בודק עומס, נתונים אמיתיים והתנהגות במכשיר. כל מה שתלוי בתשובות שרת ובביצועים מאושר כבר באפליקציה בנויה. לכן אנחנו מדברים מראש אילו מגבלות של האב-טיפוס אנחנו מקבלים במודע, ואילו סיכונים סוגרים בבדיקות נפרדות.
שלבי העבודה: מפירוק תרחישים ועד מסירה לפיתוח
אב-טיפוס אנחנו בונים לאחר שתפקידי המשתמשים והתרחישים שלהם מתועדים: אחרת האינטראקטיביות הופכת לאוסף מסכים יפים שאי אפשר לבדוק דרכם את ההיגיון. בהמשך העבודה מתנהלת בשלבים עוקבים — כל אחד סוגר סיכון שיקר יותר לתקן בשלב הבא.
סדר העבודות
- אבחון תרחישים — מפרקים את משימות המשתמש ומסמנים מצבים: מסך ריק, טעינה, שגיאה, אין הרשאה. בפלט — רשימת ענפים שהאב-טיפוס חייב להציג.
- מפת מסכים — מקבעים את המבנה, הבדלי המצבים וכל המעברים. המפה מסירה מחלוקות על ניווט לפני ציור המסכים.
- בניית אינטראקטיביות ב-Figma — מעברים לחיצים, חלונות מודאליים, טפסים עם בדיקת קלט, מחוות. האב-טיפוס מתנהג כמו אפליקציה, לא כמו מצגת.
- בדיקה במכשיר — פותחים את הבנייה בטלפונים אמיתיים בגדלי מסך שונים. בודקים אזורי לחיצה, גלילה, התנהגות מקלדת — מה שלא נראה במסך.
- אישור אב-טיפוס — עוברים על התרחיש שלב אחר שלב יחד עם הלקוח, אוספים הערות ברשימה, מבצעים תיקונים וסוגרים בהרצה חוזרת.
- מסירה למפתחים — מוסרים מפת מסכים, מצבים וכללים: תנאי מעברים, טקסטים, היגיון ולידציה.
- ליווי — עונים לשאלות הצוות בזמן הפריסה ומעדכנים את האב-טיפוס אם הדרישות משתנות.
כל שלב מסתיים בארטיפקט שאפשר לבדוק לפיו את התוצאה, ולכן האב-טיפוס נשאר מסמך עבודה גם לאחר תחילת הפיתוח.
ארטיפקטים של מסירה: תיעוד, מפרטים, הרשאות
לאחר המסירה צוות הלקוח מקבל לא ארכיון תמונות, אלא כלי עובד: קובץ שאפשר לערוך בלעדינו, וכללים שלפיהם הוא מתנהל. אנחנו מוסרים קבצי מקור עם הרשאות שהוענקו, תיאור מצבים וספרייה שנבנתה כך שמסך חדש נבנה מבלוקים מוכנים, ולא מצויר מאפס.
- קבצי עבודה של מסכים — כל עמודי האב-טיפוס ב-Figma, כולל תרחישי ביניים וענפים שנזנחו, עם היסטוריית גרסאות מופעלת; שום דבר לא נשאר במרחב האישי של המבצע.
- מפרט מצבים — עבור כל מסך מפורטים מצב ריק, טעינה, שגיאה, אופליין, התנהגות שדות ומקלדת, היגיון מעברים בין שלבים.
- ספריית קומפוננטות — אלמנטים עם וריאציות ופריסה אוטומטית, טוקנים של צבע וטיפוגרפיה; תיקון אלמנט מתפשט לכל המסכים בבת אחת.
- מפת תרחישים אינטראקטיביים — קשרים בין מסכים, נקודות חזרה והסתעפויות, כדי שהזרימה תיבדק ותתוקן בלי בניית אפליקציה.
- נוהל תיקונים — מתי נוצר קומפוננטה חדשה, מי מאשר שינוי בספרייה, איך מתעדים גרסאות ומה נחשב לשינוי שובר.
- הרשאות לקבצים — הרשאות צפייה ועריכה לצוות הלקוח ולקבלנים, חיבור למרחב עבודה, ולא לחשבון של מעצב מסוים.
- הסכמים מלווים — רשת, ריווחים, כללי שמות שכבות ועמודים: מעצב חדש ממשיך לעבוד באותה היגיון.
המסירה נסגרת בפרוטוקול: רשימת קבצים, קישורים, הרכב ההרשאות שהוענקו ושאלות פתוחות להמשך. הבדיקה פשוטה — אדם שלא השתתף בפרויקט בונה מסך חדש מהספרייה ולא שואל אותנו אף שאלה.
מקרה בוחן: איך צמצמנו תיקונים בשלב הפריסה
הלקוח — שירות להשכרת תחבורה עם אזור אישי, תשלום והתראות. את התרחישים אישרו לפי מסכים סטטיים: המסכים נראו מוכנים, אבל המעברים ביניהם, מצבי הטעינה וטיפול בשגיאות לא נבדקו בשום מקום.
ההערות הראשונות הגיעו כבר בשלב הבנייה — כשהעיבוד מחדש נגע בניווט ובהיגיון, ולא בשכבת המסך, ועלה פי כמה.
מה עשינו
בנינו אב-טיפוס אינטראקטיבי ב-Figma על ארבעה תרחישים רוחביים: כניסה והרשמה, ביצוע הזמנה, ביטול, החזרה. בנפרד עבדנו על מה שבדרך כלל צף בשלב הפריסה — מצבים ריקים, ניתוק תקשורת, שליחה חוזרת של טופס, התנהגות מקלדת, דיאלוגים מערכתיים. הלקוח והתמיכה עברו את האב-טיפוס כאפליקציה חיה והשאירו הערות לפני שהופיעה שורת הקוד הראשונה.
מה השתנה
ההערות לאחר הפריסה הפכו ל-8 במקום 41 — וכמעט כולן על טקסטים וריווחים, ולא על היגיון המעברים. סבבי אישור — 2 במקום 5: נקודות המחלוקת נסגרו באב-טיפוס, ולא בבניות מוכנות.
זמן האישור הצטמצם משלושה שבועות לשבוע אחד, והעיבודים מחדש הפסיקו להיכנס למחזור הפיתוח, שבו כל אחד מהם גורר בנייה ובדיקות חוזרות.
במה שונה תרחיש חי ממסך סטטי?
מסך סטטי הוא צילום של מצב אחד של המסך. ממנו רואים קומפוזיציה, רשת וטיפוגרפיה, אבל לא רואים מה יקרה לאחר נגיעה: לאן מוביל הכפתור, במה מסתיים הטופס ומה להציג עד שהנתונים מגיעים. לכן המסך עונה על השאלה "איך זה נראה", ולא "איך זה עובד".
אינטראקטיביות של אב-טיפוס ב-Figma מוסיפה לתמונה התנהגות: מעברים מקושרים בין מסכים, מצבי ממשק נפרדים — טעינה, רשימה ריקה, שגיאה, פעולה לא זמינה — ומשוב ממשק לכל פעולת משתמש. בדיקת ההיגיון נעשית לפי תרחיש חי: הצוות והלקוח עוברים את מסלול המשתמש כולו ורואים היכן הוא נשבר.
| אפשרות | מה בודק | היכן חסר |
|---|---|---|
| מסך סטטי | קומפוזיציה, רשת, טקסטים | מעברים, מצבים, סדר שלבים |
| אב-טיפוס לחיץ | ניווט והסתעפויות של התרחיש | התנהגות בזמני השהיה ברשת |
| אב-טיפוס עם מצבים ונתונים | היגיון כולו: טעינה, שגיאות, חזרות | אנימציה מדויקת ומחוות פלטפורמה |
מסך סטטי מספיק כשדנים בסגנון ויזואלי, בצפיפות הממשק ובניסוחים. ברגע שבתרחיש מופיעה הסתעפות — כניסה, שחזור גישה, תשלום — צילומי מסך מפסיקים להוכיח משהו.
בדיקת היגיון באב-טיפוס עולה פחות מתיקון באפליקציה שכבר נבנתה: אי-התאמה בסדר השלבים או חזרה שאבדה נראים באישור, לפני שההתנהגות התפשטה לעשרות מסכים. בהמשך נבחן איך נבנה אב-טיפוס כזה.
ספקות טכניים נפוצים לפני תחילת העבודה
לפני ההתחלה בדרך כלל צף אותו סט שאלות — ממוכנות המסכים ועד לאיך היגיון האב-טיפוס יגיע לפיתוח. אנחנו עונים על אלה שבדרך כלל עוצרים את ההשקה.
אין לנו מסכים מוכנים — ממה תתחילו?
מתחילים ממפת תרחישים: מפרקים את משימות המשתמש ובונים את מבנה המסכים לפני ציור הפרטים. האב-טיפוס הלחיץ הראשון נבנה מבלוקים טיפוסיים ובודק את היגיון המעברים, בזמן שהחלק הוויזואלי עוד בעבודה. מסכים מחברים באיטרציות לפי עדיפויות.
יש לנו ספריית קומפוננטות משלנו — תעבדו איתה?
כן. מחברים את הספרייה שלכם — צבעים, גופנים, מצבי כפתורים ושדות, רשתות — ובונים אב-טיפוס על האלמנטים שלה. אם חסרים מצבים (טעינה, שגיאה, ערך ריק), משלימים ומוסרים לכם רשימה של מה שנוסף, כדי שהאב-טיפוס לא יסתור את המוצר.
התרחישים ישתנו תוך כדי — זה עיבוד מחדש?
לא. מעברים ומצבים מתוקנים בתוך האב-טיפוס: משתנה היגיון הענף, ולא הציור של כל המסכים. נשארת גרסה אחת עדכנית, והקודמת נשמרת להשוואה — רואים מה בדיוק השתנה.
איך היגיון האב-טיפוס מועבר לפיתוח ומה עם תמיכה?
יחד עם המסכים מוסרים מפת מעברים: תנאים, מצבי אלמנטים, התנהגות בשגיאה ובתשובה ריקה. המפתח מקבל תיאור התנהגות, ולא אוסף תמונות. בהמשך אנחנו מתחזקים את האב-טיפוס: בשינויים במוצר הוא מתעדכן ונשאר מסמך עבודה של הצוות.
נדון במשימה ונחזור עם הערכה ותוכנית עבודה
כדי לבנות אב-טיפוס שבודק השערה, ולא רק מדפדף יפה, אנחנו צריכים הקשר: איזה תפקיד ממלאת האפליקציה ולפי איזה תרחיש תאשרו את התוצאה. בפגישה מספיק לדבר על זה בקול — את העיצוב והמבנה ניקח על עצמנו.
להתחלה כדאי שיהיה בהישג יד:
- רשימת תרחישי משתמש מרכזיים — מה האדם עושה מהכניסה ועד התוצאה ואילו שלבים קריטיים עבורכם;
- עדיפות פלטפורמות: אחת או שתיהן, במה שונים הניווט והאלמנטים המערכתיים;
- מגבלות: כללי חנויות האפליקציות, כניסה חובה, עבודה בלי רשת, תשלומים, התראות;
- הרשאות: פרויקט ב-Figma עם הרשאות צפייה, ספר מיתוג, גופנים ולוגואים בקבצי מקור;
- מה כבר יש: מסכים מוכנים, טיוטות, מסקנות ממחקרים קודמים, משוב ממשתמשים;
- נקודות אינטגרציה ונתונים חיצוניים, כדי שבאב-טיפוס הם ייראו אמינים;
- מי בצד שלכם מקבל החלטות לגבי הממשק, כדי שתיקונים לא יסתובבו במעגל.
בהמשך — הערכת היקף ותוכנית עבודה. נחזור עם פירוט לפי שלבים, הרכב מעברים לחיצים ורשימת שאלות הבהרה, אם משהו חסר. את הצעד הבא מתעדים прямо בשיחה: מי שולח מה ועד איזה תאריך.