RSS לפוסטים RSS לתגובות 228 מאמרים ו- 1,988 תגובות עד כה מאז 2005

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

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

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

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

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

1. ממשק נוצר בטכנולוגיה כלשהי

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

2. ממשק = קוד

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

3. "אופס. זה לא עובד."

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

4. הממשק הוא רק קצה הקרחון

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

5. ממשק תמיד יעטף במספר שכבות טכנולוגיות

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

אשמח להוסיף נקודות נוספות שיעלו בתגובות.

9 תגובות על “שיקולים טכנולוגים בסיסיים שאיש חוויית משתמש צריך להיות מודע להם”

  1. 23/06/2010 בשעה 14:18 אסף

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

  2. 23/06/2010 בשעה 14:33 צביקה

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

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

  3. 23/06/2010 בשעה 15:02 אמיר דותן

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

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

  4. 23/06/2010 בשעה 19:03 נועם

    פוסט מעולה!
    עשה לי סדר מבחינת מה אני צריך כדי להתפתח בתחום :)
    אסף – אני בהחלט מסכים שקורסים בנושא צריכים להיות חלק
    מתוכנית הלימודים במסלולים מסויימים (וחבל לי שאצלי זה לא היה קיים)

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

  5. 23/06/2010 בשעה 20:42 ויטלי

    יפה ומועיל! :)

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

    ומבחינת עומק ההיכרות – זה מאוד מזכיר לי את נושא מספר הנבדקים הנדרש בבדיקות משתמשים. כמו שחמשת הנבדקים הראשונים יתנו לך 80% מהתובנות, אבל בנבדק ה-40 לא תגלה שום דבר שלא ידעת אחרי 20 נבדקים, כך גם כאן: הכרת העקרונות הכלליים תתרום לך המון, אך ככל שהמומחיות שלך תגדל, כך התרומה של זה תרד. נדמה לי שבכלכלה קוראים לזה רווח שולי פוחת :).

  6. 25/06/2010 בשעה 0:29 אברהם

    תודה על הפוסט המעניין.

  7. 25/06/2010 בשעה 1:14 אברהם

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

  8. 28/06/2010 בשעה 0:48 יצחק

    פשוט תודה (:

  9. 30/06/2010 בשעה 8:59 יאיר

    מרתק לחלוטין, גם לאחד שהוא לא מהתחום, כמוני

RSS לתגובות לפוסט זה

הוספת תגובה