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

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

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

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

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

בסוף המצגת מסתתרת הנחה על הסדנה הקרובה

אבל היא בתוקף רק עד היום, יום רביעי ה-16/6, בחצות.

ההנחה מסתתרת גם בוידאו

אבל צריך לעבוד יותר קשה כדי למצוא אותה…

שימו לב: חכו כמה דקות כדי לראות את הוידאו, הוא לא יתחיל לנגן מייד: לוקח לו 5-10 דקות להיטען. אלה מגבלות טכנולוגיות זמניות – אני יודע שחוויית השימוש כאן לא מיטבית, אבל היה חשוב לי להביא את התוכן כמה שיותר מהר. בהמשך אשפר את עניין הוידאו.

בשבוע הבא, ביום שלישי ה-15/6/2010 בין 10:00-11:00 בבוקר אקיים מפגש ברשת (וובינר) שבו תוכלו לקבל תשובות לשאלות שיש לכם בנושאי חוויית משתמש, ממשק משתמש, ושמישות (usability). המפגש מיועד קודם כל למשתתפים בסדנה שלי, אבל כולכם יכולים לבוא ולהקשיב, וגם לשאול שאלות.

עדכון 17/6: המפגש התקיים אתמול, המצגת והוידאו של המפגש נמצאים כאן להנאתכם.

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

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

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

להשתמע ביום שלישי!

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

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

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

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

הלוואי שגם האירוע הבא יצליח ככה, ועוד יותר. יש עוד הרבה עבודה לעשות בתחום הזה.

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

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

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

זה קרה גם לכם?

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