Posted on

10 כישורים רכים שכל מעצב צריך

פיתוח כישורים רכים הם אחד מהדברים החשובים בצלחה שלנו כמעצבי UX/UI.
חידוד הכישורים הרכים שלנו תורם לנו באופן ישיר למקצועיות שלנו באותה מידה שלמידת כלי נוסף או שיטת מחקר חדשה.

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

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

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

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

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

5.     כל צורת תקשורת היא פרוייקט חווית משתמש

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

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

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

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

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

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

מקור:https://uxdesign.cc/10-soft-skills-for-ui-ux-designers-11b948739a34

Posted on

עובד חלק

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

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

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

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

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

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

 מקור:https://uxdesign.cc/5-tips-for-designers-who-are-learning-to-code-6a15a940848b

Posted on

A או B

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

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

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

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

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

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

מקור:https://productcoalition.com/effectively-using-a-b-testing-302438b59970