איך יצרנו שפה סביב עקרונות חווית משתמש

ליאור: היי רועי.

רועי: שלום ליאור.

ליאור: היי כולם. הגעתם ל-Startup for Startup, הפודקאסט שבו אנחנו חולקים מהניסיון, מהידע ומהתובנות שלנו כאן במאנדיי.קום וגם מחברות אחרות, והוא מיועד לכל מי שסטארט-אפ מדבר אליו, לא משנה באיזה כיסא הוא יושב ברגעים אלו. [מוזיקה]. אז היום אנחנו נדבר, האמת שנשתף אתכם, בעקרונות שהתוונו לאחרונה בכל הנוגע לחוויית המשתמש ולדרך שבה אנחנו עובדים כדי לייצר חוויית משתמש אחודה וטובה ו-delightful מה שאנחנו קוראים לו כאן במאנדיי. וכשמדברים על חוויית משתמש, זה נשמע אולי לחלקכם כמו משהו שנוגע רק לאנשי מוצר או לאחרים זה נשמע כמו משהו שממש נחלתם של המעצבים בחברה. אבל האמת שזו בדיוק הסיבה שישבנו יום אחד להתוות את העקרונות האלה בצורה מסודרת, כי אנחנו הבנו כאן בחברה – ותיכף נדבר על זה, בעצם נדבר על זה כל הפרק – שגם המפתחים ובעצם כל אדם בחברה אמור להיות מסוגל להבין מהם אותם עקרונות שעומדים בבסיס חוויית המשתמש שאנחנו רוצים ליצור. וזו גם הסיבה שאיתנו כאן היום אביגיל פגי, שהיא מפתחת full stack בחברה.

אביגיל: היי, שלום.

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

רועי: אז אני חושב שזה באמת פתרון למשהו שרצינו, שהוא בבסיס של החברה. כלומר, יש עניין שנקרא איכות. כלומר, מה שבאנו לעשות, שיהיה טוב, שיהיה מגניב. אני חושב שכל מי שנכנס למאנדיי מרגיש כמה בוא נגיד אהבה השקענו בדבר הזה. איך משמרים את זה. עכשיו, והדרך שלנו לשמר את הדבר הזה היה בעצם בכמה רמות. דבר ראשון, בהגדרה של ה-KPI של החברה. כלומר אם אנחנו data driven אז יש פה קונפליקט פתאום. עושים משהו נניח ממש מכוער ושאף אחד לא אוהב אותו אבל הוא מנצח במספרים. אז מה מחליטים? בסדר? אז יש משהו שנמצא מעל ה-KPIים. זה values. Values זה לא משהו שאפשר להתווכח איתו כל-כך, זה value. צריך לא להיות הרבה כאלה, וכל אחד צריך להיות מאוד מה שאנחנו מאמינים בו. נניח speed הוא גם value שיש לנו. כלומר, אף אחד לא ישכנע באף A/B test שלעשות משהו לאט יותר, כלומר מבחינת החוויית משתמש, שזה יהיה ממש לאט זה יותר טוב. פשוט אי אפשר לשכנע, כנראה הטסט לא בסדר. כאילו, אנחנו מאוד מאמינים בזה ופועלים לזה בלי לבחון את זה כל הזמן, זה ערך. ואותו דבר האיכות של ה-execution של דברים, שמוצר יהיה טוב, שהוא יהיה יפה, שתהיה לו חוויה מאוד מסוימת, לפי עקרונות מסוימים. זה לא עניין של כאילו בחינה. ופה נכנס לעניין מה זה הדבר הזה, אנחנו צריכים לפחות להסכים על זה. וככל שהצוות גדל אז צריך שזה יהיה מהר שנסכים על זה כי אז מה שיקרה, יצאו הרבה דברים שהם לא בתוך העולם הזה.

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

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

[4:00] 

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

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

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

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

רועי: אני חושב שבסופו של דבר אנחנו, יש עניין של execution, בסדר? את עושה משהו, אני סתם אתן דוגמה אחת, כי דוגמאות זה הכי טוב. נניח היה טסט עשו שאמרו רגע, אנחנו רוצים לעשות log in גם לגוגל. לא רק username ו-password. אז אמרו טוב, הבנו ליוזר שתי אופציות, והם בחרו וזה התוצאות וזה. אני מסתכל על זה ואני אומר רגע, לא הבאנו שום שתי אופציות. למה? כי יש כפתור של sign up עם גוגל, אחרי זה יש איזה אור קטן או איזה קו. ומתחת יש username-password. אני אומר טוב, מה שאני מבין זה יש כותרת שאומרת גוגל והנה תכניס את ה-credentials של גוגל מתחת. בסדר? ב-execution לי זה נראה ככה, זה לא UX שהוא ברור. לתת ליוזר שתי אופציות זה דבר מאוד מאוד קשה, אני ראיתי, לא יודע, אני מנסה, מנסים להימנע מזה בכל אפשרות, כן? כי פשוט אנשים לא מבינים את זה. אופציות ב-UI כאילו, אתה עושה או את זה או את זה, זה כאילו, א' זו שאלה קשה. כי הם עושים את זה תמיד לפני אז הם לא יודעים מה ההשלכות. פה דווקא כן יודעים מה ההשלכות, אבל זה לא היה ברור. אז נניח טסט שהיו מקשיבים לתוצאות שלו ואמרו אה, שתי תוצאות זה פחות טוב, כי אף אחד לא הבין שזה חדש אפילו.

ליאור: שהטסט בנוי מלכתחילה בצורה שאי אפשר לבחון.

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

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

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

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

רועי: כן. ושלא יודע, לזה-

ליאור: ולהקשיב לדרישות שלך אם יהיו כאלה.

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

ליאור: מה לקחת מזה?

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

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

רועי: מה, בראסרי?

ליאור: כן.

רועי: טוב.

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

רועי: אז יש להם המון empowerment, בוא נקרא לזה ככה. 

ליאור: ואיך אתה לוקח את זה לחברה?

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

ליאור: שפוגע גם בעיקרון של המהירות שתיארת קודם.

[10:00]

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

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

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

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

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

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

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

ליאור: מייצרת קונפליקט, כן.

רועי: אבל אין קונפליקט. בואו נעשה כמה שיותר פיצ'רים, בלי tradeoffs. אני יכול לתת לזה גם דוגמה, כן? כל הטלפונים הסלולאריים שלנו, כן? יש אולי מיליון אפליקציות, כנראה יותר, יש כמה מיליונים של אפליקציות ב-app store, הן לא גורמות לטלפון להיות יותר פשוט או פחות פשוט, בסדר? אז הכמות, יש פתרונות שמאפשרים שלא יהיה tradeoff. אז אנחנו תמיד מנסים למצוא גם וגם. אני רוצה את זה ואת זה, בוא נעשה גם את זה וגם את זה. כדי לא להגיד, להיכנס לנרטיב הזה של כאילו זה "או זה או זה". 

ליאור: זה עיקרון אחד.

רועי: כן. 

ליאור: בעקרונות הכלליים, כן. 

רועי: כן.

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

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

ליאור: מה, שבועיים לקח לכם להגיע לזה שצריך להחליף אייקון? זה ה-counterintuitive פה, כן.

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

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

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

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

ליאור: והפשטות הזאת לא לקחה את זה בחשבון.

רועי: זה פשוט לא פתר את הבעיה.

ליאור: סיבך לאנשים את הדברים, כן.

רועי: כן. וברגע שפתחנו את כל העץ והסתכלנו על כל ה-complexity של הדבר הזה, ניסינו לפתור את כל ה-scenarios, זה נהיה מאוד מורכב מאחורה. אבל doable וגם אפילו ברור מאוד ליוזרים, כי היה להם את האופציה שהם הבינו ורצו. בסדר? Having said that זה עדיין רחוב מלהיות מושלם. אבל זה, עשינו שם התקדמות מאוד אדירה עם זה שהתמודדנו עם ה-complexity. [מוזיקה]. אז נעבור על כל העקרונות מהר, ואחרי זה נסביר כל אחד. אז עיקרון מס' 1 זה don't make me work for the system. כלומר, אנחנו רוצים שהמערכת, שהתחושה תהיה שהמערכת עובדת בשבילי ולא שאני צריך לעבוד ולהשקיע אנרגיה בשבילה כדי שהיא תיתן לי משהו. עיקרון מס' 2. Consistency ו-intuitive UI. שהוא יהיה ברור, פשוט וקונסיסטנטי across כל המערכת, כלומר אם יש איזשהו עיקרון, שאנשים יתרגלו אליו ויראו אותו בכל מקום עוד פעם. 3, compounding effect. זה בעצם ה, משהו שהוא נכון למאנדיי, שהוא, כל משהו שאנחנו עושים שיהיה מכפלה אל-מול דברים אחרים שאנחנו בונים. ונסביר את זה בהמשך. עיקרון 4, predictable and stress free. שזה אפשר לדבר על זה שעות, אבל לא נדבר על זה. שתחושה פשוט שאני, האפקט של זה זה שאנשים מרגישים שזה פשוט עובד וקל ופשוט. עיקרון מס' 5, gradual complexity discovery. אפשר להגיע איתנו להמון complexity, לנהל דברים מאוד מורכבים. אבל אנחנו לא רוצים שמההתחלה זה יהיה overwhelming, אנחנו רוצים שאנשים יתחילו במה שהם מבינים-

ליאור: בהדרגתיות. כן. 

רועי: ובהדרגתיות יוכלו לבנות דברים יותר מורכבים. 6, meaningful copy. דיברנו על זה טיפה מקודם. שה-copy יסביר לי, ה-copywriting, הטקסט, יסביר לי מה שאניח צריך לעשות בצורה שהיא מאוד מתומצתת וברורה ולא מתחכמת ונוספת, שזה יהיה אפקטיבי. ו-7, מאוד ספציפי ל-UI, זה lists. איך מטפלים ב-lists, התפיסה של lists, זה משהו מאוד חזק, שהרבה פעמים מתפספס. 

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

רועי: אז עיקרון מס' 1, don't make me work for the system. אני חושב שבהמון תוכנות, יש קטע כזה ש, נניח גנץ זה דוגמה טובה. שהוא אומר תכניס ותכניס מידע, ותכניס מידע, ועל כל דבר אני עושה אני לא מקבל ערך חזרה. לא על כל פעולה אני מקבל. ובסוף אומרים, בסוף יש פרס, בסוף אתה תדע מה ה-dependency ואיזשהו bottleneck שיש לך. אבל כל הזמן אני נהיה עבד של התוכנה. אני צריך להזין משהו כדי שב-enterprise systems, בדרך-כלל מה שקורה, העיקרון הזה כשהוא מופר הוא נהיה abuse מטורף כאילו. אני צריך לעבוד כדי שלמנהל שלי בכלל יהיה value. כלומר, המשתמש אפילו הוא לא מקבל שום value מזה, רק הם מכריחים אותו להשתמש בתוכנה ואז הוא שונא אותה, ומישהו אחר מקבל את ה-value.

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

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

ליאור: לא הבנתי, מה זה Progress bar?

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

ליאור: כשאני כבר משתמשת בתוך הפלטפורמה?

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

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

ליאור: אז השינוי יבוא, זאת אומרת, הבחירה תבוא אחר-כך כתיקון ולא בשלב הבחירה הראשונית.

אביגיל: נכון.

רועי: אנחנו קוראים לזה smart defaults. עכשיו, מה זה אומר smart defaults? בפועל, זה אומר שאנחנו צריכים לשבת ולחשוב הרבה הרבה מה הדבר הדיפולטיבי הכי טוב שיש. פה הרבה פעמים כן יש tradeoffs, וצריך לשבת ולהבין ולוותר, ולקצוץ על דברים במוצר דווקא בשביל שה-default הראשוני יהיה טוב. ולא לבוא ולהגיד "רגע, אני לא יודע, יש פה כמה אופציות, בוא שהיוזר יבחר." זה לא product, זה, זה מה שנקרא לא להחליט.

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

רועי: ה-tradeoff הוא לשאול אותך עוד שאלה, כן. זה ה-tradeoff בסוף. כאילו, אם את צריכה-

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

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

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

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

ליאור: אין לך מה לעשות אם זה, נכון.

רועי: בנקודה הזאת אני לא יודע להחליט.

ליאור: ואז בחזרה לחוויה, זה מייצר איזושהי חוויה של חוסר ודאות ו-stress מיותר.

רועי: זה נוגע גם לנקודה 4 של ה-stress, שזה מייצר stress כאילו כל השאלות האלה. יש עוד כמה דוגמאות או תתי-סעיפים לכל עיקרון כזה. אז 1, אז בוא נעבור הלאה. של נניח, קראנו לזה don't be a technocrat. כן? מה זה אומר? זה אומר שהרבה פעמים מערכת היא נראית טיפשה. כאילו, התוכנה נראית טיפשה. אני אתן דוגמה, ה-permissions, בסדר? אני בא ואומר, אני עובד איתך על משהו, אני  הקמתי את זה, לי יש את ההרשאות, לך אין. את באה לשבת לידי על הכיסא, או אני בא לידך לשבת על הכיסא ואני אומר לך "טוב, בואי תשני את זה." את באה לשנות, "לא, אי אפשר, לכי תשאלי את רועי." זה, כאילו, ה-permission, במקרה הטוב הוא יגיד לך רועי יש לו את ה-permissions. במקרה הוא אומר לך אין לך הרשאות ולכי, אני לא יודע מה לעשות אם זה. 

ליאור: קרה לי.

אביגיל: במקרה העוד יותר רע הוא אומר "נכשלתי, error."

רועי: Error. זה נכון [צוחק], זה נכון. אז מה התנהגות טובה פה? ה-default שיהיה public. עכשיו, מה הטכנוקרט הזה? הוא אומר לכי לרועי – אני עוד יושב לידך, אז הוא אומר הנה, הוא פה, הנה, הוא מאשר לי. אבל המחשבים לא עובדים ככה. 

ליאור: נכון.

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

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

[25:00]

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

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

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

רועי: שקיפות, הנחה של שקיפות עזרה לנו. כלומר, שיש שקיפות בתוך הארגון של המשתמש. כלומר, שהוא רוצה לשתף עם אחרים. אני חושב ש-permissions ישר מייצר silos, ישר מייצר קבוצות של יוזרים, ישר מייצר את כל הבעיות האלה. אבל זה בכל מקום נוצר. אני בניתי משהו שאת לא שותפה לו. אז אם אנחנו מניחים שיתוף, מניחים שאם מישהו אחד עשה אז כולם זוכים לקבל את זה, יש הרבה פחות מהבעיות האלה שנוצרות. וגם, הניסיון שלנו לבוא ולראות בכל דבר שאנחנו עושים, כמו חשבון בנק. בן אדם משך, עם כל פעולה שהוא עושה זה הוא עשה פעולה של למשוך, למשוך לנו כסף מהבנק של האיכות. עכשיו השאלה אם נתנו לו ערך עבור הכסף הזה או לא, או שהוא סתם משך ומשך ומשך ומשך והשאיר אותנו במקום שהוא כאילו בסוף לא אוהב את המערכת. עיקרון מס' 2. Consistency and intuitive UI. אז זה ככה מדבר בעד עצמו, אבל בוא נגיד טיפה-

ליאור: אבל ממש לא אגב [צוחקת].

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

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

רועי: אז ה-intuitive UI ו-consistency קשור מאוד אחד לשני, כי אנחנו רוצים להיות consistent לא רק בינינו לבין עצמנו אלא אל-מול תוכנות אחרות ודברים אחרים שאנשים מכירים. נניח ש-radio button יהיה מה ש-radio button ו-check box יהיה check box-

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

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

ליאור: אביגיל, דוגמאות בבקשה.

אביגיל: כן. אז יש דוגמה טובה של מחיקה במערכת. אני חושבת שספרנו שהיו לנו שלוש גרסאות שונות של ה-dialog של האם אתה רוצה למחוק משהו. עכשיו, יש הבדלים באמת עיצוביים, יש הצללה קצת כזאת, קצת כזאת – זה גם עניין של אחידות ושל איך שאנחנו נראים. אבל היו הבדלים יותר מהותיים. למשל הטקסט של הכפתורים, האם אתה רוצה למחוק, במקום אחד היה כן או לא, במקום אחד היה למחוק או לבטל. וגם המיקומים שלהם היו שונים. זאת אומרת, לפעמים הכפתור הימני אומר כן למחוק ולפעמים הכפתור הימני אומר לא למחוק. ואם ההרגלים משתמשים לאיזושהי התנהגות מסוימת, הם רוצים לעשות איזושהי פעולה אז כבר באוטומט לוחצים על הכפתור הימני. פתאום קרה איזה משהו לא צפוי, אנחנו יוצרים איזשהו friction עם האנשים. חוץ מזה דיברנו גם על זה שהאנשים לפעמים גם הולכים וקוראים ישר את הטקסט שעל הכפתורים, הם לא תמיד קוראים איזושהי הודעת שגיאה, כל מה שכתוב שם. הם רוצים לראות מה יש בכפתור. ואם כתוב yes or no, הם לא קיבלו את ה-value, הם צריכים ללכת ולקרוא את כל הדברים. זה גם משהו שאנחנו משתדלים, תמיד לכתוב מה הפעולה שעומדת לקרות כשתלחצו על הכפתורים. מול העיניים שלכם. 

ליאור: אבל רגע, איך הגענו למצב שיש לנו שלוש ורסיות שונות לפעולה שהיא delete?

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

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

ליאור: היה intent מאחורי הדבר הזה, כן.

[30:00]

רועי: אבל נניח, אז כבר דב ראשון מערכות לא מניחות את זה. ישר זה אדום וישר עשית משהו שכאילו בוא נפחיד אותך. כי זה delete. נדבר גם על זה. ואז יש את השאלה הקלאסית – are you sure you want to delete? עכשיו, התשובה לזה, נניח גם אם היא no נניח, I'm not sure. אז עכשיו מה עושים, הולכים לפסיכולוג? זה לא אנגלית, כאילו. אנחנו, בוא נדבר על זה, שנייה, אם את לא בטוחה, רגע, מה זה אומר? 

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

רועי: אז נדבר על ה-

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

רועי: אז בוא נדבר אחרי זה מה זה הטוב של delete. אבל בוא נתעכב פה על כל הדברים הנוראיים, כן? אז are you sure you want to delete? ובדרך-כלל are you sure you want to delete? לא מביאים לך אפילו קונטקסט. את לא יודעת אפילו מה. בסדר? כלומר, לחצתי על משהו, אז הניחו שבטעות לחצת על זה, אבל לא אומרים לך על מה בטעות לחצת. בסדר? והתשובה היא yes or no. 

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

רועי: אז אני לא יודע על מה עכשיו, וזה מוחשך, וכאילו… זה. אז יש כל-כך הרבה חוסר ודאות וזה, וגם לא אנגלית נכונה שעוזרת. עכשיו, ואז מתחת ל-are you sure you want to delete? כותבים לך כאילו, בדרך-כלל עוד הפחדה כזאת, this will be deleted permanently and you won't be able to restore it. זה יש כותרת, תת כותרת, כפתור של yes וכפתור של no.

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

אר: אז הפחדנו לחינם.

אביגיל: אז הפחדנו עוד יותר.

רועי: עכשיו, הבעיה הזאת היא בכל התוכנות שאני מכיר, כן? זה לא מיוחד אלינו. ה-are you sure, yes/no. עכשיו, מה כן צריך לעשות? דבר ראשון צריך לקרוא, ברגע שכותבים yes/no, זה אומר שאין שם את המידע. אני צריך לקרוא את הכותרת. כלומר, ישר גורמים לי לקרוא יותר. מה שצריך לעשות, זה על הכפתורים לכתוב delete את השם של הדבר הזה. כאילו, זה הפעולה, זה לא yes לאיזושהי פעולה אחרת, זה full context, אני מביא את כל המידע שצריך לזה, ואז אני רק קורא את הכפתור אני יכול ללחוץ. ה-no צריך להיות cancel, כי זה מה שזה. והשאלה צריכה להיות delete את האובייקט, סימן שאלה. שזה בערך כמו הכפתור, בסדר? ובלי תת כותרת שזה יהיה delete permanently, נניח שזה יהיה delete permanently, אז אפשר לכתוב גם את זה. עכשיו, מה הרבה יותר טוב? שלא יהיה את כל הפופ-אפ הזה. כי כנראה שאנשים אין להם בעיה של ללחוץ רנדומלית על הכבר, ואם לחצו זה בסדר. ואנחנו צריכים לעשות משהו אחר. כלומר, התנהגות אנושית, שאת אמרת מקודם, זה נניח את הולכת להזמין פלאפל, את אומרת תשים לי חומוס, טחינה, חריף, כן? טוב, אתה יודע מה? לא. זה התנהגות אנושית. אני אומר כן ואחרי זה לא.

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

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

אביגיל: את בטוחה חריף? בטוח? בטוח?

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

ליאור: כל המצב האנושי הלא טבעי הזה.

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

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

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

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

ליאור: אז את אומרת זה גם עונה על העיקרון הראשון שנתנו.

אביגיל: כן.

ליאור: עוד דוגמאות בהקשר הזה?

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

ליאור: למשל?

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

ליאור: מבחינת היוזרים שמשתמשים בכלי.

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

[35:00] אז באמת מה שאנחנו מנסים לעשות זה כן תמיד להציג את כל האופציות, ולהראות אותן נגיד disabled, להראות אותן, שלא תוכל ללחוץ עליהן, ונסביר לך "היי, אין לך הרשאות לעשות את הדבר הזה." אבל לא נעלים לך דברים, אין פה קסמים שדברים קורים בצורה לא צפויה. וזה גם אחד הדברים שהכול אינטואיטיבי והכול consistent. אם יש לי אופציה להוסיף שורה אז היא תמיד תופיע במקום הזה. ואם אין לי הרשאות אני אדע שאני לא יכול לעשות את זה. 

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

אביגיל: בדיוק.

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

ליאור: הפוך, זה ההיפך, זה counterintuitive.

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

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

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

ליאור: שוב אתה אצל הפסיכולוג.

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

ליאור: אתה נכנס לאיזושהי רמת פרנויה מיותרת, כן.

רועי: זה חוסר ביטחון מסוים לגבי משהו שהוא-

ליאור: שהוא אמור להיות מאוד שקוף.

רועי: כן. שזה גם יוצר stress. [מוזיקה]. אז אנחנו בעיקרון מס' 3. שהוא אני חושב מאוד תופס אלינו, זה compounding effect. לנו יש, לא יודע אם מזל או פרס, אני לא יודע אם זה נכון לכל מערכת, אבל שיש פיצ'רים שהם מכפלה של פיצ'רים אחרים. שעושים פיצ'ר אחד מקבלים value x, עושים פיצ'ר מקבלים value y. שהוא כפול value x. אני אתן דוגמה, יש לנו את הבורד, שהוא דבר נהדר. טבלה עם כל הסטטוסים של כל דברים, ששם בעצם מתנהל כל המידע שלי וכל התהליכים. ועליו יש פילטר. שבעצם אני יכול לפלטר דברים. ואז הוספנו פיצ'ר חדש שנקרא views. שבעצם אפשר לראות את הבורד בצורות שונות. בצורות של גרף, בצורה של מפה, בצורה של כל דבר אחר. ופתאום, בגלל שיש את הפילטר על הבורד, הפילטר נהיה גם ל-views. אז יש לנו פתאום, כשהוספנו מפה היא נהייתה אחת המפות הכי powerful שיש, כי אני עושה פילטר וטק, אני רואה את המפה משתנה ואני רואה את כל הדברים לפי הדבר הזה וככה כל view אחר. 

ליאור: אז אותה פעולה של פילטרים שיכולת לעשות על הטבלה אתה גם יכול לעשות אותה על המפה.

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

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

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

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

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

[40:00]

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

רועי: יש מקומות שזה קשה.  

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

רועי: עוד משהו שהוא מאוד חשוב ב-compounding effect זה בעצם הגישה שלנו למוצר. שאני חושב שפירמלנו אותה ב-offsite האחרון בסוף השנה, שאנחנו עושים infra product packaging. בעצם אנחנו לוקחים את כל סט הבעיות שאנחנו לוקחים מיוזרים וממה שהם מנסים להסיק, הופכים, לוקחים אותם מאוד אחורה ומבינים איזו תשתית אנחנו יכולים לבנות שתאפשר לנו לבנות, החלק של ה-product זה הפיצ'רים או הבחירות הספציפיות לגבי התשתית הזאתי, ומעל זה אנחנו בונים packaging, כאילו הנגשה ליוזרים. אז החשיבה שלנו פה היא מאוד מאוד עמוקה לאיך לייצר תשתיות. וכל הנושא הזה של ה-compounding effect זה איזו תשתית היא מכפלה של איזו תשתית אחרת. נניח הוספנו את האוטומציות והאינטגרציות? אז האוטומציות הן כבר על הבורד, הן כבר בתוך הדשבורדז, הן כבר פתאום קיבלו כזאת משמעות אצל היוזרים, כי הם לא isolated אוטומציה שאני יכול לעשות דברים סתם ככה. היא פשוט, זה להפעיל אוטומטית את כל המערכת. אז כל חלק… אז בגלל שכל השאר הדברים בנויים כתשתית היה קל לחבר את התשתית הזאת לתוך הדבר הזה. והיה קל להפעיל את זה. עכשיו, אם כל אחד בונה מחדש את הכול isolated אז זה דברים שבסוף צריך לחבר אותם. נניח ה-my week, אני פתאום רוצה לעשות לו עכשיו אוטומציה, שיתזכר אותי על משהו, אז אם הוא לא נגיש לי בתור תשתית וברור, אז הוא גם לא ייכנס לתוך הפיצ'ר החדש הזה שמכינים.

ליאור: כבר יצרנו כאן עבודה כפולה ומורכבות.

רועי: אז הוא כבר, הוא באמת, משולשת ומרובעת וכל דבר יש לו roadmap משלו ודברים לא נתמכים פה ושם ו-

ליאור: וככל שעובר הזמן זה יהיה יותר גרוע.

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

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

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

אביגיל: יש לנו עכשיו באמת גם כמה טאסקפורסים שרצים במקביל, ופתאום מצאנו באמת כל-מיני נקודות השקה, של רגע, יש פה אזורים משותפים, מי עובד עליהם עכשיו? מה ה-vision של כולם ביחד? זה תמיד דורש מאיתנו להיות מסונכרנים ולעבוד כולנו ביחד על דברים. גם מבחינת התשתית וגם מבחינת ה-product וה-vision של פיצ'רים. [מוזיקה]. 

רועי: עיקרון מס' 4. Predictable ו-stress free. אז אני חושב שהרבה ממה שעשינו עד עכשיו, כאילו הנקודות שנגענו בהן עד עכשיו, הן מראות גם את הנושא הזה של predictable ו-stress free. אפשר לעבור על התתי-סעיפים של הדבר הזה ולראות כאילו איפה אנחנו נוגעים בזה.

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

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

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

אביגיל: בדיוק.

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

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

[45:00] ובאיזשהו שלב עלתה לי שאלה על shipping, והם כתבו לי מתחת לכפתור של השלב הבא you will be able to change your shipping details later. אוקיי? ישר הורידו לי את הלחץ-

אביגיל: וואו.

רועי: הסבירו לי את ה… עכשיו, זה פתרון בעצם לבעיה שהם כנראה יצרו [צוחק], מתוך התהליך, והם פתרו אותה ע"י עוד UI. הדרך הטובה יותר זה שאין את הבעיה הזאתי מראש. אבל עדיין זה פתרונות נהדרים לבוא ולפתור את זה. אז גם ב-pricing ראינו שזה מאוד משפיע. 30-day guarantee. כלומר כל הזמן לתת לאנשים יכולת להתחרט, יכולת להבין שהם לא מוחקים את כל מה שהם עשו. נניח אני יכול לתת דוגמה הכי גרוע שאני אי פעם ראיתי, ב-far לכל דבר אחר – ב-iTunes. אני רציתי להעתיק קובץ mp3 לטלפון שלי. אייפון, בזמנו. אז לא, אי אפשר, צריך לעשות synch מלא. עכשיו, לא עשיתי synch שנתיים, אני לא יודע עכשיו כאילו מה יקרה, איזה, מה יש, מה אין, מה המשמעות-

ליאור: מה המשמעות של ה-synch הזה.

רועי: כאילו בסדר, אפשר לעשות synch וכאילו שיסנכרן לי את כל ה, לא ידעתי את ה-iTunes, רציתי להעתיק אחד. אז היה שם כפתור, move to manual. נשמע הגיוני, נכון? אם אני אעתיק mp3 בודד הוא לא יעשה לי את ה-synch המלא וזה. אמרתי בסדר. לחצתי move to manual. מה הפופ-אפ היה? היה גאוני. Are you sure you want to move to manual? לא הוסיפו לי שום מידע, הפחידו אותי, וזה. [צוחקים]. אני זוכר בתחושה שלי זה היה יאללה, אני קופץ בנג'י עכשיו, קופץ מהגשר, לוחץ yes. אני הולך על זה. כאילו, הם אותתו לי שמשהו הולך לקרות, לא אמרו לי כלום, אבל כאילו זה. לחצתי yes, מחקו לי את כל המוזיקה מהטלפון. זה מה שקרה. פשוט מחקו לי הכול. Move to manual, אמרו אה, אתה לא רוצה את ה-synch שלנו, אין בעיה, נמחק לך את הכול.

ליאור: ולא היה undo.

רועי: לך תעשה manual.

ליאור: סוף סוף הבנתי למה רועי עבר לאנדרואיד. 

רועי: זה… [צוחק]. זה היה איפשהו בסט הציפיות שלי כשלחצתי על הכפתור הזה.

ליאור: והיה לך undo?

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

ליאור: והם התריעו מבחינתם, אתה יודע, היה לך are you sure. מכוסים.

רועי: אני לא יודע, כן? iTunes יש כאילו, רשימת הזוועות שיש בתוכנה הזאת היא ענקית. [צוחק]. אז גם, הם עברו פה בערך על כל החוקים, כן? זה לא מסביר את עצמו, זה לא predictable, זה לא Make me choose, לא regret, לא כלום, אבל-

ליאור: היית stressful לגמרי.

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

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

רועי: כש-

ליאור: אפילו דוגמה.

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

ליאור: לא, זה מעניין, אז אתה אומר שבכלל לא צריכה להיות-

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

ליאור: במוצר טוב לא אמורה להיות-

רועי: כן. כאילו, אם שמים קו וכותבים or, בסדר? יש הרבה פעמים or. אף אחד לא רואה את ה-or הזה. בסדר? גם אמרנו לעשות execution טוב על הנקודה הזאת זו בחירה, זה משהו שמאוד מאוד קשה לעשות עליו execution, כן? אני יכול, אפשר גם לעשות את זה בשלבים. נניח, ראיתי בהרבה מקומות שרוצים לעשות cancel ל-account, כן? אז הוא שואל אותך מה את רוצה, איך את רוצה לעשות cancel – freeze או זה או זה? עדיף להפוך את זה לסדרה של שאלות. אתה רוצה להקפיא את החשבון? לא. אתה רוצה לעשות זה? לא. כלומר, להפריד את ה-flow שהוא לא יהיה "אתה רוצה את זה או את זה או את זה או את זה." אז יש הרבה דרכים לבוא ולפתור את הבעיות האלה של לא לייצר את ה-UI הזה שהוא "או זה או זה". 

[50:00]

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

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

אביגיל: נכון.

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

אביגיל: נכון, ממש עשינו A/B test כזה, לקחנו את אותו dialog-

ליאור: רק לא ואלידי.

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

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

ליאור: מה אנחנו רוצים מהיוזרים שלנו, כן.

רועי: כן. [מוזיקה]. עיקרון מס' 5. Gradual complexity discovery. אני חושב שפה זה עיקרון שנכון להמון דברים, בסדר? אם ניקח אפילו consumer product כמו טלפון סלולארי. בהתחלה אני רוצה שהוא יהיה טלפון, אני רוצה שהוא יהיה, תחשבו על מישהו שלא יודע מה זה סמארטפון, איך הוא נחשף לכל העולם הזה. 

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

רועי: אני עצרתי שם.

ליאור: של זמן.

רועי: איזה עוד complexity יש לו?

ליאור: מה קרה לך? אחר-כך אתה מתחיל, אנשים או- [צוחקת]. 

רועי: אני כנראה מתחיל.

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

רועי: כן.

ליאור: לתכנן נסיעה.

רועי: אז נניח אם היית פותחת אותו והוא אומר לך "מה אתה רוצה לעשות? לנסוע עכשיו או לתכנן נסיעה או-"

ליאור: מתי את רוצה לנסוע, כן. 

אביגיל: או לדווח על מחסום או משהו.

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

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

ליאור: ואז אתה לא יודע איפה למצוא את מה שאתה מחפש.

רועי: כן.

ליאור: שעות פותח תפריטים ולא מוצא אותם.

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

ליאור: כן, זו שאלה מהסוג הקל ביותר.

רועי: זה כאילו הכול חיובי פה. לא, זה זוועה. אם עזרת למישהו כל-כך ע"י זה שהוא, הסברת לו משהו על ה-UI, it's wrong. [צוחק]. כאילו, וזה אולי אחד העקרונות שהכי בא לידי ביטוי ותמיד הולך לפח. כי לשבת ולארגן מחדש את ה-UI ולארגן מחדש את ההיררכיה ולהבין מה זה gradual exposure, ככל שמוסיפים דברים ויכולות צריך לעשות מחדש. נניח עכשיו אנחנו לוקחים את כל ה-UI, עושים עליו יישור קו, רק כדי להתמודד עם הנושא הזה של כל ה-complexity הזה שיצרנו, איך עושים אותו בהיררכיה יותר בריאה. ויש עוד כמה טיפים, אבל בוא נדבר על כמה דוגמאות.

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

ליאור: הפרק של איילה.

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

רועי: והדוגמה הזאת בעצם היא חלק מעוד מורכבות של ה-gradual exposure. נניח אנחנו נרצה שבן אדם נכנס, הוא מקבל template. אומרים לו רגע, מה אתה רוצה? אתה נניח מנהל orders עם לקוחות, הנה mini CRM. אז בום, הוא נכנס ל-CRM, הוא בכלל לא יודע שיש עמודות ושהוא יכול להוסיף אותן. בסדר? אחרי שבועיים נרצה שהוא יגיד רגע, אבל אני רוצה לשנות את התהליך, ואז הוא יגלה בכלל שהוא יכול להוסיף עמודות, כן? כדאי שזה יהיה אחרי 5 דקות, אבל נניח שזה אחרי שבועיים.

[55:00] ואז הוא נכנס לתפריט של הלהוסיף עמודות, מתלהב, אני יכול להוסיף עמודות. אז שם הוא רואה מעט עמודות, ואז הוא יכול להיכנס ל-store ולראות עוד המון עמודות. בסדר? וגם בתוך העמודות, אנחנו נרצה גם שם לעשות, בתוך ה-store, להראות את האלה למעלה. אבל נניח יש לנו formula column. אז ב-formula column אנחנו גם נרצה להגיד טוב בסדר, מה אני אעשה עם formula column? נשמע מורכב, יש פה מיליון אופציות. אז גם שם רוצים gradual exposure. נניח לעשות לו setup בסיסי לכל-מיני פריסטים שהוא יכול לבחור אותם, ואז הוא יכול להיכנס גם לנוסחה עצמה ולערוך אותה. אז כלומר, כל הזמן שמישהו יקבל משהו שהוא baked, עם הסברים, שהם פשוטים, אבל שהוא יוכל לעשות drill down לבפנים ולשנות אותם. בסוף התשתית שלנו יש לבנות את המוצר והתשתית שליוזרים יש לבנות את המוצר, אנחנו רוצים שהיא תהיה אחידה. אבל ארוזה כל פעם באריזות בצורה היררכית, שכל מי שנמצא בפני איזושהי החלטה כמו מה אני רוצה לנהל או איך אני רוצה לשנות את הבורד או כל דבר אחר, תמיד יהיה לו אפשרויות פשוטות שמסבירות לו לאן זה יכול ללכת. כלומר, זו גם דרך נהדרת לא לקרוא help אלא פשוט שהמוצר יסביר את הדברים האלה ע"י דוגמאות שאפשר לשנות אותן אחרי. דיפולטים, טמפלטים, איך שלא קוראים לזה. 

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

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

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

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

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

ליאור: הכי מוחבא שהצלחת.

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

ליאור: קטן ושולי, אלא מרכזי.

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

ליאור: נכון.

רועי: הכפתור הזה, לא צריך-

ליאור: אני אחפש אותו כמה שצריך.

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

ליאור: נכון.

רועי: לעומת פיצ'רים אחרים שהם יותר advanced שהם יכולים לקבור אותם במקומות אחרים.

ליאור: והם עושים את זה.

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

ליאור: באיזה שלב.

רועי: ובאיזה שלב.

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

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

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

ליאור: כדי שתעבור את כל התהליך.

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

אביגיל: מדהים.

רועי: עכשיו-

ליאור: אבל היה לי intent ללכת את ההליכה הזאת מלכתחילה כי אני בדרך לחלב מבחינתי.

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

אביגיל: גם חדרי מדידות אגב. בסוף. לדעתי.

ליאור: נכון. חלב וחדרי מדידות.

אביגיל: [צוחקת].

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

ליאור: מה הכוונה?

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

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

אביגיל: נכון.

ליאור: תמיד השלב הראשון יהיה לך סופר-קל ואתה תבין אותו ממש מהר.

רועי: ויש להם יתרון אחד, שזה gamification. במשחקים הוא מאוד game בתוך הסיפור.

ליאור: כן, הוא legit. כן, נכון.

רועי: לא, הוא, זה כאילו אני צוחק. זה זה, זה משחק.

ליאור: נכון.

רועי: אז אני מוכן להקשיב להם 5 דקות. אין את זה אצלנו, לנו אף אחד לא מוכן להקשיב לנו 5 דקות. הם רוצים שזה יעבוד משנייה 0 ולא מוכנים ללמוד כלום. אז ה-gradual exposure צריך להיות כזה שאנשים מוכנים אליו. והם לא מוכנים אליו באפליקציות. וניסינו את כל ה… אני לא יודע כמה פעמים ניסינו לעשות את זה הדרגתי, שלבי. אנשים לא מוכנים ללכת לפי השלבים שאנחנו הגדרנו, של ה-exposure שלהם. הם רוצים בדרך שלהם. אז כאילו זה צריך להיות sandbox, אם משווים את זה למשחקים, שכל אחד יכול לעשות כל מה שהוא רוצה תמיד. ואיכשהו כולם הולכים באותו מסלול ולומדים את הדברים האלה. או במסלולים שונים אבל מגיעים לאותו מקום. וזה קשה. זה קשה פי אלף, כי כל הפרדיגמות שעובדות במשחקים לא עובדות באפליקציות מהסוג הזה. אבל עדיין החוויות הכי כיפיות הן במשחקים. [מוזיקה]. עיקרון מס' 6. Meaningful copy. 

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

אביגיל: אז היה לנו איזשהו, גם איזשהו dialog במערכת, שרצית לעשות איזושהי פעולה-

ליאור: מה זה dialog? את אומרת כל הפרק dialog כאילו-

אביגיל: איזשהו פופ-אפ, איזשהו פופ-אפ במערכת, שרצית לעשות איזושהי פעולה. וגם בעולמות האזהרות, אולי אל תעשה את זה, והכותרת של הפופ-אפ הזה הייתה Hello there you little rebel. של "אוי, רצית לעשות פה איזה משהו נועז, איזה משהו…" זה אפילו מין טקסט משחקי כזה של מה, מה rebel, מה אתם רוצים מחיי? עשיתי איזושהי פעולה, תנו לי לעשות אותה או אל תיתנו לי לעשות אותה.

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

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

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

רועי: לא ברור, כן?

ליאור: וגם מה הטקסט הזה אומר לי באמת? זה באמת לא meaningful copy.

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

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

[65:00]

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

ליאור: גם תלוי את מי זה מצחיק, אתה יודע. אם עכשיו אני Head of RND ב-HP, זה לא כזה מצחיק אותי כאילו-

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

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

ליאור: כן, יש שם התחכמות כזאת.

רועי: copy זה דבר כזה. עכשיו, אני יכול לתת גם סיטואציות שזה לא רק ה-copy עצמו אלא גם מתי עושים אותו. נניח, לא יעזור מה הם יעשו בשום סיטואציה שאני ב-Get taxi או ב-Waze פותח אותם, אני לא רוצה לשמוע על שום דבר אחר, תנו לי כאילו להזמין מונית. זה לא הזמן שלי ללמוד על משהו אחר שאתם רוצים לקדם. בסדר? כי אני בלחץ, אני תמיד, אני רוצה להזמין מונית אז אני רוצה להזמין אותה, אני לא רוצה משהו אחר. עכשיו, ולעומת זאת נניח ב-progress bar שדברים נטענים, זה הזדמנות טובה להיות אולי מצחיקים כי אני לא עושה כלום. כל עוד הם מבינים את זה. אני חושב שגם אצלנו יש שם כל-מיני הודעות שבקונטקסט מסוים אני חושב שזה קשור להודעה שלי וזה פשוט אנחנו מריצים שם טקסטים כאילו-

אביגיל: כן, בטעינה.

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

רועי: אני יכול להביא גם דוגמה למצחיקות שאולי הייתה נחמדה, זה שיש לנו באימיילים טיפים למטה לפיצ'רים שיש, אז היה You can duplicate pulses. You can duplicate pulses. [צוחקים]. כתוב ככה. אז זה נניח עובד, זה משרת את המטרה וכאלה. 

ליאור: אבל זה מעצים את המסר.

רועי: כן.

אביגיל: אז הייתה לנו גם דוגמה, דוגמה קשה. כשיש איזה מסך שנותנים לאנשים להעלות תמונת פרופיל. ויש שם איזה טקסט נחמד, שגם מתחלף כל פעם איזשהו טקסט אחר, "איזו תמונה יפה", או "יש לך good hair day", כל-מיני דברים כאלה. עכשיו, מישהו העלה תמונה לרשתות החברתיות, של אדם שהוא קירח, עם הכיתוב "oh, what a great hair day". וכזה "מה, מה אתם צוחקים עליי, מה אתם רוצים ממני? מה פתאום?"

ליאור: וואו.

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

רועי: והנושא של המצחיק זה נקודה אחת קטנה. נניח אני אתן סיטואציה אחרת שהיא פשוט לא טובה מכל הכיוונים לאמפתיה, ללהבין את הבן אדם. עשינו פיצ'ר נוסף של churn. אם מישהו רוצה לעזוב את ה-account אנחנו מציעים לו תעשה freeze ל-account. תעצור אותו. ואז אמרנו The account is frozen. בסדר, פעולה נהדרת, הסברנו גם מה זה אומר, מישהו עשה freeze. עכשיו מישהו בא וחוזר ועושה unfreeze, כן? אז הפופ-אפ הזה היה Your account is frozen, unfreeze. זה כאילו ה-UI היה שם, כן? כאילו, חזרתי ארבעה חודשים אחרי זה, אני עושה unfreeze, מה המשמעות של זה? כאילו, המשמעות של זה הייתה לפעמים לחייב לו את הכרטיס אשראי, אבל זה לא אמרנו. במקום זה, אחרי שהוא לחץ על ה-unfreeze גם לא אמרנו לו, אמרנו לו Yeah, you unfrozen the account, אנחנו כל-כך שמחים שעשית unfreeze ושאתה חוזר להשתמש בנו, אנחנו מאוד שמחים. למי איכפת? מה זה אומר הדבר הזה? דבר ראשון מה זה freeze? זה מילה שלנו, כן? ומה זה unfreeze? זה אומר שאני מה, אני אמשיך ל… היה לך ככה ב-account, עכשיו יש לך ככה, אז נשאר לך ככה חודשים לככה יוזרים, זה מה שתעשה. המון טקסט שצריך להסביר פה מה קורה. אם תלחץ על זה אנחנו נחייב אותך אוטומטית בסוף הזמן של ה-Unfreeze. וכל-מיני השלכות כאלה כאילו. ולשלוח לו, לאשר לו לפני שהוא לוחץ על הכפתור מה זה המשמעות של זה, כי יש פה גם משמעות פיננסית. ואחרי שהוא לחץ עליה לאשר לו שוב מחדש שזה מה שהולך לקרות. לא עשינו שום דבר מהדברים האלה, רק כתבנו שם, הכול להשתמש באותה מילה שנקראת freeze, בסדר? שלא הסברנו אותה פעם אחת.

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

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

ליאור: לא, אבל לכן אני אומרת, ה-do good אומר בוא נהיה אמפתיים לאנשים. 

אביגיל: בוא נזהיר אותם אם אנחנו עומדים לחייב אותם.

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

ליאור: ופוגעים באדם קירח שאיחלנו לו good hair day.

אביגיל: באמת.

[70:00]

רועי: נכון. וכאלה דברים. ועושים לזה backlog, בעצם רשימה של דברים, ומורידים אותם. כי זה עוד value של החברה של לעשות טוב ליוזרים, אנחנו מאוד מאמינים בזה. גם אם זה בא על חשבון מה שנקרא בצורה אפילו מובהקת, revenue, שנעשה ב-short term. ב-long term זה ברור לנו בגלל שזה value שזה יותר טוב וזה ירים אותנו יותר למעלה. ועשינו הרבה דברים מהסוג הזה. אני חושב שעכשיו אנחנו מחליפים pricing structure גם כחלק מהדבר הזה, שזה יצר friction מאוד גדול בחוסר בהירות שלו.

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

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

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

ליאור: ולעצור ו-

רועי: ולבחון ולעצור ולעשות את זה.

ליאור: ולהיות ביקורתי בנקודת-

רועי: ואני חושב שאנחנו עושים את זה הרבה וצריכים לעשות את זה יותר. [מוזיקה]. נקודה אחרונה, מס' 7, lists. עכשיו, lists זה-

ליאור: רשימות בעברית.

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

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

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

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

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

ליאור: נגיד.

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

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

רועי: הלוואי. 

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

רועי: אז תשמרי print screen כאילו שם בתוך הזה. עכשיו, רשימות זה גם מאוד חזק, בסדר? מה הצד החיובי ברשימה? ואנחנו מאוד מאמינים בהקשר הזה ב-WI ולשים, גם לפזר את הפיצ'רים במקום, בקונטקסט שלהם בתוך ה-UI, אבל גם לעשות רשימה שמאפשרת את זה במקביל. למה? כי כשהפיצ'רים מפוזרים אני צריך כאילו discovery, אני צריך ללכת וללחוץ על כל הכפתורים – אף אחד לא עושה את זה. כאילו, ללכת ללחוץ על כפתורים ולראות מה הם עושים. לעומת זאת ברשימה אני יכול לעבור ולראות רגע, האובייקט הזה, זה האופציות שיש לי. וזה מאוד חזק, זה discovery מאוד חזק, זה משהו שמישהו הולך לאיבוד הוא הולך ישר לרשימה.

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

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

[75:00]

ליאור: עוד סיבה שעברת לאנדרואיד.

רועי: PayPal.

ליאור: אה לא, סבבה.

רועי: PayPal, אני באתי לראות איזה, לשנות איזה משהו בפרופיל שלי. יש איזה אייקון שהיה שם, profiles או settings או משהו כזה. ואני עומד מעל התפריט, ואני מנסה לראות כאילו את האופציה הזאת שם, והיא לא נמצאת בתוך התפריט הזה. ואז אני, כאילו, הולך לגוגל, ואומרים זה נמצא בתוך התפריט הזה. ואני נכנס ואני לא מבין. והיה איזה סרט ביוטיוב שהסביר את זה, כן? והסתכלתי, והם עשו משהו מדהים. וזה, את האמת זה מפר עוד עיקרון, לא רק של הרשימות. הם עשו משהו ש, נכון יש את הכותרת של התפריט שפותחת את התפריט? הוא היה לחיץ. אני עושה … [01:15:52] נפתח התפריט, ואז הייתי יכול ללחוץ עליו ולהיכנס לבפנים. בסדר? זה בעצם היה להם עוד אופציה בתוך הרשימה הזאת שמראה more, אבל היא לא הופיעה למטה בתור more, היא, השם שלה זה, חסכו ב-UI, עשו אותו יותר מינימלי. לא יכולתי להבין את זה, זה היה גם נראה לי לא הגיוני כשהוא עשה את זה. עשיתי סטופ ופליי וחזרתי אחורה, ולראות כאילו בדיוק איך נכנסים לדבר הזה. ושם נפתח עולם שלם של עוד מיליון אופציות, וואוו, כאילו. זה גם עוד עיקרון שלא נגענו בו, של, בחלק מהמקומות קראו לזה brain friction, זה בספר the inmates are running the asylum, זה חתיכת UI שיש לה פונקציה שונה בסיטואציות שונות. בסדר?

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

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

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

רועי: יש עוד אחד שאני חייב, זו דוגמה אדירה לנקודה הזאת. בסדר? אז רשימות זה דבר חזק וצריך לדעת להשתמש בו ולשים אותו במקומות הנכונים, ולא לנסות להבליט דברים. לא להבליט דברים זה אומר להבליט אותם, כי אנשים עוברים על הכול. יש עוד איזו דוגמה נהדרת ל-UI שהוא לא טוב, זה שיש לאותה חתיכת UI משמעות כפולה בסיטואציות שונות. כלומר, עשיתי סוויץ' למשהו, ועכשיו ה-UI, אותו כפתור יש לו משמעות אחרת. זה אחד הדברים הכי נוראיים, בספר The inmates are running the asylum, הוא ספר נהדר וקשה לקריאה כי הוא יורד בגדול על אנג'ינירים הוא יורד, כי הם תמיד עושים את הטעויות האלה. אבל יש לי דוגמה נהדרת לדבר הזה. 

ליאור: אתה מתכוון נוראית.

רועי: מה?

ליאור: נוראית אתה מתכוון. לא נהדרת.

רועי: במקרה הזה אני היחידי שידעתי, אז זה היה… אז אני כאילו-

ליאור: יאללה, נו, ספר לנו.

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

ליאור: נשמע כמו-

רועי: כולם הלכו בלי מים חמים.

ליאור: חידה ב-escape room הדבר הזה [צוחקת].

רועי: כן, אבל הם חסכו כפתור. של lock של המים החמים. כלומר, הם היו יכולים לשים כפתור אדום-

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

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

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

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

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

רועי: בדיוק. אז זה לא שכאילו מישהו בא-

ליאור: וה-aha moment בצד השני.

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

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

רועי: או לא להעלות אותו מראש. 

אביגיל: עוד יותר טוב.

[80:00]

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

אביגיל: רגרסיה. 

ליאור: במקום לפתח דברים קדימה?

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

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

אביגיל: נכון. 

ליאור: אז מה עושים עכשיו?

אביגיל: עכשיו, זה לא באג. זאת אומרת, זה לא שאנשים מתלוננים ועכשיו הם לא יכולים לעבוד. רוב הדברים האלה זה דברים שהם, שפשוט הם לא נכונים אבל זה לא שמשהו שבור. ואנחנו כאן נדרשים לתעדף אותם. אז יש לנו בעצם פורום בחברה שנקרא ה-cheese, ה-cheese gang. יש לנו נציגים של פיתוח, של product, של Customer Success ושל Sales, ואנחנו מתעדפים ביחד את הדברים האלה. אנשים מעלים לנו מכל החברה ומלקוחות כל-מיני דברים קטנים כאלה שהם לא בדיוק פיצ'ר, הם לא בדיוק באג, הם כל-מיני דברים כאלה שהיו יכולים להיות טוב יותר. ואנחנו מנסים לתעדף אותם, לתמחר אותם, כמה זמן ייקח לעשות אותם, מה הדחיפות של לעשות אותם. ובכל איטרציה, אנחנו עובדים באיטרציות של שבועיים, לנסות להכניס גם כמה כאלה לתמהיל של טסקפורסים ובאגים ותשתיות.   

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

אביגיל: נכון. אז זה גם עניין של-

ליאור: וזיהית את זה. כי את מודעת לעקרונות האלה ופתאום הם מול העיניים שלך.

אביגיל: נכון.

ליאור: מה תעשי אז?

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

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

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

ליאור: ועוד שאלה. איך לוקחים את הדבר הזה והופכים אותו למשהו שלוקחים בחשבון תוך-כדי פיתוח של משהו חדש?

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

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

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

ליאור: גם השפה-

רועי: וזה התעסקות עם הטוב.

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

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

ליאור: אביגיל, תודה רבה שהצטרפת אלינו היום.

אביגיל: תודה.

ליאור: תודה רועי.

רועי: תודה ליאור.

ליאור: תודה שהאזנתם. [מוזיקה.