בונה בריף לאתר: מטרות, קהל ותכולת הפרויקט

מה לאסוף לפני שממלאים את הבריף

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

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

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

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

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

מתרגמים רצון לרכיבים ולתוכן

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

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

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

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

קוראים את הסיכום ומאתרים חוסרים

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

בודקים סתירות בין תשובות. אם המטרה היא להקטין עומס על צוות שירות, אך הרכיבים המתוכננים מובילים כל שאלה לטופס כללי, יש צורך בהחלטה נוספת. אם הקהל משתמש בעיקר בנייד, אך תוכן מרכזי תלוי בקובץ שאינו נוח לקריאה במסך קטן, מסמנים צורך בהתאמה. הבריף אינו פותר סתירות אוטומטית; הוא הופך אותן לנראות בזמן שבו עדיין זול לשנות כיוון.

אפשר להשתמש בסיכום בהכנת שיחת תכנון. בוחרים כמה שאלות בעלות השפעה גבוהה: מה הפעולה החשובה ביותר, אילו עמודים נדרשים בהשקה, מי מאשר תוכן, אילו מערכות קיימות צריכות להתממשק ומה נשאר מחוץ להיקף. אין הכרח לפתור כל פרט לפני תחילת העבודה, אך חשוב לדעת אילו פרטים עלולים לעכב החלטה או לשנות עלות ומורכבות.

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

מגדירים היקף, מסירה ובדיקות

בריף טוב מפריד בין מה שנדרש בהשקה לבין רעיונות להמשך. לכל רכיב מרכזי מציינים אם הוא חלק מהשלב הראשון, תלוי בהחלטה חיצונית או נבחן בעתיד. ההפרדה חשובה במיוחד כשיש רעיון לפורטל לקוחות, אזור סגור, חיבור למערכת קיימת או תוכן רב־לשוני. אלו אינם פרטים קטנים שניתן להוסיף בסוף בלי לבדוק גישה, תהליך בעלות ותחזוקה.

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

בדיקות קבלה צריכות להתבסס על המצבים שנכתבו בבריף. בודקים ניווט לעמוד מרכזי, קריאה במכשיר נפוץ, שליחת טופס עם נתונים תקינים וחסרים, טיפול בקישור שבור אם יש כזה, והבנה של הודעות שגיאה. אם קיימים תפקידים שונים באתר, בודקים כל תפקיד במסגרת המתאימה. אין צורך להפוך את הבריף למסמך בדיקות מלא, אך כדאי שהסיכום יכלול את מה שחייב לעבוד ביום ההשקה.

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

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