אחד הספרים הוותיקים בתחום של עיצוב חוויית משתמש וממשק הוא The Inmates are Running the Asylum של Alan Cooper, או המטופלים מנהלים את גהה, כמו שאמיר דותן קרא לו בעברית. הספר, שפורסם ב-1998, הגדיר לראשונה את מקצוע ה-Interaction Design כתחום עיסוק.
בעיני הספר הוא חובה לכל יזם או מנהל פיתוח שלא מכיר את התחום של עיצוב אינטראקציה (IxD) או חוויית משתמש (UX). הספר מבהיר מעל לכל ספק למה מעצבי אינטראקציה הם מרכיב חיוני בכל מוצר תוכנה מצליח, ואת הערך הרב שהם מביאים. אינטראקציה שמתוכננת נכון יכולה ליצור את ההבדל בין מוצר מצליח לסטארטאפ שנמחק. נכון, אני משוחד, לכן אני ממליץ לכם לא לסמוך עלי ולקרוא את הספר :-)
אני ממליץ על הספר בחום גם למי שעוסקים ב-IxD ו-UX, גם בזכות הדוגמאות המעניינות שבו, אבל בעיקר בזכות ההצגה של תהליך הפיתוח ממעוף הציפור והתיאור של אנשי הפיתוח, על אף הסטריאוטיפיות וההקצנה שבו. התובנות שבספר מאפשרות לאנשי ה-IxD להבין יותר טוב את אנשי התוכנה, ומתוך כך לתקשר איתם בצורה מוצלחת יותר. חוץ מזה, כיף לקרוא אותו: הוא עשיר בדוגמאות מעניינות של עיצוב אינטראקציה, ומצחיק לאורך כל הדרך.
תקציר
לקופר יש כמה מסרים חשובים עליהם הוא חוזר שוב ושוב לאורך הספר. אנסה להביא אותם כאן בקצרה.
מתכנתים הם שונים משאר בני האדם
המסר הזה נשמע מעט צורם, כמו כל הכללה באשר היא, אבל יש בה לא מעט אמת. קופר מתאר את המתכנתים כאנשים אינטליגנטיים בעלי יכולת חשיבה לוגית חזקה – homo logicus הוא קורא להם, להבדיל מ-homo sapiens, שאר בני האדם. המנטליות וההינע (מוטיבציה) של שני הטיפוסים הללו שונה בתכלית:
Homo logicus, מתכנתים, מעדיפים שליטה מלאה על התוכנה, ומסכימים להתפשר ולעבוד עם מערכת מורכבת שמאפשרת להם את זה. הם מוּנעים על-ידי תשוקה להבין איך דברים עובדים.
Homo sapiens, שאר בני האדם, מעדיפים פשטות, ומוכנים להתפשר בנושא השליטה. הם מוּנעים על-ידי השאיפה להצליח.
הפער בין שני הטיפוסים עומד בשורש הצורך במעצבי אינטראקציה, שיבינו את הסוג השני של בני האדם, ויעצבו את המוצר עבורו.
הוא מביא בדיחה מצויינת בעניין הדחף החזק של מתכנתים (מהנדסים) להבין איך הדברים עובדים.
שלושה אנשים מיועדים להוצאה להורג: כומר, עו"ד ומהנדס. הכומר פוסע אל לולאת התליה והיא נכרכת סביב צווארו. התליין מושך את הידית כדי לתלות את הכומר, אבל שום דבר לא קורה. הכומר רואה בתקלה התערבות אלוהית, מבקש חנינה – ומקבל. הלולאה נכרכת סביב הצוואר של העו"ד, התליין מושך בידית, ושוב – שום דבר לא קורה. העו"ד טוען שאי אפשר להעניש אותו פעמיים על אותו הפשע, מבקש חנינה – ומקבל. המהנדס צועד לעבר עמדת התלייה, והלולאה מוצמדת לצווארו. הוא מתבונן היטב על המנוף שמחובר לידית של התליין, ולפני שהתליין מספיק למשוך בידית, הוא מסתכל למעלה, מחייך ואומר בסיפוק: "אה-הה! הנה הבעיה!"
מתכנתים מעצבים למתכנתים
קופר טוען שמתכנתים תמיד יתכננו מוצרים למתכנתים, כלומר ל-homo logicus, ולא ל-homo sapiens. מתכנתים מוכנים לחיות עם מערכות מורכבות אם הן מאפשרות שליטה מלאה. קופר אומר שאף יותר מכך, מערכות מורכבות נותנות למתכנתים ערך. הן מאתגרות אותם, וההתגברות על האתגר, תוך הבנה מעמיקה של העולם של המערכת, מעניקה להם תחושת כוח. לכן אין להם סיכוי ליצור מערכות שמתאימות ל-homo sapiens.
קופר מתייחס בכך למצב שהיה נפוץ בסוף שנות ה-90 בבתי תוכנה רבים, וקיים בלא מעט מהם עד היום: ברבים מבתי התוכנה אין מעצבי אינטראקציה, והעיצוב נעשה דה-פקטו על-ידי המתכנתים.
המתכנתים מושכים בחוטים
בכל פרוייקט תוכנה המתכנתים הם אלה שמעריכים כמה זמן ייקח ליישם כל שינוי ותוספת למוצר; אף אחד אחר לא יכול לעשות את זה במקומם. שינויי ממשק, שלא מעניינים את צוות הפיתוח, למשל, או שינויים בממשק שאינם קלים לביצוע, עשויים לקבל תווית מחיר יקרה מאוד מהמפתחים. תווית מחיר כזו תגרום למנהל הפיתוח להחליט לוותר עליהם, או להעביר אותם לתיעדוף נמוך יותר. קופר מסביר שבכך השליטה בתהליך הפיתוח נלקחת ממנהלי הפיתוח, ומועברת למפתחים עצמם.
חיכוך קוגניטיבי
חיכוך קוגניטיבי, cognitive friction, הוא מונח שקופר מגדיר. הוא מתאר אותו כהתנגדות שמביע האינטלקט האנושי כשהוא נתקל במערכת חוקים מורכבת, שמשתנים ברגע שהבעיה משתנה. הוא טוען שאינטראקציה עם תוכנה רצופה בחיכוכים קוגניטיביים.
נגינה בכינור, למשל, דורשת מיומנות רבה אבל לא יוצרת חיכוך קוגניטיבי. לא משנה מה נעשה, הכינור לא יתחיל להשמיע צילצולים במקום צלילי כינור, חורקים ככל שיהיו. במיקרוגל, לעומת זאת, מקשי המספרים יוצרים חיכוך קוגניטיבי, כי המשמעות שלהם משתנה: פעם הם שולטים בעוצמת הקרינה, ופעם בזמן הבישול. במקלדת המחשב המקש W עשוי במקרים מסויימים להקליד את האות W על המסך, במקרים אחרים (Ctrl+W) לסגור את החלון, ובמקרים אחרים להזיז קדימה שחקן במשחק מחשב. הדואליות הזו יוצרת חיכוך קוגניטיבי.
לא באנו ליהנות פה: משל הדוב המרקד
אנשים רבים מוכנים להסכים לחיות עם מוצרי תוכנה שקשה להם להפעיל, כאלה שיוצרים חיכוך קוגניטיבי, פשוט כי הם לא יודעים שאפשר אחרת. הוא ממשיל תוכנות כאלה למופע של דוב רוקד. צופים שמתבוננים בדוב רוקד כל-כך מתפעלים מהעובדה שהוא יכול לרקוד, שהם לא שמים לב לכך שהוא רקדן גרוע ביותר.
דוגמא אחת שקופר נותן לתוכנת דוב מרקד היא האימייל שכולנו משתמשים בו. רוב הודעות האימייל שמעניינות אותנו הן כאלה שהן חלק משיחה, כלומר שכמה הודעות נשלחות הלוך ושוב בין כמה אנשים סביב אותו נושא. אומנם Google Wave יהיה אחר, וג'ימייל מאגד הודעות לפי הנושא שלהן (כלומר, לפי שיחה), אבל הוא לא עושה את זה בצורה ברורה מספיק. האימייל שלנו לא מאפשר ניהול שיחה דיגיטלית, עם תגובות ממשתמשים מרובים, בצורה סבירה.
עיצוב אינטראקציה הוא לא עיצוב ממשק
קופר מסביר שהמושג "עיצוב ממשק" הוא שגוי, כי הוא שם את האנשים בצד אחד, את התוכנה בצד שני, ואת הממשק כגשר ביניהם. הוא מצביע על קשר עמוק בין המטרות של האנשים, האינטראקציה שנדרשת כדי לממש אותן, והתוכנה. הוא גם טוען שאי אפשר להצמיד בדיעבד ממשק לתוכנה שכבר נכתבה. לתפיסתו האינטראקציה שנדרשת מהמוצר צריכה להוביל את כל תהליך הפיתוח, כי אחרת התוכנה שפותחה בנפרד תגביל את האינטראקציה ותפריע לה להיות מיטבית.
כדי לעצב אינטראקציה צריך להבין מי ישתמש במוצר
קופר מגדיר את הכלי של פרסונות (personas), היום כלי מוכר היטב לעוסקים בעיצוב אינטראקציה. מי שנעזר בכלי זה מגדיר משתמשים דמיוניים (אבל מאוד ספציפיים), שעבורם המוצר יעוצב. הפרסונות מסייעות למעצב למקד את מאמציו סביב קהל יעד ברור ומדוייק.
בהיעדר פרסונות נוצר מה שקופר מגדיר כ"משתמש אלסטי" (elastic user) – כזה שאין לו איפיונים ברורים. משתמש אלסטי יכול להיות משתמש "פשוט" כשמשתמש כזה נוח למעצב המוצר, ומשתמש "מתוחכם" כשזה פחות נוח.
כדי לעצב אינטראקציה צריך להבין את המטרות של המשתמשים
המטרות (goals) הן המניע העליון של המשתמשים להשתמש במוצר. המטרות שייכות לקבוצות שונות:
- מטרות אישיות: אלה החשובות ביותר בעיני קופר, ולטענתו אסור לאף מוצר לגרום לנו להיכשל בהשגתן. הוא מביא כדוגמא מרכזית את המטרה לא להרגיש טיפש; מוצרים שקשה להשתמש בהם לא מאפשרים לנו לקיים מטרה זו. דוגמאות אחרות: לא לטעות, להספיק לעשות כמות סבירה של עבודה, ליהנות.
- מטרות עסקיות: למשל, להגדיל את רווחי החברה, לנצח את המתחרים, להציע עוד מוצרים וכד'.
- מטרות פרקטיות: כאלה שקשורות בביצוע המשימות שעומדות בפני המשתמש. למשל לרשום את פרטי הלקוח, לנהל את החשבונות של העסק, לשלוח חשבון שימוש ללקוח וכד'.
מוצר שעיצוב האינטראקציה שלו נובע מהמטרות של המשתמש יהיה בהכרח, על-פי קופר, מוצר טוב יותר. הוא ייצור חווייה טובה יותר אצל המשתמשים, ויביא לנאמנות חזקה שלהם למוצר. הוא מביא כדוגמא את מערכת ההפעלה של המקינטוש ומשתמשי המק הנאמנים לו עד אין קץ. על-פי קופר המסירות של המשתמשים נובעת ישירות מהעובדה שהמק עונה על המטרות שלהם בצורה מוצלחת.
זווית אישית
Cooper מכוון בספר את דבריו בעיקר לאנשי עסקים ומנהלי פיתוח, על-מנת להסביר להם למה מעצב אינטראקציה הוא קריטי בתהליך פיתוח המוצר שלהם. הוא מתאר את תהליכי פיתוח התוכנה כפי שהיו ב-1999, ללא מעצבי אינטראקציה, ואת המוצרים המורכבים שהם יצרו. בתי תוכנה לא מעטים, קטנים ובינוניים, ממשיכים להתנהל כך גם היום. הוא מסביר בצורה נבונה, משעשעת וקולעת, עם שפע של דוגמאות רלוונטיות, איך מעצבי אינטראקציה צריכים להשתלב בתהליך הפיתוח, ולמה כל-כך חשוב שהם יהיו שותפים לו.
במהלך שנות העבודה שלי ראיתי אינספור פעמים איך מוצר שמחלקת הפיתוח או מנהל המוצר ראו אותו בצורה מסויימת, עבר מהפך משמעותי כשעיצוב האינטראקציה נכנס לתמונה. תהליך עיצוב האינטראקציה השפיע לא רק על תהליכי העבודה שנחשפו למשתמש, אלא גם על תשתית התוכנה שעמדה מאחוריו. לא פעם קרה שתוכנה שנכתבה כבר והיה צריך רק "לעצב לה מסכים", נכתבה מחדש לאחר תכנון האינטראקציה. בדיוק על כך מדבר קופר בספר שלו.
במפגש ראשון מתכנתים עשויים לחוש מאויימים מנוכחותם של מעצבי אינטראקציה. לא פעם קורה שהתחושה הראשונית של מתכנת היא שהמעצבים לוקחים ממנו את החלק הכי יצירתי בתוכנה, הכי כייפי. למרות זאת, אחרי שתהליך עיצוב אינטראקציה מוטמע בארגון לאורך זמן, צוות הפיתוח מגלה שהתהליך מאפשר לו להתמקד במה שהוא מצטיין בו: לכתוב תוכנה איכותית, מקצועית ומדוייקת. לא מעט מתכנתים שפגשתי גם נהנים ללמוד על המוטיבציה מאחורי ההחלטות העיצוביות, שלעתים נראות להם תמוהות במבט ראשון.
סיכום
יאללה, רוצו לקנות ולקרוא. אפשר גם מכאן:
ובשביל שתוכלו לנוח מכל הטקסט הזה, הנה תמונה שצילמתי בגיאורגיה. ביליתי שם את החופשה שלי, ובעוונותי שם גם קראתי את הספר המצויין הזה. עוד צילומים שלי אפשר לראות באלבום הזה וגם בקצת על אהבה.
יש בשוק לא מעט אנשי מקצוע מצוינים.
יש גרפיקאים מוכשרים, מעצבי ממשק מיומנים ומתכנתים מעולים.
אבל מתכנת טוב שהוא גם גרפיקאי מקצועי ומעצב ממשק מיומן ?
זו חיה נדירה להפליא.
בהתחשב בכך, היה סביר לצפות שכל אחד מאנשי המקצוע יתמקד במה שהוא עושה טוב.
בפועל, לא פעם – המתכנתים מנהלים את כל העסק.
ומי שלא ראה ממשק שאופיין ע"י פקידים ועוצב ע"י מתכנתים לא ראה בלגאן מקושקש מימיו.
חשוב מאוד לנהל את תהליך אפיון הממשק במקביל לתהליך האפיון הפונקציונאלי ואפיון התכולה של המערכת.
בדיוק כמו שלא נכון לפתח מכונית, ורק כשהיא גמורה להתחיל לחשוב אל האופן בו הנוסעים והנהג יעשו בה שימוש,
כך לא נכון לפתח תוכנה ורק כשהיא גמורה להתחיל לחשוב ברצינות על המשתמש.
———-
רן.
אתה צודק, רן. זה בדיוק מה שקופר יוצא נגדו. בבתי התוכנה הגדולים יש בדרך-כלל מודעות לנושא חוויית המשתמש ועיצוב אינטראקציה, אבל גם בהם, כך ראיתי לא פעם, המתכנתים מנהלים את המשחק. המפסיד העיקרי הוא קודם כל הלקוח, ובאופן ישיר ומיידי – העסק. בעל עסק תוכנה שלא מבין שצוות הפיתוח שלו צריך לעסוק בפיתוח – ולא בתכנון מוצר – מסכן את העסק שלו, חד וחלק.
בעולם האתרים הקטנים זה בולט במיוחד, שם צוות של מתכנת וגרפיקאי פרילאנסרים מקימים אתר, כשעל-פי-רוב לא לזה ולא לזה יש ידע מקצועי בתחום חוויית המשתמש.
ברק יופי של סקירה תודה..מצד אחד "חסכת" לי סקרנות ומצד שני הקפצת את המוטיבציה שלי לקנות ולקרוא בעצמי..
נ.ב
בחופשה צריך לנוח ! (קריאת ספריים מקצועיים, בדיקת מיילים והודעות במשיבון אסורה בהחלט)
תודה אורן!
גם החברים שלי ירדו עלי בזמן הטיול, ובצדק – ובסוף אחד מהם החליט לקרוא אותו אחרי :-)
אני חולק עליכם –
מתי נקרא אם לא בחופשות?
את החופשה האחרונה שלי בתורכיה, לדוגמה,
בלתי בנעימים עם המשפחה ועם עותק מקומט היטב של
"Pro CSS and HTML Design Patterns "
( http://cssdesignpatterns.com/ )
(-B
היי ברק,
בחיי שאני לא מצליח להבין לא את ההיסטריה סביב ה-wave ובמיוחד לא את הטענות כלפי אימייל שהתחילו להתרבות אחרי ההכרזה על ה-wave. ואני עוד נמנה על מעריצי גוגל.
זה שאימייל לא מאפשר לנהל שיחה דיגיטלית יעילה אינו מפתיע, בהתחשב בזה שמדובר ב"_דואר_ אלקטרוני", כלומר משהו שאמור לאפשר לנהל _התכתבות_ דיגיטלית. אם אני רוצה שיחה ולא התכתבות, עומדים לרשותי מספיק כלים לא רעים שנועדו לזה. באותה מידה אפשר להתלונן שהאימייל לא מאפשר לערוך סרטים או לבשל פסטה (טוב, אולי באייפון כן, אני לא מכיר).
אני מאמין שצריך לדעת להבחין בין הכלים השונים ובין הייעודים שלהם. לאחר שהבנו מה יעודו של הכלי, אפשר להעריך עד כמה הוא מוצלח בתפקידו. לגבי ה-wave – עוד לא הבנתי ממש מה יעודו, ובינתיים אני מאוד מתקשה לדמיין איך הוא מחליף לי את המייל בעבודה.
יש תוסף ל-outlook בשם Xobni (כיתוב הפוך של inbox) –
http://www.xobni.com/
הוא מספק כל מני כלים שימושיים; בין השאר, הוא מאפשר להסתכל על תכתובת כחלק מ"שיחה".
דווקא את הפיצ'ר הזה אני מוצא לא נוח – תן לי לראות תכתובת לפי מי שלח, או אל מי, או מתי.
הניסיון לאגד אוסף של תכתובות מכותבים ואל מכותבים שונים כ"שיחה" רק מקשה ומבלבל אותי.
ויטלי,
בעיני לב העניין ב-wave הוא שהוא מאפשר, דרך אמצעי תקשורת אחד ופשוט (נקווה שיהיה כזה), להגיע הכי קרוב שאפשר לשיחה אמיתית, פנים מול פנים. מאחר ו-Wave מאפשר לנהל גם התכתבות דיגיטלית, אבל גם שיחה מורכבת עם שיתוף מידע ובזמן אמיתי, יש לו את הפוטנציאל להחליף את האימייל, המסנג'ר ומוצרי שיתוף כמו WebEx ואחרים.
אבל עזוב אותך מ-wave, מה דעתך על הספר? אני חושב שיש לו חשיבות היסטורית גדולה, לאופן שהוא הציב את המקצוע של interaction design על סדר היום של ההנהלה.
הי ברק,
פוסט מעניין, תמיד טוב לשמוע על ספרים חדשים, אני אישית קורא את "חפצים שימושיים" אבל נתקעתי בעמוד השלישי.
לא הבנתי מדוע "עיצוב האינטראקציה הוא לא עיצוב ממשק", מהו אותו קשר עמוק בין מטרות האנשים , האינטראקציה והתוכנה.
לדעתי, המונח "אינטראקציה" כולל בתוכו "עיצוב ממשק" ועוד מאפיינים שתורמים לחווית המשתמש.
אסף
היי אסף,
אני חושב שהכוונה של קופר (ואני לגמרי איתו בעניין הזה) היא שההתייחסות לממשק כאל חזית התוכנה בלבד, כזו שאפשר להדביק בדיעבד למוצר תוכנה אחרי שהוא כבר כתוב, מפספסת את העיקר. העניין שהוא מצביע עליו הוא שאינטראקציה שונה לרוב מכתיבה תוכנה שונה מאחורי הקלעים. לכן, הוא מסביר, חשוב שעיצוב האינטראקציה יתחיל ויוביל את תהליך פיתוח התוכנה, ולא יבוא רק לאחר מעשה.
הוא גם מצביע על הניתוק שמשתמע מהמילה עצמה, "ממשק": היא מצביעה על מצב שבו יש את האנשים בצד אחד, את התוכנה בצד שני, ואת הממשק שמקשר ביניהם, בעוד שבמציאות יש קשר הרבה יותר הדוק בין האנשים והתוכנה – יש אינטראקציה.
כמובן שהמונח "אינטראקציה" כולל בתוכו "עיצוב ממשק", אבל לתפיסתו השימוש במושג "עיצוב ממשק" כדי לתאר את עבודת עיצוב האינטראקציה הוא שגוי. במישור התאורטי אני מסכים איתו, אבל אם תנסה למכור ללקוח את שירותיך ותסביר לו כמשפט פתיחה שאתה במקצועך מעצב אינטראקציה, סביר להניח שהוא לא יבין בכלל על מה אתה מדבר. בשפה המדוברת "עיצוב ממשק" עדיין אומר "עיצוב אינטראקציה" למי שלא בקיא במקצוע.
הבעייתיות במונח "עיצוב ממשק" היא שנוצר הרושם שאפשר לתכנן ולבנות הכל רק כדי שמישהו עם עין עיצובית יעטר את המערכת בצבעים, אייקונים, תמונות ופונטים ולמעשה יפיק סוג של "צילום מסך" שהוא בגדר שכבה אסתטית במקרים רבים ולא יותר. אפשר לסכם את הגישה של קופר במשפט "קודם כל צריך לכתוב את חוברת ההוראות על פי שיהיה נכון וברור למשתמש ורק אחר כך לבנות את המערכת" כאשר בפועל מה שקורה הוא שהמתכנתים שבונים את המערכת מגדירים דה-פקטו את השלבים והפעולות ורק לאחר מכן מישהו צריך לכתוב את חוברת ההוראות כדי שאנשים יבינו מה הם אמורים לעשות.
עיצוב האינטראקציה מתייחס לאלף בית של המערכת מבחינת השלבים, האופציות, הלוגיקה של הפעולות, המודלים המנטאלים של קהל היעד ושאר השיקולים שצריך לקחת בחשבון לפני שכותבים את הקוד. לפי הגישה הקלאסית לפיתוח תוכנה שקופר יוצא נגדה בין אם בצורה ישירה או עקיפה, מגבשים רשימה אין סופית של דרישות מערכת המתארות את מה שהמערכת אמורה לעשות ואז המהנדסים שצריכים לבנות את אותה מחליטים תוך כדי התהליך מה יהיה הדיאלוג בין המשתמש והמערכת. בשביל המתכנת שמקבל את רשימת הדרישות היעד העיקרי הוא "שזה יעבוד" ואם הוא מתכנת טוב אז שזה יעבוד בצורה חלקה ומהירה, בלי באגים וצרות אחרות. דרישות מערכת יכולות להיות מאוד כלליות וכאשר מתכנת קורא את הדרישה "המשתמש יוכל לשנות את פרטי המשתמש שלו" הוא צריך לשבור את הראש ולהחליט על המקום במקרים רבים איך בדיוק זה יקרה בפועל. מתקוף המקצוע שלנו אנו חושבים על הודעות השגיאה, השלבים, המינוחים, חיווי ושאר שיקולי האינטראקציה.
אותם שיקולי שמישות ואינטראקציה לא נלקחים בחשבון או שאינם נלקחים בחשבון בשלבים הקריטים בגלל מגוון סיבות כמו היעדר מודעות, היעדר יכולת מקצועית וסדרי עדיפויות ("העיקר שזה יעבוד ויהיה מוכן בזמן – אם אנשים יתקשו לתפעל את זה נצרף חוברת הוראות ונאייש כמה טלפונים במחלקת התמיכה הטכנית"). מה שקופר אומר, וכיום זאת גישה יותר מקובלת ופחות מהפכנית, היא שתכנון האינטרקציה וגיבוש סדר הפעולות צריכים להתבצע בבסיס התהליך ואינם משהו שאפשר לעשות אחרי שהקוד נכתב והאינטראקציה כבר הוגדרה הלכה למעשה על ידי מי שכתב את הקוד והחליט שבשביל לשנות את פרטי המשתמש צריך לעבור חמישה מסכים כאשר בכל מסך ניתן לשנות רק פרט אחד למשל.
תודה אמיר, לא הייתי יכול לסכם את זה יותר טוב בעצמי. הגישה אכן יותר מקובלת היום מאשר כשהספר נכתב, אבל עדיין בהרבה בתי תוכנה שאני נתקל בהם בארץ הגישה היא – "טוב, גמרנו לפתח את המוצר, פחות או יותר, בואו ניקח איזה יועץ GUI שיעשה לנו קצת סדר בממשק". למסר של קופר ייקח עוד זמן לחלחל כאן לעומק.
אמיר,
ההסבר שלך בהחלט נתן לי מבט על ה"תמונה הגדולה" ואני מבין יותר את הבעייתיות במונח "עיצוב ממשק" ואת השוני בין עיצוב אינטראקציה לבין עיצוב ממשק.
בנוסף, אני חושב שנתת דוגמא טובה מדוע חשוב שאיש המקצוע שאחראי על עיצוב האינטראקציה גם יהיה בחלקו איש טכני, ויבין את המשמעות של הקוד שרשם המתכנת, אבל זה כבר נושא לפוסט אחר :-).
אסף, אם מעצב אינטראקציה טעם בעברו קוד זה פלוס מאוד רציני כי הוא מבין שלהוסיף כפתור לממשק זה לא פשוט כמו בפוטושופ ויש לכך השלכות שיוצרות בקלות אפקט דומינו. אני לא חושב שהוא צריך להבין את המשמעות של הקוד ברמת המיקרו קרי מה עושות המתודות, המחלקות והמשתנים כי למען האמת גם מתכנתים אחרים (ולפעמים המתכנת שכתב את הקוד בעצמו) לא מבינים במקרים רבים מה הולך שם. מי שיצא לו לתכנת מבין טוב מאוד את הנושא של אילוצים טכנים, תאימות ובאגים ויודע שכל פתרון לבעיה טכנית יוצר כמעט תמיד בעיה חדשה. אני לא טוען שכל מי שעוסק בתכנון אינטראקציה חייב לדעת מה זה מערך, משתנה ולולאה אבל זיקה משמעותית לתיכנות מאוד עוזרת במיוחד בדיאלוג עם הצוות הטכני שאמור לממש את התכנון שלך.
אמיר,
אני חושב שאפקט הדומינו וההשלכות של שינויי ממשק שהזכרת, שייכים יותר לעולם של מנהל המוצר מאשר של מאפיין האינטראקציה. מובן ששניהם צריכים להיות מודעים אליהם, אבל אלה יותר שאלות של התנהלות פרוייקט וחסמים שמנהל הפרוייקט צריך לשים על שינויים, בהתאם לנקודה שנמצאים בה על ציר תהליך הפיתוח, ופחות להבנה הטכנית של המאפיין.
אסף,
בתור מי שהיה מתכנת בעבר, אני יכול להעיד שידע בתכנות וחשיבה "תכנותית", או חשיבת ה"הומו לוגיקוס" בטרמינולוגיה של הספר, מאוד עוזרים בהיבטים שונים של עבודת מאפיין האינטראקציה עם צוות פיתוח התוכנה. הם עוזרים, למשל:
– להסביר למפתחים את ההגיון והלוגיקה שמאחורי הממשק
– לזהות את מקרי הקצה כדי ליצור איפיון מפורט שהוא מלא ומדוייק יותר
– להבין טוב יותר את המגבלות והיכולות הטכנולוגיות של המפתחים ולמצוא פתרונות אינטראקציה שמתחברים אליהם
– למצוא פתרונות זולים יותר (מבחינת זמן פיתוח) כשהאינטראקציה שאופיינה יקרה מדי לפיתוח
מצד שני, צורת החשיבה שבאה מתוך עולם התכנות יכולה גם להפריע לעבודת עיצוב האינטראקציה, ואת זה חוויתי לא פעם על בשרי:
– חשיבה הנדסית שונה מחשיבה של "אנשים רגילים" (ראה הומו סאפיינס לעומת הומו לוגיקוס למעלה). חשיבה כזו מובילה לא פעם לפתרונות מפורטים ומסובכים יתר על המידה. אלה אולי מדוייקים מאוד ומאפשרים למשתמש שליטה מלאה, אבל דורשים ממנו להבין הרבה יותר ממה שהוא באמת היה רוצה בשביל לעשות את המעט שהוא צריך לעשות עם המערכת.
– האמפתיה וההבנה שמתכנת (/לשעבר) חש למתכנתים ולקשיים שלהם עשוייה להסיט אותו ממציאת פתרון שהוא אופטימאלי עבור המשתמשים, לפתרון שיקל על המתכנתים.
– היכולת לרדת לפרטי הקשיים הטכניים והנסיון לסייע במציאת פתרונות טכניים מעוררת לא פעם התנגדויות מצוות הפיתוח, שנובעות משמירה על גבולות. במקרים כאלה המפתחים מרגישים, ובצדק, שחודרים לטריטוריה שלהם.
לסיכום, לדעתי מאפיין אינטראקציה צריך להכיר ולהבין את עולם התכנות, בעיקר כדי לתקשר עם צוות הפיתוח. הוא צריך להיות בעל איזושהי נטייה טכנית, אבל בעיני הוא לא צריך להבין את הקוד. לא פעם ההיפך הוא הנכון – הבנה מעמיקה של הקוד עשוייה להפריע למאפיין לבצע את העבודה שלו בצורה מיטבית.
ברק, ההערה שלי לגבי אפקט הדומינו היתה שמעצב אינטראקציה צריך להיות מודע שלהצעות שלו, גם אלו שנראות מאוד פשוטות כמו הוספת כפתור, יש לפעמים השלכות בעייתיות ברמת הקוד. זה משהו שחשוב לדעתי לזכור כאשר מדברים עם מתכנתים מתור אמפתיה בסיסית עם התפקיד שלהם ולו רק בשביל הערך הפוליטי בזמן התהליך. אני מסכים שאם האמפתיה הזאת "גוררת" אותך לצד שלהם על חשבון נוחות השימוש יכולה להיווצר בעיה אך מצד שני, אי אפשר להתעלם לחלוטין מאילוצים בשטח כי אז האיפיון יכול לצאת מנותק מהמציאות ולא ימומש כפי שרצינו. המצב האידיאלי הוא שהמתכנת, בעזרת יכולות ניתוח ופתרון בעיות גבוהות, ישבור את הראש וימצא פתרון לפני שמתפשרים.