איך כותבים אפיון אתר: סדר העבודה ומה להכין
כתבו מסמך משותף שמתחיל במטרת האתר ובמשימות המבקרים, וממשיך למפת העמודים, לתוכן ולתיאור הפעולות. לכל דרישה הוסיפו דרך לבדוק שהיא הושלמה, ציינו מי אחראי לספק את החומרים והפרידו בין מה שנדרש להשקה לבין תוספות עתידיות. את המסמך הזה שולחים לספקים כבסיס להצעת המחיר.
לפני הכתיבה, אספו את חומרי העסק הקיימים: תיאור השירותים, שאלות של לקוחות, תמונות, זהות חזותית ופרטי המערכות שהאתר יצטרך להתחבר אליהן. אם יש אתר קיים, הכינו גם רשימת עמודים ותכנים שתרצו לשמור. מנו אדם מטעם העסק שירכז החלטות ויאשר את הגרסה שנשלחת לתמחור.
סדר העבודה המומלץ הוא להגדיר מטרה וקהל, למפות עמודים, לפרט פעולות, לחלק אחריות לתוכן ולכתוב בדיקות מסירה. אפשר להתחיל במסמך טקסט ובתרשים פשוט; בשלב הזה המטרה היא להגיע להחלטות שאפשר לתמחר.
מדריך השירותים של ממשלת בריטניה מציע לתאר כל צורך דרך המשתמש, מה הוא צריך ולמה, ולהוסיף רשימת תנאים שמראה מתי הצורך נענה. הוא גם ממליץ לפצל צורך גדול לחלקים קטנים שאפשר להשלים בנפרד. זו שיטת תכנון ולא חובה בישראל. הפרטים מופיעים בהנחיות לכתיבת צורכי משתמש ותנאי קבלה.
| הצורך | מה לפרט באפיון | תנאי השלמה לדוגמה |
|---|---|---|
| יצירת קשר | שדות הטופס, שדות חובה, יעד השליחה והודעת האישור | פנייה תקינה מגיעה ליעד, והמבקר רואה אישור |
| מציאת שירות מתאים | חלוקת השירותים, המידע בכל עמוד והקישורים ביניהם | המבקר יכול להגיע מהתפריט לעמוד השירות ולפעולת הפנייה |
| עדכון תוכן בעסק | התוכן שניתן לעריכה וההרשאות הדרושות לעובד | העובד מעדכן תוכן בחשבון המיועד לו ושומר את השינוי |
| טיפול בטעות בטופס | הודעת השגיאה והדרך לתקן את המידע | המבקר מזהה את השדה שדורש תיקון ויכול לשלוח מחדש |
| שליטה בהיקף הפרויקט | דרישות להשקה ורשימה נפרדת של תוספות עתידיות | ההצעה מפרטת אילו דרישות כלולות בתוצר שנמסר |
מקור: דוגמאות אפיון על בסיס שיטת תנאי הקבלה של ממשלת בריטניה
שלב 1: הגדירו מטרה ומשימות של מבקרים
בחרו פעולה עיקרית שהאתר אמור לאפשר: השארת פרטים, הזמנת מוצר, קביעת פגישה או קבלת מידע. כתבו גם מה נחשב פנייה מתאימה לעסק. למשל, באתר של נותן שירות מקומי אפשר להגדיר שהמבקר צריך להבין את אזור השירות ואת סוג העבודה לפני שהוא ממלא טופס.
תארו את קהל היעד דרך הצורך שלו. בעלת עסק שמחפשת תחזוקה שוטפת ולקוח פרטי שצריך תיקון דחוף עשויים להזדקק למידע ולמסלול פנייה שונים. ליד כל קהל כתבו מה הוא מחפש, מה הוא צריך לדעת לפני ההחלטה ואיזו פעולה תופיע בסוף המסלול.
היעזרו בשאלות שהגיעו לעסק ובשיחות עם לקוחות כדי להחליט מה להציג. כשאין מידע, סמנו את ההחלטה כהנחה שצריך לבדוק. מדריך מחקר המשתמשים של ממשלת בריטניה ממליץ להסתמך על ראיות קיימות, כמו נתוני אנליטיקס ושיחות עם משתמשים ועם אנשים שעובדים מולם, ולהתייחס להצעות שאינן מגיעות ממשתמשים כהנחות שיש להוכיח.
שלב 2: בנו מפת עמודים ורשימת תבניות
רשמו כל עמוד שמתוכנן להשקה ואת מקומו בניווט. לכל עמוד ציינו את המטרה, התוכן הדרוש והפעולה הרצויה. התחילו בעמודים שמאפשרים למבקר להשלים את המשימה המרכזית, והעבירו לרשימה נפרדת רעיונות שאפשר לפתח בהמשך.
הפרידו בין עמודים לבין תבניות עיצוב. בדוגמה היפותטית, אתר כולל עמוד בית, עמוד אודות, עמוד יצירת קשר וחמישה עמודי שירות: שמונה עמודים בסך הכול. אם עמודי השירות משתמשים באותו מבנה, אפשר לתאר עבורם תבנית משותפת, לצד תוכן נפרד לכל שירות. בהצעה צריך להופיע גם היקף העיצוב וגם היקף הזנת התוכן.
הוסיפו מצבים שמבקר עשוי להגיע אליהם במהלך השימוש: אישור שליחת טופס, חיפוש ללא תוצאות או עמוד שלא נמצא. אם מבנה האתר עדיין לא ברור, המדריך לבניית אתר תדמית לעסק יכול לעזור לגבש את רשימת העמודים לפני שמפרטים כל מסך.
שלב 3: תארו פעולות, טפסים וחיבורים
החליפו ניסוחים כלליים כמו ״טופס מתקדם״ בתיאור של מה שקורה בפועל. פרטו אילו שדות מוצגים, אילו מהם חובה, מה מופיע כשחסר מידע, לאן הפנייה נשלחת ומה המבקר רואה לאחר השליחה. הגדירו גם מי בעסק מטפל בפניות.
לכל חיבור למערכת חיצונית ציינו את שם המערכת, המידע שצריך לעבור וכיוון ההעברה. לדוגמה היפותטית: טופס באתר מעביר שם, טלפון ושירות מבוקש למערכת הלקוחות, ומצרף את מקור הפנייה. בקשו מהספק לבדוק היתכנות לפני התחייבות למחיר, וציינו מי אחראי לספק חשבון מתאים והרשאות גישה.
תארו גם כשל אפשרי: מה יקרה אם המערכת החיצונית אינה זמינה, ואיך האחראי בעסק ידע שההעברה נכשלה. אם האתר כולל קביעת תורים, פרטו כללי ביטול, שעות פעילות והטיפול בתור שכבר נתפס. אם הוא כולל רכישה, הכינו רשימה נפרדת של תשלום, משלוח, מלאי והודעות ללקוח.
שלב 4: חלקו אחריות לתוכן ושרטטו את המסכים
ליד כל עמוד ציינו מי כותב, מי מאשר ומי מעלה את התוכן. הגדירו אם הספק מקבל טקסט מוכן או נדרש לראיין את העסק ולכתוב אותו. פרטו בנפרד תמונות, תרגום, קבצים להורדה והעברת חומר מהאתר הקיים, כדי שהמונח ״הקמת אתר״ לא ישאיר משימות פתוחות.
הכינו שרטוט בסיסי של המסכים המרכזיים. מספיק להראות את סדר הכותרות, אזורי התוכן, התמונות והכפתורים. התחילו גם מתצוגת הטלפון, והחליטו מה יופיע בתחילת העמוד, איך ייפתח התפריט ואיך המבקר יגיע לפעולה הרצויה.
צרפו אתרי השראה עם הסבר נקודתי: ״החלוקה לשירותים ברורה״ או ״התפריט מאפשר להגיע ישירות להזמנה״. ציינו מה תרצו לאמץ ומה אינו מתאים לעסק. הקצו מראש אחריות לבדיקת דרישות הנגישות והפרטיות החלות על האתר ולהכנת הנוסחים הדרושים. משאבי תכנון הנגישות של W3C עוסקים בשילוב נגישות בתכנון ובהגדרת תפקידים ואחריות לעמידה בהנחיות WCAG.
שלב 5: פרטו את ניהול האתר ואת דרישות וורדפרס
באפיון אתר וורדפרס כתבו אילו שינויים אנשי העסק צריכים לבצע בעצמם: החלפת תמונה, עריכת שירות, פרסום מאמר או הוספת איש צוות. בקשו שההדרכה והמסירה יכללו ביצוע של המשימות האלה בחשבון שמיועד לעבודה היומיומית.
הגדירו הרשאות לפי התפקיד בעסק. וורדפרס כוללת תפקידים עם יכולות שונות: עורך יכול לנהל ולפרסם תוכן, ומנהל אתר מקבל גישה רחבה יותר לפעולות הניהול. בחרו את ההרשאות לפי המשימות הנדרשות, כפי שמפורט בתיעוד התפקידים וההרשאות של וורדפרס.
אם מוצע בונה עמודים, בקשו לציין איזה כלי ישמש לעריכה, מי מחזיק ברישיון ומי משלם על חידושו. המדריך על אלמנטור בתוך אתר וורדפרס מתאים למי שרוצה להבין את הבחירה הזאת לפני האישור. הוסיפו למסמך דרישה לפירוט התוספים והשירותים בתשלום, כולל שימוש שמחייב רישיון בבעלות העסק.
שלב 6: כתבו בדיקות מסירה ותוכנית מעבר
הצמידו לכל פעולה תנאי קבלה שאפשר להדגים. עבור טופס, למשל: מילוי תקין מציג אישור ומעביר את הפרטים ליעד שנקבע; השארת שדה חובה ריק מציגה הודעה ליד השדה. עבור עריכת תוכן: נציג העסק מצליח לעדכן עמוד בלי לשנות את המבנה שלו.
ציינו באילו מכשירים ודפדפנים תיערך הבדיקה, מי בודק ומי מאשר תיקונים. אם נדרשת בדיקת מהירות, הסכימו מראש על כלי המדידה, העמודים והמדד המבוקש. כך אפשר לדון בתוצאה מסוימת במקום להסתפק בהבטחה ״האתר יהיה מהיר״.
בשדרוג אתר קיים, הכינו רשימה של הכתובות הישנות והיעדים שלהן באתר החדש. הנחיות Google להעברת אתר כוללות מיפוי כתובות והפניות קבועות (301 או 308) מכל כתובת ישנה ליעד המתאים לה, ללא שרשראות הפניות. לפי ההנחיות, כדאי להשאיר את ההפניות לפחות שנה ולבדוק אותן לפני ההעברה ואחריה.
הגדירו גם גיבוי ודרך חזרה במקרה תקלה. לפי תיעוד הגיבוי של וורדפרס, שחזור מלא של אתר טיפוסי דורש גם את הקבצים וגם את מסד הנתונים.
שלב 7: הגדירו מחיר, מועדים וגבולות לשינויים
שלחו לכל ספק את אותה גרסת אפיון ובקשו פירוט של מה שכלול, מה מוחרג ומה דורש בירור. בקשו להפריד בין ההקמה לבין אחסון, רישיונות ותחזוקה. אפשר להיעזר במדריך לעלות והיקף תחזוקת אתרים כשמגדירים את העבודה שאחרי ההשקה.
קשרו את לוח הזמנים לתוצרים ולאישורים: מתי העסק מספק תוכן, מתי מוגש עיצוב ומתי מתחילות בדיקות המסירה. הגדירו מראש את סבבי התיקונים ואת דרך ריכוז המשוב. כשנוסף צורך חדש, בקשו הצעה כתובה להשפעתו על המחיר ועל מועד ההשקה לפני שמאשרים אותו.
אם אתם פונים לשירות בניית האתרים של ברנדיני, הסוכנות שמפעילה את המגזין, הביאו את המסמך לשיחת ההיכרות ובקשו שההצעה תתייחס לסעיפיו. אותו מסמך אפשר להציג גם לספקים אחרים, בלי לנסח מחדש את הדרישות בכל שיחה.
בדיקת השלמה לפני ששולחים לספקים
עברו על המסמך כאילו אתם הספק שקורא אותו לראשונה. אם סעיף עדיין מאפשר כמה פירושים, הוסיפו דוגמה או סמנו אותו כשאלה פתוחה שדורשת תשובה לפני התמחור.
- לכל עמוד יש מטרה, תוכן מתוכנן ואחראי לספק אותו.
- לכל פעולה יש תוצאה צפויה ותנאי מסירה שאפשר לבדוק.
- החיבורים למערכות הוגדרו, והסעיפים שדורשים בדיקת היתכנות מסומנים.
- ברור מה נכלל בהשקה ומה נשאר להמשך.
- מוגדרים בעלי החשבונות והרישיונות, חומרי המסירה וההדרכה.
- יש אדם שמאשר החלטות וגרסה מוסכמת שעליה מתבססת הצעת המחיר.
שמרו את הגרסה שנשלחה יחד עם ההצעה שקיבלתם. שאלה שנותרה פתוחה צריכה לקבל תשובה מתועדת לפני אישור העבודה, במיוחד אם היא משנה את היקף הפיתוח או את האחריות של העסק.
