שדרוג והחלפת אתר קיים

מיפוי נכסים לפני בחירת מסלול

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

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

בחירת כתובת יעד לפי כוונת מבקר

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

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

בדיקות תהליכים, לא רק עמודים

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

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

תוכן, הרשאות ומסירה לאחר העלייה

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

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

בודקים מה קורה ביום שאחרי המעבר

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