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

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

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

חייכתי והשתעלתי קלות, מתכונן לנאום הקבוע שלי (:

״לא״.

״מה? למה?״ הוא שאל.

״אז אני אשאל אותך בחזרה: למה אתה רוצה, או לכל הפחות - שוקל, לעשות את הקורס הזה?״

״אני רואה המון חבר׳ה בונים אתרים ומוכרים אותם, וזו נראית לי אחלה הכנסה פאסיבית.״

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

“תגיד, יש לך אולי דוגמה למישהו שאתה מכיר שבנה אתר ומכר אותו?״ שאלתי.

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

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

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

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

״לא יודע, למי אפשר?״

״נראה לי שלכולם, לא?״

״אוקי….״

הבנתי שאין לו מושג איך להתחיל בכלל אז ניסיתי לדחוף -

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

״נשמע אחלה״

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

״התקשרנו לאמא שלי (סליחה אמא יקרה) והחייל פנה אליה קצת מגומגם ואמר לה, שלום - שרית? אהההם, בניתי לך אתר אינטרנט ותהיתי אם את רוצה לקנות אותו״

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

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

״אתה מוכן לעשות 40-50 כאלה ביום?״

״לא יודע, לא ממש אהבתי את זה״, הוא ענה.

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

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

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

:

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

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

רגע, על מה אנחנו מדברים

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

מה AI הזיז, ומה הוא השאיר בדיוק במקום

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

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

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

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

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

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

אז מה אני מביא כמעצב, דווקא עכשיו

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

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

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

השאלה שאני מצרף עכשיו לכל משימה

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

נגיעה אישית, וגם לאן זה הולך

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

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

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

“טל, מה עכשיו?”

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

אז הנה מה שאני עונה לכולם, ואני אומר את זה דוּגרי:

תנשמו. אתם מבלבלים בין הכלי לבין המקצוע.

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

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

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

“אבל טל, אני לא יודע לעבוד עם AI”

מצוין. גם לא ידעת לעבוד עם פיגמה ב-2016.

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

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

הסטודנטים שיאמצו את זה יהפכו לגדולים מהכלי

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

למשתמש יש מטרה, והמוצר יכול לעזור לו להשיג אותה.

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

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

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

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

“כתיבת PRDs. ניהול backlog. עבודה עם stakeholders. אנליזה של data. הגדרת metrics.”

שמעתי על PM שהכניס לקלוד את ה-JD שקיבל, ביקש שיעדכן אותה ל-2026. קיבל בחזרה את אותו הדבר עם שורה שנוספה בסוף: “ניסיון עם כלי AI - יתרון.” הוא לא פרסם אותה. הוא גם לא ידע מה לשנות.

יאללה, בואו נצלול.

Discovery: כשניתוח 40 ראיונות לוקח שעתיים

שלב ה-discovery הוא כנראה זה שהושפע הכי הרבה. לא ה-interview עצמו, אבל כל מה שסביבו ואחריו.

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

אבל ניתוח? שם הכל השתנה.

40 ראיונות זה בערך 40 שעות הקלטה, כלומר 200 עמודים של תמלול. בעולם הישן, שניים מאנשי צוות מוצר ישבו שבוע-שבועיים על affinity mapping. פוסט-איטים על קיר, clusters, pain points, themes. עבודה חשובה ומתישה בו-זמנית.

היום: מעלים את התמלולים ל-Dovetail (שיש לו AI synthesis מובנה ומחובר ישירות לממשק ה-research), או ל-Notion עם Notion AI, או עובדים ישירות עם קלוד עם prompt מוגדר. מבקשים: “מצא את חמשת ה-pain points החוזרים הכי הרבה, ציטוט לכל אחד, וכמה משתמשים/ות ציינו כל אחד.” תוך שעה מקבלים תמצות ב-95% דיוק.

Dovetail הוא כלי UX research שמובנה בו AI synthesis. אפשר להעלות הקלטות, תמלולים וציורי screen ולקבל insights, pattern recognition ו-highlight reel. הוא לא מחליף את שיקול הדעת של researcher, אבל חוסך 60-70% מה-grunt work (הניתוח המכני, לא הפרשנות).

זה לא אומר שהניתוח נעשה ב-autopilot. זה אומר שהזמן שה-PM מבלה/ת ב-validation, ב-cross-referencing ובהצגת ממצאים עלה. הזמן ב-mechanical synthesis ירד.

עובדה חביבה: מחקר של Lenny Rachitsky הראה שה-PM הממוצע/ת
מבלה 15-20% מזמנה ב-synthesis ו-documentation.
עד 2025, המספר הזה ירד לפחות מ-8% בצוותים שאימצו AI.
הזמן לא נעלם — הוא עבר ל-validation ולדיאלוג עם stakeholders.

PRD: שלא תגיעו למצב ש- “AI כותב את זה”

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

מה שקורה זה שונה ויותר מעניין.

ה-PM עושה/ת שיחה. לפעמים עם קלוד, לפעמים עם ChatGPT, לפעמים עם עצמה ועם doc ריק. אבל בשיחה, לא בדף ריק. השיחה מחלצת thinking. “מה אנחנו בונים? למה? מה success נראה כמו? מה ה-scope שלא נגע בו עכשיו?”

אחרי שה-thinking ברור, ה-crystallization נעשה עם AI: ה-PM מאכיל/ה context (על המוצר, על המשתמשים, על ההחלטות שכבר התקבלו), ה-AI מייצר מבנה ראשוני, ה-PM מגיב/ה ומדייק/ת. אחרי שלושה סבבים יש draft שמייצג נאמנה את מה שה-PM חשב/ה.

ה-documentation הוא ה-last step. לא ה-first.

זה ה-flip האמיתי: לפני, כתיבת PRD הייתה חלק מה-thinking process. עכשיו, ה-thinking process קורה בשיחה, וה-PRD הוא output שלה.

מי שמנסה “ל-prompt AI לכתוב PRD” בלי ה-thinking שקדם לזה מקבל/ת artifact יפה שלא שווה כלום. זה כמו לבקש ממישהו לצייר מפה בלי לספר לו לאן אתם הולכים.

Prioritization: קלוד לא עושה פוליטיקה

אחד השימושים הכי underrated של AI ב-product management הוא כ-thinking partner לprioritization.

RICE scoring, MoSCoW, opportunity sizing - כולם frameworks שרוב ה-PMs מכירים, אבל כשמנסים ליישם אותם בנסיבות אמיתיות, הפוליטיקה נכנסת. “ה-CEO ביקש את הפיצ’ר הזה.” “ה-feature הזה חשוב ל-big customer.” “ה-eng team מעדיף/ת את זה כי הם כבר יודעים איך לבנות.”

קלוד לא עושה פוליטיקה. hell, הוא לא יודע בכלל מי ה-CEO. תנו לו את הנתונים, תנו לו את ה-framework, תנו לו את ה-business context, ובקשו ממנו לאתגר את ה-assumptions שלכם.

“לפי הנתונים שנתתי לך, feature X מקבל Reach גבוה אבל Impact נמוך. מה הסיבות הסבירות שהצוות עשוי לdebate זאת?” - זו שאלה שAI עונה עליה בלי שיקולים פוליטיים, ואז ה-PM יכול/ה לקחת את ה-output לדיון עם ראש צלול.

זה לא מחליף את ה-judgment. זה מנקה את ה-playing field לפני שה-judgment נכנס.

Delivery: פחות glamour, יותר leverage

כתיבת tickets. dependency mapping. sprint planning. ה”עבודות הכפופות” של delivery.

תכלס, הרבה מזה שעמם PMs לאורך שנים. “תתאר task ל-developer” - כמה פעמים כתבתם את אותו הריקוויירמנט עם קצת שינויים?

AI הפך את זה ל-leverage נקי. ה-PM מגדיר/ה ב-natural language מה צריך לקרות. קלוד ממיר/ה ל-structured ticket עם acceptance criteria, edge cases שצריך לחשוב עליהם (כולל כאלה שה-PM לא חשב/ה עליהם), ו-dependencies שכדאי לוולידציה. ה-PM מדייק/ת. ה-developer מקבל/ת משהו שאפשר לעבוד איתו.

לא כל ticket יוצא מושלם. אבל ה-baseline עלה משמעותית, וה-PM מבלה/ת 30 דקות במקום שעתיים.

עובדה חביבה: טכניקה נקראת "pre-mortem על tickets".
לפני שמעבירים ticket ל-eng, שואלים AI: "מה יכול להשתבש ב-implementation הזה?"
הרבה bugs נמצאים בשלב הזה, לפני שנכתב שורת קוד.

Analytics ו-Retrospective: כשה-data מספר סיפור לבד

הרבה PMs מקבלים dashboard עמוס נתונים וצריכים להתכונן משהו כמ 30 דקות לפני quarterly review כדי להגיד משהו חכם.

בעולם ה-AI זה נראה אחרת. מייצאים data (בד”כ CSV פשוט, לא צריך יותר מזה), נותנים לקלוד לנתח trends, ומבקשים: “מה שלושת ה-patterns הכי מפתיעים ב-data הזה? מה ה-hypotheses שמסבירות אותם?” ה-PM מקבל/ת נקודות פתיחה לניתוח, לא דף ריק. אנחנו לא משתמשים בזה as is כמובן.. אתםן צריכים לעבור על זה, לדייק, לאמת ולוודא שמפעם לפעם קלוד מוציא לכםן סיכום טוב יותר ומדויק יותר שאתםן (וכל שאר הנמענים) יכולים ״לעכל״ בקלות.

ב-retrospective זה אותו הדבר. “הנה ה-sprint data, הנה ה-velocity, הנה ה-bugs שנסגרו. מה שאלות טובות לשאול ב-retro?” זה לא מחליף את ה-retro, זה מכין אותו. (ועל context ו-memory של AI כתבתי מאמר נפרד בבלוג.)

מה מחכה לבני האדם

כאן הדברים נהיים מעניינים.

כל מה שתיארתי למעלה הוא leverage על tasks. אבל יש set שלם של skills שלא רק שלא הפכו פחות חשובים, הם הפכו יותר חשובים.

ניהול stakeholders: שימו לב ש- AI לא יודע לנהל/ת את ה-dynamic עם CTO שחושב שה-feature שלו חייב להיות Q1. AI לא יודע לקרוא את ה-room כשה-board member מביע/ה תמיכה פומבית אבל ספקנות פרטית. זה human skill, תמיד יהיה.

לומר לא: זה תמיד היה הדבר הכי קשה ב-product management, ו-AI לא עושה אותו קל יותר. ה-PM צריך/ה vision ברור ו-conviction אמיתית. לא prompts.

הגדרת vision: המוקד הוא Where are we going and why does it matter? זה לא תמלול של user research, זה synthesis של market, users, business ו-timing. כשה-AI יכול להכין את ה-inputs, אבל ה-synthesis הוא human judgment גרידא.

Empathy עם users: שימו לב לניואנס: AI יכול לנתח ראיונות, אבל ה-awareness שמגיעה מלשבת שעה עם משתמש/ת ולראות אותה טובעת בממשק שחשבתם שהוא ברור, זה לא ב-dataset.

Workflow אמיתי לאורך cycle מלא

שבוע ראשון של sprint: ה-PM מריץ/ה synthesis על ה-user interviews החדשים ב-Dovetail. מקבל/ת 5 themes. מוולידציה 3 מהם עם quantitative data. עובד/ת עם קלוד לבנות hypothesis doc. מציג/ה לצוות ב-15 דקות במקום שעה.

הגדרת scope: שיחת thinking עם קלוד שמחלצת את ה-product decisions הסמויים ב-feature request. כותב/ת brief. מבקש/ת מ-AI לייצר PRD draft. מדייק/ת. שולח/ת ל-review.

Backlog grooming: RICE scoring עם AI כ-thinking partner. בקשת אתגורים על הנחות. מוצאת/ת עמדה. מביאה/ה לדיון עם צוות ו-stakeholders.

כתיבת tickets: template עם AI. validation של edge cases (כולל pre-mortem). העברה ל-engineering עם context מלא.

Mid-sprint check: data dashboard עם AI synthesis. anomalies? pattern שמסמן בעיה? מגיב/ה מהר, לא מחכה ל-retro.

Retro + planning: AI מכין שאלות ל-retro, מסכם learning, מציע hypotheses ל-sprint הבא.

מה שנשאר human בכל אחד מהשלבים האלה: ה-judgment calls, ה-stakeholder conversations, ה-vision וה-conviction. אלה לא השתנו. הזמן שנפנה לקראתם כן.

שני דברים שבאמת השתנו

ה-ratio - עבודת ידיים מכנית ירדה. עבודת judgment עלתה. PM שלא מאמץ/ת AI tools מבלה/ת עכשיו 60% מזמנה בעבודה שהייתה יכולה להיעשות ב-20% מהזמן. זה זמן שמחכה להישקע בדיאלוג אנושי, ב-user proximity, ב-vision.

ה-baseline expectations - ה-output שנחשב “טוב” עלה. PRD שלקח שבוע עכשיו נכתב ביום. זה לא אומר שה-PM עובד/ת פחות שעות, זה אומר שיש עוד עבודה שמצפה לתשומת לב.

הכשרה נדרשת ומה רוב הקורסים מפספסים

PMs שלא יודעים/ות לעבוד עם AI tools ב-2026 עובדים/ות ב-disadvantage אמיתי. לא ב”עתיד”, עכשיו. אבל הכשרה שדרושה היא לא “ללמוד לכתוב prompts”. זה נחמד אבל זה surface בלבד.

ההכשרה הדרושה: להבין מה AI עושה טוב (synthesis, pattern recognition, drafting, challenging assumptions) ומה הוא לא עושה טוב (judgment ב-ambiguity, empathy, פוליטיקה ארגונית, timing). ולבנות workflow שמניח כל tool במקום הנכון שלו.

ה-PM שעושה את זה נהנה/ית מ-leverage אדיר. ה-PM שלא עושה את זה עובד/ת קשה יותר מהנדרש ומייצר/ת פחות.

הכל השתנה, כלום לא השתנה?

אכן.

הדברים שמנהלי/ות מוצר טובים/ות תמיד אהבו - הקרבה למשתמשים/ות, החשיבה על impact, הדיאלוג עם הצוות - אלה גדלו, לא קטנו. הדברים שתמיד הרגישו כסיזיפיים -affinity mapping, PRD drafting, ticket writing, data grinding - אלה הצטמצמו משמעותית.

אם בניתם career על ה-overhead: הגיע הזמן לשנות. אם בניתם career על ה-thinking: אתם/ן ב-place טוב.

מה הדבר שלקח לכם הכי הרבה זמן החודש שמרגיש כמו overhead שAI היה יכול לעשות? זה המקום להתחיל. 🙏

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

יאללה, בואו נצלול.

chatbot רגיל - chat gpt, קלאוד, ג׳מיני - עובד ככה: שואלים, מקבלים תשובה. נקודה. הוא לא עושה כלום. הוא לא יוצא מהחלון, לא מפעיל כלי חיצוני, לא שולח מייל, לא כותב לדאטהבייס. ChatGPT במצב הבסיסי שלו, Copilot רגיל, Claude בלי tools - כולם chatbots. גאוניים, אבל רק chatbots.

לעומתם, agent הוא מודל שמסוגל להפעיל כלים.

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

זה ההבדל כולו. הבדל ארכיטקטוני גרידא.

ומה קורה בפנים

מתחת למכסה, agent עובד בלופ שנראה בערך כך:

Plan → Act → Observe → Plan again

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

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

הזיכרון של agent יכול לעבוד בכמה רמות: זיכרון של השיחה הנוכחית (context window), זיכרון שנשמר בין sessions (בקובץ, ב-database, בוקטור DB כמו Pinecone), וזיכרון שמשותף בין agents שונים. המורכבות עולה, אבל גם העוצמה.

עובדה חביבה: המושג "tool calling" הוא מה שהפך LLMs ל-agents.
Anthropic הכניסו tool use ל-Claude בקצב מהיר מאז 2023.
OpenAI קוראים לזה "function calling". זה אותו הדבר.

שלוש קטגוריות של Agents

לא כל agent הוא אותו הדבר, יש כאן spectrum:

Simple agent הוא agent שעושה דבר אחד: “קח את הטופס הזה, חלץ ממנו את הנתונים, שמור אותם בספרדשיט.” זה agent. לא מרשים, אבל עובד מצוין לאוטומציה של פרוצס חוזר.

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

Multi-agent system היא agents שמנהלים agents. Orchestrator agent שמקבל משימה ומחלק אותה ל-sub-agents מתמחים. אחד לחקור, אחד לכתוב, אחד לוולידציה. זה המצב הנוכחי של החלק המרשים של התחום.

Use cases אמיתיים

שיווק: צוות של חמישה אנשים בסטארטאפ B2B. הם לוקחים כל בלוג פוסט שמישהו כותב, מעבירים אותו דרך agent שמחלץ את ה-key insights, כותב thread לטוויטר/X, draft ל-LinkedIn, סיכום ל-newsletter, ומציע hook למודעות. מה שלקח שלוש שעות לקריאיטיב לקח לאייג׳נט 12 דקות.

בריאות: מרפאת שיניים בינונית. agent שמקשיב לתמלול של שיחת הקבלה, בונה רשומה ראשונית, מציע מועדים לפי זמינות הרופא/ה, ושולח confirmation לפציינט/ית. הצוות לא נוגע בזה. זה לא רובוטיזציה, זה שחרור של זמן ל-care אמיתי.

חינוך: ארגון לימודים שמייצר content לקורסים. agent שמקבל syllabus ומחולל שאלות לדיון, quiz, תמצות ל-study guide, הצעות לתרגול. מה שלקח שבוע לוקח עכשיו כמה שעות.

ייצור: מפעל שמחפש anomalies בנתוני חיישנים. agent שרץ על הנתונים כל שעה, מזהה patterns חריגים, מייצר דוח עם השוואה לבסיס, ושולח alert עם הצעה לפעולה לאדם הרלוונטי. לא מחליף את המהנדס/ת, מאפשר לה להיות שם כשזה באמת חשוב.

מכירות: SaaS B2B למשל - agent שמקבל lead חדש מהאתר, בודק ICP fit לפי פרמטרים מוגדרים, מחפש את החברה ב-Crunchbase וב-LinkedIn, מייצר brief מותאם לנציג/ת שיתקשר, ומעדכן את ה-CRM. ה- Sales rep פותח/ת את הבוקר עם inbox מסוכם, במקום לטבוע בעבודת כפיים.

הכלים שיש היום בלי לכתוב קוד

כאן זה מעניין כי ה-barrier ירד דרמטית.

n8n הוא הכי עוצמתי מבין ה-visual builders. יש לו open-source, אפשר להריץ locally (זה חשוב מאוד לארגונים עם מגבלות compliance), יש לו מאות connectors מובנים, ותמיכה מלאה ב-AI nodes שמאפשרת לחבר LLM לכל workflow. זו לא “אוטומציה קלה”, זה כלי שאנשי טכנולוגיה אמיתיים בונים איתו pipelines ברמת production.

Make (לשעבר Integromat) - ממשק יפה יותר מ-n8n, קל יותר ל-onboarding, קצת פחות גמיש. אידיאלי לצוותים שרוצים להתחיל מהר בלי ללמוד יותר מדי. יש AI modules שמאפשרים לחבר Claude, GPT, או Gemini לתוך flow.

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

Voiceflow, Botpress - יותר ספציפיים ל-conversation design. אם בונים agent עם ממשק שיחתי, שם תמצאו כלים ייעודיים.

עצה: התחילו עם n8n locally. יש deployment ב-Docker שלוקח 10 דקות. אפשר לבנות את כל ה-workflow offline, לוולידציה, לפני שחושבים על cloud.

מה עושה agent טוב

זו השאלה שאני שומע הכי פחות אנשים שואלים, ואולי הכי חשובה.

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

הוראות ברורות - ה-system prompt הוא ה-DNA של ה-agent. אם הוא מעורפל, ה-agent יתנהג בצורה לא עקבית. “עזור לצוות המכירות” זה לא הוראה. “קח כל ליד חדש שמגיע מ-HubSpot, בדוק אם הוא עומד בשלושת הקריטריונים האלה, אם כן — יצר brief עם המידע הזה ושמור ב-Notion, אם לא — תייג כ-low priority ועדכן שדה ב-CRM” — זה הוראה.

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

context מספיק - agent שלא יודע מיהו ה-user, מה ה-business context, מה המגבלות - יקבל החלטות שגויות. לא כי הוא טיפש, כי הוא לא יודע משהו אחר.

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

איפה agents נכשלים ולמה זה בסדר

agents נכשלים כשה-task מאוד ambiguous. כשהם מקבלים מידע שסותר את ההוראות שלהם. כשה-tools לא עובדים כמצופה. כשה-context window מתמלא ו”שכחו” מה קרה קודם.

אבל כל הכשלונות האלה ניתנים לתיקון עם design טוב יותר. הם לא פגם מובנה ב-technology.

האנלוגיה שאני אוהב: אם מגייסים עובד/ת חדש/ה ונותנים לה ללמוד את העבודה על ידי ניחושים בלי הדרכה, היא גם תטעה. זה לא אומר שאדם לא יכול לעשות את העבודה. זה אומר שה-onboarding שלה היה גרוע.

agents צריכים design. לא רק deployment.

עובדה חביבה: Anthropic פרסמו מחקר שמראה שאחד הגורמים הגדולים
לכשלון של agents הוא ambiguity ב-tool descriptions - לא ב-model quality.
Design טוב של כלים = agent טוב יותר.

Multi-agent orchestration - המצב נכון לעכשיו

Multi-agent זה כבר לא עתיד, זה הווה. חברות כמו Anthropic, OpenAI וGoogle בנו frameworks ל-agent-to-agent communication.

הפטרן הכי נפוץ: orchestrator + specialists. ה-orchestrator מקבל מטלה גדולה, מחלק אותה לאחראים/ות, מאסף תוצאות, ומחליט מה הלאה. Specialists הם agents עם scope מוגדר וכלים ספציפיים.

content pipeline אמיתי ב-2026 יכול להיראות כך: orchestrator מקבל “כתוב ניתוח תחרותי לפני Investor meeting”. הוא מפעיל research agent שמחפש, מסכם, ומחלץ עובדות. מפעיל writing agent שכותב דראפט. מפעיל fact-check agent שמוולידציה. מחזיר תוצאה. כל ה-pipeline לוקח 20 דקות.

זה לא science fiction. זה n8n workflow עם שלושה Claude API calls.

איך מתחילים היום?

חמישה צעדים.

1. identify: מה ה-process החוזר בחיי העבודה שלכם שלוקח יותר זמן ממה שהוא שווה? לא “כל האימיילים שלי” — משהו ספציפי. “כל שבוע אני מסכמת את ה-standups ל-stakeholders.”

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

3. n8n workflow פשוט: בנו את ה-automation בלי AI קודם. רק connectors. וודאו שה-data זורם.

4. הכניסו AI: עכשיו הוסיפו LLM node לחלק שדורש הבנה. הסיכום, החלטת הניתוב, הכתיבה. שמרו את ה-decision points האנושיים.

5. expand: כשזה עובד, הרחיבו. הוסיפו כלים, הגדילו את ה-scope, אולי הוסיפו agent נוסף שמשלים את ה-pipeline.

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

מה שנשאר

המילה “agent” לא הולכת לשום מקום כי מה שהיא מתארת כבר משנה איך עבודה נעשית. לא בצורה דרמטית בבת אחת, אלא incrementally, צוות אחד ו-workflow אחד בכל פעם.

השאלה היא לא “האם agents יגיעו לתחום שלי?” השאלה היא “מה ה-process שלי שהכי ייהנה מ-agent ראשון?”

מה ה-process החוזר שלכם שמחכה ל-agent ראשון? 🙏

בנובמבר 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 הפכה לכלי שלא ניתן לוותר עליו, ואני ממליץ לכל א.נשי חוויית המשתמש

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