עבודה על דיזיין סיסטם באה עם אחריות. כל תוספת, שינוי או מחיקה של אלמנט מסויים שנעשה כנראה תשפיע על הרבה מאוד אנשים בתוך שלוקחים חלק בבניית מוצר - מעצבי מוצר, מעצבי מרקטינג, מפתחי פרונט אנד, כותבי תוכן ומנהלי מוצר - תלוי בהיקף התפקיד של הדיזיין סיסטם באירגון שלנו.
כנמלים חרוצות אנחנו עמלים קשה כדי להבטיח שהרכיבים בתוך הדיזיין סיסטם שלנו הם שמישים, נגישים, עברו טסטים, כתובים היטב בקוד ובנויים היטב בפיגמה ויש הנחיות ברורות איך משתמשים בהם. אך לעיתים, מתרחשת התנגשות או אי התאמה בין מה שקיים במערכת לבין דברים שנוצרים ומפותחים.
בוא ננסה להבין את זה קצת יותר לעומק.
מה מוגדר כהפרת שימוש?
הפרת שימוש היא יישום יכולת או ניראות שאינה קיימת ברכיב המקורי בדיזיין סיסטם שלנו. בואו נמנה מספר דוגמאות:
- שינוי באטום עיצובי - אטום מתייחס ל״חומרי הגלם״ כגון צבעים, פונטים, צל, פינות מעוגלות ורווחים
- שימוש בקומפוננטה שלא למטרה המיועדת לה - לדוגמא, שימוש בדיאלוג/מודאל כדי להציג הודעת ואלידציה
- יצירת רכיב חדש שדומה לרכיב שכבר קיים
- ״דריסה״ של רכיב באמצעות
styleאוclassNameמותאם אישית
למה זה בעצם קורה?
בואו נמנה את הסיבות העיקריות:
- רכיב בתוך הדיזיין סיסטם קיים, אבל לא עומד בכל הדרישות
- רכיב בתוך הדיזיין סיסטם לא קיים
- שימוש חד-פעמי - קומפוננטה שהיא ״פתית שלג״ ייחודי. מתישהו בעתיד אכתוב על זה בהרחבה.
למה זה בעייתי שיש לנו הפרות שימוש?
- העקביות נשברת - כשיש הפרת שימוש אנחנו מאבדים את היכולת שלנו להיות עקביים בשפת חווית המשתמש, שזה מהיתרונות הבולטים שיש לדיזיין סיסטם (והסיבה שאתם כנראה קוראים בבלוג שלי)
- ביזבוז זמן - פיתוח שמוגדר כהפרה (כלומר שלא מיועד לדיזיין סיסטם) למעשה אומר שצריך להשקיע זמן בפיתוח ובQA בעוד שניתן היה להשתמש במה שכבר קיים וזמין בדיזיין סיסטם.
- פוטנציאל לבאגים - הפרות שימוש לעיתים מיושמות באמצעות ״דריסות״ של קוד (או Overrides בפיגמה) וזה מציב אותנו בסיכון שהקומפוננטה לא תדע להתמודד עם עידכונים עתידיים.
זה אומר שכל דבר צריך לעבור דרך צוות הדיזיין סיסטם?
התשובה היא כמעט :)
לפעמים יש דברים שבאופן מכוון לא נרצה שייכנסו לדיזיין סיסטם. לדוגמא, מה נעשה כשצוות מסויים עובד על A/B/C/D Test? האם נכניס את כל הוריאציות לקומפוננטה? כמובן שזה לא הגיוני וכנראה שיהיה נכון לעבוד עם branching עד שנבין טוב יותר את תוצאות הטסט שלנו.
ומה לגבי צוות שעובד על פיטצ׳ר חדש, שבניגוד לA/B Test שהוא יותר ממוקד, מביא משהו חדש לגמרי למוצר? הצוות צריך לבנות פרוטוטייפ, לעשות איטרציות מהירות ולנסות דברים חדשים. זו יכולה להיות הזדמנות נהדרת לבחון דברים מחדש.
אז מה אפשר לעשות?
- חינוך והסברה - הבסיס לכל דיזיין סיסטם מוצלח הוא תקשורת ושיתוף פעולה בין כל מי שלוקח חלק בתהליכי הפיתוח. מרגישים שאנשים לא לגמרי מבינים את ההנחיות, או מכירים את הדיזיין סיסטם מספיק טוב? נסו לארגן סדנת דיזיין סיסטם שבה תסבירו מה זה דיזיין סיסטם, למה זה חשוב ותנו סקירה על הדיזיין סיסטם שלכם. דיזיין סיסטם זה תחום מענין, אתם תראו שהרבה יגלו עניין בהשתתפות בסדנה כזאת.
- הטמעת תהליכים מסודרים - נסו לאתר את הסיבות שבגללן הפרות מתרחשות. סיבות שחוזרות על עצמן אולי מעידות על מחסור בתהליך מסודר.
- חיבור טוב יותר בין פיתוח לעיצוב - מהניסיון שלי הרבה מעצבים מהססים לפני שהם פונים למפתחים. נסו לייצר חיבור טוב יותר בין המעצבים למפתחים. לדוגמא, ערוץ דיזיין סיסטם ב-Slack/Teams משותף למעצבים ולמפתחים יכול לחולל פלאים. הרבה הפרות יכולות להימנע בדרך הזאת.
מקווה שהפוסט נתן לכם השראה ורעיונות להתמודד עם אחת הבעיות הנפוצות בדיזיין סיסטם. במידה וכן, תוכלו לשתף אותו באירגון שלכם.