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

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

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

Mustafa Kurtuldu

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

המדריך הזה מבוסס במידה רבה על שיטת Design Sprint, שבה משתמשים צוותים רבים ב-Google כדי לפתור בעיות ולעמוד באתגרים כמו הרכבים האוטונומיים ו-Project Loon.

Double Diamond

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

הכנת הרקע

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

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

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

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

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

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

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

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

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

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

אימות הבעיה

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

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

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

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

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

הרצאות בזק

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

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

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

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

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

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

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

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

מחקר אתנוגרפי שנעשה בשטח

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

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

סיכום כל המידע

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

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

מפת הפרויקט

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

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

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

תכנון של wireframe ו-storyboard

Crazy 8s

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

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

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

שיפור העיצוב

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

סטוריבורד של הרעיון

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

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

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

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

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

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

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

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

מה שצריך לברר הוא:

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

בודקים מחדש את העיצובים ומבצעים עוד סיבוב בדיקות

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

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

יצירה!

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

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

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