בנובמבר 24׳ הצגתי בכנס COM.PLEX את מודל הדגים שהמצאתי במהלך התקופה שלי בחברת רדיס (Redis).

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

1. ברק דנין, סר הכנסים של קהילת ה- UX,

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

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

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

5. וכמובן נועה אשתיייי המהממת שהייתה הקהל הכי אובייקטיבי ומקצועי שיכולתי לבקש מבת-זוג.

ותודה ענקית לכל מי שנכחו בכנס 🙏

יאללה, לעניין

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

במידה ואתםן מעוניינים/ות לשמוע יותר על ההרצאה או לעבור סדנה בנושא ביחד עם הצוותים שלכםן (לאו דווקא רק המעצביםות!) אנא פנו אליי במייל או בלינקדאין.

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

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

יהלומים כפולים

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

1. המעצבים/ות לא היו מעורבים בספרינטים של צוותי הפיתוח ובגדול לא היו מעורבים במה שמכונה באג׳ייל Squad.

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

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

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

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

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

הגישה משתמשת ב- 2 יהלומים המייצגים 2 ״מרחבים״:

1. מרחב הבעיה, בו נרצה להבין למה משהו קורה.

2. מרחב הפתרון, בו נרצה לייצר את הפתרון הטוב ביותר לבעיה שמצאנו ביהלום הראשון.

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

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

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

עובדה חביבה (fun fact)

ה- UK Design Council העומדים מאחורי הדאבל דיאמונד, למעשה ביססו את המודל שלהםן על מודל ה״פתיחה-סגירה״ (the divergence-convergence model) שהוצג לעולם על-ידי Béla H. Bánáthy, איש תנועת הצופים (וחוקר שפה) אמריקאי-הונגרי, שהמציא את המודל שלו עבור קורסי הדרכה בתנועת הצופים האמריקאית. כבוגר ומרכז לשעבר בתנועת הצופים, אני מוצא את זה משעשע במיוחד. הייה נכון!

דגים מוזרים

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

כאמור, את הבעיה הראשונה יכולתי לפתור ״על המקום״ באמצעות הדאבל דיאמונד:

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

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

אח״כ ביצעתי יחד עם הצוות HMW (How Might We) מהיר שעזר לנו להבין טוב יותר את מוקד הבעיה ולג׳נרט פתרונות ״מעוצבים״ עוד לפני שגיבשנו הגדרת בעיה סופית.

שיטת ה- HMW מאפשרת לדמיין פתרונות אפשריים לבעיות הנכונות על-ידי שאילת השאלה How Might We שהמשכה מסנתז בעיה ופתרון. למשל (בעברית): ״איך נוכל לגרום למשתמשיםות להרגיש בטוחים בזמן שהם מכניסים את פרטיהםן לאתר שלנו בתהליך ההרשמה אליו״.

הצעת הפתרון שלי הסתמכה על יצירת Tooltip שישמש כמעין ״שלט״ שמצביע (או צועק) הי! זה השלב הבא! תלחצי פה! וזה נראה משהו כזה:

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

כאתגר UXי, זה אתגר מאוד פשוט:

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

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

זה היהה פרויקט שהתחיל עבורי בללמוד מושג חדש (שהיווה את שם הפרויקט, משהו עם Access Control) והמשיך עם עוד עשרות מושגים חדשים שמעולם לא שמעתי (או קראתי) בחיי, כמוgeo-distribution, regions, replicas, active-passive, ועוד.

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

יש פה הרבה יותר שלבים עד שנוכל להתחיל לדבר על ״פתרונות״:

ואז מנהל המוצר אמר את המשפט שהיה כל מה שחסר לי כדי לארוז את המודל שלי:

״אז זה בעצם... וואחד יהלום?!״

כן, וואחד יהלום indeed.

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

פה הבנתי שאני יכול לחלק את כל הפרויקטים שעשיתי ושנעשה בהמשך ל- 2 צירים מרכזיים:

היכרות מוקדמת והיקף.

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

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

פנצ׳ר בגלגל? בעיה לוקלית, ברגע שנחליף את הגלגל הספציפי (הנקור) הבעיה תיפתר.

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

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

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

נשארו לנו כרגע 2 רבעונים במודל שטרם הזכרנו.

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

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

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

דוגמה טובה תהיה פרויקט שקראנו לו - Maintenance window, ובעברית - חלון תחזוקה.

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

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

ומרגע שסיימנו ללמוד על התהליך, תהליך העיצוב יהיה מהיר, משום ש

1. מדובר על בעיה לוקלית, ומשום כך גם הפתרון יהיה לוקלי.

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

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

ואז הסתכלתי עליו ופשוט ראיתי את זה..

דגים.

הכל הזכיר לי דגים פתאום.

מודל הדגים

במודל הדגים יש לנו 4 דגים שמייצגים 4 סוגי פרויקטים:

נמו.

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

טונה.

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

סלמון.

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

ווילי.

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

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

איך?

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

נמו.

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

טונה.

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

סלמון.

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

נדבר עם משתמשים, עם שותפים לא-מעצבים ולמעשה עם כל stakeholder שנוכל.

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

ווילי.

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

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

תסתכלו על השקף הזה:

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

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

אבל תראו מה קרה ברבעון שאחריו:

לא רק שהצלחנו להכניס יותר משימות רודמפאיות (מתוכננות) אלא גם הצלחנו להתמודד עם המון משימות שלא היו מתוכננות בכלל או משימות איטרציה - שלבי ב׳ של משימות שלא הצלחנו להגיע אליהן עד כה…!

יוצאים מהמים

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

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

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

3. רק מיקבול משימות: ברגע שיש שפה משותפת ואנחנו עובדים באג׳ייל, מאוד קל להכניס עוד משימות נמו קטנות, למשל לטובת growth או כל מיני ניסויים, מה שבתורו מאפשר גם להגדיל את הקשר עם לקוחות ה- Low touch ובכך לתמוך עוד יותר במה שאנחנו קוראים לו עיצוב מוכוון-משתמשים 💪.

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

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

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

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

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

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

ולסיום, שאלת בונוס:

למה קראתי להרצאה ״דגים מוזרים״ ואיך זה מתקשר ללהקה האהובה עליי בתבל?

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

בשורות טובות 🙏

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

מי השחקנים שלנו?

• הנוסע / המשתמש (User): האדם שמבקש מונית.

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

  • שירות המפות (GPS Service): מערכת חיצונית המספקת נתונים על מיקום, זמינות נהגים, וחישוב זמן הגעה.

  • ספק התשלום (Payment Gateway): שירות צד שלישי שבודק האם ניתן לחייב את הנוסע או לשמור אמצעי תשלום לביצוע החיוב בסיום הנסיעה.

• נהג המונית (Driver): האדם שיקבל את הקריאה מהאפליקציה, יאשר אותה ויגיע לאסוף את הנוסע.

מהלך האירועים:

1. הנוסע מזין כתובת יעד באפליקציה.

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

3. שירות ה-GPS מחזיר רשימה של נהגים באזור, לצד זמני הגעה משוערים.

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

5. לאחר אישור התשלום, האפליקציה שולחת התרעה לנהג.

6. הנהג מאשר ומקבל פרטי נסיעה.

7. הנוסע מקבל הודעת אישור ויכול לראות את פרטי הנהג וזמן ההגעה.

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

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

להפוך שרשרת פעולות למפה ויזואלית עם OSD

בואו ניקח את הדוגמה של הזמנת המונית ונתאר אותה כ-OSD.

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

1. מי פועל מתי?

2. איך מידע עובר מגורם אחד לאחר?

3. מה סדר הפעולות הנדרש?

4. היכן עלולים להופיע עיכובים, כשלים או נקודות תורפה.

איך נראה OSD להזמנת מונית?

ממש ככה:

בואו נצלול.

• ראשית, התרשים נע משמאל (מהנוסע) לימין (עד לנהג).

• בראש התרשים אנו רואים עמודות (Swim lanes) עבור כל שחקן: נוסע, אפליקציה, שירות GPS, ספק תשלום, נהג.

• נצייר חיצים המייצגים הודעות, בקשות ותגובות. כל חץ מסביר בדיוק מה קורה (לדוגמה: “האפליקציה שולחת בקשת זמינות” ל-GPS).

• הציר האנכי (מלמעלה למטה) מתאר את כרונולוגיית האירועים.

פירוט OSD להזמנת מונית (במילים):

1. הנוסע ← האפליקציה: הנוסע מזין יעד ולוחץ “חפש מונית”.

2. האפליקציה ← ה- GPS: האפליקציה מבקשת מ-GPS רשימת נהגים זמינים.

3. ה- GPS ← האפליקציה: GPS מחזיר רשימת נהגים וזמני הגעה משוערים.

4. האפליקציה ← תשלום: האפליקציה מבקשת אישור חיוב.

5.תשלום ← האפליקציה: התשלום אושר (או יש עניין לחייב רק בסוף? גם זה יופיע כאן).

6. האפליקציה ← נהג: האפליקציה בוחרת נהג מתאים ושולחת אליו הזמנה.

7. נהג ← האפליקציה: הנהג מאשר את ההזמנה.

8. האפליקציה ← נוסע: האפליקציה מציגה לנוסע את פרטי הנהג וזמן ההגעה.

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

מה עשינו כאן בעצם?

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

אבל למה זה חשוב בעצם?

• ה- OSD עוזר לנו להבין שאנחנו מאפיינים ”מסע” – לא מסך בודד, אלא רצף פעולות התלויות זו בזו.

• בעזרת ה-OSD נוכל לזהות היכן בתהליך המשתמש עלול להיתקע, איפה המערכת מבזבזת זמן או מאטה, והאם יש שלבים מיותרים.

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

אז מהו תרשים רצף תפעולי (OSD)?

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

נקודות השקה בין OSD ל-Sequence Diagram:

• בשניהם רואים Actors ופעולות מסודרות בציר זמן.

• בשניהם נשתמש בחצים להראות אינטראקציה.

• בשניהם ניתן להציג תרחישים חלופיים (מה אם אין נהגים זמינים? מה אם התשלום לא מאושר?).

הבדל מרכזי:

בעוד Sequence Diagram UML קלאסי מתמקד במבנה הפנימי של התוכנה, OSD מרחיב את המבט גם לגורמים אנושיים ומערכות חיצוניות, תוך דגש על חוויית המשתמש והמסע השלם. OSD הוא יותר “מרקם הסיפור” מכלל האינטראקציות, ולא רק תרשים טכני.

מתי הכי נכון להשתמש ב-OSD?

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

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

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

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

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

איך בונים OSD מעולה?

1. התחילו מהמשתמש: הגדירו את המטרה שלו – למשל, להזמין מונית ולהגיע ליעד.

2. מפו את כל השחקנים: לא רק המשתמש והאפליקציה, אלא גם שירותים חיצוניים, ספקי תשלום, נהגים, נציגי שירות, וכל גורם שמשפיע על התהליך.

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

4. הציגו תרחישים חלופיים: מה אם אין נהגים זמינים? האפליקציה צריכה להחזיר הודעה למשתמש. מה אם התשלום לא מאושר? יש להציג אפשרות לאמצעי תשלום אחר.

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

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

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

בהצלחה.

המספרים בתעשייה מספרים סיפור מעניין: לפי מחקר של Nielsen Norman Group מ-2020, היחס הטיפוסי בין חוקרי משתמשים, מעצבים ומפתחים עומד על 1:5:50. זה שיפור משמעותי לעומת היחס שנמדד ב-2017, שעמד על 1:5:100. למעשה, כיום ב-50% מהחברות יש לפחות מעצב אחד לכל 10 מפתחים, וב-54% מהחברות יש לפחות חוקר אחד לכל 10 מעצבים.

סוגי מחקר משתמשים

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

ציר ראשון: כמותי מול איכותני

• מחקר כמותי: נתונים מספריים - כמה משתמשים, זמני ביצוע, שיעורי שגיאה

• מחקר איכותני: תובנות עומק - מוטיבציות, מחשבות, תחושות

ציר שני: התנהגות מול דיווח

• התנהגות: מה המשתמשים באמת עושים (צפייה, ניתוח לוגים, בדיקות שמישות)

• דיווח: מה המשתמשים אומרים שהם עושים (ראיונות, סקרים, קבוצות מיקוד)

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

שיטת הצומ”י: המדריך המעשי

צא ולמד: חצי שעה ביום משנה הכל

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

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

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

משתמש אחד: העומק חשוב מהכמות

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

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

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

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

חלום שמתגשם 🦄

יד ביד: שיתוף הוא המפתח

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

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

הכלי שמשנה את המשחק: Nugget Board

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

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

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

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

איך מתחילים?

כיצד מתחילים ליישם את שיטת הצומ”י? הכנתי תוכנית פעולה פשוטה לשלושת השבועות הראשונים:

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

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

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

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

סיכום

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

ב- 1985 אלן קופר (Alan Cooper), חלוץ בתחום חוויית המשתמש ומפתח תוכנה בהכשרתו, יוצר את הפרסונה (Persona) הראשונה שלו - קאת׳י (Kathy). קאת׳י ייצגה את קבוצת המרואיינים שקופר חקר בזמן שבנה מוצר חדש שישמש אותםן לצורך תכנון פרויקטים. בהמשך אותו מוצר (שנקרא בהתחלה Plan*It) יימכר למיקרוסופט ויקרא Visio, אבל מה שחשוב כאן הוא שזו הייתה הפעם הראשונה בה פרסונה - דמות ארכיטיפית המייצגת קבוצת משתמשים/ות בעלת מאפיינים דומים - תרמה את חלקה ביצירת מוצר חדש.

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

בספר הנהדר שלו The inmates are running the asylum (מוזמנים לקרוא על הספר פה) בו קופר בעצם דרש מתעשיית התוכנה להפסיק לייצר מוצרים שמשרתים רק את השגעונות של המפתחים ולהתחיל להיפגש עם משתמשים, הוא מבחין בין buyer personas (פרסונות רוכשים) ו- user personas (פרסונות משתמשים) וכותב כך:

“Personas are not real people, but they represent them through the design process. They are hypothetical archetypes of actual users. Although they are imaginary, they are defined with significant rigor and precision.”

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

הבנת מטרות משתמש

החלק האהוב עליי בספר About Face הוא החלק בו אלן קופר מדגיש את החשיבות של הבנת סוגים שונים של מטרות-משתמש (user goals) בעת יצירת פרסונות. המטרות הללו מספקות תובנות עמוקות יותר על המוטיבציות של המשתמשים ועוזרות לתעדף החלטות עיצוב:

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

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

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

יצירת פרסונות: המתודולוגיה של קופר

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

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

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

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

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

מדריך פרסונות to go

1. התחילו עם מחקר: ערכו מחקר משתמשים מקיף באמצעות ראיונות, סקרים ותצפיות. אספו כמה שיותר נתונים כדי להבטיח הבנה מקיפה של קהל המשתמשים שלך.
2. נתחו את הממצאים שלכםן: חפשו דפוסים וטרנדים בנתונים. זהו התנהגויות מפתח, מטרות ונקודות כאב שיהוו את הבסיס של הפרסונות שלכםן.
3. צ(יי)רו את הפרסונות שלכםן: צרו (באופן גרפי) פרסונות מפורטות בהתבסס על הניתוחים שלכםן. כללו פרטים דמוגרפיים, מטרות, צרכים, התנהגויות ונקודות כאב. הוסיפו תמונות וסיפורי רקע כדי להפוך אותן לניתנות להזדהות.
4. השתמש בפרסונות בעבודת ה-UX שלכםן: שלבו את הפרסונות שלכםן בכל שלב בתהליך העיצוב וה- UX. ״פנו אליהן״ בעת קבלת החלטות עיצוב, יצירת תרחישים ואימות העיצובים שלכםן.
5. שתפו עם הצוות שלכםן: הפיצו את הפרסונות לכל הצוותים השונים. ודאו שכולםן מבינים מי הם המשתמשים ומה הם צריכים. השתמשו בפרסונות כשפה משותפת באופן קבוע כדי להקל על שיתוף פעולה.
6. עדכנו את הפרסונות באופן קבוע: כמו בני אדם אמיתיים, גם הפרסונות מתפתחות ומשתנות ככל שצורכיהן והתנהגותן מתפתחים ומשתנים. כדי לשמור על הרלוונטיות שלהן יש לסקור ולשפר את הפרסונות באופן קבוע על סמך מחקר ותובנות חדשות.

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

יישום פרסונות בעיצוב מוצר

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

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

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

ההבדל בין פרסונות (Personas) ו- Jobs to Be Done (JTBD)

בדומה לפרסונות, גם Jobs to Be Done (JTBD) מהווה Framework (מסגרת עבודה) חשובה בעיצוב ממוקד משתמשים, אולם שתי המתודות הללו שונות במטרותיהםן:

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

לעומת זאת, הפוקוס ב- JTBD הוא על ה״מה״ - מה המשתמשים מנסים להשיג עם המוצר או השירות שלכםן, תוך דגש על ההקשר. קלייטון כריסטיאנסן (Clayton Christensen) מי שפיתח (אך לא המציא) את רעיון ה- JTBD בספרו The innovator’s solution (2003) אמר כך:

“When people find themselves needing to get a job done, they essentially hire products to do that job for them. The marketer’s task is therefore to understand what jobs periodically arise in customers’ lives for which they might hire products the company could make”

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

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

בהצלחה 🦄

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

1. מטרות חוויה (Experience goals) -
   התחושה (או הרגש) שהמשתמשים רוצים לחוות בעת השימוש במוצר או שירות. למשל, משתמש עשוי לרצות להרגיש תחושה של שמחה, יצירתיות או סיפוק רגשי בעת עריכת תמונות. עירור רגשות חיוביים ויצירת חוויה מעניינת ומספקת הם מפתח ל- engagement.

2. מטרות קצה (End goals) -
   המשימות או התוצאות הספציפיות שהמשתמשים רוצים להשיג, כמו שיפור ושיתוף תמונות עם יישום לעריכת תמונות. אלו בעצם מטרות המוצר עצמו.

3. מטרות חיים (Life goals) -
   המוטיבציות והשאיפות הרחבות יותר המשפיעות על גישת המשתמשים למוצר, כמו הרצון לתעד ולשמר זיכרונות באמצעות צילום. מטרות החיים מייצגות את “התמונה הגדולה” של הסיבות המניעות את המשתמשים.
   

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

את הטיסה להרצאה ביליתי בקריאת הספר הפחות מוכר של קופר - The inmates are running the asylum (האסירים מנהלים את בית המשוגעים) ולהפתעתי גיליתי שהוא הטוב יותר מבין השניים.

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

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

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

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

קופר ואני

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

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

שיטת הצומ״י

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

בחזרה לסיפור שלנו.

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

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

לפגוש את קינג-קונג

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

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

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

מה זה צומ״י?

צומ״י הוא ראשי תיבות של:

1. צא ולמד.

2. משתמש אחד.

3. יד ביד.
   

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

1/ צא ולמד

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

1. מה המוצר עושה?
   

2. מה האבנים הגדולות (הפיצ׳רים המרכזיים) שבו ומה נחשב לאבנים הקטנות (פיצ׳רים משניים)?

3. מה הפלואים המרכזיים?

4. איך נראים תהליכי ההרשמה?

5. איך נראים תהליכי התשלום?

6. איך נראים תהליכי העבודה?

7. איך נראה ה-Money flow (הפלואו שמוביל ל- A-Ha moment?
   

8. איך נראית השפה העיצובית?

9. מה הקשר בין המוצר לבראנד?

10. איך נראה תהליך העבודה על המוצר?

11. מי הם מקבלי ההחלטות?

12. מי המבצעים בפועל?

13. מתי פוגשים את המעצבות?

14. האם מישהו פוגש משתמשים בתהליך?

15. מה ההיכרות הנוכחית של כל בעלי העניין עם המשתמשים?

16. מי המתחרים של המוצר?

17. מה מייחד כל מתחרה?

18. מה המשתמשים של המתחרים אוהבים במוצרים המתחרים?

19. איפה המתחרים פועלים (גיאוגרפית)?

20. מי הפרסונות אליהן הם מכוונים?

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

2/ משתמש אחד

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

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

זה בדרך כלל יהיה התהליך, בגדול:

1. מאתרים את הנבדקים הפוטנציאליים. איפה?

2. באינטרנט

3. קבוצות חברתיות רלוונטיות

4. היכרות אישית

5. חיפוש שרירותי בספר הטלפונים

6. מתאמים ציפיות

7. מה אני רוצה ממנו בכלל?!

8. איך הוא הולך לעזור לי ואיך זה הולך לעזור לו?

9. כמה זמן זה ייקח ממנו?
   

10. נבצע את התצפית + ריאיון (contextual inquiry)
    במקום העבודה של המשתמש.

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

12. סגמנטים

13. מטרות

14. מוטיבציות

15. צרכים

16. נקודות כאב

17. מוצרים משיקים / מקבילים

18. קונטקסט העבודה שלהםן
    

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

כמה טיפים של אלופות:

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

3/ יד ביד

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

1. בוחרים צוות של מפתחים, מנהלי מוצר ומעצבים

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

3. מגדירים את מטרות ויעדי המחקר הספציפי

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

5. מבצעים

6. מסכמים יחד, כצוות

7. מפרסמים יחד, כצוות
   

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

בהצלחה!

1. נלחץ על כפתור הכנת הקפה.

2. המכונה תופעל כעת ותתחיל לחמם את המים על פי הפרמטרים שהוגדרו מראש.

3. נורית חיווי תהבהב ותציין שהמכונה קיבלה את הפקודה.

4. המכונה תתחיל להשמיע צלילים שמעידים שמשהו קורה (טחינת פולים, זרימת מים וכו’).

5. אנימציית ה- LED (אם יש לכםן) תראה את ההתקדמות של תהליך ההכנה.

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

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

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

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

בשלב הזה נכון יהיה לו בוגרי התואר השני בהנדסת אנוש (human factors engineering) ירימו גבה, שכן התיאור של מיקרו-אינטראקציות מזכיר בבירור את הרעיון הותיק יותר של ניתוח מטלות היררכי (hierarchical task analysis). ואכן מדובר על אותה גברת בשינוי אדרת, או יותר נכון - עם אדרת המתאימה קצת יותר לעולם של עיצוב אינטראקטיבי למערכות מורכבות.

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

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

איך אינטראקציות משפרות את חוויית המשתמש?

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

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

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

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

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

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

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

דן סייפר דן בס(יי)פר שלו (סליחה 😅):

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

בואו נצלול למודל המתואר הספר.

ארבעת רכיבי המיקרו-אינטראקציה

לפי סייפר, מ״א מורכבת מ- 4 רכיבים: טריגר, חוקים, משוב ומצבים/לולאות.

טריגרים

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

1. טריגר משתמש: פעולה מכוונת של המשתמש כמו לחיצה, הקשה, תנועת יד, פקודת קול וכו’.

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

חוקים

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

משוב

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

1. ויזואלי (אנימציה, שינוי צבע, שינוי צורה של אייקון וכו’)

2. שמיעתי (צליל, טון)

3. תחושתי (רטט)

לולאות ומצבים

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

בכל פעם שאנחנו ניגשים לייצר מ״א, נחשוב על ארבעת הרכיבים - הטריגר, הכללים, המשוב והלופים/מצבים - וכמו לגו נרכיב מ״א יעילות ואינטואיטיביות שמשפרות את השמישות ו(כתוצאה מכך גם את ה-) engagement במוצרים דיגיטליים.

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

יישום בפועל

סייפר (Saffer) מציע 2 גישות לשילוב מיקרו-אינטראקציות בתהליך העיצוב:

על-בסיס מקרה-קצה (case-to-case basis)

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

1. מהו הטריגר (פעולת משתמש או מצב מערכת) שמפעיל את מ״א הזו?

2. מהם הכללים ששולטים בהתנהגות של המ״א הזו?

3. איזה משוב (ויזואלי, שמיעתי, מגעי) צריך להיות מסופק למשתמש על בסיס הכללים?

האם יש מצבים (התנהגויות חלופיות) או לולאות (מצבים חוזרים) למ״א הזו?

גישה הוליסטית

קביעת סט של עקרונות והנחיות לאינטראקציות מיקרו שמתאימים לשפת העיצוב הכוללת של המוצר ולמטרות חווית המשתמש. סוג של Design-system למיקרו-אינטראקציות. אני אמליץ שמי שרוצים לנקוט בגישה זו יבחנו ראשית את הגישה הראשונה, הספציפית יותר ולאט לאט יתוו חוקים ועקרונות אותם ננסה להלביש על המ״א הבאות שנייצר.

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

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

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

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

הנה כמה דוגמאות נפלאות למיקרו-אינטראקציות יעילות

בחירות וקוסטומיזציות

ולידציה וקידום של טפסים

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

פעולות גרירה

כפתורים ממונפשים

התחלה / עצירה

מיקרו-אינטראקציה תעזור לנו לסמן למשתמש מתי פעולה התחילה / הסתיימה.

אנימציות גלילה

כותרות דביקות (sticky), אפקטי Parallax או תנועה רכיבים עוזרים לייצר חוויה דינמית ו- engaging.

מצבי שגיאה/הצלחה

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

אנימציות טעינה

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

תוספות מהנות

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

לסיכום

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

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

מה זו בעצם מטלת לוח?

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

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

מה בודקים בראיונות כאלה?

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

מה זה אומר בפועל?

• קולגיאליות: איך אני מתקשר עם המראיין והצוות? איך אני אגרום לקולגות שלי להראות טוב? איך אני נותן ומקבל ביקורת?

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

• מתודיות: מה תהליך העבודה שלי? מה השלב הבא? האם אני יכול ללמד את הצוות משהו חדש? איך אני חושב ועובד תחת לחץ?

• תקשורת: האם אני האדם שהצוות רוצה לעבוד איתו ביום-יום? האם אני יודע לבקש מה שאני צריך בצורה נעימה ומכבדת?

כלי עבודה

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

1/ מגהפון

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

2/ סימטריה

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

3/ לפתור גרסה קטנה של הבעיה

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

4/ לחשוב עם צירים

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

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

לסיום, כמה כללי אצבע שאני ממליץ לאמץ

1/ לא להמציא אתגרים איפה שאין

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

2/ התשובה הכי טובה ל”יש לך שאלות אלי?”

ברוב המקרים המטלה תסתיים בשאלה ״יש לך שאלות אלי?״ ואני רוצה להמליץ על מה שהיא לדעתי התשובה הטובה ביותר:

“בהנחה ואני מתחיל לעבוד פה מחר, אלו פרויקטים יתאימו לי לדעתך?״

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

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

3/ לפתוח לעומת לסגור

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

תהליך ה- Double diamond מתחלק ל- 4 שלבים כשכל אחד מהם ״פותח״ (מחפש עוד אפשרויות) או ״סוגר״ (מצמצם את האפשרויות) כשהמבנה הוא פתיחה > סגירה > פתיחה > סגירה. בעיניי זה מבנה מצוין לריאיון מהסוג הזה כשהמוקד הוא להבין באיזה שלב אתםן נמצאים. יש לכם בסה״כ 40 דקות לראיון, לא הייתי מנסה ״לפתוח״ דברים בדקה ה-35. הייתי מנסה לשמור על המודל הזה כדי לסיים את הראיון עם תוצר שאפשר להתייחס אליו, ואגב אורחא להראות שאתם מאורגנים ומבינים היכן אתם בתהליך העבודה.

4/ ללמוד את מרחב הבעיה לפני הראיון

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

גדול עליכםן? דברו עם ChatGPT וספרו לו שאתם מתראיינים לתפקיד מעצב מוצר בחברה X, שעושה Y ואתם צריכים 6-7 מודלים שאתם צריכים ללמוד כדי להבין מה עושים בחברה הזאת. זה יכול להיות הרשאות, לוגים, API, תעבורת רשת - כל דבר שיתן לכם בסיס טוב לשיחה עם המראיין וקצה חוט לפתרון תרגילים פוטנציאלים. לפעמים זה מצליח ולפעמים ״רק״ לומדים משהו חדש על הדרך.

5/ מה באמת משנה

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

שיהיה המון בהצלחה ונתראה בשמחות 🙏

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

למעשה, היא תמיד הייתה שם בתור אלמנט אפיוני, UX׳י.

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

מה התפקיד של אנימציה ב-UX?

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

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

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

פוקוס

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

פידבק

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

שימו לב שלגבי זמני פידבק, ההמלצה של NN/g היא לדבוק בשיטת ה- 0.1, 1, 10.

תקשור מצב מערכת (אוריאנטציה, טעינה)

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

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

וגם בהוספת מוצר לעגלה באמזון

תקשור ה- affordance (אפשרויות אינטראקציה)

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

איך להשתמש נכון באנימציה ב- UX

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

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

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

3. תאוצה תאוטה. כמעט כל תנועה שאנחנו רואים בחיים האמיתיים היא לא ליניארית. כלומר היא לא מתחילה ונגמרת באותה מהירות. דמיינו שאתם זורקים כדור כלפי מעלה, הוא מתחיל מהר, ואז מאט לקראת שיא הגובה שלו, ואז בירידה, מתחיל לאט ומאיץ לקראת הפגיעה שלו באדמה. מהירות התנועה שלו משתנה. וכך גם צריכים להתנהג האלמנטים בממשקים שלנו. הם צריכים להראות ולהרגיש ״טבעיים״. לכן כדאי להקפיד להשתמש ב- ease in / ease out כאשר אנחנו מגדירים אנימציה לאובייקט בממשק.

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

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

המאמר נכתב על-ידי אורי פרידמן, מעצב חוויית משתמש בחברת Martix.

לכל שאלה אתםן מוזמנים/ות ליצור איתו קשר כאן:

ori370@gmail.com

https://www.linkedin.com/in/ori-fridman-a3272535/

orifridman.co.il

עריכה: טל סולומון

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

נתחיל בהדגמה קלה:

1. מה היה השם של הגננת שלכם בגן החובה?

2. האם רותי הייתה הגננת שלכם בגן החובה?

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

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

דוגמא למוצר שמפחית באופן דרמטי את הצורך בשליפה הוא נטפליקס:

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

דוגמא למוצר נהדר שדווקא קצת כושל לטעמי מהבחינה הזאת היא Slack. Slack היא אפליקציית מסרים מידיים שמשמשת בעיקר לצורכי עבודה. אפשר לייצר בה “ערוצים”, על אותו עיקרון של קבוצות בוואטסאפ. מטבע הדברים, די מהר מצטברים עשרות ערוצים כאלו והשמות שלהם מאוד דומים אחד לשני, מכיוון שמדובר בסביבת עבודה ואין מקום לשמות משוגעים או מצחיקים. היזכרות בשם של ערוץ ספציפי על מנת לכתוב אותו בשורת חיפוש ולהגיע לערוץ הרצוי היא מאוד קשה ויתכן שSlack היו צריכים לעשות יותר על מנת להקל על המשתמשים ולאפשר להם זיהוי במקום שליפה. לשם ההוגנות, אציין כי קיים navigation bar ובו יש אזכור לכ15 ערוצים שאני חברה בהם. לצערי, זה לא פתרון מספק כי מדובר בטיפה בים ועדיין אני מוצאת את עצמי פעמים רבות שוברת את הראש בנוגע לשם המדויק של ערוץ ספציפי. והשליפה, רבותיי, השליפה היא כואבת.

אם כן, בתהליך עיצוב המוצר, דאגו לספק למשתמשים שלכם כמה שיותר רמזי שליפה על מנת לייצר להם קונטקסט ולא להשאיר אותם לסרוק פרטי זיכרון רדומים. מעצבים מסך Login ובראשו “username:____” למרות שבמוצר שלכם מתחברים עם אימייל? כתבו “Email” וספקו למשתמשים קונטקסט חוסך זמן ועצבים (בנוגע לסיסמא, הנה מאמר מעולה שיעזור לכם לעזור למשתמשים שלכם לקבוע סיסמא שהם יזכרו). אל תתביישו להציג למשתמשים נתונים דוגמת “היסטוריה”, אשר מזכירים להם פעולות קודמות שהם עשו ואולי רוצים לבצע שוב. כל אלו יספקו למשתמשים חוויה קלה ונעימה יותר.

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

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

זיכרון עבודה הוא מוגבל

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

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

שיטה נוספת שמקלה על המשתמשים היא חלוקה לקטגוריות או קבוצות. מסתבר שמידע אשר מסודר בקטגוריות (גם אם הן שרירותיות למדי) יוחזק בקלות רבה יותר בזיכרון העובד. דוגמא אחת היא שקל לנו יותר לזכור מספר טלפון שנראה ככה 052-678-9445, מאשר מספר שנראה ככה: 0526789445. הסיבה לכך היא שהחלוקה לקבוצות במספר הראשון עוזרת לנו לזכור פחות (אנו מייצרים “צ’אנק” מכמה פרטי מידע וזה מקל על הזיכרון העובד).

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

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

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

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

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

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

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

תפיסה ועיבוד

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

עיבוד הוליסטי

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

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

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

ואיך זה בא לידי ביטוי בעולם ה- UI? דוגמא מצוינת תהיה השימוש בתמונות חצויות, כמו בתמונה הזו:

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

עיבוד אוטומטי

ריצה. לא כולם אוהבים לרוץ אבל בכל זאת מוצאים את עצמם רצים מספר לא מבוטל של פעמים בשבוע מתוך “החלטה מודעת. אמירה כמו “אני ארוץ 5 קילומטר כי אני רוצה להיות בריא יותר” מסמלת כי מאחורי פעולת הריצה עומדת החלטה מודעת כלשהי שהניעה את האדם לפעול (=לרוץ).

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

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

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

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

עיבוד Top Down לעומת עיבוד Bottom Up

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

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

בואו נדגים.

קראו נא את המשפט הבא:

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

הצלחתן?

לא ממש?

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

לו היינו משתמשים רק בעיבוד מסוג Bottom Up סביר להניח שלא היינו עושים טעויות כלל, שכן היינו עוברים מילה מילה, מחברים אותן למשפט ומפענחים את המשמעות. אולם משום שאנו, בעל כורחנו, משתמשים גם בעיבוד Top Down, קרי מושפעים מאמונות ומציפיות מוקדמות, אנחנו קוראים (=תופסים) את המשפט באופן בו היינו מצפים לקרוא אותו. משום כך אנחנו מופתעים, בקריאה שנייה, לגלות שהמילה are מופיעה פעמיים ברצף מבלי ששמנו לב לכך מלכתחילה. היכרותנו עם חוקי תחביר ובאופן כללי העובדה שהתנסינו מספיק פעמים בקריאה, גורמת לכך שאופן העיבוד את המשפט ייעשה בתמציתיות Top Down כאשר במהלך הקריאה נתעלם מ”שגיאות” שאינן תואמות את הציפיות והאמונות שלנו. במקרים מסויימים, כמו בדוגמא הזו, ההתעלמות אכן מייעלת את תהליך הקריאה, שכן אין באמת סיבה לכתוב פעמיים are או to ואם טרם זיהיתן, גם את המילה mistakes שכתובה באופן שגוי (mitstakes). במקרה הזה אגב, המוח שלנו יודע לזהות שצבר מסוים של אותיות המתחיל באות מסוימת ונגמר באות מסוימת, מייצר מילה מסוימת. העובדה שצבר האותיות (פרט לאות הראשונה ואחרונה) שונה, לא מהווה בעיה בשביל המוח המדהים שלנו – כל עוד אנחנו “מומחים” בקריאה. כלומר שהמילה שאנחנו קוראים היא בשפת האם שלנו.

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

אה, כן, ואם תהיתן מה הן חמש הטעויות:

• פעמיים are

• פעמיים to

• המילה mistakes מאויתת לא נכון

• הטעות הרביעית היא פרדוקס למתחכמים. ובכן, יש 4 טעויות בלבד, לכן התוכן עצמו של המשפט הוא טעות ויש 5 טעויות, אך אם יש 5 טעויות במשפט הרי הטעות החמישית היא כלל לא טעות וחוזר חלילה. סליחה על זה ☺

קשב

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

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

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

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

נותן לסרטון הגורילה בראש, אה?

התופעה הזו שבה אנו מפספסים דברים שממש מתחת לאף שלנו רק כי אנו עסוקים במטלה אחרת נקראת “עיוורון קשבי” ואם אתם חושבים שלכם זה לא קורה אז תנו לי לשאול אתכם שאלה קטנה:

היכן נמצא מטף כיבוי האש בעבודה שלכם?

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

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

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

רמזים חיצוניים ופנימיים

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

רמזים חיצוניים

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

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

אתרים רבים משתמשים באפקט הפופ-אאוט כדי לעורר תשומת לב מיידית לכפתור החשוב מכולם, ה- CTA (call to action). בתמונה הזו ניתן לראות שכפתור ה”הוסף לסל” (add to cart) צבוע בצבע מובחן משאר הדף ולכן אין סיכוי שנפספס אותו.

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

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

ומה לגבי מספר הפריטים הכולל, האם גם הוא משפיע? כמובן.

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

רמזים פנימיים

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

נשמע מוכר (חוץ מכל עניין הבריטים ב- 1920)?

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

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

“אם אני יכול לאכול את זה, לשכב עם זה או לההרג על ידי זה- זה ימשוך לי את הקשב. “

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

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

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

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

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

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

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

הייתי מתחיל עם הטמעה של ספריית קומפוננטות ענפה ככל האפשר

כשתהיתי מדוע, הוא הסביר שכדי שצוות פיתוח, ובפרט FrontEnd צריך לרוץ מהר וליישם את חוויית המשתמש בצורה המדויקת ביותר, הדרך הקלה ביותר לעשות זאת היא באמצעות רכיבים שנועדו בדיוק לכך, כמו אלו המוצעים בספריות הקומפוננטות השונות כמו: Material design, MaterialUI, RadixUI, AntDesign ועוד. כל ספריה כזו מציעה מאות קומפוננטות שכבר אופיינו בצורה יחסית קונבנציונלית ומאפשרת למפתח להוציא לפועל היבטי UI מתקדמים כמו תנועה, אנימציה, צל וכו׳, במהירות ויעילות. למעצב קל יותר להשתמש ברכיבים, שכן הם כבר קיימים, מותאמים לגדלים שונים, קלים מאוד לעדכון (למשל שינוי צבע או ציר Z) ולמפתח קל יותר לקבל עיצוב הכולל רכיבים מאופיינים (ומפותחים).

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

 שישנה ״תרבות UX״ בארגונים רבים, כלומר ה- UX מעורב משלבים מוקדמים ועד מאוחרים ומוכר היטב בכל רמות הארגון. 

רוב א.נשי ה- UX שהשתתפו במחקר היו מעורבים בפרויקטים האחרונים שלהם מההתחלה ועד הסוף, כאשר הפרויקטים כללו היבטי UX. מספר המשתתפים שדיווחו כי פעילויות UX היו משולבות באופן מלא, ברובן, או באופן מתון בתהליך הפיתוח של הפרויקטים האחרונים שלהם היו 81 (19.2%), 113 (26.8%), ו-122 (28.9%), בהתאמה. מבין המשתתפים הנותרים, 32 (7.6%) ו-55 (13%) דיווחו כי פעילויות UX לא נכללו או ברובן לא נכללו בפרויקטים שלהם, בהתאמה.

בספרו ״האסירים מנהלים את בית המשוגעים״, טוען קופר (Alan Cooper) ששנות ה- 2000, בהן פיתחנו מוצרים דיגיטליים ״מדהימים״ לראשונה, לוו בחוסר תשומת לב לחוויית המשתמש (UX). אליבא דקופר, למתכנתים היה תפקיד לא פרופורציונלי בהכרעת העיצוב ואינטראקציית המשתמש ורוב ההחלטות העיצוביות/UXיות נעשו במחשבה שנייה, בדיעבד, מה שהוביל לאינטראקציית אדם-מחשב בינונית ברוב התוכנות הצרכניות של אותה תקופה. מה שעצוב עוד יותר בעיניי, הוא שרוב העיצוב הבינוני הזה של תוכנות על כמו Microsoft Office,למשל, המשיכו איתנו לעשור השלישי של שנות ה- 2000.

אזהרה: לדור ה- X והמילניאלס התמונות למטה עשויות להעלות זכרונות ילדות מתוקים.

מניסיוני, ואני מתנצל מכל מתכנת/ת שחורגים מהרשימה הזו,

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

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

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

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

אז מה לעשות?

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

ולא בקצרה,

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

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

3. בחרו יחד את הכלי שדרכו תעבירו עיצובים וקומפוננטות. אם הכל נעשה ב- Figma, ודאו כי לכולםן יש אישור כניסה. אם הם צריכים כלי נוסף כמו Zeplin או Storybook - ודאו שאתםן בוחריםות אותו יחד.

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

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

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

לסיכום,

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

1. עמוד בודד.

2. ללא עומס טקסטואלי או עומס צבעים.

3. תמונה קטנה.

4. 2 טורים, מרכזי ומשני.

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

מדוע? הישארו איתנו.

מה זה CV?

נתחיל בהגדרה המילונית:

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

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

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

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

הדוגמה הפשוטה ביותר היא הכותרת.

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

“מה שעליו לא ניתן לדבר, על אודותיו יש לשתוק”

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

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

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

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

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

אז מה כן לכתוב?

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

האם זה מספיק? תלוי במשרה.

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

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

כפי שניתן לראות בקורות החיים האישיים שלי פה למטה, אני מציג רק 3 עבודות אחרונות, על אף שניסיוני המקצועי כולל הרבה יותר חברות, תקופות כפרילנס, יועץ ועוד. 3 עבודות - 2 רלוונטיות לניסיון שלי כמנהל UX ואחת המתייחסת לעיסוק הנוסף שלי שהוא הובלת המסלול בחוויית משתמש באקדמית ת״א-יפו. אולם סביר שאם אתמיין בהמשך למשרת Product Design מסוג Hands-on, כלומר עבודה הרבה יותר עיצובית-מעשית ממה שאני עושה היום, אספר על המשרות הללו.

הפרדוקס: ניסיון הוא קריטי למשרה הראשונה

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

הפעם הראשונה שלי 😉

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

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

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

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

שימו לב לאתר -

• יפה? לא ממש.

• מיוחד? ממש לא.

• מושקע? עבודה של 20 דקות בלחץ, בעיקר לסדר את התמונות בקטגוריות.

• פונקציונליות? אפס. תמונות בלבד.

אז למה הוא טוב?

הו, פה נכנס הראש האפיוני לפעולה.

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

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

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

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

זה היה הניסיון הראשון שלי.

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

הפעם השנייה שלי 😎

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

ֿ

אממה, בתקופה הזו בחיי גיליתי את אמנות הבארטר.

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

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

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

אוקי, אז מה לכתוב בקורות החיים?

הנוסחה היא כזו:

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

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

• 2-3 משרות אחרונות רלוונטיות.

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

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

  • תיאור המשרה צריך להיות קצר, תמציתי וקולח. חישבו על הנקודות שהכי רלוונטיות למשרה שאתםן מחפשים. אם אני כ- Sr. Dir of PD אחפש משרת VP, ודאי שעליי להראות שאני יודע לדבר עם C-level כמו המנכ״ל וכדומה, דבר הנחשב כבסיסי ברמת VP, אבל לא תמיד טריוויאלי ברמת Sr. Dir. כך המגייסת תוכל לזהות את הסיכוי שלי להצליח כ- VP כגבוה יותר משום שהתנהגות חשובה אחת כבר נמצאת באמתחתי.

• פרטים אישיים בחלק העליון של העמוד - מייל, טלפון ועמוד לינקדאין.

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

  • במידה והמשרה היא בפארק המדע ברחובות ואתםן גרים ברחובות, עדיף לכתוב בכתובת המגורים ״רחובות״ ולא ״ישראל״.

• ציינו שפות שאתםן שולטים בהן ובעיקר בשפה האנגלית.

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

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

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

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

והנה הצצה לקורות החיים שלי

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

ובכל אופן, אאחל לכולכםן בהצלחה במציאת העבודה הראשונה/הבאה שלכםן 🫶

Trello

טרלו היא דוגמא ומופת לחוויית שימוש שקופה.

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

הנה השטף:

1. (וורד) המשתמש עובד על קובץ שמכיל כמה שורות נתונים -
   Bullets, Numbering, או סתם Enter שמפריד בין שורה לשורה. נניח שכל שורה היא משימה שונה ושהמשתמש מעוניין להפוך כל משימה לכרטיס טרלו.

2. (וורד) המשתמש מעתיק (copy) את כל השורות.

3. (טרלו) המשתמש פותח כרטיס חדש בטור המשימות הרצוי.

4. (טרלו) המשתמש מדביק את התוכן המועתק ואז קורה הקסם הבא:
   

אני מתעצבן רק מלחשוב על מספר ההעתק/הדבק שהייתי עושה בלי הפיצ’ר הזה.

Apple TV

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

הנה הפלואו:

1. (אפל TV) המשתמש בוחר באפשרות ה”חיפוש” מתוך כל אפליקציה שמותקנת על ה- Apple TV.

2. (אפל TV) המשתמש גולל עם השלט לשורת החיפוש עצמה.

3. (אייפון) המשתמש מקבל התראה במכשיר הנייד שהוא יכול להשתמש במקלדת של הנייד בכדי להזין אותיות לטלוויזיה.

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

Google Docs

לא תמיד אנחנו, המשתמשים, רואים את הדברים המובנים מאליהם. גישת ה- Material Design של גוגל מנסה לפתור את המצב על ידי הצפה של הכפתור החשוב ביותר – CTA – למקום הברור ביותר. ועם זאת, כשנתתי לקבוצת ניסוי כמעט מייצגת – המשפחה שלי – את האפליקציה של Google Docs וביקשתי מהם לפתוח את המסמך ששמו Lorem ipsum ולערוך אותו (ציינתי במפורש שהמטלה היא להוסיף את המילה “ערוך” בראש המסמך) גיליתי שכפתור העריכה, שבאמת קשה להגיד שאינו בולט לעין, שימש כמתודת הפעלת מצב העריכה רק במחצית מהמקרים (3/6). אלו שנחשבים פחות טכנולוגיים השתמשו באפשרות ב’ של גוגל ופשוט הקישו על המסך כאילו מחפשים אחר קסם שיקרה. ואכן הוא קרה והמסמך הפך עריך.

Netflix

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

הנה השטף:

המשתמשת מורידה עונה שלמה של “Stranger things” למכשיר הנייד (היא לא צריכה לדאוג כמובן שאם תצא מחוץ לטווח ה- Wi-Fi תיגמר חבילת הגלישה - Netflix דאגו להגביל את ההורדות ל- Wi-Fi בלבד).

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

כשהפרק מסתיים, הקסם הזה קורה:

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

Shazam

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

הנה השטף:

1. המשתמש שומע שיר שהוא אוהב.

2. הוא מפעיל את Shazam.

3. האפליקציה מפעילה את החיפוש מבלי שהמשתמש לחץ על משהו (תלוי בהגדרות האפליקציה).

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

Whatsapp

החבר’ה ב- Whatsapp לקחו החלטה מעניינת: תוכן קודם לחברים. הם הבינו שכשחסרה לנו כוס סוכר לעוגה והילדים צריכים עוגה למחר לגן – גם השכנה הנוראית מלמטה היא אופציה. ובהקבלה, כאשר אדם שאינו איש קשר שולח לי הודעה, Whatsapp קודם כל מציגה לי את תוכן ההודעה – אותה כוס סוכר שהייתה חסרה לי – ורק אחריה את האפשרות להתייחס למוסר ההודעה -
מַכָּר או “דבר איתי מחר” (:

יש לכן עוד דוגמאות? אשמח לשמוע!

Apple TV image source:

https://developer.apple.com/tvos/human-interface-guidelines/interface-elements/text-and-search/

אתםן מכיריםות את הרגע הזה שאתםן מסתכלים על הבת/בן זוג והיא מסתכלת עליכםן ואתםן יודעים שזו אהבה? אז אני מאוהב 🥰

איך אמרת? פרלקס.. מה?

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

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

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

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

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

ולמה זה עדיף על גוגל בעצם?

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

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

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

בואו נראה איך פרפל עונה על שאלה כזו (תמונה קצת גדולה):

שימו לב לסגנון התשובה -

1. פותח עם התשובה המדויקת לשאלה ששאלתי - NRR הוא המדד החשוב יותר עבורי.

2. מסביר לי למה ב- 5 נקודות מפורטות. בפעם אחרת ששאלתי אותו את השאלה הוא אפילו הדגיש עבורי (bold) את המשפט הראשון בכל נקודה כדי שאוכל לשים לב טוב יותר לשורה התחתונה.

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

4. הוא מסכם.

כמדריך פסיכומטרי לשעבר, זו רמת חיבור של מישהו שקיבל 800.

אחד החלקים האהובים עליי בתשובה הוא המקורות.

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

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

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

הנה כמה דוגמאות:

מחקר משתמשים

1// מהן נקודות הכאב והתסכול העיקריות שמשתמשים חווים כשהם מנסים להשלים [משימה ספציפית] עם [מוצר/שירות קיים]?

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

2// כיצד [קהל היעד] מתמודדים כרגע עם [פעילות ספציפית] בחיי היום-יום שלהם, ומהם המודלים הקוגניטיביים שלהם סביב זה?

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

3// מהם הגורמים החשובים ביותר המשפיעים על תהליך קבלת ההחלטות של [קהל היעד] בבחירת [סוג מוצר/שירות]?

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

מחקר שוק

1// מהן המגמות והחדשנות העולות ב[תעשייה/שוק ספציפיים] שעשויות להשפיע על תוכנית הדרכים של המוצר שלנו?

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

2// כיצד המוצרים של המתחרים שלנו נמדדים מבחינת [תכונה/היבט ספציפיים] על בסיס ביקורות וחוות דעת של משתמשים?

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

3// מהם ההבדלים התרבותיים והאזוריים שעלינו לקחת בחשבון בעיצוב [מוצר/שירות] עבור [שוק גיאוגרפי ספציפי]?

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

אפיון ועיצוב

1// איך אני יכול לשפר את תהליך האונבורדינג למשתמש בעבור האפליקציה הסלולרית שלנו כדי להגביר את שיעורי ההפעלה?

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

2// מהם דפוסי עיצוב יעילים להצגת ויזואליזציות נתונים מורכבות על גבי דשבורדים?

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

3//איך אני יכול לשלב אינטראקציות קוליות ותנועות גוף בחוויית המשתמש הסלולרית של המוצר שלנו?

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

4// מהן הנחיות הנגישות והפרקטיקות המומלצות העדכניות ביותר לעיצוב מוצרים הנגישים לכולםן?

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

5// האם תוכל להציע דרכים לשפר את ארכיטקטורת המידע והניווט באתר ה- e-commerce שלנו?

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

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

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

לסיכום, מה פרפל נותן לנו?

תשובות מקיפות ומעמיקות

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

תשובות ויזואליות עשירות

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

אמינות המידע

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

ממשק ידידותי ויעיל

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

מיקוד בתשובות ולא בפרסומות

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

לסיכום,

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

לנסות ולהבין כמה זה יכול לשפר את תהליך העבודה שלהן 🦄

מבואות:

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

עזרים:

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

מחקר משתמשים:

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

פסיכולוגיה:

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

בלוגים ופודקאסטים:

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

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

1. הצורך לזכור באופן פרטני חלקים נרחבים וספציפיים בספרים/מאמרים, וגם

2. הרבה מהספרות האקדמית שנתקלתי בה לא ידעה “לספר סיפור”, מה שהצריך אותי לבנות את הסיפור (בין אם בראשי או על הנייר).

משום כך הייתי חייב לאמץ גישת קריאה אקטיבית. גיליתי שכאשר אני:

1. קורא לאט יותר,

2. שומר על שעות קריאה קבועות (בקרים, כשהאנרגיה עוד בשיאה),

3. “עובד” על הספר (כלומר מקפל פינות, כותב בעיפרון על הדפים עצמם, מדגיש במרקר, מסכם עמודים עם sticky notes),

4. מתנתק מהעולם עם מוזיקה מאוד ספציפית (חפשו פלייליסט בשם “Pure Focus” ב- Apple Music), ועושה הפסקות תכופות בעת הקריאה (הפסקה של 5-10 דקות כל, בערך, 50 דקות)

או-אז אני באמת זוכר את מה שקראתי.

תהנו!

מבואות

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

Don’t Make Me Think / Steve Krug

אפשר (ואולי גם צריך) להסתכל על כותרת הספר ככותרת לדיסציפלינה כולה – אל תתנו למשתמשים שלכם לחשוב. כמי שנחתו בפעם הראשונה באתר שלכם, או נכנסו בפעם הראשונה לאפליקציה שלכם, משתמשים לא אמורים לתהות לגבי הצעד הראשון שלהם וכמובן גם לא לגבי שאר הצעדים. קרוג מתאר בפשטות יוצאת דופן את הדבר הבסיסי ביותר שמצופה ממאפיין חוויית משתמש – יצירת חוויית משתמש שקופה. הדוגמא האהובה עליי מהספר היא השימוש במיקרו-קופי “מגניב” על חשבון “ברור”. כך למשל במקום לכתוב “Jobs” ככותרת לחלק באתר שמציג את העבודות הזמינות בחברה כלשהי, קרוג נותן דוגמאות לשגיאות אפשריות (שמשום מה צצות דווקא בזמן האחרון) כמו “employment opportunities”, או גרוע יותר: “job-a-rama” ה(לא)מגניב.נכון, הספר נוגע לאתרי אינטרנט Webיים, אבל זה לא אומר שהעקרונות שמוצגים בו אינם רלוונטיים גם לשאר עולמות התוכן. ולכן לא משנה מה אתם מעצבים, קרוג יעזור לכם לעצב אותו כשהמשתמשים כל הזמן בראשכם.

לינק לרכישת הספר

the Design Of Everyday Things / Don Norman

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

אחד הדברים המעניינים ביותר בספר הוא החלוקה המצוינת של נורמן ל- 3 סוגי פסיכולוגיות* של אנשים: Visceral – התנהגויות טבעיות הקשורות בעיקר למערכת העצבים כמו נשימה או עייפות. מושג רלוונטי בהקשר הזה יהיה פידבק, כך שכאשר כפתור נלחץ המשתמשים מצפים להתנהגות טבעית של “תגובה” תוך זמן הגיוני; Behavioral – התנהגויות רפלקסיביות כמו התרחקות טבעית מאש, שהן מודעות מטבען ואינן דורשות זמן עיבוד ארוך. בהקשר הזה ניתן לדבר על החיוויים שאנחנו מקבלים מהסביבה כדי להבין כיצד להתנהג בהמשך, כמו למשל הבנה שתהליך מסוים (למשל תהליך טעינת מסך) מסתיים; ו- Reflective – התנהגויות ברמה קוגניטיבית גבוהה יותר המערבות תהליכי קבלת החלטות או תכנון. דוגמא רלוונטית תהיה בחינה מדוקדקת של תסריט משתמשים כדי שהמעצב יתאים את הממשק לשלל התהליכים האפשריים שהמשתמשים יבחרו להוציא לפועל.חלוקה כמו זו מאפשרת למעצבי חוויית משתמש להתייחס לתהליכים הפסיכולוגיים השונים של המשתמשים בעיצוב ממשקים שונים – פיזיים או דיגיטליים – ובכך לספק את הפתרונות הרלוונטיים לכל צעד בתהליך.

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

לינק לרכישת הספר

About Face (4th Edition) / Alan Cooper

בפברואר 2018 פתח אלן קופר את כנס IxDA בליון (צרפת) בהרצאה דרמטית בה סיפר על זניחתו את עצוב חוויית המשתמש בכרך הבורגני הסן-פרנסיסקואי לטובת מחשבות על עיצוב “מגן-משתמשים” בפרברי קליפורניה (אמיתי לגמרי – כל ההרצאה שלו מלווה בתמונות בסגנון “בוב החקלאי”). אם לסכם את ההרצאה במשפט, קופר טוען שכמעצבי חוויית משתמש עלינו לחשוב על טובת המשתמשים לא רק בהיבט העיצובי, אלא גם בהיבט המוסרי. הנה, תראו בעצמכם.אבל לפני שהתגייס לשומרי הגלקסיה הסיבר-נטית, קופר היה עסוק בלעזור לנו לעצב טוב יותר עבור משתמשים באמצעות “עיצוב-מוכוון-מטרות”. הוא פיתח את מושג ה”פרסונה” לכדי תיאוריה שלמה ובמהדורה הרביעית גם קישר את 3 סוגי המטרות עליהן מדבר ל- 3 סוגי הפסיכולוגיות של נורמן. פרסונה היא מודל-משתמש, ארכיטיפ המייצג תופעות מורכבות בצורה אבסטרקטית ואנושית – מה שמאפשר לנו, המאפיינים, להיות מדויקים ומקיפים יותר באופן בו אנחנו מעצבים עבור המשתמשים שלנו (במידה וניתחנו את “סוגי” המשתמשים שלנו לאור ניתוח פרסונה).החלק האהוב עליי בספר הוא ההתייחסות של קופר למושג ה- Undo מתוך נקודת מבט מוכוונת-מטרות. כשהצגתי את גישת ה- “Undo enables exploration” למפתחים בעבר, נתקלתי בהרבה הרמות גבה. אבל כשהצלחתי לפשט לאדם שמולי את האספקט הפסיכולוגי של המושג (בקצרה, ה- Undo בעצם מאפשר למשתמש “לטעות” מבלי לשלם על טעויותיו, מה שמעלה את הסיכוי לאקספלורציה ומזרז את למידת המערכת) הגבות הורדו חזרה לחצי התורן (;

לינק לרכישת הספר

עזרים

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

100 Things Every Designer Needs To Know About People / Susan M. Weinschenk

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

לינק לרכישת הספר

The Elements Of User Experience / Jesse James Garrett

חוויית משתמש, אליבא דג’סי ג’יימס גארת, מורכבת מ- 5 אלמנטים אשר “מונחים” האחד על השני בצורת שכבות: Strategy, Scope, Structure, Skeleton, Surface (כאשר ה- Surface הוא כמובן השכבה העליונה). האלמנטים מספקים לנו תשתית קונספטואלית המאפשרת לתכנן ולכוונן את חוויית המשתמשים במוצר שלנו, תוך שאנחנו בוחנים כל בעיה אפשרית העולה בכל אחת מהשכבות. כמו קודמיו, מעלה גארת את החשיבות של מיצוי צרכי המשתמש בטרם עוברים לעצב את שכבת ה- UI. הוא גם דואג להזכיר את מה שמתסכל פעמים רבות מאפיינים ומעצבים רבים – צרכי המשתמש לפעמים עלולים להתנגש עם צורכי העסק ולגרום לנו, המעצבים והמאפיינים, להיות גמישים באופן בו אנו “פותרים” את הבעיות בשכבות העליונות של חוויית המשתמש.

לינק לרכישת הספר

Observing the User Experience / Elizabeth Goodman

אולי הנקודה החשובה ביותר בעיניי בחוויית משתמש היא ההבנה שמאוד קשה למדוד אותה. ספרים רבים המתיימרים לעסוק במדידת חוויית המשתמש מתייחסים פעמים רבות דווקא למדידת Usability, מבלי להתייחס להבדל (הלא ממש דק) בין 2 הדיסציפלינות ובעיקר לעובדה ש- Usability מהווה נדבך אחד בתוך חווייתהמשתמש כולה. Observing the UX לא מעגל פינות ומספק את מה שהוא מתחייב לספק – A Practitioner’s Guide to User Research. הסגנון הישיר מכניס את הקורא לתוך עולם מחקר המשתמשים דרך אסופת מתודות מקיפה, דוגמאות ברות-קיימא ואפילו אזהרות לגבי נושאים חשובים שקרוב לוודאי יצוצו במהלך העבודה ושווה להתכונן אליהם מראש. הרועץ היחיד הוא הפוקוס הכמעט בלעדי על אתרי אינטרנט ולא על אפליקציות (או כל ממשק אחר). אולם מבחינתי דווקא יש כאן יתרון מעניין – במקום לקבל את המתודה כפי שהיא, עלינו להתאים אותה לפלטפורמה, מה שמכריח אותנו להבין את המתודה יותר לעומק, שכן רק הבנה עמוקה מאפשרת לנו לעשות אדפטציה איכותית מבלי לפגוע בעקרונות הבסיס של המתודה.

לינק לרכישת הספר

An Introduction To Human factors engineering / Christopher D. Wickens

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

לינק לרכישת הספר

Understanding Your Users / Catherine Courage

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

לינק לרכישת הספר

מחקר משתמשים

מתחילים

Just Enough Research / Erika Hall

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

לינק לרכישת הספר

Rocket Surgery Made Easy / Steve Krug

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

לינק לרכישת הספר

מתקדמים

Quantifying the User Experience / Jeff Sauro

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

לינק לרכישת הספר

Interviewing Users: How To Uncover Compelling Insight / Steve Portigal

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

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

2. אל תכווינו את המרואיינת. שאלות מכווינות הן שאלות שקובעות עבור המרואיינת את התשובה עוד לפני שענתה עליה.

3. הישארו שקטים ככל שהקונטקסט מאפשר. השקט הוא אולי החלק החשוב ביותר בריאיון משום שהוא מאפשר למשתמש להעלות את הסוגיות “שיושבות לו על קצה הלשון” ובכך הוא בעצם מתייחס למה שהשאיר עבורו חותם במהלך האינטראקציה עם הממשק.

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

לינק לרכישת הספר

Handbook of Usability Testing / Jeffrey Rubin

לרובנו אין את ההכשרה האקדמית (או כל הכשרה אחרת לצורך העניין) כדי להעביר בדיקת שמישות תקפה. הספר הזה נכתב מתוך נקודת ההנחה הזו. הוא מאפשר לקוראיו לצלול לקרביים של בדיקות השמישות באופן מעניין ומדויק. העובדה שג’ארד ספול, מאנשי בדיקות השמישות המוכרים והעסוקים ביותר בעולם, חתום על הספר מהווה גושפנקא מעולה לטיבו של הספר. הספר (או לפחות הגרסה ה-2 שבידי) מחולק ל- 3 חלקים: (1) היכרות עם עולם בדיקות השמישות, (2) המבחן עצמו – משלבי ההכנה דרך ביצוע המבחן ועד הצגת הממצאים, (3) טכניקות בדיקה מתקדמות וקישור לתהליך ה- UX. אז נכון, קשה לומר שבלי ידע סטטיסטי בסיסי תוכלו לצלוח את הספר, אבל אם תשלבו את הספר הזה עם הספר הראשון בקטגוריה הזו – Quantifying the User Experience – תוכלו ליישם את בדיקות השמישות עם הסטטיסטיקה הרלוונטית.

לינק לרכישת הספר

מתודות

Conceptual Design for Interactive Systems / Avi Parush

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

גילוי נאות: פרופ’ אבי פארוש, הכותב, היה המנחה שלי בתואר השני.

לינק לרכישת הספר

Lean UX / Jeff Gothelf

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

בתוך כך הוא טוען שכדי להאיץ את התהליך מבלי לפגוע בטיב התוצרים, העבודה על המוצר צריכה להיות ‘עבודת צוות חוצת-פונקציות’, כלומר כדי שהעבודה של הצוותים השונים תהיה איכותית ויעילה, עליהם להבהיר יחד את התוצאות (Outcomes, מושג חשוב מאוד בגישת ה- Lean UX) המצופות מבעוד מועד. כל תוצאה צפויה שכזו צריכה להיות מדידה (Measurable). גוטהלף מאמין מאוד בגישת ה”תנו למשתמשים להגיד לנו כמה צדקנו” ולכן נרצה למדוד את התוצאות הצפויות אחרי הטמעת הפיצ’רים בממשק. כדי לעשות כן באופן יעיל, עלינו לפרק את התהליך הכללי לביסים קטנים שקל למדוד. כל ביס הוא השערה שניתן לאשש או להפריך (ובכלל, גישת ה- Lean Startup מקדשת את תהליך “תיקוף ההשערות”). זה כמובן לא דבר חדש – כל סטודנט שנה ב’ לפסיכולוגיה יאמר לכם את אותו הדבר, אולם בהקשר של UX ועיצוב ממשקים בכלל, חשוב ואולי אף חשוב יותר, לדייק את ההשערות העיצוביות מבעוד מועד.

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

לינק לרכישת הספר

Sprint / Jake Knapp

ממש כמו שמו, זהו אולי הספר שקראתי הכי מהר בחיי. הכותבים, יוצאי Google, העבירו סדנאות “ספרינט” בחברות כמו Slack, Medium ו- Uber (בין השאר), מציגים בצורה נהדרת ומהנה תהליך (”ספרינט”) שמטרתו לעזור לצוותים לפתור בעיות-עיצוב אקוטיות. התהליך מוצג לאורך שבוע עבודה (שני עד שישי, כמנהגם של הגויים בניכר) ומציג מה יש לעשות בכל יום. כפי שאומרים הכותבים, התהליך מספק לסטארטאפים כוח-על: הם יכולים להריץ את המציאות קדימה אל המוצר המוגמר ותגובות המשתמשים, בטרם יתחייבו להוצאות גבוהות.

הנה קצת משבוע הספרינט כפי שמוצג בספר:

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

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

הערת שוליים: בשלב הזה, אגב, אמליץ למי שיאמץ את השיטה שמוצגת בספר, להשתמש במתודות LUMA.

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

היום הרביעי מוקדש לבניית הפרוטוטייפים. בספר הכותבים מציעים אסטרטגיות וכלים שיעזרו לכם לבנות פרוטוטייפ ב- 7 (~) שעות.

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

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

לינק לרכישת הספר

פסיכולוגיה

Hooked / Nir Eyal

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

לינק לרכישת הספר

Thinking Fast, Thinking Slow / Daniel Kahneman

במקרה כתבתי כמה מילים על הספר בעבר, אז הנה הטקסט (עם ריוויזייה קלה):שאלה שאני שומע המון לאחרונה: “אני רוצה להיכנס לתחום ה- UX אבל לא ממש בטוחה מאיפה להתחיל… יש לך המלצות? כן, יש לי (:לא ניכנס כאן לדיון על מהי חוויית משתמש, איפה היא מתחילה והיכן נגמרת, אבל נסכים (אני מניח) שה- User מהווה את חלק הארי של הדיסציפלינה מעצם שמה חוויית משתמש. אם כך תסכימו איתי שהדרך הנכונה “להיכנס” לעולם של חוויית המשתמש תתחיל בלהבין אנשים באופן כללי, ואת האופן בו הם חושבים בפרט. למזלנו, אנשים חכמים ומוכשרים מאיתנו כבר חשבו על הרבה תשובות לשאלה הזו (תרשמו “פסיכולוגים קוגניטיביים” בגוגל) ואנשים אחרים, חכמים ומוכשרים מאיתנו גם הם, ממשיכים לערום שאלות בנושא. ביניהםן יש את אלו שעוברים מתחת לרדאר ומצליחים להשפיע בעיקר ברדיוס הקטן שלהם, אולם יש את אלו שמצליחים להשפיע עד כדי פרס נובל. דניאל כהנמן (ושותפו, עמוס טברסקי המנוח) הם שניים כאלו.כהנמן, פסיכולוג קוגניטיבי, אביה המשותף של תורת הערך (עם טברסקי) הסופר-סופר-סופר חשובה ומעניינת, הקדיש את רוב חייו להבין את דרכי החשיבה של אנשים, וכפי שהדגים בתורת הערך – את האופן בו אנשים מקבלים החלטות במצבים ותנאים שונים (דילמות מוניטריות בעיקר). הוא גם כתב ספר – Thinking Fast, Thinking Slow – שגם מסכם באופן מופשט את עיסוקו בתחום קבלת ההחלטות, וגם מתמקד ב-2 המערכות בהן אנו עושים שימוש כשאנו מקבלים החלטות. שמן המקצועי של המערכות הללו הוא מערכת 1 ומערכת 2 (הוא פסיכולוג, לא איש מיתוג…).מערכת 1 היא המערכת האוטומטית שלנו, זו הפועלת על בסיס אינטואיציות, ומשום כך היא גם המהירה להגיב מבין שתי המערכות בעת שאנחנו נתקלים בסיטואציה הדורשת “קבלת החלטה” כלשהי (כמו למשל האופן בו תבחרו להגיב לאמירה של מישהו, או תגובתכן לכשתראו מישהו רץ לעברכם עם סכין). זו המערכת הלא-מודעת מבין השתיים (בכל זאת, פסיכולוגיה…) ומשום כך היא מאוד אסוציאטיבית בניתוחה את המציאות. מערכת 2 היא המערכת המודעת. היא זו שמנתחת את המציאות באופן אנליטי ורציונלי, ובעיקר – לאט יותר ממערכת 1. במקרים בהם נדרש מאמץ קוגניטיבי (כמו כתיבת שורות אלו למשל) מערכת 2 היא שתיקח את המושכות. למעשה, בכל זמן שהיא מסוגלת לכך, מערכת 2 תנטר את מערכת 1. מערכת 1 תציע פתרון מהיר, מערכת 2 תבחן, תדייק ותוציא לפועל את הפתרון הנכון בעיניה. אולם כאמור, מערכת 2 לא תמיד תהיה שם כדי לנטר בזמן. למעשה, היא תיכשל בניטור ברוב המקרים, בין אם משום שתסמוך על מערכת 1 (למשל במצבי שמחה מוקצנים) או פשוט מעצם היותה איטית (ואולי גם עצלנית) יותר.”לחשוב מהר, לחשוב לאט” הוא ספר נהדר שפותח ה-מ-ו-ן דלתות לעולם המרתק של הפסיכולוגיה הקוגניטיבית ומאפשר ללמוד על התפתחות התחום באמצעות הדרך שעבר כהנמן בעצמו, שעליה הוא מספר בספר.עובדת בונוס: רוצים לדעת אם מערכת 2 של האדם איתו אתם מדברים עובדת כרגע? שימו לב לאישונים שלו. מחקרים מראים שבזמן שימוש במערכת 2 האישונים מתרחבים. למעשה, גם לחץ הדם עולה קלות והדופק מתגבר.

לינק לרכישת הספר

Emotional Design / Don Norman

אם קראתם את The DOET book ואת About Face שנמצאים בקטגוריה הראשונה של הרשימה הזו, אתם ודאי מכירים את 3 סוגי הרגשות שנורמן מתייחס אליהם בספרו Emotional Design. הראשון הוא Visceral – הרגש הראשוני שהמשתמש חווה בפעם הראשונה שהוא פוגש בממשק. ככל שהממשק שלכם מתאר באופן המוצלח ביותר את הרגש שאתם מעוניינים שהמשתמש יחוש (מפחיד, מרגש וכו’) כך הרגש הויסרלי יהיה חיובי יותר; השני הוא Behavioral – שמישות הממשק. ככל שרמת השמישות של הממשק שלכם תהיה גבוהה יותר (כלומר הממשק יספק למשתמש תהליך נוח, יעיל ומשביע רצון להשיג את מטרתו) כך המשתמש יהיה מרוצה יותר; השלישי הוא Reflective – סוג הרגש הזה נוגע לרמת ההבנה של הממשק/מוצר, כלומר יש כאן כבר עירוב של הקוגניציה של המשתמשים. ככל שהמשתמשים “יתחברו” לממשק באופן אישי יותר, כך החוויה תהיה חיובית יותר.אני מרגיש שדיברתי יותר מדי על דון נורמן והתרומה שלו לתחום, אז פשוט נסכם שתקראו גם את הספר הזה, טוב?

לינק לרכישת הספר

אי אפשר לסיים את החלק הזה בלי להמליץ על ספרים שנכתבו על ידי חברים טובים 🙂

הפסיכולוגיה של האינטראקציה: עיצוב חווייה אנושית / ד”ר עופר מונר

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

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

זה ספר על אפיון לבני אדם.

לינק לרכישת הספר

ידידותי למשתמש: טכנולוגיה, שמישות והנדסת אנוש / ד”ר שמואל ארואס

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

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

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

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

לינק לרכישת הספר

בלוגים ופודקאסטים

1. Little big details:

Little Big Details – כל אותן האינטראקציות הקטנות שאנחנו נהנים מהן בזמן השימוש.

The Big Web Show – פודקאסט מצוין (!) הנוגע בנושאי עיצוב שונים וסופר מגוונים.

52 Weeks of UX – בלוג שנכתב על ידי צמד מעצבי אינטראקטיב מצויינים שמכיל 52 פוסטים בנושאי UX שונים. קל להתמצא בו ולמצוא הסברים ל(כמעט) כל נושא שמעניין אתכם בתחום.

Boxes and Arrows – אחד מהבלוגים המוצלחים ביותר בעיניי לחוויית משתמש. הוא בנוי בצורת “מגזין” כך שכל אחד ואחת יכולים לכתוב בו תוכן הנוגע לארכיטקטורת מידע וחוויית משתמש. התוכן איכותי ומגוון.

Nielsen Norman Group – ואיך אפשר בלי NN/g, ה- Wham! של עולם ה- UX. האתר גדוש בממצאי מחקרי משתמשים ומקיף כמעט כל עניין בהיבטים של חוויית משתמש.

חברות רבות אימצו את שילוב הגישה הכמותנית והאיכותנית כפי שמציעה ה- Thick Data, ונעזרות בכך לא רק כדי להבין את המשתמשים, אלא גם כדי לכמת את חוויית המשתמש. בכלל, תהליך כימות חוויית המשתמש הוא בבסיסו רעיון אבסורדי, שכן – איך מעריכים בכלל חווייה? האם אני באמת נהנה להשתמש ב-Whatsapp, או שמה הערך שאני מקבל מהשימוש באפליקציה נובע בעיקר מהעובדה שכל חבריי משתמשים בה גם? האם הנראות המזעזעת לכל הדעות של Craigslist הופכת אותו לאתר בעל חוויית משתמש גרועה, או שמא העובדה שאפשר למצוא בו literally כל דבר הופכת אותו לבעל חוויית משתמש מצוינת?

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

• מועיל (Useful) – במקום לצבוע בתוך הקווים שמשרטטים מנהלי המוצר, אליבא דמרוויל, מעצבי חוויית משתמש נדרשים למצוא פתרונות יצירתיים המועילים למשתמשים יותר מפתרונות אחרים.

• שמיש (Usable) – המוצר צריך להיות קל לשימוש (פוסט בנוגע למדדי שמישות ומדידתם יעלה בקרוב).

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

• קל להתמצאות (Findable) – כנראה המרכיב החשוב ביותר בהיררכיית ה-UI Design הוא היכולת למצוא אלמנטים נחוצים בכל רגע נתון בקלות.

• נגיש (Accessible) – בדיוק כמו שמעלית תומכת באלו שאינם יכולים לעלות במדרגות, רבים מהמשתמשים המגיעים למוצר שלכם צריכים תמיכה.

• אמין (Credible) – רבים מאתרי הקניות שהפסקתי להשתמש בהם לוקים באמינותם. פרויקט מעניין בנושא הוא ה Web Credibility Project של אוניברסיטת סטאנפורד.

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

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

שימו לב

מסגרת העבודה (האם זו הפרשנות הנכונה ל- Framework?!) שאני מוצא כמוצלחת ביותר למדידת הערך שהמוצר נותן עבור המשתמשים היא HEART-GSM מבית גוגל. החבר’ה במחלקת חקר המשתמשים הבינו כי כדי לספק ערך למשתמשים צריך להסתכל על 2 מדדי-על בו זמנית – איכות חוויית המשתמש ומטרות המוצר – ופירקו כל מדד-על שכזה למטריקות מדידות הניתנות להתאמה אד-הוקית כלפי הפרויקט או המוצר עליו עובדים:

HEART הם ראשי התיבות של Happiness, Engagement, Adoption, Retention ו- Task Success. אלו, לפי היוצרים, הקטגוריות המרכזיות שצוות ה- UX מבקש למדוד בכל פרויקט UX, ולפיכך אלו הם הגורמים הישירים להפקת הערך עבור המשתמשים.

• Happiness מודד את עמדות המשתמשים כלפי המוצר, או במילים רגילות – את שביעות רצון המשתמשים. המדידה נעשית ע”י שאלונים או כלים ייעודיים (כמו NPS ודומיו).

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

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

• Retention מתייחס למידת החזרה של המשתמשים אל המוצר או הפיצ’ר. המושג ההופכי והחשוב לא פחות הוא ה- churn.

• Task Success הוא המטריקה הידועה מעולם השמישות שמתייחסת להצלחת המשתמשים בביצוע מטלה. מונחי שמישות כמו Efficiency (משך הזמן הלוקח לבצע מטלה), Effectiveness (אחוז המטלות שהמשתמש(ים) מצליח לבצע) וכמובן Error-rate (מספר או אחוז הטעויות היחסי שמשתמש(ים) מבצע בתהליך ביצוע המטלה).

אוקיי, אבל איך אנחנו מודדים כל קטגוריה דה-פקטו? אז החבר’ה בגוגל הוסיפו את הציר השני (GSM) המורכב מ- Goals, Signals ו- Metrics. ההנחה מאחוריו היא שאופן מדידת הקטגוריות בציר ה- HEART תלוי בפרויקט ובמטרותיו, ולכן יש צורך בתהליך אופרציונלי (שלקוח מעולם הסטטיסטיקה) שמתחיל במטרה הנגזרת לכדי משתנה תיאורטי שהופך בסופו של דבר למשתנה אופרציונלי (קרי, מדיד).

• Goals – באופן קצת הפוך מההיגיון הבריא, אלו לא מטרות המשתמשים אלא מטרות המוצר. כמובן שאם עשינו עבודת מחקר איכותית וזיהינו את המטרות והצרכים של המשתמשים נראה חפיפה כמעט מלאה בין אלו של המשתמשים לבין אלו של המוצר. Uber למשל יכולים להגדיר בקטגוריית ה- Happiness שלהם מטרה כמו הגעת המונית לנקודת האיסוף תוך פחות מ- 2 דקות, ותחת קטגוריית ה- Task Success תוגדר מטרה כמו הורדת מספר הקליקים להזמנת מונית ל- 3.

• Signals – אחרי שזיהינו את המטרות עבור כל קטגוריה (להזכיר, אנחנו מגדירים את המטרות כלפי כל קטגוריה בהתאם למשימה הרלוונטית – בין אם היא פרויקט, פיצ’ר, או המוצר כולו) נחשוב על המשתנים שבעזרתם נוכל למדוד את הגשמת המטרה. אדגיש שוב, מדובר על משתנים תיאורטיים בלבד. לדוגמא, משך הזמן שמשתמשים נמצאים בתוך שרטוט באפליקציית AutoCAD mobile מהווה משתנה תיאורטי מצוין כדי להבין את רמת ה- Engagement של המשתמשים באפליקציה. מספר הפעמים שמשתמש מזכיר את השורש ק.ש.ה בריאיון יכול להיות מדד עבור קטגוריית Happiness. נשמע פשוט נכון? לא בדיוק... לא תמיד תוכלו למדוד את כל המשתנים שבאמת תרצו (בשל חוסר במשאבים הנחוצים). לכן, שיקלו בקפידה את המשתנים לפני שתרוצו לשלב הבא.

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

הנה 2 מקרי בוחן מעניינים של HEART-GSM:

• UXPin

• Usabilla

חשוב לתת כבוד למתודה עליה נשענת מתודת ה- HEART, הלוא היא מתודת ה- PULSE (Page views, Uptime, Latency, Seven-day active users, Earnings) הוותיקה. לא ארחיב לגביה בפוסט זה, אבל אציין כי היא מוכוונת לצרכים פרודקטיאליים (או ביזנסיאליים, תלוי את מי שואלים) ומתעלמת ממדדי חוויית משתמש פר-סה.

אז מתי כדאי להתחיל למדוד? עכשיו

ואם לא עכשיו אימתי?

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

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

• אחרי שהעיצוב שופר – אם אכן מדדתם את ה- Baseline של השלבים הקודמים, תוכלו כעת להשוות אותם למדדים שהתקבלו לאחר השיפור.

ומה הפשט?

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

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

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

לפני שנה בערך ראינו את הנהירה של ישראלים לפתיחה של סבן/אילבן (7/11) - חנות ״נוחות״ שככל הנראה הופרדה מתחנת דלק בלידתה. חנות שבארה״ב תיכנסו אליה כמזור אחרון בהחלט. אבל בארץ - תורים שלא נראו כמותםן לפני. לחנות נוחות.

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

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

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

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

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

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

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

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

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

עד עכשיו אני לא זוכר כמה זה עלה. אבל האשרור החברתי עבד חזק וזואי הקטנה שלי נהנית מהבובה.

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

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

ללינקדאין יש Hook אחד מרכזי - כמה א.נשים צפו לי בפרופיל.

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

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

או:

או:

מה הפשט?

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

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

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

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

״וורום, וורום״, צועק גודפרד ומניע את האוד כאילו היה מכונית מהירה.

אולה הסתכל על בנו וחשב -

״אאוריקה״ 💡

משחק ילדים

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

צעצועים בכל מחיר

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

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

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

שחק, טוב

ב-1934, כשישב עם בנו גודפרד בן ה-14 וניסה לחשוב על שם לחברה החדשה שלו, הם החלו לייצר ״שמשות מילים״ המייצגות את צעצועי העץ המיוחדים ולבסוף נותרו עם 2 מילים - שחק, טוב. הם כמובן קראו אותן בדנית: Leg, Godt, ולאחר הלחם קצר הגיעו למילה הקצרה והקליטה - Lego.

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

חלומות מפלסטיק

המהפכה הראשונה ואולי המשמעותית מכולן של חברת ׳לגו׳ הגיעה ב-1947. אולה כריסטיאנסן סיים לקרוא את עיתוני הערב ושם לב למודעה קטנה בתחתית העמוד האחורי - ״חומר חדש עושה את דרכו לדנמרק! הפלסטיק כבר כאן!״. הבנקאי המקומי חשב שאולה השתגע כשביקש הלוואה לצורך רכישת מכונת הזרקת פלסטיק - “אתה רוצה להחליף צעצועי עץ באיכות מעולה בצעצועי פלסטיק זולים?” שאל בתדהמה. “אני רוצה ליצור צעצועים שכל ילד יוכל להרשות לעצמו,” ענה כריסטיאנסן וחייך לבנו גודפרד, שכבר היה גבר צעיר בן 24.

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

קוביות מזל

חורף 1949.

אחר הצהריים סגרירי.

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

“אבא,” לחש גודפרד למכשיר הטלגרף, “אני חושב שמצאנו את זה.”

אולה חייך.

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

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

חווייה הוליסטית

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

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

מהלך מבריק נוסף של לגו היה יצירת “מערכת משחק” שלמה. ב-1957, לגו השיקה את “System i Leg” (מערכת המשחק):

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

זה איפשר ללגו לייצר את הקטלוג הראשון שלהםן:

ינואר 1960.

טרגדיה פקדה את המפעל בעיר בילונד.

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

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

עיצוב אינטראקציה

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

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

סקיילביליות

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

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

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

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

יוצאים מפוקוס

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

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

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

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

אבל משהו אבד בה.

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

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

מפולת קוביות

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

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

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

״רעיונות חדשים״

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

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

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

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

באג 2000

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

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

המספרים היו ברורים: החברה מפסידה מיליון דולר ביום. כן, ביום.

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

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

ועכשיו לחלק האמנותי: מחקר משתמשים

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

“לפני שאני מתחיל לתקן משהו,” הוא אמר, “אני צריך להבין מה הקסם שאיבדנו.”

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

לצאת לשטח

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

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

חזרה למקורות

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

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

פרסונות

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

סוף טוב הכל טוב

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

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

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

ומה אנחנו למדים מזה?

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

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

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

טל

*** המאמר מבוסס על ההקדמה לפרק הראשון בספר Observing the user experience, ספר מחקר המשתמשים המקיף והטוב ביותר בעיניי שנכתב עד כה.