חוויית המשתמש – העקרונות הבסיסיים

מדריך מפורט להכרת היסודות של עיצוב UX.

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

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

Double Diamond

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

הכנת הבמה

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

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

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

• תכנון מערכת לניהול הטיפול במטופלים עם כף רגל קלובה ומעקב אחריהם.

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

• עיצוב אפליקציה עקבית לנייד בפלטפורמות שונות בלי לפגוע במותג.

עדכון הצהרה על אתגר

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

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

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

אימות הבעיה

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

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

ראיונות פנימיים עם בעלי עניין

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

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

הרצאות בזק

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

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

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

ראיונות עם משתמשים

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

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

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

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

מחקר שדה אתנוגרפי

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

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

איסוף כל הנתונים

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

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

פרויקט מפה

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

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

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

שרטוט ו-storyboarding

Crazy 8s

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

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

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

שיפור העיצוב

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

יצירת סטוריבורד לרעיון

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

יצירת אב-טיפוס

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

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

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

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

שאלות שכדאי לשאול

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

מה שצריך לגלות הוא:

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

חזרה לעיצובים וסבב בדיקות נוסף

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

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

יוצרים!

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

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

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