top of page

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

תודה, נתראה בספאם (:

  • Snapchat
  • Facebook
  • Twitter
  • LinkedIn

מעצבים ומפתחים מסרבים להיות אויבים 🤝

Tal Solomon

עודכן: 3 באוק׳ 2024

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


https://x.com/pJacquelDesign/status/1841448106568900677

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


 

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


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


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

הייתי מתחיל עם הטמעה של ספריית קומפוננטות ענפה ככל האפשר

כשתהיתי מדוע, הוא הסביר שכדי שצוות פיתוח, ובפרט FrontEnd צריך לרוץ מהר וליישם את חוויית המשתמש בצורה המדויקת ביותר, הדרך הקלה ביותר לעשות זאת היא באמצעות רכיבים שנועדו בדיוק לכך, כמו אלו המוצעים בספריות הקומפוננטות השונות כמו: Material design, MaterialUI, RadixUI, AntDesign ועוד. כל ספריה כזו מציעה מאות קומפוננטות שכבר אופיינו בצורה יחסית קונבנציונלית ומאפשרת למפתח להוציא לפועל היבטי UI מתקדמים כמו תנועה, אנימציה, צל וכו׳, במהירות ויעילות. למעצב קל יותר להשתמש ברכיבים, שכן הם כבר קיימים, מותאמים לגדלים שונים, קלים מאוד לעדכון (למשל שינוי צבע או ציר Z) ולמפתח קל יותר לקבל עיצוב הכולל רכיבים מאופיינים (ומפותחים).


במאמר שסקר שיטות עבודה של אנשי מקצוע בתחום חוויית המשתמש (UX) - הסביבה שלהם, הפרקטיקות, הכלים והאתגרים - נבדקו 32 מחקרים אמפיריים על עבודת שמישות (Usability) ו-UX כדי לזהות סוגיות מפתח. החוקרים אספו נתונים מ- 422 א.נשי UX מחמש מדינות שונות באמצעות שאלון מקיף של 62 שאלות. התוצאות הראו, לשמחתנו,

 שישנה ״תרבות UX״ בארגונים רבים, כלומר ה- UX מעורב משלבים מוקדמים ועד מאוחרים ומוכר היטב בכל רמות הארגון. 

רוב א.נשי ה- UX שהשתתפו במחקר היו מעורבים בפרויקטים האחרונים שלהם מההתחלה ועד הסוף, כאשר הפרויקטים כללו היבטי UX. מספר המשתתפים שדיווחו כי פעילויות UX היו משולבות באופן מלא, ברובן, או באופן מתון בתהליך הפיתוח של הפרויקטים האחרונים שלהם היו 81 (19.2%), 113 (26.8%), ו-122 (28.9%), בהתאמה. מבין המשתתפים הנותרים, 32 (7.6%) ו-55 (13%) דיווחו כי פעילויות UX לא נכללו או ברובן לא נכללו בפרויקטים שלהם, בהתאמה.

אינטגרציה של פעילויות UX בתהליך הפיתוח, מתוך המאמר.

בספרו ״האסירים מנהלים את בית המשוגעים״, טוען קופר (Alan Cooper) ששנות ה- 2000, בהן פיתחנו מוצרים דיגיטליים ״מדהימים״ לראשונה, לוו בחוסר תשומת לב לחוויית המשתמש (UX). אליבא דקופר, למתכנתים היה תפקיד לא פרופורציונלי בהכרעת העיצוב ואינטראקציית המשתמש ורוב ההחלטות העיצוביות/UXיות נעשו במחשבה שנייה, בדיעבד, מה שהוביל לאינטראקציית אדם-מחשב בינונית ברוב התוכנות הצרכניות של אותה תקופה. מה שעצוב עוד יותר בעיניי, הוא שרוב העיצוב הבינוני הזה של תוכנות על כמו Microsoft Office,למשל, המשיכו איתנו לעשור השלישי של שנות ה- 2000.


אזהרה: לדור ה- X והמילניאלס התמונות למטה עשויות להעלות זכרונות ילדות מתוקים.




מניסיוני, ואני מתנצל מכל מתכנת/ת שחורגים מהרשימה הזו,


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


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


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


  4. מתכנתים רבים לוקים בהטיית האגוצנטריות - Egocentric bias. זו הנטייה להסתמך יתר על המידה על נקודת המבט האישית (ו/או להחזיק בדעה גבוהה יותר על עצמך מאשר במציאות). במילים אחרות, מתכנתיםות רבים פחות אמפטיים כלפי המשתמשים מאשר מעצבי UX. הם מניחים שמשתמשים מיומנים במחשבים כמוהם, או מאבחנים בעיות משתמשים כחוסר הדרכה במקום כבעיית עיצוב. בנוסף, חלקםן לא מאוד מוצלח בבניית פתרונות ויזואליים שיאפשרו למשתמשים ״להבין״ דברים מבלי לקרוא הסבר מקיף בנושא.


אז מה לעשות?

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



ולא בקצרה,

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

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

  3. בחרו יחד את הכלי שדרכו תעבירו עיצובים וקומפוננטות. אם הכל נעשה ב- Figma, ודאו כי לכולםן יש אישור כניסה. אם הם צריכים כלי נוסף כמו Zeplin או Storybook - ודאו שאתםן בוחריםות אותו יחד.

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

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

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


לסיכום,


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

Commenti


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

תודה אלוף/ה! נתראה ב- Spam 🫶

© 2024 by Gestalt UX. All rights reserved to Tal Solomon

bottom of page