איך מגיעים לעיצובים מהממים גם בפיתוח

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

ואז מגיעים תוצרי הפיתוח.

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

מיד עולות בנו תחושות קשות, שלא לומר אלימות, כלפי חברינו וחברותינו מהפיתוח.
אנחנו הרי טלית שכולה תכלת (שנבחר בקפידה עם 70% אחוז opacity ו-20% blur). העיצוב שלנו היה מושלם, לא יכול להיות שיש לנו חלק במחזה המחריד שניצב מול עינינו הדומעות. זה בטוח באשמתם.

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

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

1. לשמור על אחידות

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

איך מיישמים בפועל?

• מייצרים כמה שיותר מוקדם Styles לטקסטים
• צריכים לשכפל משהו? קודם הופכים את הרכיב לקומפוננטה.
• מייצרים קומפוננטות גמישות, שמוגדרות נכון ומאפשרות שימוש חוזר במקרים שונים.
  ראו לדוגמא את הרשימה למטה. היא יכולה לשמש אותנו בארבעה מקרים שונים:
  1 – רשימה עם צ’קבוקסים ומספרים
  2 – רשימה רק עם צ’קבוקסים
  3 – רשימה רק עם מספרים
  4 – רשימה ללא צ’קבוקסים וללא מספרים

בדוגמה מימין אפשר לראות רשימה שלא הוגדרה נכון, ולכן אם ננסה להסתיר את המספר או את הצ’קבוקס – הטקסט לא מתיישר כמו שצריך.
במקום לייצר 4 קומפוננטות שונות, אנחנו יכולים להגדיר Auto layout נכון ולייצר Properties לרכיב כך שישמש אותנו בכל המקרים.בדוגמה מימין אפשר לראות
למה זה כדאי? כי כך כל שינוי בריווח / בפונט / במשקל שנבצע ברשימה אחת יעבור מיד לכל הרשימות. שמרנו על אחידות ולא בזבזנו זמן 😊

2. לחשוב גמיש

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

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

איך מיישמים בפועל?

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

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

• וגם – חשוב לזכור להגדיר את אופן ההתאמה לרזולוציות השונות ולהדגים במקרה הצורך

3. להגדיר נכון את התמונות והאייקונים שלנו

שמרתם על אייקונים עם עובי קו אחיד ופתאום בפיתוח משהו לא נראה נכון? יכול להיות שלא הגדרתם את האייקונים עם גודל Frame אחיד , מה שיכול לגרום לקפיצות בפיתוח. (חשוב שיהיה Frame ולא Group כדי שיהיה אפשר לקבוע את הגודל)

4. לתת כמה שיותר מידע על האנימציות שתכננו

כדי להבטיח שאנימציה שתכננו תהיה מדויקת, חשוב לתת לפיתוח מקסימום מידע על האנימציות שלנו.
אם אנחנו מספקים קבצי Lottie או GIF – ללוות אותם בהנחיות.
אם האנימציה צריכה להיעשות בקוד – מומלץ לתת רפרנס לאיך אנחנו רוצים שהאנימציה תיראה (שמוצאים באינטרנט או מייצרים במיוחד), יחד עם הסבר מילולי הכולל את קצב האנימציה, הנחיות לתאוצה ותאוטה, כולל ממש כמה מילישניות ייקח כל דבר, ועוד.

5. לא לחכות שיבקשו מאיתנו

מצב שגיאה של שדה, Empty states, תאריכון, מצבי Disabled ו-Hover אלה דברים שמאוד קל לשכוח ולראות שהם חסרים רק כשאנחנו רואים בשלב הבדיקות את המוצר שפותח.
עבודה עם צ’קליסט מסודר ועם תבנית קבועה של מצבים נדרשים ל-UI KIT או ל-Design System תעזור לנו לא לשכוח את הדברים האלה וכך תמנע חוסרים בשלב הפיתוח.
אני ממליצה לנהל לעצמנו צ’קליסט קבוע שאנחנו לוקחים איתנו לכל פרויקט (ומתאימים כמובן), ובכל פעם שמגלים משהו ששכחנו – להוסיף לצ’קליסט כדי לא לשכוח בפעם הבאה.

6. לקרוא לילד בשמו

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

תנו למסכים ולרכיבים שם משמעותי, עדיף לפי תבנית קבועה, לדוגמה:
Settings page > Personal details tab > Error message

ובלי Copy, Copy 1, Copy 7, כן?

7. ליצור פרוטוטייפ כבר בשלב האפיון ורצוי גם בשלב הפיתוח

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

8. לתאם ציפיות

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

9. לתת כבוד להחלטות שעשינו

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

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

10. לדבר על רגשות (ועל הפרויקט)

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

איך מיישמים בפועל?

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

• מעבר על התוצרים
• הדרכה על השימוש בפיגמה (או על הכלי שאיתו עובדים בפרויקט)
• הסבר איפה למצוא כל דבר
• הצגה של הפרוטוטייפ והעיצובים
• קריאה מודרכת של המסמך/ים

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

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

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