הקמת Design System בארגון – ההיבט הניהולי

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

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

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

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

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

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

בואו נראה איך זה עובד. 

בחירת הפרוייקט

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

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

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

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

בחירת מודל העבודה

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

יש לכך שלוש שיטות טובות שנבדלות זו מזו באופי ובתרבות של הארגון שלכם, אבל בכדי להסביר אותן, אני צריך להסביר לכם קודם מהי השיטה השגויה – זאת שככל הנראה שקלתם ליישם, אבל רוב הסיכויים שהיא לא מתאימה לארגון שלכם. השיטה הזאת מתאפיינת בדבר אחד משמעותי – היא לא מתבססת על פרוייקט מסוים בארגון. כלומר, היא "מרחפת" מעל הקיים בארגון באותה נקודה בזמן ובונה את הדיזיין סיסטם במנותק מהמערכות הקיימות. Material Design של Google ו- Carbon של IBM הן כאלו. מטרתן של דיזיין סיסטמס כאלו היא פחות לשרת את הארגון עצמו, ויותר להגדיר, שלא לומר להנחית, את הכללים לשאר השוק. אלמלא אתם ארגון בסדר גודל שכזה, הרשו לי להניח שהשיטה הזאת אינה מתאימה לכם. במקום זאת, אתם זקוקים לשיטה שבה הדיזיין סיסטם צומחת מתוך הפרוייקטים הקיימים בארגון. זה אומר שצוות הדיזיין סיסטם עובד בצמוד לפרוייקטים הנבחרים (כאמור, רצוי לא יותר משלוש), מחלץ החוצה את דפוסי האפיון והעיצוב, ומתעד אותם באופן גנרי על מנת להנגיש אותם לפרוייקטים נוספים ועתידיים לשימוש הכלל.

שלוש השיטות נבדלות זו מזו במודל העבודה של צוות ההקמה: 

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

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

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

1. האם תהיו מוכנים לשקול התפשרות על היקף הגרסה הראשונה של הדיזיין סיסטם שלכם?
2. עד כמה חשוב לכם כבר בגרסה הראשונה של הדיזיין סיסטם שלכם למקסם את העקביות עם פרוייקטים עתידיים?
3. באיזו מידה חשוב לכם שהדיזיין סיסטם תושק בהקדם האפשרי?
4. באיזו מידה את יכולים לקבל השפעה אפשרית של מאמץ הקמת הדיזיין סיסטם על לוחות הזמנים של הפרוייקטים?

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

 5. האם יש לכם אתגרי כוח אדם של אנשי UX?

בסופו של דבר זה נראה ככה: 

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

לקפוץ על הסוס הנכון

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

בהצלחה!