אחרי מעל 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 עוד אין, אבל יהיה בקרוב… ויש שם גם כמה דפוסי עיצוב אחרים.

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

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

כן, אני מתכוון גם כאן, אצלנו. באתרים של רוב הגדולים.

מאיפה בא ה"נקה" הזה?

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

עוד כפתור = עוד עבודה

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

הנה דוגמה מאלפת מבית NRG – זה מהטופס של "המייל האדום".

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

חוץ מעניין כפתור ה"נקה", אגב, יש פה עוד כמה חוקי שמישות חשובים שנשברו:

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

עוד דוגמאות מהנוף המקומי

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

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

בכללית יש מסלול אקספרס (ככה נקרא הדף) שמוביל ישירות לכפתור ה"נקה טופס".

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

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

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

בשירות הלקוחות של תנובה התמונה די דומה, אבל רק למי שגולש ב-Internet Explorer. זה ברור למה – שועל אש זה בשרי, תנובה זה חלבי:

כמה דוגמאות טובות יותר

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

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

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

בביטוח הלאומי יש בכל הטפסים רק כפתור "שלח". מצויין!

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

אז מה עושים?

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

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

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

כדי להאזין לפרק (30:27 דקות)

אפשר להוריד את הפרק (12.8MB), להאזין לו באייטיונז, או באתר – בסוף הדף יש נגן כסוף.

קישורים שהוזכרו בפרק

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

אינדקס נושאים וזמן בפרק

3:30 מה זאת המרה?
5:00 על השינוי שהרשת עברה בשנים האחרונות
7:30 מה זה עמוד נחיתה ומה מייחד אותו ואת חוויית השימוש בו?
11:00 מה צריך להיות בעמוד נחיתה ומה הוא צריך להכיל?
16:30 איך לחזק את תחושת הביטחון של המשתמש בעמוד נחיתה?
18:00 על Split Test והאתר whichtestwon
19:45 תהליך האופטימזיציה של עמוד נחיתה
24:00 סיפור מקרה מאתר תכשיטים.
25:00 עוד טיפים לאופטימזציה של עמודי נחיתה

הרשמה לפודקאסט

יש לפודקאסט RSS Feed משלו וגם מקום ב-iTunes Store. אם אתם משתמשים ב-iPod או ב-iPhone תוכלו לעשות מנוי ב-iTunes ולהוריד את הפרקים אוטומאטית ברגע שהם מתפרסמים.

כדי להאזין, תלחצו כאן למטה:

אם היה לי שקל על כל פרסום שהיה בשבועות האחרונים על ה-Tablet החדש ("מחשב לוח" בעברית), שסטיב ג'ובס (אהה, כלומר, אפל) צפוי להכריז עליו מחר, הייתי מיליונר. מ-Tech Crunch (כתבה לשעה, בערך) ו-Gizmodo ועד כלכליסט, מה-New York Times ועד בלוגרים עלומים שמבטיחים שחבר של חבר של חבר (או סתם חבר) עובד באפל ושלח להם את התמונות של הדבר האמיתי. אם אתם רוצים כיסוי היסטורי מקיף של ה-Tablet ואפל, יש אחד מושקע ב-Engadget.

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

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

זה יקרה מחר ב-20:00 שעון ישראל, יום רביעי ה-27/1/2010, 10:00 שעון סן-פרנסיסקו (שם זה יקרה), אבל מומלץ להתחבר קצת קודם.

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

• עדכון: יש פה שידור LIVE דרך הטלפון.
• Engadget מזמינים להקשיב אצלם
• MacWorld מבטיחים לדווח בשידור חי
• The Loop אומרים שיספרו לנו הכל

ויש עוד הרבה, אבל אלה בוודאי יספיקו.

תהנו!

עדכון: אפשר לראות את הצעצוע פה:

http://www.apple.com/ipad/#video