האתר לא מתחיל במסך הבית
לפני שבוחרים צבעים, מערכת או פריימוורק, צריך להחליט מה האתר אמור לעשות. בריף טוב אינו מסמך ארוך לשם עצמו: הוא דרך להוציא מהפרויקט הנחות סמויות, כדי שהעסק, המעצב והמפתח יקבלו את אותן החלטות.
הצ׳קליסט הבא מתאים לאתר תדמית, אתר שירותים או אתר שמטרתו לייצר פניות. לא כל שאלה תקבל תשובה סופית ביום הראשון, אבל לכל שאלה צריך להיות בעלים ותאריך החלטה.
15 שאלות שכדאי לענות עליהן
- מה המטרה העסקית העיקרית? לידים, מכירה, קביעת פגישה, תמיכה או הצגת אמינות? בחרו תוצאה ראשית אחת.
- למי האתר מיועד? הגדירו את קהל היעד, את הבעיה שלו ואת רמת הידע שלו — לא רק גיל או תחום.
- מה ההצעה במשפט אחד? אם קשה להסביר מה אתם מציעים, האתר יתקשה לעשות זאת במקומכם.
- איזו פעולה תרצו שהמבקר יבצע? קבעו CTA מרכזי: טופס, טלפון, WhatsApp, הזמנה או הורדת מסמך.
- אילו עמודים באמת נחוצים? התחילו ממפת אתר מינימלית: בית, שירותים, אודות, FAQ, יצירת קשר — והוסיפו רק מה שמשרת את המסע.
- מי מספק ומאשר את התוכן? הגדירו בעלים לטקסטים, תמונות, תרגומים, אישורים ועדכונים. “נשלים אחר כך” הוא סיכון ללוח הזמנים.
- באילו שפות האתר צריך לעבוד? עברית, אנגלית, רוסית או שפות נוספות? החליטו גם על RTL, כתובות URL, SEO ותחזוקת כל גרסה.
- לאילו מערכות האתר צריך להתחבר? CRM, מערכת דיוור, סליקה, יומן, WhatsApp, אנליטיקה או כלי תמיכה. רשמו מי הבעלים של כל חשבון.
- לאן מגיע ליד חדש ומה קורה אחר כך? הגדירו שדות, התראות, הקצאה לאיש מכירות, זמן תגובה, כפילויות וגיבוי. טופס שעובד אך לא מגיע לאדם הנכון הוא תקלה עסקית.
- איך תדעו שהאתר מצליח? בחרו מדדים שמתאימים למטרה: פניות איכותיות, קביעות, מכירות או שימוש בפיצ׳ר — לא רק כניסות.
- איך ייראה מבנה ה-SEO? הגדירו נושאים, כותרות, כתובות URL, קישורים פנימיים ועמודים שצריכים להופיע בחיפוש. Google ממליצה על תוכן ברור, כתובות תיאוריות ונגישות של המשאבים לסורק.
- מה רמת הנגישות הנדרשת? החליטו על יעד בדיקה, ניווט מקלדת, טקסט חלופי, ניגודיות וטפסים ברורים. WCAG 2.2 היא נקודת ייחוס טובה, לא תחליף לבדיקת משתמשים.
- מהו יעד הביצועים? הגדירו מכשירים, רשתות ועמודים קריטיים לבדיקה. אל תחכו לסוף כדי לגלות שתמונות, סקריפטים או וידאו מאטים את המסלול לליד.
- איזה מידע נאסף ואיך מגינים עליו? פרטו נתוני טפסים, הרשאות, שמירה, מחיקה, ספקי צד שלישי ולוגים. OWASP ASVS נותן בסיס לדרישות אבטחה שאפשר לבדוק מול המפתח.
- מי הבעלים אחרי ההשקה? ודאו מי מחזיק בדומיין, אחסון, קוד, חשבונות צד שלישי, גיבויים, עדכונים ותיקון תקלות. אתר הוא מערכת שצריך לתחזק — לא קובץ שמוסרים ונפרדים ממנו.
מה צריך לצאת מהפגישה
בסוף הבריף צריכים להיות לפחות: מטרה ראשית, קהל, הצעה, מפת אתר, CTA, רשימת אינטגרציות, בעלים לתוכן, שפות, מדדי הצלחה, דרישות נגישות ואבטחה, ותוכנית תחזוקה. אם נשארו מחלוקות, הפכו אותן להחלטות פתוחות עם אחראי ותאריך — לא להערות כלליות.
המסמך גם עוזר להשוות הצעות פיתוח בצורה הוגנת יותר: לא רק לפי מחיר, אלא לפי מה כל הצעה כוללת, מי אחראי על מה, ואיך יימדד “מוכן”. להעמקה אפשר לקרוא גם את המדריך לאודיט UX ואת ההסבר על בחירת טכנולוגיה לאתר עסקי.
השורה התחתונה
הבריף הטוב ביותר אינו זה שיש בו הכי הרבה עמודים, אלא זה שמונע החלטות יקרות מאוחר מדי. לפני שמתחילים לעצב, ודאו שאפשר לענות על 15 השאלות — גם אם חלק מהתשובות הן “נבדוק בשלב הבא”.
מקורות: Google Search Central — SEO Starter Guide; W3C — WCAG 2.2; OWASP — Application Security Verification Standard.