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

האם אתם אוכלים את הדייסה שאתם מבשלים?

הביטוי Eat your own dog food מתאר מצב בו עובדים בחברה משתמשים במוצר שהם עובדים עליו. מעבר לנושא בדיקת איכות המוצר (Quality Assurance), מדובר במצב שמעמת את הצוות עם המוצר מנקודת מבט קריטית של משתמש קצה שתלוי במערכת בכדי לעשות דברים שונים. כל עוד אנו לא משתמשים במוצר ביומיום והאינטראקציה שלנו נוטה להיות מרוחקת וסטרילית. היא מסתכמת בניתוחים קרים של תסריטי שימוש, התעסקות עם אבות טיפוס, קידוד ואנו לא באמת "טועמים" אותו ולכן קל מאוד לא לראות (או להתכחש לעובדה) שלעיתים הטעם מר מאוד ולא ראוי למאכל אדם, או כלב במקרה הזה.

איסוף מידע

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

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

לטעום את המוצר

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

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

לא תמיד אפשר להשתמש במוצר גם אם רוצים

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

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

דקה לפני שאוכלים

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

בתאבון.

7 תגובות על “האם אתם אוכלים את הדייסה שאתם מבשלים?”

  1. 22/04/2009 בשעה 15:00 Dana Dumai

    Super important post amir, I agree with each and every word! :)

  2. 22/04/2009 בשעה 23:57 shvilam

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

  3. 23/04/2009 בשעה 16:09 ברק

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

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

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

  4. 23/04/2009 בשעה 19:21 אורי ער

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

  5. 25/04/2009 בשעה 16:26 ברק דנין

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

  6. 27/04/2009 בשעה 16:31 אמיר דותן

    אני ממליץ לקרוא פוסט קשור לנושא בשם
    Why we disagree with Don Norman
    אשר כולל התייחסות קולינרית רלוונטית ומציג למעשה את הגישה הקיצונית ההפוכה ללא לטעום בכלל מה אנחנו מאכילים את המשתמשים.

    We’re like chefs. We make food that we think tastes good and that we believe in. We make it for customers who have the same sensibilities that we do. It might not be for everyone. That’s ok. But for people who think the way we do, and appreciate the things we appreciate, it’s perfect.

    http://tinyurl.com/38sdq9

  7. 24/06/2009 בשעה 7:42 ברק

    אפרופו 37signals ולאכול את התבשילים שלך, הם התחילו בסידרת פוסטים שמראה איך הם משתמשים בכלים שלהם בתוך הארגון:
    http://www.37signals.com/svn/posts/1780-how-we-use-backpack-to-keep-track-of-our-email-newsletters

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

הוספת תגובה