שימושיות: ההבחנה בין טיפשות מדרגה ראשונה לטיפשות מדרגה שנייה
אנחנו לא שואלים טייסים האם הם רוצים לטפס גבוה כשהם מושכים את חזק ההגה, אז למה לשאול אותי אם אני רוצה למחוק את הקובץ - כשכרגע לחצתי על "מחק"Software
![]() | ![]() |
|

דיק טיילור, סמנכ"ל לענייני מידע רפואי בשירותי הבריאות Providence שבאורגון, עוסק בעקרון השימושיות מזה זמן. "בלי שאלות מטופשות: תזכרו למה המשתמשים הרפואיים שלכם הגיעו לעבודה היום, וכבדו את צרכיהם", הוא נוהג לומר. עד לאחרונה, תייקתי אותו תחת "ברור מאליו אבל לא פרקטי". אך לא מזמן הייתה לי הזדמנות לדבר עמו בנושא. יצאתי משוכנע שהעיקרון שלו הוא גישה משמעותית אל הנושאים העדינים ביותר של תכנון ממשק משתמש. כמו לכל מדען-פילוסוף טוב, דיק פיתח קריטריונים למיון. הוא מתאר:
- שאלות מטופשות מהמעלה הראשונה: שאלות כל כך טריוויאליות שלענות עליהן זה עלבון לזמנו של המשתמש.
- שאלות מטופשות מהמעלה השנייה: שאלות שרוב המשתמשים לא יכולים לענות עליהן.
הוא מציע את הדוגמא הבאה לשאלה מטופשת מהמעלה הראשונה: המשתמש מבקש למחוק קובץ והמערכת שואלת "האם אתה רוצה למחוק את הדבר הזה?". שאלות מטופשות מהמעלה הראשונה נוצרו בגלל הצורך להגן על משתמשים מטעויותיהם שלהם, כמו "האם אתה באמת רוצה למחוק חמישה עמודי טקסט?". לפני שלמחשבים הייתה תכונה של "בטל את הפעולה האחרונה", ייתכן ומשתמשים העדיפו שיהיו אזהרות שכאלה; כיום אנחנו מצפים מתוכנה להציע אפשרויות של "בטל" או "צא מבלי לשמור את השינויים" או דרכים אחרות שיאפשרו לנו לתקן את השגיאות אחרי שהן קורות. שאלות מטופשות מגיעות, לפעמים, במסווה של הצהרות. אם אחרי שהמשתמש משגר פקודה ישנה תיבת דיאלוג שאומרת "הפקודה שוגרה, אנא לחץ אישור", המערכת מעליבה את המשתמש או מביעה ספקות רבים לגבי האמינות שלה עצמה. מרגע שהמשתמש חתם על הפקודה, המוח שלו רץ קדימה לפקודה הבאה, או למטופל הבא. בואו לא נסיח את דעתו.
דוגמא לשאלה מטופשת מהמעלה השנייה עשויה להיות "הנך נכנס לעמוד אינטרנט מאובטח, אבל חלק מהתוכן בו מגיע משרת לא מאובטח, האם תרצה להמשיך?" מעטים המשתמשים שיודעים מה זה אומר. אפילו אלה שיודעים מה זה אומר, לא יכולים להגיע להחלטה בלי לדעת איזה מידע הגיע מהשרת הבלתי מאובטח. כל מה שהשאלה הזו עושה זה לעודד את המשתמשים לפתח הרגל של ללחוץ "כן" באופן עיוור כשעולות אזהרות אבטחה ולתת לאיש אבטחה אי שם את התחושה המוטעית שהמשתמשים בטוחים יותר.
כיום, כל הטמעה של החלטת תמיכה רפואית כוללת מציאת איזון בין שיפור השירות לבין יצירת לאות אזהרות. לאות אזהרות היא באמת "לאות שאלות מטופשות". אנחנו לא שואלים טייסים האם הם רוצים לטפס גבוה כשהם מושכים את ההגה חזק, אפילו שחיים עשויים להיות בסכנה. אנחנו עושים אופטימיזציה לזמן ותשומת הלב של הטייס בכך שאנחנו מניחים שיש לו רמה מסוימת של מקצועיות והכשרה. אם התוצאה היא להתקרב למהירות הזדקרות אז האיזון נוטה לכיוון האזהרה.
העיקרון של "לא לשאול שאלות מטופשות" לא מוביל להגדרה נוסחאתית לגבי תקפות של שאלות. עם זאת, העיקרון צריך להיות מיושם באופן שגרתי בעת עיצוב פונקציות או ממשק משתמש. מעצבים צריכים לשאול את עצמם:
1. האם השאלה הזו נחוצה עבור איש מקצוע כשיר העובד ביעילות?
2. אם השאלה נוגעת לשגיאת משתמש אפשרית, האם אפשר לחכות עד אחרי שהשגיאה תתרחש? (אם לא, אנחנו צריכים לחשוב שוב על עיצוב המערכת כולה).
3. אם השאלה הולכת להיות כזו שרוב המשתמשים עוברים דרכה באופן אוטומטי, למה לשאול אותה? אם המטרה היא לגלות נושאי אבטחה נדירים, אולי הגישה המתאימה תהיה ליצור רישום בקובץ ביקורת.
4. האם השאלה הזו מייצגת בחירה בבזבוז שבריר מזמנו של המשתמש לעומת בזבוז ימי מזמנו של המתכנת? אם התשובה היא "כן" זו החלטה גרועה, גם תחת לחץ של תאריך יעד. לדוגמא, אם השאלה מזהה שגיאת משתמש נדירה אך חשובה שעשויה להתרחש, האם תכנות מסובך יותר עשוי לבטל את הצורך בשאלה הזו עבור רוב המשתמשים ברוב הזמן?
לפעמים בחינת הנושא הזה בעיצוב תבטל שאלות מטופשות. לפעמים זה יאשר את השאלות שאינן מטופשות. לפעמים זה יגרום למעצב לחשוב מחדש על זרימת המידע כך שהשאלה הופכת למיותרת. בכל מקרה, המשתמש מרוויח.
עשרת הגדולים
| שימושים: דף הבית | RSS | אודות האתר | פרסום באתר | תקנון האתר | ||
| TheMarker: העמוד הראשון | הייטק | שוק ההון | וול סטריט | בעולם | קריירה | פרסום ומדיה | צרכנות | נדל"ן | משפט | רכב | המדריך למשקיע | ||
| Cafe: ראשי | העמוד שלי | אנשים | קהילות | בלוגים | תמונות | וידאו | קהילת תמיכה | ||
| עכבר העיר: עכבר העיר | סרטים | קולנוע | מסעדות | מתכונים | הופעות | פעילויות ילדים | הצגות | לילה | מסיבות | עכבר העיר: סרטים, לילה, מסעדות | ||
| לוח העיר: דרושים | דרושים הייטק | נדל"ן | פרוייקטים חדשים | רכב | בעלי מקצוע | קח תן | ||
האתר פותח ע"י![]() |