מבריף מעורפל לאתר חי: תהליך סוכנות שניתן לחזור עליו

סיכום

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

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

הסכנה אינה הכלי

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

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

שיחת הפתיחה שחוסכת לך את השוליים

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

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

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

המתנה לתוכן היא תהליך, לא הפתעה

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

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

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

בחר את הבונה אחרי שאתה יודע מה העבודה

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

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

הדברים הלא זוהרים של ההשקה

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

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

אבטחה מטופלת כמו רשימת בדיקה מפחידה ויקרה, אבל היסודות משעממים ויעילים. מדריך אבטחת האתרים של UpGuard מפרט את הסט הסטנדרטי: עדכן תוכנה, אכוף אימות חזק כמו MFA, הגבל הרשאות משתמש, גבה נתונים באופן קבוע, והשתמש בהצפנת SSL/TLS. חומת אש ליישומי אינטרנט היא שכבה נוספת שכדאי להפעיל היכן שהפלטפורמה תומכת בכך. עבור אתר קטן, זה לא פרויקט אבטחה; זה התקנה קצרה. אבל כמה דקות עכשיו מונעות את השיחה שבה האתר של הלקוח מעביר קבצים זדוניים במשך חודש. העיקרון: אירוח, דומיין ואבטחה שייכים לפתיחה, לא לספירה לאחור של ההשקה. הם משימות של הגדר-ושכח — וזו בדיוק הסיבה שצריך לעשות אותם בעוד יש לך זמן לתקן שגיאת הקלדה בפרטי הקשר.

בדיקות כנות

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

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

ההשקה היא התחלה, לא קו סיום

האתר חי. הטלפון של רואה החשבון מתחיל לצלצל — בתקווה. אימייל ההשקה אומר "זה נגמר." אבל שתי משימות בלתי נראות מפרידות בין אתר שקיים לבין אתר שאפשר למצוא: הגש מפת אתר XML והגדר robots.txt. הסבר ה-SEO של המכון לשיווק דיגיטלי מציין את אותה נקודה בשפה דיפלומטית יותר: נראות בחיפוש תלויה ביסודות טכניים כמו HTTPS ומפות אתר מובנות, לא רק במילות מפתח. עבור אתר קטן, זו משימה קצרה וזה ההבדל בין אתר שגוגל יכול לאינדקס לבין אתר שחי בחשכה.

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

מה "בוצע" באמת אומר

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