(This story is also available in English)
בפרשה הקודמת – בראשית – קרו מספר דברים שאינם זניחים. נברא העולם, אדם וחווה גורשו מגן עדן, קין הרג את הבל, והתקבלה החלטה להשמיד את האנושות באמצעות מבול.
נח מקבל הוראות מפורטות לבניית התיבה.
עם קבלת ההוראות נח ישר ניגש למלאכה. הוא לא שואל שאלות, לא מנסה להבין מדוע אלו הן המידות וזהו המבנה המדויק, לא מאתגר את דרישות הלקוח. טוב, במקרה שלו אולי זה לא רעיון מאוד מוצלח, אבל מצבנו בדרך כלל לא כזה נורא. לעיתים קרובות אנחנו מקבלים פתרונות מוגמרים שרק מתחזים לדרישות – "צריך שבעמוד הראשון תהיה כותרת, מתחתיה דרופדאון, אחר-כך טבלה ושני כפתורים". במקרה הטיפוסי זה מגיע בטקסט. במקרים הקשים זה מגיע בתמונה. אם אנחנו מאמינים שתפקידנו משמעותי יותר מאשר "צייר wireframes", עלינו לנסות להבין מה בעצם עומד מאחורי הממשק הזה שתואר לנו, איזה משתמש יעשה בו שימוש ומתי, מהם צרכי המשתמש והארגון, והאם אין דרך טובה יותר להשיג את היעדים.
אפשר פשוט לבקש דרישות טקסטואליות מנומקות במקום תיאורי ממשק (בין אם בתמונה או בטקסט). זאת דרך שמשרתת אותנו היטב אבל לעיתים מקשה על לקוחותינו הפנימיים, כי בתור אנשים שעובדים מול המחשב כל היום, גם הם כבר התרגלו לחשוב בצורה ממשקית, אז בפועל אנחנו מבקשים מהם "להנדס לאחור" את התמונה שיש להם בראש ולהפוך אותה לדרישות. זה אמנם מה שהם "אמורים" לעשות, אבל ברמה הפרקטית הרבה פעמים עדיף שאנחנו נהיה אלה שעושים את זה – יחד איתם, תוך כדי תשאול וקריאה משותפת "בין השורות". תהליך כזה מייצר שיחה מעולה שמאפשרת לענות על כל השאלות ולהבין את הדרישה לעומקה.
אילו הלקוח של נח היה קצת פחות… אהם… נקרא לזה "דומיננטי", נח היה יכול לנקוט בשיטות שונות העוזרות לנו לצלול לעומקה של הדרישה, כולל שיטת "חמשת הלמה" הנהדרת.
נח בונה את התיבה.
לפי מקורות שונים, בניית התיבה ארכה בין 75 ל-120 שנה. כך או כך, ברור לגמרי שבאופן נבואי משהו, נח עובד בשיטת Waterfall, בה קודם עושים את כל המחקר, אחר-כך מתכננים את כל המוצר מא' ועד ת', ובסוף מפתחים ומשיקים. שיטה זו אפיינה את תהליך פיתוח התוכנה עד תחילת שנות האלפיים, ולקראת הסוף היא כבר ייצרה מוצרים שהיו מיושנים עוד לפני שהושקו, אחרי שנים של פיתוח, שבמהלכם לא היו שום הכנסות, שום ערך ללקוחות, ושום משוב מהשטח.
עם התגברות קצב השינוי הטכנולוגי, הצורך להישאר עדכניים לשוק הפך ליותר ויותר חיוני, עד שהובן הצורך בשינוי מקיף של כל גישת הפיתוח. בשנת 2001 החלו להופיע שיטות Agile שונות, שמדגישות מחזורים קצרים של פיתוח פיצ'רים קטנים ובעלי משמעות, ואת השקתם המיידית. בדרך זו, הלקוחות מקבלים ערך ראשוני חודשים ספורים אחרי תחילת העבודה, החברה מייצרת הכנסות, וצוות המוצר מקבל משוב מיידי שעוזר לעצב את המוצר בזמן אמת.
אילו נח עבד בשיטה כזו, הוא כנראה היה מייצר קודם כל רפסודה קטנה, אח"כ סירה, אחר כך מפרשית, אוניה, ספינה הולכת וגדלה ולבסוף את התיבה. כמובן שזה לא אפשרי ארכיטקטונית ולכן מזל שהיה לו לקוח שיודע בדיוק מה הוא רוצה ומתי הוא צריך את זה, וגם הקצה מספיק זמן לטובת העניין. כל נושא שילוב הUX בתהליכים אג'יליים הוא מאתגר כי הוא דורש אופי וקצב עבודה שונים ממה שהיה הכי נח (סליחה) לנו, ונכתב בנושא הזה לא מעט. המסקנה היא בד"כ אותה אחת – המתכון הוא להשתלב באופן אורגני בעבודת צוות הפיתוח, להקדים אותם במחזור אחד (עדיף שניים), ולאמץ שיטות מחקר זריזות, יעילות ופחות פורמליות, תוך ויתור מודע על חלקים מהמתודולוגיה הקלאסית – תיכף נראה אחת כזאת בפעולה.
[slideshare id=119704148&doc=uxagilev25-181017063259]
המבול מציף את העולם. אחרי שנפסק הגשם, נח מתחיל לשלוח ציפורים כדי להבין האם המים ירדו מספיק כדי שייצא מהתיבה.
זוהי דוגמא נהדרת לגישת המחקר האג'יליות – במקום לשוט בכל פעם על איזו סירה ולחפש יבשה, נח מוצא דרך זריזה ויעילה לעשות את הבדיקה, תוך ניצול מבריק של האמצעים העומדים לרשותו. זה גם מאפשר לו לחזור על הבדיקה כמה פעמים בעלות נמוכה. זו בעצם כל המהות של מה שנקרא מחקר גרילה – בדיקות מהירות וממוקדות, כמו לשלוף בן אדם מהמסדרון או מבית הקפה הקרוב וללבקש ממנו לענות על כמה שאלות או להעיף מבט מהיר במסך שבניתם.
כשנח פורק מהתיבה הוא קודם כל בונה מזבח ומעלה קורבן לאל. האל מקבל את הקורבן, מבטיח שלא יהיה מבול נוסף, ומסמן את זה באמצעות קשת בענן.
יש לנו כאן משוב הדדי. נח מסמן לאל שהוא זוכר מה הביא את החורבן על המין האנושי ושמעכשיו בני האדם הולכים להתנהג יפה. הוא למעשה מקבל את תנאי השימוש בעולם הטרי (והלח) שקיבל לידיו. האל מצידו מסמן לנח שגם הוא מחויב אליו. אבל הוא גם מודע למגבלות הזיכרון האנושי ויודע שכאשר מדובר במידע חשוב, לא מספיק ליידע את המשתמש פעם אחת אלא יש להוציא חיווי חזרתי שיזכיר לו מדי פעם את מה שחשוב שיידע. אסור שהחיווי פשוט יישב שם כל הזמן כי אז יתרגלו לנוכחותו וישכחו שהוא נושא משמעות. חשוב גם שהוא יהיה בולט וימשוך את תשומת הלב. לכן – תשומת לב ("קשב" בעגה הפסיכולוגית) ומגבלות הזיכרון הם בין הנושאים המרכזיים בהתאמת הממשק אל הקוגניציה האנושית.
נח משתכר מיין. בנו חם נוהג בו בגסות רוח, אך בניו שם ויפת נכנסים לאוהל בהליכה לאחור כדי לא לראות את אביהם במערומיו.
התנהגותו של חם מזמינה את הדיון באתיקה בעולם הUX, אבל יהיו לנו עוד הזדמנויות רבות לדבר על זה בהמשך, לחבר'ה בספר הזה יש קוד אתי רעוע משהו. הפעם אני מעדיף להתמקד בגישוש באפילה של שם ויפת. הם נכנסו לאוהל בהליכה לאחור, והשלימו את המטלה באמצעות חושי השמיעה והמישוש בלבד (ובהתחשב במצבו של נח, כנראה גם חוש הריח) – בלי לראות שום דבר בעיניים.
ישנם לא מעט ממשקים שאינם מבוססי גרפיקה. לפני תחילת עידן הממשק הגראפי במעבדות Xerox PARC בשנת 1973, אנשים השתמשו בממשקי command line. וגם אם רובם המוחלט נמחק במבול הממשקים הגראפיים, עדיין יש תעשיות בהן ממשקי command line שולטים ביד רמה – וזה לא עקב הפיגור הטכנולוגי שלהן אלא בגלל שממשקים אלה הם יעילים וגמישים הרבה יותר מאשר ממשקים גראפיים, והמשתמשים שלהם מגינים עליהם בחירוף נפש. המחיר שמשלמים על כך הוא שממשקים אלה תובעניים הרבה יותר מבחינה קוגניטיבית, עם עקומת למידה מפלצתית, הסתמכות נרחבת על זיכרון ארוך-טווח ועומס רב על זיכרון העבודה.
האח הקטן והלא-צפוי של ממשקי command line נולד לפני שנים מעטות בצורת צ'אטבוטים למיניהם – נציגי שירות וירטואליים באתרים, ובוטים בפייסבוק ובסלאק לדוגמא. הם הרבה יותר קלילים לשימוש מאשר ממשקי CLI מלאים, והם גם מוגבלים בהתאם. הזרם המשמעותי השני של ממשקים שאינם גראפיים הוא ממשקים קוליים – סירי של אפל, אלקסה של אמאזון, קורטאנה של מיקרוסופט והאסיסטנט של גוגל הם הדוגמאות הכי מוכרות, אבל ישנם גם אינספור יישומים פחות מפורסמים. הם כולם יודעים לדבר עם המשתמש ולבצע את בקשותיו במידות שונות של הצלחה.
שאלה נפוצה בקרב אנשים שאינם מהתחום היא "מה הקשר בין זה לUX? מה יש לאפיין שם, אם אין מסכים אפילו?". ובכן, מבחינת אפיון חוויית משתמש העבודה היא לא מאוד שונה. המחקר הוא בדיוק אותו מחקר, מגבלות הזיכרון והקשב הן בדיוק אותן המגבלות, תרחישי השימוש, הפרסונות ומפות מסע המשתמש תקפים באותה במידה. יצירת ארכיטקטורת המידע ובניית הקונספט למערכות אלו נראות בדיוק אותו דבר כמו במערכות ויזואליות. כמובן שלכל פלטפורמה יש את הניואנסים שלה – אבל זה המקרה גם כאשר מדברים על אייפון לעומת אנדרואיד לעומת ווב לעומת דסקטופ. העבודה היא אותה העבודה בדיוק, למעט התאמות ברמת הפלטפורמה.
נח עושה ולידציה ראשונית, גוסטב דורה, ויקימדיה.
תקופת מה אחרי נח חיים בני האדם בשלום ואחווה ואף מחליטים לבנות את מגדל בבל ולהגיע לשמיים. האל לא ממש מפרגן למיזם ומערבב את שפותיהם כך שהם כבר לא מבינים זה את זה. הפרויקט לעולם לא מקבל טופס 4.
מוסכמות, סטנדרטים, קונבנציות. נכון שזה כיף כשכולם מדברים אותה שפה? אפשר לבנות דברים מדהימים. אבל זה לא ממש קורה. לפעמים מרגישים שהדברים מתחילים להתייצב קצת. ואז יש איזו התקדמות טכנולוגית מרשימה, מיליוני מפתחים בכל העולם מתנפלים עליה בבת אחת, כולם רוצים להקדים את הפקקים ולפתח את המוצר המדהים שלהם לפני המתחרים, כל אחד עושה את זה בדרך אחרת, ואנחנו מקבלים מבול (סליחה) של דרכים שונות לעשות את אותו הדבר בדיוק. הברירה הטבעית עושה את עבודתה באיטיות ונדרש איזה עשור כדי להגיע לכמה דרכים עיקריות שמכסות 80% מהשוק. ואז מגיעה ההתפרצות הבאה. ראינו את זה בתחילת תקופת המחשוב האישי, בתחילתו של האינטרנט, בימי ווב 2.0, בתחילתן של פלטפורמות פתוחות במובייל ובטח תיכף נראה את זה שוב בממשקים קוליים / מציאות רבודה / מציאות מדומה. בינתיים, התרשים הזה מתאר את כל מכשירי אדרואיד הקיימים בשוק, ואת השכיחות שלהם. אם הייתם רוצים לפתח אפליקציית אנדרואיד שתעבוד בכל המכשירים – הייתם צריכים לתמוך בכל הקוביות בתמונה.
(מקור)
האם אברהם יודע לזהות הנעה לפעולה? מה המודל המנטאלי של המצרים? האם גמישות עוזרת לעשות ילדים? מה קורה כשיש מקרה קצה שהוא, במקרה, ממש בקצה? כל זאת ועוד – בשבוע הבא. הרשמו לקבלת עדכונים!