צאו מחשיבה של Single Designer ותתחילו לחשוב כמו צוות (גם אם אתם לגמרי לבד)

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

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

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

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

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

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

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

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

בעיה נוספת שהקשתה על התקשורת בצוות היתה שכל אחד מהמעצבים עבד על תוכנה אחרת. בהחלטה גורפת עברנו כולנו יחד לתוכנת Figma וזה שינה את התמונה לגמרי, באופן חד משמעי. נוצר שיתוף פעולה כל כך חזק, עד שאפילו עבדנו יחד כמה מעצבים על אותו מסך בו זמנית. ברגע שעברנו ל-Figma לא הסתכלנו לאחור, כל המסכים שבנינו לפני זה בתוכנות אחרות כמו Sketch, Illustrator או XD לא עברו איתנו וב-Figma נולדו רק מסכים חדשים עם חיבור חזק ל-Design System. בכך, נוצר מקום אחד שהוא ה-"one source of truth" וכל הפרוייקטים היו מקושרים אליו וניזונו ממנו. 

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

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

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

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

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

כיום העבודה בצוות הדיזיין ב-SparkBeyond עובדת בצורה חלקה (רוב הזמן…) ובזכות כל הדברים שהזכרתי כאן, ועוד רבים אחרים, שעל כל אחד מהם אפשר לכתוב עוד מאמר שלם:

  • בצד הטכני:
    • מבנה קבצים קבוע
    • הוספת תיעוד ללוגיקה
    • קישור חזק בין Jira ו-Figma לניהול משימות
    • סטנדרטים גבוהים ב-handoff לפיתוח
    • יישור קו בין הדיזיין סיסטם ל-UIcommons
    • יצירת מאגר מסכים לתחילת עבודה של ה-UX וה-UI
  • בצד הבין-אישי:
    • יצירת ערבות הדדית
    • פידבק פנימי בין המעצבים
    • גיבוי אחד של השני 
    • קבלת החלטות משותפות
    • קשר אישי חזק

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

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

יש לי עוד הרבה טיפים לחלוק איתכם

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

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