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