אפיון חוויית משתמש (UX) – צעד אחר צעד

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

יש מגוון רחב של גישות ומתודולוגיות שקיימות בתחום. הספר "A Project Guide to UX Design" מתמקד באבני הדרך המשותפות לרוב הפרויקטים: הבנת המטרות וצרכי הפרויקט, אפיון קהל היעד והחוויה, והגדרת הפתרון הרצוי ע"י אפיון מפורט. כמות החפיפה בין השלבים השונים משתנה מפרויקט לפרויקט - הדבר תלוי מאוד בגישה התפעולית בה בוחרים עבור הפרויקט, ובהתאמה של איש ה-UX לחברה שאיתה הוא עובד.

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

1. מבינים את סוג הפרויקט

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

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

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

2. מכינים הצעת מחיר וחוזה (אם אתם פרילנסרים או חברות ייעוץ)

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

3. מגדירים עם הלקוח את מטרות הפרויקט ואת אופן העבודה 

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

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

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

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

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

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

• אילו שאלות עלינו לשאול ומתי: לדוגמה, אם עובדים בשיטת ה-Waterfall, יש צורך להשקיע מאמץ רב על מנת לאסוף את כל הדרישות מכל בעלי העניין בפרויקט, ולוודא שיש לנו את כל הנתונים הדרושים כדי לגשת לשלב האפיון המפורט.

• ציפיות לגבי תקשורת עם הצוות וכיצד יתנהלו שיתופי פעולה: לדוגמה, בשיטת ה-Agile דרוש שיתוף פעולה צמוד מאוד של כל הצוות, באופן יומיומי. בשיטת ה-Waterfall יכולים אנשי המקצוע השונים לעבוד בנפרד רוב הזמן, ולהיפגש רק פעם בשבוע.

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

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

4. מגבשים רשימת דרישות  

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

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

5. מבצעים מחקר משתמשים

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

מתי משתמשים בסקרים?

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

6. מכינים פרסונות

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

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

7. בונים אסטרטגיית תוכן

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

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

8. מבצעים תיעדוף של דרישות הלקוח

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

מה רמת החשיבות שלו לעסק? 

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

מה רמת החשיבות שלו למשתמש?

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

לשאלה האחרונה צריך להקדיש תשומת לב מיוחדת, מכיוון שכמה פתרונות שונים לאותה בעיה יכולים ליצור בלבול אצל המשתמש, והם גם קשים יותר לפיתוח ותחזוקה. לדוגמה, לחברת New York Times יש צוות פיתוח מספיק גדול כדי לפתח את כל אופציות ה-Sharing שרק ירצו עבור האתר שלהם, אבל חלק מהמשתמשים שירצו לשלוח מאמר לחבר לא ידעו על מה ללחוץ: Recommend ,E-mail או Share? אם המשתמשים שלנו לא מכירים את כל אופציות ה-Share המרובות שהתפתחו במהלך השנים האחרונות, עדיף להקל עליהם ולצאת קודם עם גרסה שיש בה פחות פיצ'רים כאלה.

מה המשמעות הטכנולוגית מבחינת פיתוח? 

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

מה המשמעות שלו מבחינת משאבים? 

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

9. מגדירים עקרונות מנחים

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

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

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

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

עקרונות עיצוב אינטראקטיבי בהקשר של תנועה במרחבי האתר/מוצר

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

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

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

10. יוצרים מפת אתר וניתוח משימות

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

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

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

11. יצירת Wireframes 

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

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

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

12. יוצרים אב-טיפוס (Prototype)

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

אפשר ליצור Prototype מנייר ומדבקות Post-it, כדי לבדוק באופן זריז ולא מחייב את הקונספט (מה שנקרא בז'רגון המקצועי Paper Prototyping). לרוב נעדיף ליצור אותו בעזרת כלים טכנולוגים במחשב, מה שמאפשר לנו להדגים בדיוק איך אזורים אינטראקטיביים באתר/מערכת/אפליקציה שלנו יופיעו ויתנהגו בתגובה לפעולה של המשתמשים.

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

13. מבצעים בדיקות שמישות (Usability Testing)

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

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

אלו הם השלבים המקובלים בהקשר של ביצוע בדיקות השמישות:

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

14. מודיעים לכל העולם

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

מה חסר? User Adoption הוא מונח שמתאר עד כמה המשתמשים באוכלוסיית המטרה באמת משתמשים באתר או באפליקציה. חלק מהבעיות ב-User Adoption יכולות להימנע ע"י אופטימיזציה באתרי חיפוש (SEO), על מנת לוודא שהמשתמשים שלנו יכולים למצוא את האתר בקלות. יש צורך להשקיע בשיווק ופרסום, כדי שהמשתמשים ידעו שהמוצר בכלל קיים.

ועוד כמה מילים לגבי הספר A Project Guide to UX Design

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