או לפחות כך נדמה מהאתר של המשרד.

אני שואל אתכם: האם זה הגיוני שבשנת 2011 לא יהיה מקום ברור באתר של משרד הפנים שאפשר למצוא בו את רשימת הסניפים של המשרד ברחבי הארץ ואת שעות הפתיחה שלהם?

האם זה סביר שאי אפשר יהיה לשלוח פניה למנהל האתר דרך האתר עצמו?

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

התחלתי בחיפוש בגוגל – לא מצאתי כלום בחיפושים שהייתם מצפים למצוא בהם משהו ("משרד הפנים סניפים גבעתיים" או רמת גן). התוצאות בראש תוצאות החיפוש מביאות לאתרים מקודמים שלא קשורים לעניין, והתוצאה הראשונה מ-gov.il מגלה שיש לאתר משרד הפנים מאגר של כל הסניפים עם שעות הפתיחה, אבל אין שום קישור למאגר.

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

המשכתי בחיפוש והגעתי לקוביה הקטנה הזו מצד שמאל:

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

מכאן הגעתי לתפריט השירותים:

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

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

גם שם הסיפור לא נגמר, כי הרשימה המתקבלת לא מכילה שעות פתיחה ושום אפשרות סינון לפי ישוב או איזור בארץ (יש הרבה לשכות שירות). שימו לב שהשם הוא "לשכות שירות" ולא "סניפים" או "קבלת קהל" כפי שחיפשתי.

אני כבר שומע כמה שלוחשים לי מאחורי הגב – תלחץ על ה"+". בסוף הרשימה יש את הסניף של רמת גן (לגבעתיים אין, מסתבר):

כשניסיתי לפנות ל"פניות הציבור" באתר, קיבלתי את ההודעה הזו – נראה כמו באג:

מה היה אפשר לעשות אחרת?

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

רוצים שהאתר שאתם אחראים עליו יצליח?

ביום שני הקרוב, ה-14/2/2011, אפתח ברמת-גן סדנה של 16 שעות (4 מפגשים של 4 שעות) ובה אלמד אתכם, בין השאר, איך להמנע מטעויות כאלה בתכנון האתר או המערכת שלכם. אגלה לכם את שיטות העבודה והתהליכים שתוכלו ליישם ביום-יום שלכם, כבר במפגש הראשון של הסדנה. אלמד אתכם איך לראות את האתר שלכם דרך עיני המשתמשים וליצור אתרים ומערכות טובים יותר, כאלה שאנשים אוהבים ומסתדרים בהם בקלות.

נותרו עוד מספר מקומות בסדנה, ואני מציע אותם לקוראי הבלוג במחיר מוזל של 2,250 ש"ח+מע"מ - רק אם תירשמו עד יום חמישי, ה-10/2.

לפרטים נוספים והרשמה

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

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

ניסיתי לעבוד עם האתר החדש ודי מהר נתקלתי בכמה דוגמאות שגורמות למשתמש חדש באתר לחשוב. הן הזכירו לי מיד את הספר הנפלא, Don't Make Me Think, מיד אסביר למה.

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

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

ואז לא קרה כלום.

חיכיתי עוד כמה שניות, ועדיין לא קרה כלום.

הסתכלתי על המסך, וניסיתי לחשוב איפה הייתי. כאן חשבתי על Don't Make Me Think בפעם הראשונה. נזכרתי שהתחלתי את התהליך בתיבה הכתומה, וראיתי שכתוב בה כבר סן פרנסיסקו, 2 מבוגרים… מצויין. לחצתי על "חפש".

נתעלם רגע מהודעת ה-JavaScript המיושנת (זה כל-כך 90s), בעיני אין לה מקום באתר חדש.

לחצתי OK והסתכלתי שוב על הטופס:

שום דבר לא סימן לי מה השדה חסר.

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

יכול להיות שעבור 80% מהמשתמשים זה ברור מה לעשות, אבל לא כדאי בשביל אלה שזה לא ברור להם לסמן את הדרך?

מילאתי תאריך והגעתי לדף התוצאות (הקליקו כדי להגדיל בחלון חדש)

מה שקרה לי כאן היה שלא ראיתי בכלל את החלק העליון של הדף, כי הרשימה משכה את תשומת הלב שלי.

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

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

כך נראה החלק העליון:

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

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

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

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

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

רביעית, אין בחלק הזה שום Call for Action חזק שמושך אותי לבחור את האפשרות הזולה ביותר שזמינה לי כעת.

הצעה לשינוי

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

עשיתי פה כמה שינויים:

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

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

אני משער שעם מעצב גראפי מוצלח יותר ממני זה גם בוודאי היה נראה יותר טוב

לאחר הלחיצה

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

אני משאיר לדמיון שלכם מה אפשר לעשות במקום זה…

איך להימנע מבעיות כאלה?

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

אם תצטרפו לסדנה תוכלו לעשות בדיקות כאלה בעצמכם, במערכות שלכם. בנוסף, תלמדו כללים אוניברסליים לשמישות (usability) וכיצד לבנות מערכת מנקודת המבט של המשתמש.

הסדנאות הקרובות נפתחות בשבוע הבא, בשלושה מועדים:

• 5/12, יום ראשון (ועוד 3 ימי ראשון שאחריו) – למנהלי מוצר, מנהלי פרויקטים, מנהלי פיתוח ויזמים, בתל-אביב.
• 6/12, יום שני (ועוד 3 ימי שני שאחריו) – למעצבים גראפיים, בתל-אביב.
• 7/12, יום שלישי (ועוד 3 ימי שלישי שאחריו) – למעצבים גראפיים, בחיפה.

הסדנה נמשכת ארבעה מפגשים של 4 שעות, בין 9:00-13:00.

מחיר הסדנה המלא הוא 2,600 ש"ח+מע"מ,

מחיר הסדנה למי שירשם עד יום שלישי הקרוב, ה-30/11: 2,200 ש"ח+מע"מ (15% הנחה!)

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

לפרטים נוספים והרשמה לסדנה

משתתפי הסדנה מספרים

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

שירית שרגא, מנהלת פרויקטים, ווייט לייבל

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

דן ברק, מנהל מוצר, קלירזן

לפרטים נוספים והרשמה לסדנה

במערכת החשבוניות שאני משתמש בה בעסק שלי, flex (ממליץ בחום!), נתקלתי בטופס שהפריע לי במיוחד. לא בגלל שהוא לא מעוצב יפה, או בגלל שהטקסטים בו לא בסדר. הוא פשוט הולך, לדעתי, נגד אחד מעקרונות השמישות החשובים יותר.

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

הטופס: הזנת צ'ק

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

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

להזכירכם, צ'ק נראה כך:

הבעיה

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

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

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

בואו נתבונן על סדר השדות בטופס, לפי סדר המילוי (ימין לשמאל, למעלה למטה):

• סכום במספר
• תאריך
• מס' שיק
• שם בנק
  
• סניף
• מס' חשבון

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

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

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

הצעה לשינוי

אם היינו רוצים ליצור רצף שיותר קל לסרוק, היינו יכולים לסדר את השדות בטופס ככה:

• סכום במספר
• תאריך
• מס' חשבון
• סניף
  
• מס' שיק
• שם בנק

מסלול סריקת הצ'ק היה נראה אז ככה:

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

חדי העין שביניכם בוודאי שמו לב שגם שיניתי את היישור של התוויות – הן צמודות לשמאל עכשיו במקום לימין. בפוסט שלי על עיצוב טפסים סיפרתי לכם שיישור שמאלי יכול לצמצם את זמן ההקלדה בכ-50% (!!!), וזו בדיוק הסיבה ששיניתי את היישור.

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

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

תגובת בעל האתר

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

היי ברק,

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

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

2.      זרימה: זרימת העין היא נגד כיוון השעון סכום >> תאריך >> מס' שיק >> מספר בנק >> סניף >> חשבון.

הקונפליקטים שלך נובעים מ:

1.       היפוכי rtl/ltr (כל החלק התחתון של שיק הוא ltr לעומת חלק תחתון של טופס ההזנה שהוא rtl);

2.       מהתייחסות ללוגו כשם הבנק במקום למספר הבנק בחלק התחתון של השיק (במקרה שלך: 10 הוא מספר הבנק).

תודה שוב על ההתייחסות, וערב טוב.

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

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

להערכתי בדיקה קצרצרה (20 דקות) עם 4-5 משתמשים אמיתיים וכמה צ'קים אמיתיים היתה חושפת את הבעיות האלה תוך זמן קצר.

מה דעתכם?

מהידע והנסיון שלכם, או סתם מההערכה שלכם מהתבוננות בטופס ובצ'קים, האם נכון לשנות את הטופס, או שעדיף להשאיר אותו כפי שהוא?

אשמח לשמוע מה דעתכם.

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

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

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

כמה פעמים ישבתם מול הודעה שאומרת לכם – "[משהו] עומד לקרות. האם להמשיך?", עם כפתורי "המשך" ו"בטל"? כמה פעמים מתוכן קראתם את ההודעה שוב ושוב והתלבטתם על מה ללחוץ, וכמה פעמים פשוט לחצתם על "בטל" או "המשך" בלי לחשוב?

על הודעות אישור פעולה (confirmation messages), מתי להשתמש בהן ומתי ממש לא.

דוגמה

כולנו נתקלנו בהודעות כמו זו מג'ימייל:

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

עדיף לא להסתכן בטעות

מאיר אריאל שר "טעות במחשב עלתה לי מיליון…" – ויטלי כתב על מקרה מהשבוע האחרון שבו זה באמת קרה: סוחר בבורסה לחץ בטעות על הכפתור הלא נכון, והזרים הוראה לרכישה של מיליארדי (ביליונֵי) מניות, במקום מיליונים. הבורסה הגיבה בנפילה. האם המשתמש טעה ולחץ על "b" (עבור billion) במקום על "m" (עבור million)? כנראה שלא נדע. אבל בכל מקרה שבו מציבים מכשול, מקום שבו משתמשים עשויים לטעות, יהיו כאלה שיטעו בו. אפשר לשאול את המשתמש "האם אתה בטוח?", אבל יותר כדאי לעצב את המערכת כך שלא יהיה סיכוי לטעות.

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

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

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

סכנה 1: הטרדה

הסכנה העיקרית בשימוש בהודעות אישור פעולה הוא הטרדה. לשאול את המשתמש על כל פעולה "האם אתה בטוח?" זו הטרדה אמיתית. יש מערכות ששואלות "האם אתה בטוח שאתה רוצה לצאת מהמערכת?" בכל פעם שיוצאים (Log Out). האם זה באמת נחוץ? התשובה היא, כמובן, לא.

כדי להמנע מהטרדה כזו צריך להפעיל שיקול דעת פשוט ולשאול כמה שאלות פשוטות:

• האם הפעולה הזו בלתי-הפיכה?
• אם היא הפיכה, האם המשתמש ידע בקלות כיצד לבטל אותה?
• אם היא בלתי-הפיכה, האם ביצוע שלה יגרום לאובדן מידע או זמן משמעותיים למשתמש?

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

סכנה 2: ניסוח

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

לא הבנתם? הנה, אריק איינשטיין יסביר לכם:

אז האם זה "Document Recovery task pane" במובן של "גרופן" או במובן של "גראפן"?

אם נשים לרגע את הצחוק בצד, למי מכם שלא יודע, ה"Document Recovery task pane" זו החלונית שבה מופיעים כל המסמכים ש-Powerpoint שמר אוטומטית עבורכם לפני שהתוכנה התרסקה. כלומר, אלה גרסאות של מצגות שלא שמרתם בפעם האחרונה שעבדתם עליהן, וזו ההזדמנות האחרונה להציל אותן. האם אי אפשר היה לכתוב משהו שאומר את זה?

סכנה 3: עיצוב גראפי

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

היה אפשר, למשל, להשתמש באייקון כזה (נלקח ממקינטוש):

אפשר היה לעשות כמה דברים נוספים בעיצוב:

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

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

סכנה 4: ברירות מחדל וכפתורי פעולה

ההודעה הלקויה של Powerpoint הופכת לקריטית הרבה יותר כשלוקחים בחשבון שברירת המחדל של כפתורי האפשרויות היא "No", כלומר אם לחצתם באופן אוטומאטי OK, שמסומן גם הוא כברירת מחדל, הקבצים שלכם הלכו. נמחקו. נעלמו. לנצח. כפי שכבר כתבנו קודם, רוב האנשים לא קוראים מה כתוב בהודעה, ולכן הם פשוט ילחצו על הדבר הראשון שנראה שיקדם אותם הלאה – כפתור ה-OK. הסכנה ברורה?

סיכום

כדאי לתכנן את המערכת כך שהיא לא תכשיל את המשתמש ותגרום לו לבצע פעולות שהוא לא מעוניין בהן (action slips). פתרונות עיצוביים שונים עשויים לבטל את הצורך בהודעות כאלה בכלל, או לצמצם אותו משמעותית. אם מחליטים להציג הודעות כאלה, כדאי:

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

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

התמונה שלמעלה: CC by adobemac

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

כדי להוריד את המדריך:
http://uniqui.co.il/theguide

תהנו!

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

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

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

הטופס

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

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

שנית, ההודעה "הקוד נשלח בהצלחה" נראית כמו תגובה לתווית "הקלד את הקוד…", במקום אישור שהפעולה שמתוארת בראש הטופס בוצעה ("לצורך שמירה…"). שוב – גשטאלט. ההודעה מתייחסת למה שהיא נמצאת הכי קרוב אליו. אם ההודעה היתה מתחת לשתי השורות שבראש הטופס, ומרווחת מההמשך שלו, היינו מבינים מיד את ההקשר שלה.

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

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

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

אני מציע את העיצוב החדש הזה:

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

את ה-SMS הייתי משנה ל"הקלד קוד זיהוי זה להמשך התהליך באתר אורנג': 999999". כך השם הוא "קוד זיהוי" כמו בטופס, וגם ברור למי שקיבל את ההודעה שקורה משהו עם הקו שלו באתר אורנג'.

נשמע הגיוני?

מה דעתכם על השינוי הזה? הייתם משנים עוד דברים כאן? כרגיל, אשמח לשמוע את דעתכם.

כתבה חדשה שלי באתר UXI, על סיסמאות, שמות משתמש, ועוד כמה אמצעים שנועדו להגן על המידע של המשתמשים שלכם (ושלכם) באתרים השונים. מה מהם יוצרים אבטחה יעילה בשילוב עם חוויית משתמש טובה? תציצו בכתבה ותגלו…

http://uxi.org.il/pages/1789

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

זהירות, הצלחת!

נכנסתי לחשבון הבנק שלי כדי לעדכן את הסיסמה, ולאחר השינוי קיבלתי את ההודעה הזו:

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

• 

  תמרור א-40

  אנחנו רואים את הדבר הגדול והבולט ביותר – האייקון. זה שכאן מסמל בעולם התוכנה "אזהרה" (warning) ובעולם התמרורים – "מקום מסוכן".

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

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

אייקונים מוסכמים להודעות

בהנחיות שמיקרוסופט נותנת ליישומים ב-Windows מופיעים האייקונים הבאים:

ההנחיות ברורות:

• X – הממשק מראה שגיאה או בעיה שהתרחשו.
• ! – הממשק מראה מצב שעשוי להיות בעייתי בעתיד.
• i – הממשק מראה מידע שימושי.
• ? – הממשק מראה נקודת כניסה למערכת העזרה

במקינטוש יש גם אייקונים סטנדרטיים שמשמשים באופן דומה, למשל אלה:

במקינטוש נוהגים גם להצמיד אליהם בפינה את האייקון של היישום שהעלה את ההודעה.

ברשת נהוג להשתמש בצבע הירוק ובסימן ה-V כדי לציין הצלחה. כך למשל בטוויטר:

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

חשיבות השימוש בסטנדרטים

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

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

סטדנרטים קיימים לא רק באייקונים של הודעות שגיאה. הם קיימים בהרבה מקומות בממשק. למשל, מוסכם בהודעת אימייל שיש "Reply" כדי להשיב לכותב, ו-"Reply to All" בשביל להשיב לכל הנמענים.

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

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

זה קרה גם לכם?

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

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

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

דברים קטנים אבל מעצבנים

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

הנה דוגמה לתבנית לא סלחנית מתוך המערכת flex הישראלית לניהול חשבונות:

flex. לא סולחת ולא שוכחת.

למקרה שלא הבנתם את הודעת השגיאה, הייתי צריך להקליד כאן 11/03/2010 ולא 11/3/2010. ברור, לא? כמה היה עולה לתכנת שדה שיודע להבין גם 11/3/2010 ולא רק 11/03/2010? שלא לדבר על 11-3-10 או 11.3.10. במקרה של flex הטעות חמורה אפילו יותר, כי יש כאן מקום להזנת תאריך, אבל אי אפשר לבחור מלוח שנה כמקובל בשדות תאריך. כך שכל מי שרוצה להזין תאריך לעשות את זה לפי איך שהמתכנת של השדה הזה הסכים לקבל תאריכים – his way or the highway.

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

גם טדי קולק ז"ל היה מסתדר עם המפות של גוגל, יוּרשלים

תאריכים סלחניים

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

• 17-3-2010
• 17/3/2010
• 17.03.2010

אני יכול להשתמש בתאריך מקוצר:

• 17/3
• 17

וגם ביום:

• Wednesday
• Wed

אפשר גם ברביעי הבא:

• Wed Week
• Wed W

וכן הלאה. כמה זה מסובך לתכנן ולתכנת את זה? לא מאוד. וזה יכול לעבוד בכל שדה תאריך.

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

• Dinner with John tonight at 19:00
• Dinner at 19:00 with John
• 7pm dinner with John

הוספה מהירה בלוח השנה של גוגל

עמודי נחיתה סולחים בקלות

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

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

טופס בעמוד נחיתה שאוכל הכל (כמעט)

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

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

לבחור קידומת טלפון מרשימה? למה?

יש עמודי נחיתה שעושים את זה פחות טוב:

למה צריך לבחור את הקידומת מרשימה?

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

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

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

תבנית סלחנית – דפוס עיצוב

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

• ב-Quince
• ב-UI-Patterns
• ב-Designing Interfaces (האתר של הספר)
• ב-UXI עוד אין, אבל יהיה בקרוב… ויש שם גם כמה דפוסי עיצוב אחרים.