10 בניית מיומנויות

Wireframes ו-Prototypes — מאפיון לדמו

בפרק הזה תלמדו את כל הנתיב: מאפיון גולמי בגווני אפור (Wireframe) דרך עיצוב מלא עם צבעים ותוכן (Mockup) ועד לדמו אינטראקטיבי שהלקוח יכול ללחוץ עליו (Prototype). תבנו 3 מסכים לאפליקציה ישראלית, תמירו אותם ל-Mockup עם Design System, ותייצאו HTML שעובד — הכל בלי שורת קוד אחת ובלי Figma.

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

בפרקים 7-9 בניתם את התשתית: Design System מלא, Brand Assets, ושליטה מלאה ב-RTL עברי. בפרק הזה תשתמשו בכל אלה יחד — תתכננו מסכים מאפס (Wireframe), תלבישו עליהם את ה-DS שבניתם (Mockup), ותהפכו הכל לדמו שלקוח יכול ללחוץ עליו (Prototype). בפרק 11 תקחו את ה-Prototype הזה ותמירו אותו לקוד עובד עם Claude Code — Design-to-Code Handoff.

מילון מונחים — פרק 10
מונח (English) תרגום/הסבר בעברית הגדרה
Wireframe שלד / מאפיון ויזואלי שרטוט גולמי בגווני אפור שמראה מבנה ומיקום של אלמנטים — בלי צבעים, בלי תמונות אמיתיות, בלי תוכן סופי
Mockup הדמיה מלאה עיצוב מפורט עם צבעים, פונטים, תמונות ותוכן אמיתי — נראה כמו המוצר הסופי אבל עדיין לא אינטראקטיבי
Prototype אב-טיפוס / דמו אינטראקטיבי גרסה שאפשר ללחוץ עליה — כפתורים עובדים, מסכים מתחלפים, תפריטים נפתחים — אבל בלי backend אמיתי
Low-Fidelity (Lo-Fi) רמת פירוט נמוכה שלד פשוט — קופסאות אפורות, placeholder text, בלי צבעים. נועד לבדוק מבנה ו-flow, לא יופי
High-Fidelity (Hi-Fi) רמת פירוט גבוהה עיצוב קרוב לסופי — צבעים, תמונות, אנימציות. זה מה שהלקוח רואה לפני הפיתוח
User Flow מסע משתמש / זרימת משתמש התיאור של השלבים שמשתמש עובר כדי לבצע פעולה — לדוגמה: מסך ראשי → עמוד מוצר → עגלה → תשלום
Clickable Prototype דמו לחיץ Prototype שבו כל כפתור וקישור עובד — הלקוח יכול ללחוץ ולנווט בין מסכים כאילו זה מוצר אמיתי
Hover Effect אפקט ריחוף שינוי ויזואלי שקורה כשהעכבר עובר מעל אלמנט — שינוי צבע, הגדלה, צל — מרמז למשתמש שאפשר ללחוץ
Viewport אזור תצוגה גודל המסך שבו המשתמש רואה את האתר — מובייל (375px), טאבלט (768px), דסקטופ (1280px)
Feedback Loop מעגל משוב תהליך מובנה לקבלת הערות מלקוח, תיקון, ושליחה חוזרת — עד שהתוצאה מאושרת
מתחיל 10 דקות חינם מושג

Wireframe, Mockup, Prototype — מה ההבדל

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

דמיינו שאתם בונים בית. Wireframe הוא כמו תוכנית הארכיטקט — מראה איפה החדרים, הדלתות, החלונות, אבל הכל בשחור-לבן ובלי ריהוט. Mockup הוא כמו הדמייה תלת-ממדית — רואים את הצבעים על הקירות, את הריצוף, את הרהיטים, אבל אי אפשר להיכנס פנימה. Prototype הוא כמו דירה לדוגמה — אפשר להיכנס, לפתוח ארונות, לבדוק את התאורה. האנלוגיה הזאת עוזרת גם להסביר ללקוחות ישראליים מה הם מקבלים בכל שלב.

שלב Wireframe (שלד) Mockup (הדמיה) Prototype (דמו)
מה רואים קופסאות אפורות, placeholder text, בלי צבע צבעים, פונטים, תמונות, תוכן אמיתי כמו Mockup, אבל עם לחיצות ומעברים
מטרה לאשר מבנה ומיקום לאשר עיצוב ותחושה לאשר התנהגות ו-flow
זמן הכנה 15-30 דקות 30-60 דקות 60-90 דקות
שינויים קלים ומהירים — זה רק שלד בינוניים — כבר יש עיצוב כבדים — כבר יש קוד/אינטראקציה
מתאים ל- פגישה ראשונה, אישור מבנה אישור עיצובי לפני פיתוח הדגמה למשקיעים, בדיקת UX

למה הסדר חשוב? כי שינוי ב-Wireframe לוקח 5 דקות. אותו שינוי ב-Mockup לוקח 20 דקות. ב-Prototype — שעה. ובקוד? יום. לכן תמיד מתחילים מהשלד — בודקים שהמבנה נכון — ורק אז מוסיפים צבעים ואינטראקציה.

בשוק הישראלי זה קריטי במיוחד. לקוחות ישראליים נוטים לתת feedback ישיר ומהיר — "לא אהבתי, תשנה" — ואם אתם כבר בשלב ה-Mockup המלא, כל שינוי מבנה עולה זמן וכסף. בנוסף, אתרים ואפליקציות ישראליות מחייבים חשיבה מיוחדת על RTL מההתחלה. כפי שלמדתם בפרק 9, בעיות RTL שלא תופסים ב-Wireframe הופכות ליקרות מאוד לתיקון בשלבים מאוחרים.

נתון מעניין

מחקרי UX מראים שתיקון בעיית שימושיות בשלב ה-Wireframe עולה פי 1 (בסיס). אותה בעיה ב-Mockup עולה פי 5, ב-Prototype פי 10, ובקוד פי 30-100. Wireframe הוא ה-insurance policy הכי זול שיש. (הערכה מבוססת על עקרון "1-10-100 Rule" המקובל בתעשיית ה-UX)

עשה עכשיו 3 דקות

חשבו על הפרויקט האחרון שעבדתם עליו (מפרקים 4-8). באיזה שלב הייתם — Wireframe, Mockup, או Prototype? כתבו: "הפרויקט שלי היה ברמת _________ כי ________". רוב הסיכויים שדילגתם ישר ל-Mockup. זה בסדר — עכשיו נלמד למה כדאי לעצור קודם ב-Wireframe.

הבנה חשובה: Wireframe, Mockup ו-Prototype הם לא 3 מוצרים שונים — הם 3 שלבים באותו מוצר. כמו לבנות בניין: קודם שרטוטים (Wireframe), אחר כך הדמיות 3D (Mockup), ולבסוף דירה לדוגמה (Prototype). כל שלב בונה על הקודם ומוסיף שכבת פירוט. לכן גם ב-Claude Design, אתם לא מתחילים מאפס בכל שלב — אתם מתקדמים מהשלד הקיים.

מתחיל 8 דקות חינם אסטרטגיה

מתי להשתמש ב-Claude Design למאפיון

Claude Design הוא לא Figma. הוא לא מיועד לעבודה pixel-perfect עם שכבות, constraints ו-auto layout. אבל יש לו יתרון עצום שב-Figma אין: אתם מתארים מה אתם רוצים בשפה טבעית — והוא מייצר את השלד. בשביל עסק קטן שרוצה לתכנן אפליקציה או אתר, זה Game Changer. לא צריך ללמוד כלי חדש, לא צריך לשלם מנוי נוסף, ולא צריך לשכור מעצב UX.

בפרק 2 סקרתם את הממשק ובפרק 3 יצרתם את הפרויקט הראשון. שם עבדתם על תוצרים סופיים (one-pagers, slides). כאן המנטליות שונה: Wireframe הוא כלי עבודה — לא תוצר שנשלח ללקוח כמו שהוא. הוא נועד לחסוך לכם זמן, לא ליפות את העולם.

מסגרת החלטה: Claude Design או Figma למאפיון?
מצב הכלי המתאים למה
עסק קטן שרוצה להראות ללקוח רעיון Claude Design מהיר, לא דורש לימוד Figma, מייצר HTML
פרילנסר שרוצה להציע שירות מאפיון Claude Design מייצר תוצר מקצועי ב-30 דקות במקום 3 שעות
צוות UX/UI בחברה עם Design System בFigma Figma אינטגרציה עם פיתוח, גרסאות, Components Library
אישור מהיר מלקוח לפני עיצוב מלא Claude Design Wireframe ב-15 דקות, שליחת קישור מיידי
פרויקט עם 50+ מסכים ו-Design Tokens Figma Claude Design לא מנהל פרויקטים בקנה מידה גדול

כלל אצבע: אם הפרויקט שלכם דורש עד 10 מסכים, לקוח אחד, ותוצר סופי ב-HTML — Claude Design מושלם. אם יש לכם צוות של 3+ מעצבים שעובדים במקביל על מאות Screens — Figma הוא הבית הטבעי.

הנקודה הישראלית: חברות ישראליות קטנות ובינוניות — בין אם זה עסק מזון בשוק הכרמל, יועצת עסקית מרעננה, או סטארטאפ שמגייס pre-seed — צריכות בדרך כלל 3-8 מסכים. הן לא צריכות Figma עם Auto Layout ו-Variables. הן צריכות תוצאה מהירה שאפשר להראות למשקיע, לשותף, או ללקוח ראשון. וזה בדיוק מה ש-Claude Design עושה — ובעברית, עם RTL, בלי לשבור את הראש.

שימו לב: בפרק 2 למדתם את הממשק, בפרקים 4-6 יצרתם slides, one-pagers ו-landing pages. כל אלה היו מוצרים סופיים — דברים שנשלחים ללקוח. כאן נכנס שינוי מנטלי: Wireframe הוא לא מוצר סופי. הוא כלי תקשורת. המטרה שלו היא לא להרשים — אלא לוודא שאתם והלקוח על אותו עמוד לפני שמתחילים לעצב.

טעות נפוצה: לדלג ישר ל-Mockup

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

למה זה מפתה: Claude Design כל כך מהיר שמרגיש "אין סיבה לא לעשות ישר יפה".

מה לעשות במקום: תמיד תתחילו מ-Wireframe אפור. שלחו ללקוח. קבלו אישור על המבנה. רק אז — צבעים. זה חוסך שעות, לא מוסיף.

עשה עכשיו 2 דקות

פתחו Claude Design. כתבו ב-Chat: "Create a simple wireframe for a food delivery app home screen. Grayscale only, no colors, placeholder images." בדקו: האם התוצאה באמת אפורה ושלדית? אם Claude הוסיף צבעים — כתבו "Remove all colors, make it a pure wireframe in grayscale" ובדקו שוב.

בינוני 15 דקות חינם תרגול

Prompt ל-Wireframe — מבנה ודוגמאות

Prompt טוב ל-Wireframe הוא לא "תעשה לי wireframe לאפליקציה". אם תכתבו את זה ל-Claude Design, תקבלו תוצאה — אבל היא תהיה גנרית, אולי LTR, וכנראה לא תתאים לצרכים שלכם. כדי לקבל wireframe מדויק, צריך prompt מובנה. בפרק 3 למדתם לכתוב prompts ל-one-pager — עכשיו נרחיב את הגישה לwireframes.

Prompt טוב מגדיר 5 דברים שClaude Design צריך כדי לייצר שלד שימושי:

5 מרכיבי Prompt ל-Wireframe
  1. סוג המסך: Home screen / Product page / Checkout / Dashboard / Settings
  2. קהל יעד: מי ישתמש — גיל, רמת טכנולוגיה, הקשר שימוש
  3. אלמנטים נדרשים: מה חייב להיות — חיפוש, קטגוריות, כרטיס מוצר, CTA
  4. סגנון Wireframe: Lo-Fi (קופסאות בלבד) / Mid-Fi (מבנה + placeholder text)
  5. פלטפורמה: Mobile (375px) / Desktop (1280px) / Both

טעות שמתחילים עושים: כותבים prompt שמערבב מידע ויזואלי עם מידע עסקי. לדוגמה: "Make a wireframe for my chocolate business that has 20% growth this year and serves the Tel Aviv market." ה-20% growth וה-Tel Aviv market לא רלוונטיים לWireframe — הם רלוונטיים ל-copy שיבוא אחר כך ב-Mockup. ב-Wireframe, Claude צריך לדעת מה נמצא על המסך, לא מה העסק שלכם עושה.

הנה 3 prompts מוכנים שאפשר להעתיק ולהתאים:

Prompt 1: Wireframe לאפליקציית מובייל — Home Screen

"Create a mobile wireframe (375px width) for a home screen of an Israeli artisan chocolate delivery app called 'Shokli' (שוקלי). Grayscale only. Include: top search bar, promotional banner area, 4 category icons (dark chocolate, milk chocolate, gift boxes, seasonal), horizontal product cards with placeholder image + name + price in NIS, bottom navigation with 4 tabs (Home, Categories, Cart, Profile). RTL layout — Hebrew text direction. Mid-fidelity — show placeholder text in Hebrew where possible."

Prompt 2: Wireframe לאתר עסקי — Homepage Desktop

"Create a desktop wireframe (1280px) for a homepage of an Israeli consulting firm. Grayscale. Include: hero section with headline + subtitle + CTA button, 3 service cards below, testimonials section with 2 quotes, contact form at bottom, header with logo + navigation (4 items) + phone number. RTL layout, Hebrew placeholder text. Lo-fi — boxes and lines only, no detailed content."

Prompt 3: Wireframe ל-Dashboard — SaaS Product

"Create a desktop wireframe for a SaaS dashboard. Grayscale. Include: sidebar navigation (6 items), top bar with user avatar + notifications bell, main area with 4 KPI cards (Revenue, Users, Orders, Conversion), chart area below (line chart placeholder), recent activity table with 5 rows. LTR layout — this is an English-language product. Mid-fidelity."

עשה עכשיו 5 דקות

קחו את Prompt 1 (שוקלי) — או כתבו prompt משלכם על בסיס 5 המרכיבים. הדביקו ב-Claude Design. כשהתוצאה מגיעה, בדקו: (1) האם זה באמת אפור? (2) האם כל האלמנטים שביקשתם נמצאים? (3) האם ה-RTL נכון? סמנו מה חסר: ________

טעות נפוצה: Wireframe מפורט מדי

מה קורה: מבקשים wireframe עם "micro-interactions, animations, detailed icons, real product photos". התוצאה כבר לא Wireframe — זה Mockup. והבעיה: הלקוח מתייחס לצבעים במקום למבנה.

למה זה מפתה: אתם כבר יודעים איזה צבעים אתם רוצים (יש לכם DS מפרק 7), אז למה לא?

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

בינוני 25 דקות חינם תרגול

Wireframe לאפליקציה — 3 מסכים

עכשיו נבנה סט שלם של 3 מסכים לאפליקציית "שוקלי" — אפליקציית משלוחי שוקולד אומנותי ישראלית. למה דווקא 3 מסכים? כי 3 מסכים מספיקים להראות ללקוח את ה-User Flow (זרימת משתמש) — המסלול שמשתמש עובר מרגע שפותח את האפליקציה ועד שמבצע רכישה. אם תבנו רק מסך אחד, הלקוח לא מבין את ה-flow. אם תבנו 10 מסכים, אתם מבזבזים זמן על שלד שאולי ישתנה. 3 מסכים = Sweet Spot.

חשוב: בפרק 7 בניתם Design System — בשלב הזה עוד לא משתמשים בו. ה-DS ייכנס רק ב-Mockup. ב-Wireframe אנחנו עובדים אפור בלבד. זה דורש משמעת, כי Claude Design "רוצה" להוסיף צבעים. אם הוא מוסיף — אמרו לו לא.

ה-User Flow של שוקלי: משתמש פותח את האפליקציה (Home), גולל ורואה מוצרים, לוחץ על מוצר (Product), קורא את התיאור ולוחץ "הוסף לעגלה", ואז עובר לעגלה (Cart) לסיום הרכישה. זה flow קלאסי של אי-קומרס — וזה עובד לכל אפליקציית מסחר, לא רק שוקולד.

3 המסכים שלנו:

  1. Home Screen — מסך הבית עם קטגוריות ומוצרים מומלצים
  2. Product Page — עמוד מוצר עם תמונה, מחיר, ותיאור
  3. Cart + Checkout — עגלת קניות עם סיכום וכפתור תשלום
מסך 1: Home Screen — שלב אחרי שלב
  1. פתחו Claude Design → New Project → שם: "שוקלי — Wireframe v1"
  2. כתבו ב-Chat את Prompt 1 מהסעיף הקודם (עם ההתאמות שלכם)
  3. בדקו את התוצאה: האם ה-Navigation Bar למטה? האם יש Search Bar למעלה?
  4. אם חסר אלמנט — כתבו: "Add a promotional banner at the top, below the search bar. Grayscale placeholder."
  5. אם ה-RTL לא נכון — כתבו: "Fix RTL — the search icon should be on the left side, text aligned right"
  6. שמרו את המסך (Save) ומעבר למסך הבא
מסך 2: Product Page
  1. כתבו ב-Chat: "Create a second wireframe — product detail page for the same app. Include: large product image placeholder at top (square), product name in Hebrew, price in NIS (₪89), description text (3 lines), quantity selector (- 1 +), 'Add to Cart' button full width, 'Related Products' section with 3 horizontal cards. Grayscale, RTL, mobile 375px."
  2. בדקו: האם כפתור "הוסף לעגלה" בולט מספיק? גם ב-Wireframe, הCTA צריך להיות האלמנט הכי בולט
  3. בדקו: האם מחיר ₪89 מופיע בכיוון הנכון (הסימן ₪ לפני המספר)?
  4. אם הbackground של כפתור ה-CTA דומה מדי לשאר — כתבו: "Make the Add to Cart button darker — it should be the most prominent element on the page"
מסך 3: Cart + Checkout
  1. כתבו ב-Chat: "Create a third wireframe — cart/checkout page. Include: list of 2 items (product thumbnail, name, quantity, price in NIS), subtotal, delivery fee (₪25), total, promo code input, 'Proceed to Payment' button. Below: delivery address section with placeholder. Grayscale, RTL, mobile 375px."
  2. בדקו: האם הסכום הסופי בולט? האם יש הפרדה ברורה בין המוצרים?
  3. בדקו: שורת "משלוח: ₪25" — האם היא ברורה ולא מסתתרת?
  4. בדקו: האם יש מקום לשדה "קוד קופון"? לקוחות ישראליים מצפים לזה
  5. בדקו: האם כתובת למשלוח כוללת שדה "עיר" ו"כתובת" בנפרד — כנהוג בישראל?

בדיקת ה-User Flow: אחרי שיצרתם את 3 המסכים, שחקו את תפקיד המשתמש. התחילו ב-Home Screen. לחצו (בדמיון) על מוצר. הגעתם ל-Product Page. לחצו "הוסף לעגלה". הגעתם ל-Cart. שאלו את עצמכם: האם יכולתי לחזור אחורה? האם יש כפתור "המשך בקניות"? האם ה-Navigation Bar מאפשר לי לחזור ל-Home? User Flow שלא מאפשר חזרה = חוויה גרועה.

שימו לב שכל מסך עוסק ב-פעולה אחת: Home Screen = גלישה וגילוי. Product Page = בחירה והוספה. Cart = סיכום ותשלום. אם מסך עושה יותר מדי דברים — הוא מבלבל. אם אתם מוצאים שמסך ה-Cart מכיל גם המלצות, גם קופון, גם כתובת, גם פרטי תשלום — פיצלו: Cart עמוד אחד, Checkout (כתובת + תשלום) עמוד שני. 4 מסכים עדיפים על 3 מסכים עמוסים.

טיפ: עקביות בין מסכים

כשבונים 3 מסכים, ודאו שהNavigaton Bar נראה אותו דבר בכל מסך. אם ב-Home Screen ה-nav bar למטה עם 4 כפתורים — הוא חייב להיות זהה ב-Product Page וב-Cart. כתבו ל-Claude: "Keep the bottom navigation bar consistent across all 3 screens — same 4 tabs, same layout."

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

אפליקציות ישראליות כוללות כמעט תמיד אלמנטים שלא נמצאים באפליקציות אמריקאיות: (1) מחירים בש"ח — סימן ₪ לפני המספר, (2) משלוח — ציון אזורי משלוח (גוש דן, חיפה והקריות, ירושלים), (3) WhatsApp button — כמעט כל אפליקציה ישראלית קטנה מאפשרת יצירת קשר ב-WhatsApp, (4) תנאי שימוש בעברית — חובה חוקית. ודאו שה-Wireframe כולל placeholders לאלמנטים אלה.

עשה עכשיו 4 דקות

הציגו את 3 המסכים שיצרתם זה לצד זה (אפשר צילום מסך של כל אחד). בדקו: האם ה-User Flow הגיוני? האם משתמש שרואה את Home Screen מבין מה ללחוץ כדי להגיע ל-Product Page? ומשם ל-Cart? אם לא — מה חסר? כתבו: "חסר ________"

בינוני 15 דקות חינם תרגול

Wireframe לאתר — Homepage + Inner Page

Wireframe לאתר שונה מWireframe לאפליקציה בכמה דרכים משמעותיות. באתר יש יותר תוכן, מבנה Grid רחב יותר, ורוב המשתמשים גוללים למטה (scroll) במקום לנווט בין מסכים. נבנה 2 עמודים: Homepage ועמוד שירות פנימי.

הבדלים מרכזיים בין Wireframe לאפליקציה לWireframe לאתר:

פרמטר אפליקציית מובייל אתר דסקטופ
רוחב Canvas 375px 1280px
ניווט Bottom Tab Bar (4-5 כפתורים) Header Navigation (4-7 פריטים)
Scroll מועט — מסכים קצרים רב — עמודים ארוכים
Grid עמודה אחת 2-4 עמודות
CTA כפתור אחד בולט (Full Width) יכול להיות כמה CTAs במקומות שונים
דוגמה מייצגת: אתר חברת ייעוץ עסקי ישראלית

חברת "אופק ייעוץ" מתל אביב רוצה אתר חדש. יש להם 3 שירותים (ייעוץ עסקי, ייעוץ פיננסי, ייעוץ שיווקי), 12 לקוחות מרוצים, ומספר טלפון. הם לא צריכים את מקום מגוריו של כל עובד — הם צריכים אתר שמביא לידים.

זה דיוק ישראלי: רוב העסקים הקטנים בישראל לא צריכים אתר עם 30 עמודים. הם צריכים Homepage שמושכת, עמוד שירות שמסביר מה הם עושים, ודרך ליצור קשר (טלפון, WhatsApp, טופס). Wireframe ל-2 עמודים מספיק — ואם הלקוח שמח, אפשר להוסיף עוד עמודים אחר כך.

ההבדל בגישה: ב-wireframe לאפליקציה חשבתם על מסכים (Screens) — יחידות עצמאיות שעוברים ביניהן. ב-wireframe לאתר חשבו על סקשנים (Sections) — בלוקים אנכיים שנערמים אחד מעל השני בעמוד אחד ארוך. Homepage טיפוסי של עסק ישראלי כולל 5-8 סקשנים, כל אחד עם תפקיד ברור:

  1. Hero: כותרת + משפט משנה + כפתור CTA ("צרו קשר" / "קבעו פגישה")
  2. שירותים: 3-4 כרטיסים עם שם שירות + תיאור קצר + אייקון
  3. נתונים / הוכחה חברתית: מספרים ("150+ לקוחות", "12 שנות ניסיון")
  4. המלצות: 2-3 ציטוטים מלקוחות מרוצים
  5. טופס יצירת קשר: שם, טלפון, אימייל, הודעה, שלח
  6. Footer: לוגו, קישורים, רשתות חברתיות, כתובת
Homepage Wireframe — Desktop
  1. כתבו ב-Chat: "Create a desktop homepage wireframe (1280px) for an Israeli consulting firm 'Ofek Consulting'. RTL, Hebrew placeholder text. Grayscale. Sections from top to bottom: (1) Header — logo right, nav 4 items center, phone number left. (2) Hero — large headline + subtitle + CTA button. (3) 3 Service cards in a row. (4) Stats bar — 3 numbers (150+ clients, 12 years, 98% satisfaction). (5) Testimonials — 2 quote cards. (6) Contact form — name, email, phone, message, send button. (7) Footer — logo, nav links, social icons, address."
  2. בדקו: האם ה-Header נראה מקצועי? מספר טלפון בצד שמאל (כי RTL)?
  3. בדקו: האם ה-Hero Section תופס מספיק מקום (לפחות 40% מהמסך)?
Inner Page Wireframe — שירות
  1. כתבו: "Create an inner service page wireframe for the same consulting site. Title: 'ייעוץ עסקי'. Sections: (1) Same header as homepage. (2) Page title + breadcrumb. (3) Service description — 2 paragraphs. (4) 4 benefits in 2x2 grid, each with icon placeholder + title + text. (5) Process — 4 steps numbered vertically. (6) Pricing — table with 3 columns (basic ₪2,500/mo, pro ₪5,000/mo, enterprise custom). (7) CTA section. (8) Same footer."
  2. בדקו עקביות: Header ו-Footer זהים ל-Homepage?
  3. בדקו: טבלת תמחור — האם המחירים בש"ח מוצגים נכון?
עשה עכשיו 3 דקות

השוו את ה-Wireframe של האתר לאחד האתרים הישראליים שאתם מכירים. מה דומה? מה שונה? האם חסר סקשן שנפוץ באתרים ישראליים (למשל: WhatsApp button, סרגל נגישות, Google Maps)? כתבו: "חסר לי סקשן _______"

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

מה קורה: בניתם wireframe מושלם — hero, services, testimonials, contact — אבל שכחתם שאתר ישראלי חייב סרגל נגישות (חוק שוויון זכויות לאנשים עם מוגבלות), הצהרת נגישות בfooter, ואייקון WhatsApp צף. הלקוח מקבל את ה-prototype ושואל "ומה עם הנגישות?".

למה זה מפתה: כי ב-wireframe אתם מתמקדים במבנה ושוכחים חובות רגולטוריות.

מה לעשות במקום: הוסיפו ל-wireframe checklist ישראלי: סרגל נגישות (placeholder), WhatsApp button, תנאי שימוש/מדיניות פרטיות ב-footer, ו-Google Maps embed placeholder אם יש כתובת פיזית. גם אם אלה placeholder — הלקוח צריך לדעת שהם יהיו שם.

בינוני 20 דקות חינם תרגול

מ-Wireframe ל-Mockup — הוספת צבעים ותוכן

אחרי שהלקוח אישר את המבנה (Wireframe), הגיע הזמן "ללבוש" את השלד. המעבר מ-Wireframe ל-Mockup הוא הרגע שבו ה-Design System מפרק 7 נכנס לפעולה. במקום לבחור צבעים מאפס — פשוט מיישמים את ה-DS שכבר בניתם.

זה אחד הרגעים שבהם כל ההשקעה מפרקים קודמים משתלמת. אם בניתם DS מסודר בפרק 7, ההמרה מ-Wireframe ל-Mockup לוקחת דקות. אם דילגתם על פרק 7 — תצטרכו לבחור צבעים, פונטים ו-spacing עכשיו, בזמן אמת, תחת לחץ. זה ההבדל בין "יש לי מערכת" ל-"אני ממציא בזמן אמת".

שלבי ההמרה בפועל: יש 5 שלבים ברורים, וחשוב לעשות אותם בסדר. אל תתחילו להחליף placeholder text לפני שיישמתם DS — כי אז תגלו שהפונט שבחרתם לא מתאים לאורך הטקסט שהוספתם.

מ-Wireframe ל-Mockup — 5 שלבים
  1. יישום DS: כתבו ב-Chat: "Apply the Design System I created for [שם העסק]. Use the Primary color for CTAs, Secondary for accents, Neutral for backgrounds and text." — או אם אתם עובדים עם DS שמור: "Apply DS: [שם ה-DS]"
  2. החלפת Placeholder: כתבו: "Replace all placeholder text with real Hebrew content for a chocolate delivery app. Product names: 'טראפל מריר 72%', 'פרלין אגוזי לוז', 'מארז חגיגי'. Prices: ₪49, ₪39, ₪189."
  3. הוספת תמונות: כתבו: "Replace image placeholders with relevant placeholder images. Use warm brown tones for the food images." (Claude Design ייצר תמונות AI או ישתמש ב-placeholder מתאים)
  4. Typography: ודאו שהפונטים מתאימים — Heebo/Rubik לעברית (כפי שהגדרתם בפרק 7)
  5. RTL Check: העבירו את ה-checklist מפרק 9 — כיוון טקסט, אייקונים, מספרים

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

טיפ לתוכן עברי ב-Mockup: כשמחליפים placeholder text בעברית, יש כמה דברים לשים לב אליהם. ראשית, טקסט עברי קצר יותר מאנגלי (בממוצע 20-30% פחות תווים לאותו מסר), אז כפתורים ו-cards עשויים להצטמצם. שנית, מספרי טלפון ישראליים (05X-XXXXXXX) ארוכים יותר מאמריקאיים, אז ודאו שיש מספיק מקום. שלישית, כתובות ישראליות הן בפורמט שונה (רחוב + מספר + עיר), לא כמו כתובות אמריקאיות עם State ו-ZIP. כל אלה דברים שלמדתם בפרק 9 ושעכשיו מתחברים לעבודה מעשית.

עשה עכשיו 3 דקות

קחו את מסך ה-Product Page שלכם (Mockup). בדקו: (1) האם שם המוצר בעברית לא חתוך? (2) האם המחיר ₪89 מוצג בכיוון הנכון? (3) האם כפתור "הוסף לעגלה" רחב מספיק לטקסט העברי? כתבו: "צריך לתקן ________"

מסגרת החלטה: מתי לדלג על Wireframe ולעבוד ישר על Mockup?
מצב החלטה סיבה
פרויקט חדש ללקוח חדש תמיד Wireframe קודם אתם לא יודעים מה הוא רוצה — שינויים מבניים בMockup יקרים
לקוח קבוע עם DS מוגדר אפשר לדלג ל-Mockup כבר יודעים מה הוא אוהב, המבנה דומה לפרויקטים קודמים
פרויקט פנימי שלכם Mockup ישר אתם הלקוח — אם תרצו לשנות, אתם תחליטו מיד
Pitch למשקיעים Mockup + Prototype משקיעים רוצים לראות "מוצר" — wireframe אפור לא מרשים
עשה עכשיו 5 דקות

קחו את ה-Wireframe של מסך Home Screen מהסעיף הקודם. כתבו ב-Chat: "Transform this wireframe into a full-color mockup. Use warm brown (#6B4226) as primary, cream (#F5E6D3) as background, and dark brown (#3D2314) for text. Heebo font." בדקו: האם כל האלמנטים שמרו על המיקום שלהם? כתבו: "שינוי מפתיע: ________"

טעות נפוצה: לא לשמור את ה-Wireframe לפני ההמרה

מה קורה: ממירים Wireframe ל-Mockup — ואז הלקוח אומר "חזור לגרסה האפורה, אני רוצה לשנות את המבנה". אין גרסה אפורה. התחילו מחדש.

מה לעשות במקום: לפני ההמרה: Duplicate את הפרויקט. שם: "שוקלי — Wireframe v1 (LOCKED)". עכשיו עבדו על העותק. תמיד תהיה לכם גרסת Wireframe נקייה לחזור אליה.

בינוני 20 דקות חינם תרגול

מ-Mockup ל-Prototype — אינטראקטיביות בסיסית

Mockup הוא תמונה יפה. Prototype הוא חוויה. ההבדל: ב-Prototype הלקוח לוחץ על כפתור ומשהו קורה. ב-Claude Design, המעבר מ-Mockup ל-Prototype מתבסס על היכולת לייצא HTML אינטראקטיבי — קוד שאפשר לפתוח בדפדפן ולנווט בו.

למה Prototype חשוב דווקא בשוק הישראלי? לקוחות ישראליים — בין אם זה בעל עסק שרוצה אפליקציה, או משקיע שבודק סטארטאפ — רוצים לגעת. "תראה לי" לא מספיק. "תתן לי ללחוץ" — זה מה שסוגר עסקה. Prototype שהלקוח יכול לפתוח בנייד שלו ולנווט בו כאילו זה מוצר אמיתי — שווה אלף תמונות. פרילנסר שמציע שירות wireframe + mockup + prototype ב-₪2,500-4,000 מספק ערך שפעם עלה ₪15,000-25,000 בסטודיו עיצוב מסורתי.

מה Claude Design יכול לעשות ב-Prototype:

מה Claude Design לא יכול לעשות (עדיין):

החשוב: אל תנסו להפוך את ה-Prototype למוצר אמיתי. זה לא תפקידו. Prototype הוא כלי מכירה וכלי תקשורת — הוא מראה ללקוח, למשקיע, או לשותף מה אתם מתכוונים לבנות. הבנייה עצמה? בפרק 11 (Design-to-Code Handoff) עם Claude Code.

3 רמות של Prototype: לא כל Prototype צריך את אותה רמת פירוט. זה תלוי במטרה ובלקוח:

רמה מה כולל מתאים ל- זמן הכנה
Basic ניווט בין מסכים בלבד אישור מבנה מלקוח, פגישה ראשונה 15-20 דקות
Standard ניווט + hover effects + mobile menu רוב הפרויקטים, הצגה לצוות 30-45 דקות
Premium ניווט + hover + forms + tab switching + responsive Pitch למשקיעים, דמו מוצר 60-90 דקות

לפרילנסרים: אפשר לתמחר את 3 הרמות בנפרד. Basic = חלק מחבילת המאפיון. Standard = ₪500 תוספת. Premium = ₪1,000-1,500 תוספת. הלקוח מבין את ההבדל כשמראים לו טבלה ברורה, ובוחר את הרמה שמתאימה לתקציב שלו. בפרק 12 נעמיק בתמחור.

הפיכת Mockup ל-Prototype — שלב אחרי שלב
  1. הגדירו את ה-Flow: כתבו ב-Chat: "I have 3 screens: Home, Product, Cart. Create an interactive HTML prototype where: clicking a product card on Home navigates to Product page, clicking 'Add to Cart' on Product navigates to Cart page, clicking the Home tab always returns to Home."
  2. הוסיפו Hover Effects: כתבו: "Add hover effects: buttons change color on hover, product cards get a subtle shadow on hover, navigation tabs show an underline on hover."
  3. הוסיפו מצבי טופס: כתבו: "Add form interactions: input fields show a border color change on focus, the 'Proceed to Payment' button changes from gray to primary color when all fields are filled."
  4. בדקו Responsive: כתבו: "Make sure the prototype works on both mobile (375px) and desktop (1280px). Test both viewports."
  5. ייצאו HTML: Export → HTML → שמרו את הקובץ
עשה עכשיו 5 דקות

קחו את ה-Mockup שיצרתם בסעיף הקודם. כתבו ב-Chat: "Add hover effects to all buttons and product cards." בדקו ב-Preview: האם Hover עובד? האם שינוי הצבע מרגיש טבעי? אם ה-hover חזק מדי (צבע חד מדי) — כתבו: "Make hover effects more subtle — reduce opacity change to 10%"

עשה עכשיו 3 דקות

פתחו את ה-Prototype ב-Preview ובדקו: לחצו על כרטיס מוצר — האם הוא מנווט לעמוד המוצר? לחצו "הוסף לעגלה" — האם זה מעביר לעגלה? לחצו על Tab בית — האם חוזרים ל-Home? ספרו: כמה לחיצות מ-Home ועד ל-Checkout? כתבו: "מספר לחיצות עד Checkout: ___". אם יותר מ-4 — יש בעיה ב-User Flow.

בינוני 15 דקות חינם כלי

ייצוא HTML אינטראקטיבי

הרגע שבו ה-Prototype עוזב את Claude Design והופך לקובץ עצמאי שאפשר לפתוח בכל דפדפן. הייצוא ל-HTML הוא אחד היתרונות הגדולים של Claude Design על פני Figma — ב-Figma צריך Figma Mirror או לשלם ל-plugin. פה מקבלים קובץ HTML שעובד.

למה Single File HTML? כשאתם שולחים ללקוח ישראלי prototype, אתם רוצים שזה יהיה פשוט ככל האפשר. לא ZIP שצריך לחלץ. לא תיקייה עם 15 קבצים. קובץ HTML אחד שפותחים בדפדפן — וזהו. Claude Design יכול לייצא את כל ה-CSS, ה-JavaScript, ואפילו תמונות (כ-base64) בתוך קובץ אחד. הקובץ אמנם יהיה גדול יותר, אבל לצורך Prototype — זה בסדר גמור. אפשר גם להעלות את הקובץ ל-Cloudflare Pages (חינם!) או Netlify Drop ולשלוח קישור במקום.

הקשר לפרק הבא: ה-HTML שתייצאו כאן הוא בדיוק הקובץ שתפתחו ב-Claude Code בפרק 11. שם תשדרגו אותו — תוסיפו JavaScript אמיתי, responsive מלא, ו-deploy לאתר חי. לכן שמרו את הקובץ היטב ותנו לו שם ברור.

3 אפשרויות לייצוא:

אפשרות מתי להשתמש יתרונות חסרונות
Single HTML File שליחה ישירה ללקוח, Prototype פשוט קובץ אחד, קל לשלוח, עובד בכל מקום קובץ גדול, לא מתאים לsite מורכב
Multi-file (HTML+CSS+JS) העברה ל-Claude Code בפרק 11 קוד נקי, קל לערוך, modular צריך ZIP לשליחה, מורכב יותר
Deploy ישיר (URL) לקוח שרוצה "לראות אונליין" לקוח לוחץ על קישור, בלי הורדות דורש Cloudflare Pages/Netlify (חינם)
ייצוא HTML — הנחיות
  1. לחצו Export → HTML (או כתבו ב-Chat: "Export this prototype as a single HTML file with embedded CSS and JavaScript")
  2. בחרו Single File — כל ה-CSS וה-JS בתוך קובץ אחד (קל יותר לשלוח)
  3. שמרו את הקובץ עם שם ברור: shokli-prototype-v1.html
  4. פתחו את הקובץ בדפדפן Chrome → בדקו: האם כל הלחיצות עובדות?
  5. בדקו מובייל: לחצו F12 → Toggle Device Toolbar → בחרו iPhone 14 → האם זה עובד?

אחרי הייצוא: אל תשלחו את הקובץ ישר ללקוח. ב-100% מהמקרים יש משהו קטן שצריך לתקן. אולי פונט לא נטען, אולי RTL לא עבד, אולי כפתור אחד לא מנווט לעמוד הנכון. 5 דקות בדיקה חוסכות מייל מביך מהלקוח.

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

בדיקה מה לבדוק מה לתקן
RTL טקסט עברי מיושר ימינה, מספרים תקינים הוסיפו dir="rtl" ל-HTML אם חסר
פונטים Heebo נטען, לא fallback ל-Arial ודאו Google Fonts link בhead
ניווט כל לחיצה מנווטת למסך הנכון בדקו anchor links / JavaScript handlers
מובייל לא גולש, כפתורים לחיצים, טקסט קריא בדקו viewport meta tag ו-media queries
מהירות נטען תוך 2 שניות אם תמונות כבדות — בקשו מClaude לדחוס
עשה עכשיו 3 דקות

ייצאו את ה-Prototype שלכם ל-HTML. פתחו בדפדפן. עברו על 5 הבדיקות בטבלה למעלה. כמה עברתם? כתבו: "עברתי __/5 בדיקות. צריך לתקן: ________"

טעות נפוצה: לשלוח ללקוח HTML בלי לבדוק בדפדפן אחר

מה קורה: ה-HTML נראה מושלם אצלכם ב-Chrome. שלחתם ללקוח. הוא פותח ב-Safari — חצי מה-CSS שבור. או פותח בנייד — הכל יוצא מהמסגרת.

מה לעשות במקום: בדקו בלפחות 2 דפדפנים (Chrome + Safari/Edge) ובלפחות viewport אחד של מובייל. זה 3 דקות שחוסכות מייל "זה לא עובד אצלי".

בינוני 10 דקות חינם אסטרטגיה

הצגת Prototype ללקוח — Best Practices

Prototype מוכן. איך שולחים אותו ללקוח בלי שיקרה אחד מהדברים הבאים? (א) הלקוח חושב שזה המוצר הסופי. (ב) הלקוח מבלבל בין feedback על מבנה ל-feedback על צבע. (ג) הלקוח שולח WhatsApp עם "אהבתי" ואין לכם מה לעשות עם זה.

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

5 כללים להצגת Prototype
  1. הגדירו ציפיות מראש: "מה שאני שולח לך זה דמו — אפשר ללחוץ ולנווט, אבל זה לא המוצר הסופי. אין פה בסיס נתונים, אין תשלום אמיתי, והנתונים הם placeholder."
  2. תנו הנחיות ל-feedback: "אני רוצה שתבדוק 3 דברים: (1) האם המבנה הגיוני? (2) האם ה-flow מרגיש טבעי? (3) האם חסר משהו קריטי?"
  3. הגבילו את סבב ה-feedback: "יש לנו 2 סבבי תיקונים בלי תוספת עלות. סבב ראשון — הערות על המבנה. סבב שני — הערות על העיצוב."
  4. שלחו קישור, לא קובץ מצורף: העלו ל-Cloudflare Pages (חינם) או ל-Netlify Drop — הלקוח לוחץ על קישור ורואה ישר. לא צריך להוריד קובץ ולפתוח.
  5. בקשו feedback כתוב ומסודר: שלחו טופס feedback (Google Forms / Typeform) עם שאלות ממוקדות — לא WhatsApp פתוח.
דוגמה מייצגת: הודעת WhatsApp ללקוח

"היי [שם], הכנתי לך דמו ראשון של האפליקציה. אפשר ללחוץ על הקישור ולנווט בין המסכים בדיוק כמו שהמשתמש יעשה. שים לב — זה לא המוצר הסופי, אין כאן חיבור לבסיס נתונים, והתמונות הן placeholder. אני רוצה שתבדוק: (1) האם המסלול מסך הבית → מוצר → עגלה מרגיש הגיוני? (2) האם חסר משהו שחשוב לך? (3) יש משהו שמפריע? מלא את הטופס הזה [קישור] עם ההערות. יש לנו סבב תיקונים אחד על המבנה, ואחריו סבב על העיצוב. [קישור ל-Prototype]"

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

שפת גוף דיגיטלית: שימו לב לתגובה הראשונה של הלקוח. "וואו, נראה מדהים!" זה סימן טוב — אבל עדיין צריכים feedback מובנה. "אוקי, ראיתי" בלי שום התלהבות — זה סימן שמשהו לא עבד, אבל הלקוח לא יודע מה. במקרה כזה, התקשרו (לא WhatsApp) ועברו על ה-Prototype ביחד במסך משותף (Zoom/Google Meet). הרבה יותר קל ללקוח להגיד "כאן משהו מפריע" כשהוא מצביע על המסך בזמן אמת.

עשה עכשיו 4 דקות

כתבו הודעת WhatsApp (או אימייל) ללקוח דמיוני שבה אתם שולחים את ה-Prototype. השתמשו ב-5 הכללים למעלה. כמה מילים ההודעה שלכם? אם מעל 150 — קצרו. אם מתחת ל-60 — הוסיפו הנחיות feedback. כתבו את ההודעה כאן: ________

בינוני 10 דקות חינם אסטרטגיה

Iteration עם לקוח — Workflow של Feedback

הלקוח ראה את ה-Prototype ויש לו הערות. עכשיו מתחיל ה-Feedback Loop (מעגל משוב) — התהליך שבו מקבלים הערות, מתקנים, שולחים שוב, ועוד פעם, עד שיש אישור. בלי workflow מסודר, זה יכול להימשך שבועות. עם workflow — זה 2-3 סבבים.

חוק הזהב של feedback על Prototype: הפרידו תמיד בין feedback מבני ("תזיזו את הטופס") ל-feedback עיצובי ("הכחול חזק מדי"). כשהלקוח שולח הכל ביחד, אתם לא יודעים מאיפה להתחיל. הפתרון: feedback form מובנה שמכריח את הלקוח לחשוב לפי קטגוריות.

הנה ה-workflow המומלץ — 3 שלבים ברורים:

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

אחרי 3 סבבים — אישור סופי. כל דבר נוסף = scope change = עלות נוספת. הגדירו את זה מראש בהצעת המחיר.

מסגרת החלטה: איך להגיב ל-feedback מלקוח
סוג ה-feedback דוגמה פעולה
שינוי מבנה "תזיז את הטופס למעלה" חזרו ל-Wireframe → עדכנו → Mockup מחדש
שינוי עיצובי "הכחול חזק מדי" עדכנו ב-Mockup → עדכנו DS → Export חדש
הוספת פיצ'ר "אני רוצה גם דף בלוג" הגדירו זה כ-scope change → תמחרו בנפרד
תיקון באג "הכפתור לא עובד במובייל" תקנו ב-HTML → בדקו ב-2 דפדפנים → Export
feedback לא ברור "זה לא מרגיש נכון" חזרו ללקוח עם 3 שאלות ממוקדות לפני שמתחילים לעבוד
Feedback Form — תבנית מוכנה

צרו Google Form או Typeform עם השאלות הבאות. שלחו ללקוח במקום לבקש "תגיד לי מה אתה חושב":

  1. מבנה כללי: "האם סדר הסקשנים (hero, services, testimonials, contact) הגיוני? כן/לא — אם לא, מה הייתם מזיזים?"
  2. User Flow: "ניסית לנווט מהמסך הראשי לעמוד המוצר ולעגלה — האם ה-flow היה טבעי? כן/לא"
  3. תוכן: "האם הכותרות והטקסטים ברורים? יש משהו שהייתם משנים?"
  4. מובייל: "פתחת את ה-Prototype בנייד? האם הכל נראה תקין? כן/לא"
  5. חסר משהו: "האם יש אלמנט שחסר ושחשוב לך? (מקסימום 3 דברים)"
  6. עדיפות: "מכל מה שציינת — מה הדבר הכי חשוב לתקן קודם?"
טיפ לפרילנסרים: תמחור סבבי feedback

הגדירו מראש בהצעת המחיר: "השירות כולל 2 סבבי תיקונים. סבב = עד 10 שינויים. סבב נוסף — ₪350." זה מונע מצב שבו הלקוח שולח 47 הערות ב-17 הודעות WhatsApp. אם הלקוח מבקש שינוי מבנה מהותי (למשל "תחליף את כל המבנה") — זה scope change, לא סבב תיקונים. תמחרו בנפרד.

טעות נפוצה: לקבל feedback בWhatsApp במקום בטופס

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

למה זה מפתה: כי WhatsApp קל ומהיר, והלקוח מרגיש ש"הוא רק שולח הודעה".

מה לעשות במקום: אמרו ללקוח: "אשמח לשמוע! בשביל שלא אפספס כלום, מלא את הטופס הזה [קישור]. לוקח 5 דקות ומכסה הכל." רוב הלקוחות ישתפו פעולה אם הטופס קצר וממוקד. אם הם בכל זאת שולחים WhatsApp — אתם מעתיקים את ההערות לטופס ומסמנים "הועתק מWhatsApp של הלקוח בתאריך X".

עשה עכשיו 3 דקות

צרו Feedback Form (Google Forms — חינם) עם 6 השאלות מלמעלה. שמרו את הקישור. מהרגע הזה, בכל פעם שתשלחו Prototype ללקוח — תשלחו גם את הטופס הזה. קישור הטופס שלי: ________

בינוני 90 דקות חינם תרגול

תרגילים מעשיים

שלושת התרגילים מכסים את שלושת השלבים: Wireframe → Mockup → Prototype. מומלץ לעשות אותם בסדר — כל תרגיל בונה על הקודם. התוצרים ישמשו אתכם בפרק 11 (Design-to-Code Handoff), אז שמרו הכל.

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

מה תצטרכו: חשבון Claude Pro/Max פעיל, Design System מפרק 7 (או צבעים שבחרתם), ודפדפן Chrome לבדיקת HTML מיוצא. אם אין לכם DS מוכן — תוכלו ליצור DS מהיר תוך כדי תרגיל 2, אבל זה יאט אתכם ב-15 דקות.

תרגיל 1: Wireframe ל-3 מסכים של אפליקציה ישראלית (30 דקות)

מטרה: לבנות סט Wireframe שלם שמציג User Flow מלא — מהרגע שמשתמש פותח את האפליקציה ועד שמבצע רכישה.

הקשר: ה-wireframes האלה ישמשו בסיס לתרגילים 2 ו-3 ולפרק 11 (Design-to-Code). שמרו הכל.

  1. בחרו אפליקציה ישראלית (או השתמשו ב"שוקלי"): תנו שם, תארו את השירות, הגדירו קהל יעד
  2. פתחו Claude Design → New Project → שם: "[שם] — Wireframe v1"
  3. בנו מסך 1 — Home Screen: כתבו prompt לפי מבנה 5 המרכיבים. ודאו RTL
  4. בנו מסך 2 — Product/Service Page: ודאו שיש CTA בולט, מחיר בש"ח, ותיאור
  5. בנו מסך 3 — Cart/Contact/Action: ודאו שיש סיכום, CTA סופי, ואישור
  6. בדקו עקביות: Navigation Bar זהה בכל 3 המסכים
  7. שמרו + Duplicate (גיבוי לפני המרה ל-Mockup)

תוצר צפוי: 3 מסכי Wireframe בגווני אפור, עקביים בעיצוב, עם User Flow ברור מ-Home → Product → Cart.

תרגיל 2: המרה ל-Mockup עם Design System (30 דקות)

מטרה: להמיר את ה-Wireframe ל-Mockup מלא עם DS מפרק 7 — צבעים, פונטים, ותוכן אמיתי בעברית.

דגש ישראלי: ודאו שמחירים בש"ח, מספרי טלפון 05X, וכתובות ישראליות מופיעים נכון.

  1. Duplicate את פרויקט ה-Wireframe → שנו שם ל-"[שם] — Mockup v1"
  2. יישמו DS: כתבו ב-Chat: "Apply Design System with [Primary color], [Secondary color]. Heebo font."
  3. החליפו placeholder text בתוכן אמיתי בעברית — שמות מוצרים, מחירים, תיאורים
  4. הוסיפו תמונות (AI-generated או placeholder מתאים)
  5. בדקו RTL Checklist מפרק 9: כיוון טקסט, אייקונים, מספרים
  6. השוו ל-Wireframe המקורי: האם המבנה נשמר? האם שום אלמנט זז?
  7. שמרו + ייצאו PDF (לתיעוד)

תוצר צפוי: 3 מסכי Mockup צבעוניים, עם DS מיושם, תוכן עברי אמיתי, ומבנה זהה ל-Wireframe.

תרגיל 3: Prototype אינטראקטיבי + ייצוא HTML (30 דקות)

מטרה: להפוך את ה-Mockup ל-Prototype לחיץ ולייצא HTML שעובד בדפדפן.

למה זה חשוב: ה-HTML שתייצאו כאן הוא נקודת ההתחלה של פרק 11 — Design-to-Code Handoff. ככל שהHTML נקי וטוב יותר, ככה ההמרה לקוד עובד תהיה קלה יותר.

  1. הגדירו ניווט: כתבו ב-Chat שרוצים שלחיצה על כרטיס מוצר תנווט לעמוד מוצר
  2. הוסיפו Hover Effects לכל הכפתורים וכרטיסי המוצרים
  3. הוסיפו Mobile Menu (hamburger) אם יש גרסת מובייל
  4. ייצאו ל-HTML → שמרו כ-[name]-prototype-v1.html
  5. פתחו ב-Chrome → בדקו את 5 הבדיקות מטבלת ה-QA
  6. פתחו ב-Safari/Edge → בדקו שוב
  7. פתחו DevTools → Mobile View → בדקו במובייל
  8. תקנו כל מה שלא עובד → Export חדש

תוצר צפוי: קובץ HTML אינטראקטיבי שעובד ב-Chrome, Safari ומובייל. כל הכפתורים עובדים, ניווט בין מסכים פועל, RTL תקין.

בונוס: העלו את ה-HTML ל-Cloudflare Pages (חינם) או Netlify Drop. שלחו את הקישור לחבר ובקשו ממנו לבדוק במובייל. זה הסימולציה הכי אמיתית של "שליחת prototype ללקוח" — ותגלו בעיות שלא ראיתם על המסך שלכם.

טיפ: מה לעשות אם ה-HTML לא עובד

בעיות נפוצות בHTML מיוצא: (1) פונטים לא נטענים — ודאו שיש Google Fonts link ב-head. אם Claude שכח — הוסיפו ידנית: <link href="https://fonts.googleapis.com/css2?family=Heebo:wght@400;700&display=swap" rel="stylesheet">. (2) RTL שבור — ודאו שיש dir="rtl" על ה-html tag. (3) JavaScript לא רץ — בדקו שאין שגיאות ב-Console (F12 → Console). אם תקועים — זה בדיוק מה שפרק 11 פותר עם Claude Code.

שגרת עבודה — Wireframes & Prototypes

מאפיון הוא לא פעולה חד-פעמית — זו מיומנות שמשתפרת עם תרגול. ככל שתבנו יותר wireframes, ככה ה-prompts שלכם יהיו מדויקים יותר, ההמרה ל-Mockup תהיה מהירה יותר, וה-Prototypes יהיו חלקים יותר. השגרה הבאה מבטיחה שלא תפסיקו לתרגל בין פרויקט לפרויקט.

בנוסף לשגרת ה-DS מפרק 7 ושגרת ה-RTL מפרק 9, הוסיפו את שגרת המאפיון:

תדירות משימה זמן
לכל פרויקט חדש התחילו ב-Wireframe אפור — לעולם אל תדלגו ישר ל-Mockup ללקוח חדש 15-30 דקות
לכל פרויקט חדש Duplicate את ה-Wireframe לפני המרה ל-Mockup — תמיד שמרו גרסת שלד 2 דקות
שבועי בדקו Prototypes פתוחים: האם יש feedback שלא טופל? עדכנו ושלחו חזרה 15 דקות
שבועי עדכנו את ספריית ה-Wireframe Prompts — הוסיפו prompts שעבדו טוב, מחקו כאלה שלא 10 דקות
חודשי סקרו את ה-Prototypes שייצאתם: האם ה-HTML עדיין עובד? עדכנו קישורים שבורים 20 דקות
חודשי בנו wireframe לרעיון חדש — גם אם אין לקוח. תרגול שוטף שומר על המהירות 30 דקות

שימו לב: השגרה הזו מתווספת לשגרת ה-DS מפרק 7 (בדיקת עדכוני DS) ולשגרת ה-RTL מפרק 9 (בדיקת RTL לפני כל ייצוא). אל תחליפו — הוסיפו. עם הזמן, כל 3 השגרות יהפכו לאוטומטיות ויקחו 5-10 דקות מהזמן שלוקח לכם עכשיו.

כמה עולה שירות מאפיון? תמחור מומלץ לשוק הישראלי

פרילנסרים ישראליים שמשתמשים ב-Claude Design יכולים לתמחר שירות מאפיון לפי שלבים. הנה הערכה ריאלית בהתבסס על זמני העבודה מהפרק הזה:

שירות זמן עבודה טווח מחירים מומלץ
Wireframe בלבד (3-5 מסכים) 1-2 שעות ₪500-1,000
Wireframe + Mockup 2-4 שעות ₪1,000-2,500
Wireframe + Mockup + Prototype 4-8 שעות ₪2,500-5,000
Full Package (+ 2 סבבי תיקונים) 6-12 שעות ₪4,000-8,000

אלה הערכות בלבד ותלויות ברמת המורכבות, בניסיון שלכם, ובתקציב הלקוח. בפרק 12 נעמיק בתמחור ובבניית חבילות שירות.

עשה עכשיו 2 דקות

מדדו כמה זמן לקח לכם לבנות את ה-Wireframe הראשון (מסך Home). חלקו ב-3 (סבבי iteration ממוצעים). הכפילו ב-3 (מסכים). זה זמן ה-Wireframe הצפוי שלכם לפרויקט. כתבו: "זמן wireframe ל-3 מסכים: ___ דקות. מחיר שאקבע: ₪___"

אם אתם עושים רק דבר אחד מהפרק הזה 30 דקות

בנו Wireframe ל-3 מסכים של האפליקציה או האתר שאתם צריכים הכי הרבה עכשיו. לא Mockup, לא Prototype — רק Wireframe אפור. שלחו אותו ללקוח (או לעצמכם, אם זה פרויקט פנימי) עם השאלה: "האם המבנה הזה הגיוני?" התשובה שתקבלו תחסוך לכם שעות של עבודה מיותרת על עיצוב שצריך לשנות. Wireframe שלוקח 15 דקות חוסך 3 שעות של redesign.

בדוק את עצמך — 5 שאלות הבנה

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

  1. מדוע חשוב להתחיל ב-Wireframe אפור ולא ישר ב-Mockup — גם כשClaude Design מייצר עיצוב מלא תוך דקות? (רמז: חשבו על מה הלקוח מתמקד בו כשהוא רואה צבעים)
  2. מה ההבדל בין Lo-Fi Wireframe ל-Mid-Fi Wireframe — ומתי כל אחד מתאים? (רמז: חשבו על השלב בפרויקט ועל רמת הפירוט שהלקוח צריך)
  3. למה חשוב ל-Duplicate את ה-Wireframe לפני המרה ל-Mockup? (רמז: חשבו מה קורה כשהלקוח רוצה לשנות מבנה אחרי שכבר הוספתם צבעים)
  4. מה ההבדל בין feedback על "מבנה" ל-feedback על "עיצוב" — ולמה חשוב להפריד ביניהם? (רמז: חשבו על עלות השינוי בכל שלב)
  5. מדוע עדיף לשלוח ללקוח קישור ל-Prototype במקום קובץ HTML מצורף? (רמז: חשבו על חוויית המשתמש של הלקוח וניהול גרסאות)

4/5 נכון = עברתם. פחות — חיזרו על הסעיפים הרלוונטיים לפני שממשיכים לפרק 11. הבנה של תהליך המאפיון היא בסיס הכרחי ל-Design-to-Code Handoff שנלמד שם.

סיכום הפרק

הפרק הזה לימד אתכם את שלושת שלבי המאפיון: Wireframe (שלד), Mockup (הדמיה), ו-Prototype (דמו אינטראקטיבי). התובנה המרכזית: הסדר חשוב. שינוי ב-Wireframe לוקח 5 דקות — אותו שינוי ב-Prototype לוקח שעה. לכן תמיד מתחילים מאפור, מאשרים מבנה, ורק אז מוסיפים צבעים ואינטראקציה.

ראיתם איך Claude Design מאפשר לכם לבנות Wireframe ב-15 דקות עם prompt מובנה של 5 מרכיבים, להמיר אותו ל-Mockup עם Design System מפרק 7, ולייצא Prototype אינטראקטיבי ב-HTML שלקוח יכול ללחוץ עליו בדפדפן. בשביל עסק קטן או פרילנסר ישראלי, זה כלי שמחליף תהליך שנהג לדרוש Figma, מעצב UX, ושבועות של עבודה.

למדתם גם את הצד העסקי: איך להציג Prototype ללקוח עם 5 כללים ברורים, איך לנהל סבבי feedback מובנים (מבנה → עיצוב → אינטראקציה), ואיך לתמחר שינויים בצורה שמגנה עליכם מ-scope creep. שירות מאפיון (wireframe + mockup + prototype) הוא אחד השירותים הכי אטרקטיביים שפרילנסר יכול למכור — כי הלקוח מקבל "מוצר" שהוא יכול לגעת בו, לפני שהוציא שקל אחד על פיתוח. בפרק 12 נדבר על תמחור ספציפי של שירותים כאלה.

בפרק הבא נעבור ל-Design-to-Code Handoff — מ-Claude Design ל-Claude Code. תקחו את ה-Prototype שבניתם כאן, תייצאו אותו כ-HTML, תפתחו אותו ב-Claude Code, ותהפכו אותו לאתר עובד עם JavaScript, responsive מלא, ו-deploy חי. ה-pipeline המלא: brief → wireframe → mockup → prototype → live website — בלי מפתח.

Checklist — פרק 10
→ פרק 9: עברית ו-RTL ב-Claude Design פרק 11: Design-to-Code Handoff ←