145: על תהליך עיצוב המוצר שלנו

דריה: הי כולם, אני דריה וורטהיים ואתם הגעתם ל- Startup for Startup. היי דניאל.

דניאל: היי דריה.

דריה: כשאנחנו ניגשים לעבודה על מוצר או פיצ’ר חדש ב-Monday, אנחנו עובדים בצוותים שכוללים שלוש זרועות. פיתוח, מוצר ועיצוב. בפרקים 120 ו-121 בעצם דיברנו על תהליך של בניית פיצ’ר מהצד של הפרודקט ושל RND, והיום דניאל וורטמן שהיא Product Designer כאן ב-Monday, נכון?

דניאל: נכון.

דריה: אז את הולכת לדבר על הצד של העיצוב בכל התהליך הזה, ואיך בכלל בנינו את התהליך הזה.

דניאל: נכון.

דריה: מעולה. אנחנו נדבר על כל התהליך הזה מהזווית העיצובית וממש נסביר נראה איך נראה תהליך עיצוב מוצר מ-א’ ועד ת’.

[מוזיקת מעבר]

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

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

דריה: כן, זה גורם לזה להישמע קטן.

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

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

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

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

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

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

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

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

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

דריה: מה הכוונה?

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

דריה: כי המפתחים בעצם לא היו חלק מהמחקר המקדים הזה – 

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

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

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

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

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

דריה: אז איך פותרים את זה?

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

[מוזיקת מעבר]

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

דניאל: נכון.

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

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

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

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

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

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

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

דניאל: נכון.

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

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

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

דניאל: כן.

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

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

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

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

דריה: ואת האימפקט גם.

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

דריה: גם לך וגם לשאר הצוות.

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

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

דניאל: נכון.

דריה: אז בואי נעבור לשלב השני, שדיברנו עליו הרבה בפרק 120, אז אנחנו נרוץ עליו, ושלב שני זה Shaping, נכון?

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

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

דניאל: נכון.

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

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

דריה: יש איזה שהם Pitfalls באיזור הזה?

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

דריה: יש לך איזה דוגמא לשלב הזה?

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

דריה: כי מה, כי זה היה מורכב מדי פיתוחית?

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

[מוזיקת מעבר]

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

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

דריה: לגמרי.

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

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

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

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

דניאל: כן. אז אנחנו, בשלב הזה של ה – Design יש כמה Steps שאנחנו בתור מעצבים צריכים לעבור. יש חמישה Steps, הגדרנו כרגע חמישה Steps. זה כמובן כל ה – Steps האלה נתונים לשינוי בהתאם לגודל המוצר, לגודל החברה, לגודל הצוות, זה הכל תלוי בעיה ופתרון שאנחנו רוצים לתת, אז השלב הראשון של העיצוב ה – Flow, שזה ה – Design Craft שלנו. השלב השני, נקבל פידבק מהצוות, פרוטוטייפ, וואלידציה מיוזרים ו – Pixel Perfect Design. Design Raft היא השלב הראשון בתהליך העיצוב. בהתחלה אנחנו כמובן נרצה להבין את הזרימה העיקרית, איך משתמש מגיע מנקודה A לנקודה B, כולל כל השלבים שהוא עובר בדרך, וה – Flow הזה מגיע אחרי שיצאנו מה – Shaping עם שתיים שלוש רעיונות. אנחנו מתחילים לבנות את ה- Flow. השלב שאנחנו חושבים על כל המקרים כמו שאמרתי. First State, Empty State, הודעות שגיאה, Use Cases שונים.

דריה: מה זה First Stat ו – Empty State?

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

דריה: אין תוצאות בחיפוש.

דניאל: אין תוצאות בחיפוש. אז מה זה ה – Empty State שלו.

דריה: עכשיו, על כל מקרה כזה, על כל פיצ’ר כזה יש מעצבת אחת? יש מעצב או מעצבת אחת?

דניאל: כן. בעצם התרבות שלנו פה ב – Monday, איך שאנחנו עובדים, זה אנחנו באמת עובדים בגישה של Task Forces, שבעצם כל task Force כזה מורכב ממעצב, מספר מפתחים, ומנהל מוצר. לפעמים יש גם אנליסט, זה תלוי בגודל האיזור ובגודל המוצר שאנחנו עובדים עליו, ואנחנו בתור מעצבים ממש מובילים את המוצר הזה.

דריה: ואז בעצם עיצבת את ה – Draft ואז את מתייעצת עם הצוות.

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

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

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

דריה: ומתייחס גם לפתרונות גם כאלה.

דניאל: בדיוק. וגם עוד אתגר שעולה לנו פה, זה שאנחנו, לא יודעת אם זה אתגר, או יותר משהו שאנחנו צריכים גם לשם לב עליו בתהליך העיצו זה Micro Copy. אנחנו כותבים את ה – Micro Copy בעצמנו, גם מהסיבה שאנחנו חיים את המוצר, אנחנו מבינים אותו, ואנחנו יודעים איך להנגיש אותו ליוזרים שלנו. כמובן שאנחנו עושים QA עם UX Writer או עם English Native.

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

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

דריה: זה בעצם הדרך שלנו לוודא שה – Copy מחובר מאד לנראות.

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

דריה: האמת שאני עד עכשיו לא ידעתי שזה התפקיד של המעצבים ב – Monday, וזה פשוט מזכיר לי כל מיני נקודות שבאמת נטע שעושה את העיצובים שלנו ב – Startup for Startup, היא הייתה עושה עיצובים והכפתורים באמת היו מגיעים כזה עם טקסטים, ו – 90% מהפעמים אני זוכרת שהסתכלתי על כפתור וחשבתי, “וואי זה ממש עובד”. כאילו הטקסט שהיא כתבה ממש עובד, אני לא מתכוונת לשנות את זה.

דניאל: נכון.

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

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

דריה: אחלה. אז בעצם השלב הבא זה לקבל פידבק.

דניאל: נכון. אז מעל כל השלבים האלה, משלב שהתחלתי לעצב עד השלב שהמוצר הזה פוגש משתמש, אנחנו שמים מעל את המושג Design Review. בעצם אנחנו נהיה בקשר רציף גם עם המפתחים וגם עם המנהלי מוצר בשביל לוודא שאנחנו באמת גם דוקרים את הבעיה וגם אנחנו נמצאים ב – Scope הטכני. אני לא אעצב עכשיו Flow שלם מ-א’ עד ת’ ואעשה אותו “מפונש” בלי שאף אחד מהצוות לא ראה אואתו. זאת אומרת, כבר משלב מאד מאד ראשוני שהתחלתי לעצב, אני אראה לצוות שלי, ל  – Stake holders, מי שרלוונטי, את העיצובים שלי, וגם בשביל לקבל אינפוטים, אם אני באמת עומדת ב-, אם אני באמת נגעתי בבעיה בעיצוב, ואם באמת אני, אם זה אפשרי טכנית.

דריה: זאת אומרת זה משהו שהוא באמת מתמשך.

דניאל: הוא פינג פונג, הוא תמיד תמיד קורה.

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

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

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

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

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

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

דריה: איך את עושה את זה?

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

דריה: קחו תשתמשו.

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

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

דניאל: נכון. אז זה דרך אחת. דרך שניה, שזה דרך שאנחנו מאד מאד אוהבים, שיש לנו את האופציה להעלות User Testing ו – Usability Hub ולראות איך בעצם משתמשים, גם אם זה משתמשים לא של Monday, איך אם חווים את המוצר, והיתרון בזה שזה נורא קל ומהיר. זאת אומרת, כבר בשלב מאד מאד מוקדם של התהליך, גם כשרק התחלתי את התהליך, זה לא חייב להיות עכשיו Flow שלם שאני בודקת, אני יכולה לבדוק ממש דברים קטנים, לראות שהם עובדים. לדוגמא, רצינו לבדוק Copy, אם הוא מספיק ברור למשתמשים שלנו.

דריה: אה אוקיי, אז אתם בודקים לא רק את העיצוב, אלא את ה – Copy עצמו.

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

דריה: ולעשות שינויים אם צריך.

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

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

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

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

דניאל: נכון, יורדים ממש ל – Pixel Perfect, מבינים ממש מה אנחנו רוצים לעשות שם, איך המפתח יכול להבין הכי טוב את ה – Flow, ומה קורה בכל שלב. אם דיברנו על וואלידציות, ודיברנו לפני זה על הוואלידציה שקיבלנו על ה – Flow המרכזי, על סטטוס, שקיבלנו אפס אחוז הצלחה מלשנות צבע. בשלב של ה – Design עיצבנו פתרון, העלינו את הפתרון הזה ל – Usability Hub, רצינו לבדוק אם הוא באמת מצליח לפתור את הבעיה, שיוזרים לא מצליחים לשנות צבע, והעלינו טסט עם אותה שאלה ששאלנו בטסט הקודם, וקיבלנו וואלידציה מדהימה ש-87% הצליחו לעשות את השינוי צבע.

דריה: וואו, עברתם מ-0% ל-87%.  

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

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

דניאל: בוא נגיד – 

דריה: אם הייתי מקבלת עכשיו תוצאות של 40% הצליחו להשתמש.

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

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

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

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

דניאל: נכון. אנחנו תמיד תמיד, קודם כל אצלנו אנחנו תמיד עובדים על לשפר דברים אצלנו במערכת, אבל באמת כאילו, גם אם קיבלנו וואלידציה בשלב העיצוב שהפתרון הזה פותר את הבעיה ב-90%, אחרי חודש פיתחנו את המוצר הזה וקיבלנו, הוצאנו DATA לראות אם ענינו באמת על כל ה – KPI’s שלנו וכל המה שרצינו להשיג, הבנו שזה לא. שזה לא, זה לא פותר ב-90%, זה פותר ב-40%.  

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

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

דריה: שהוא בכיוון הנכון.

דניאל: שהוא בכיוון הנכון, הוא עובד.

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

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

[מוזיקת מעבר]

דריה: אז בואי נעבור לשלב הבא, השלב הבא זה מיני Kick off ותכנון טכני.

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

דריה: תמיד יכולות להיות הפתעות.

דניאל: תמיד יכולות, אנחנו כאילו לא, אנחנו דינמים.

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

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

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

דניאל: יש לחץ. לחץ כאילו הוא – 

דריה: כי הם כבר בפיתוח.

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

דריה: אז כדי לסגור את השלב של המיני Kick off, מה אמור לקרות בו? איך אנחנו אמורים לצאת ממנו?

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

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

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

[מוזיקת מעבר]

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

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

דריה: איך יוצאים מהשלב הזה?

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

דריה: מה קורה אחרי שהפיצ’ר משוחרר?

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

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

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

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

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

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

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

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

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

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

דניאל: נכון.

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

דניאל: תודה לכם.

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

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

דריה: תודה שהאזנתם. ביי.

[מוזיקת סיום]

 

הניוזלטר שלנו

הירשמו וקבלו עדכונים על פרקים חדשים, כתבות, אירועים ועוד הפתעות!

רוצים לקחת חלק בשיתוף ידע?

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