"The Inmates Are Running the Asylum" איך להצב ממשקים בצורה נכונה

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

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

אלן קופר הוא מעצב ומתכנת אמריקאי. ידוע ממייסדי שפת התכנות Visual Basic והוא קיבל מקום בטוח עבורו במוזיאון היסטוריית המחשבים ב-2017. פיתח שיטת עיצוב goal-directed המטרה להתמקד במטרות המשתמש והיה מהראשונים שהשתמשו בפרסונות בעיצוב מוצר.

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

מהמאמר תלמדו:

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

דוב רוקד

בטח ראיתם את הסרטון הזה שבו עובד משרד מתעצבן על המחשב שלו:

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

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

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

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

תראה את ממשק של קופסת הטלוויזיה Xfinity X1. הוא מאפשר לך לשמור את לוח הזמנים של הצפייה בתוכניות בתפריט המשנה לוח זמנים. תפריט המשנה הזה ממוקם בלשונית שמור - ופשוט לא ניתן לנחש בלי הוראות:

זו דוגמה ל"דוב רוקד" - יש פונקציונליות של שמירת לוח הזמנים, זה עובד גרוע, אבל זה עובד!

דדליין ותכונות

ב-1990, GO פיתחה את ה-PenPoint שהיה אמור להיות אב הטיפוס לעוזרים דיגיטליים אישיים, אך נכשל ב-1992. הניסיון הבא נעשה על ידי אפל עם Newton שלה ולאחר מכן על ידי General-Magic עם ה-Magic Link שלה ב-1994. כל המוצרים הללו נכשלו ומשקיעים כינו את שוק ה-PDA חסר סיכוי. אבל ב-1996 מופיע PalmPilot - הוא איחר בשש שנים אבל בזכות האטרקטיביות שלו הוא הצליח לכבוש את השוק.

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

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

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

בעיות של מערכות מודרניות

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

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

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

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

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

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

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

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

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

עיצוב בשביל תוצאות

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

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

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

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

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

מטרות בפיתוח תוכנות

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

• לא להרגיש טיפש
• לא לעשות טעויות
• לעשות את כמות העבודה הנכונה
• ליהנות (או לפחות לא להשתעמם)

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

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

מטרות פרקטיות - עוזרות להשיג מטרות אישיות או עסקיות.

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

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

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

מטרות שווא - הן מלכודת למי שרוצה להקל על עיצוב התוכנה עבור עצמו:

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

למעשה, כל זה הוא רק אמצעי להשגת מטרה, אשר כשלעצמה לא תביא לשום תוצאה.

לדוגמה, המטרה הכוזבת "ממשק פשוט" לא אומרת כלום אבל במקביל עולות עבורו שאלות רבות: "איך זה יעזור למשתמש לפתור את הבעיה שלו?  למה הממשק צריך להיות פשוט? מה יקרה אם היעד הזה לא יתממש?

פרסונה לצורך פיתוח

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

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

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

מתכנת: "מה אם המשתמש ירצה להדפיס את זה?"

מעצב: "אני לא חושב שיש צורך בהדפסה בגרסה הראשונית."

מתכנת: "ייתכן שמישהו יצטרך להדפיס."

מעצב: "כנראה שכן, אבל האם נוכל לדחות את האופציה הזו לפעם הבא?"

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

מתכנת: "מה אם המשתמש רוצה להדפיס את זה?"

מעצב: "שרון לא צריכה הדפסה."

מתכנת: "ייתכן שמישהו יצטרך להדפיס."

מעצב: "אבל אנחנו מעצבים עבור שרון, לא עבור אף אחד אחר."

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

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

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

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

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

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

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

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

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

עבודה על תרחיש שימוש

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

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

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

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

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

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

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

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

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