מדריך מפורט ליסודות של עיצוב חוויית המשתמש.
במאמר הזה נציג תהליך עבודה שיכול לעזור לצוותים, למוצרים, לסטארט-אפים ולחברות ליצור תהליך משמעותי ויציב לפיתוח חוויית משתמש טובה יותר ללקוחות שלהם. אפשר להשתמש בחלקים שונים של התהליך בנפרד, אבל הם פועלים בצורה הטובה ביותר כסדרה של שלבים.
המדריך הזה מבוסס במידה רבה על מתודולוגיית Design Sprint, שמשמשת צוותים רבים ב-Google לפתרון בעיות ואתגרים, כמו המכונית האוטונומית ו-Project Loon.
יהלום כפול
תהליך העבודה הזה מבוסס על מה שאנחנו מכנים בחוגי חוויית המשתמש "היהלום הכפול", שהפך לפופולרי על ידי מועצת העיצוב הבריטית. בתהליך הזה, הצוות שלכם מתפצל כדי להבין רעיון באמצעות מחקר, ואז מתכנס כדי להגדיר את האתגר, מתפצל כדי לשרטט אותו בנפרד, משתף את הרעיונות, מחליט מהי הדרך הטובה ביותר להתקדם, בודק ומאמת.
הכנת הבמה
הדבר הראשון שצריך לעשות הוא להתחיל עם האתגר הבסיסי ולכתוב אותו כמו הצעה, תוך כדי שאתם שואלים את עצמכם, "מה הבעיה שאני באמת מנסה לפתור?". הצהרת האתגר היא התקציר שאתם מגדירים לפרויקט, והיא כוללת את המטרה שלכם.
האתגר יכול להיות קשור לתכונה קיימת של מוצר שצריך לשפר, או למוצר חדש לגמרי. לא משנה מה המשימה, פשוט מתאימים את השפה למטרה שמנסים להשיג. ההצהרה צריכה להיות קשורה ליעדי הצוות, להתמקד בקהל, להיות מעוררת השראה ותמציתית.
אלה כמה דוגמאות מהחיים האמיתיים למוצרים שעבדתי עליהם בעבר:
תכנן מערכת לניהול הטיפול והמעקב אחרי מטופלים עם קלאב פוט.
ליצור אפליקציה שמפשטת מערכות פיננסיות מורכבות ומצמצמת אותן לדברים החיוניים.
לעצב אפליקציה לנייד שתהיה עקבית בפלטפורמות שונות בלי לפגוע במותג.
עדכון הצהרת הערעור
אחרי שכתבתם כמה וריאציות של היעד, הציגו אותו לצוות כדי להגיע להסכמה. כדאי לציין מועד אחרון כדי לעזור לצוות להתמקד בבעיה. אז עם ההתאמות הנוספות, הרשימה שלמעלה יכולה להיות:
- תכנון מערכת לניהול הטיפול והמעקב בילדים מתחת לגיל שנתיים עם קלאב פוט, שתושק ברבעון הראשון של השנה.
- ליצור אפליקציית שירותים פיננסיים פשוטה שמאפשרת לקנות ולמכור מניות בלחיצת כפתור, בלי ידע מוקדם בעולם הפיננסי. האפליקציה הושקה לראשונה ביולי 2017.
- עד סוף השנה, להפיק מדריך עיצוב שמתאים למספר פלטפורמות וממצב את המותג של החברה בצורה יעילה בכל פלטפורמה.
כשהניסוח של האתגר מוכן, הציגו אותו במקום בולט כדי שתוכלו לראות אותו בזמן העבודה. תצטרכו לחזור אליו כל הזמן, ואולי אפילו לעדכן או לשנות אותו במהלך הפרויקט.
אימות הבעיה
השלב הבא הוא לחקור את האתגר וללמוד על הבעיה. אתם צריכים לגלות אם האופן שבו הצוות שלכם מבין את הבעיה הוא נכון. לעתים קרובות אנחנו מסתכלים על בעיות מנקודת המבט שלנו, וזה מסוכן כי רובנו בתחום הטכנולוגיה הם למעשה משתמשים מתקדמים, ואנחנו למעשה מיעוט של משתמשים. אנחנו מיעוט קולני, ואנחנו יכולים לטעות ולחשוב שמשהו הוא בעיה, כשהוא לא.
יש כמה שיטות לאיסוף נתונים כדי לאמת את האתגר. כל אחת מהן תלויה בצוות שלכם ובשאלה אם יש לכם גישה למשתמשים. המטרה היא להבין טוב יותר את הבעיה.
ראיונות פנימיים עם בעלי עניין
תהליך הראיונות כולל ראיון של כל חבר צוות ובעל עניין בחברה, משיווק ועד חשבונות. כך תוכלו לגלות מהם האתגרים האמיתיים לדעתם ומהם הפתרונות האפשריים. כשאני אומר פתרון, אני לא מתכוון לפתרונות טכניים, אלא לתרחיש הטוב ביותר ולמטרה הסופית של החברה או המוצר. לדוגמה, אם נשתמש באתגרים שלמעלה, "התקנת התוכנה שלנו לטיפול בקלאב פוט ב-80% מהמתקנים הרפואיים עד סוף השנה" תהיה מטרה מצוינת לשאוף אליה.
יש נקודה אחת שחשוב לשים לב אליה. שיטת האימות הזו היא הכי פחות מומלצת, כי היא מונעת דיון ושיתוף פעולה בצוות, ועלולה ליצור אווירה של חוסר שיתוף פעולה בארגון. עם זאת, הוא יכול לספק מידע טוב על הלקוחות ועל אתגר העיצוב, שאחרת הייתם עלולים לפספס.
הרצאות בזק
השלב הזה דומה לראיונות הפנימיים, אבל הפעם אתם מכניסים את כל בעלי העניין לחדר אחד. לאחר מכן, בוחרים חמישה או שישה מבעלי העניין האלה (שיווק, מכירות, עיצוב, חשבונות, מחקר וכו') כדי שיעבירו הרצאה, שבה כל אחד יתמקד באתגר מנקודת המבט שלו, למשך 10 דקות לכל היותר. הנושאים שהם צריכים לכלול במצגת:
- יעדי העסק
- האתגרים בפרויקט מנקודת המבט שלהם (האתגרים יכולים להיות טכניים, קשורים לאיסוף מחקר, ליצירת עיצוב וכו'…)
- מחקר על התנהגות משתמשים שאתם עורכים כרגע
השאירו 5 דקות בסוף לשאלות, ומינו מישהו שיסכם את הפגישה. אחרי שתסיימו, אולי תרצו לעדכן את האתגר כדי לשקף את מה שלמדתם. המטרה היא לאסוף רשימה של נקודות שיכולות להוביל לתכונה או לתהליך שיעזרו לכם להשיג את היעד של המוצר.
ראיונות עם משתמשים
זו אולי הדרך הטובה ביותר ללמוד על המסלול, הבעיות והתהליך של המשתמש. קובעים לפחות חמישה ראיונות עם משתמשים, ואפילו יותר אם יש לכם גישה אליהם. השאלות שאתם שואלים אותם צריכות לכלול:
- איך משלימים משימה קיימת? לדוגמה, אם אתם רוצים לפתור את הבעיה של אפליקציית השירותים הפיננסיים שצוינה למעלה, אתם יכולים לשאול את המשתמשים "איך אתם קונים מניות כרגע?"
- מה הם אוהבים בתהליך הזה?
- מה הם לא אוהבים בתהליך הזה?
- באילו מוצרים דומים המשתמש משתמש כרגע?
- מה הם אוהבים?
- מה הם לא אוהבים?
- אם היה להם שרביט קסמים והם היו יכולים לשנות דבר אחד בתהליך הזה, מה הם היו משנים?
המטרה של הראיון היא לגרום למשתמש לדבר על האתגרים שלו. זה לא נושא לדיון, ולכן אתם צריכים להיות שקטים ככל האפשר. זה נכון גם כשהמשתמש מפסיק לדבר. תמיד צריך לחכות רגע, כי יכול להיות שהוא פשוט חושב מה להגיד. תתפלאו לגלות כמה אנשים ממשיכים לדבר אחרי שהם עוצרים לכמה שניות.
כדאי לרשום הערות במהלך הראיון, ואם אפשר, להקליט את השיחה כדי לתעד את כל מה שפספסתם. המטרה היא להשוות בין האתגר לבין התובנות שאספתם מהמשתמשים. האם הם תואמים? האם למדתם משהו שעוזר לכם לעדכן את הצהרת האתגר?
מחקר שדה אתנוגרפי
בשלב הזה אתם צופים במשתמש בשטח, בהקשר של הפעולה שהוא מבצע, למשל איך הוא עושה קניות, איך הוא נוסע לעבודה, איך הוא שולח הודעות SMS וכו'. הסיבה לכך היא שבמקרים מסוימים אנשים יגידו לכם את מה שהם חושבים שאתם רוצים לשמוע. אבל אם תצפו במשתמשים מבצעים פעולות ומשימות בעצמם, תוכלו לקבל תובנות. בעצם, אתם צופים בלי להתערב, ורושמים דברים שקל או קשה להם לעשות ודברים שהם אולי פספסו. המטרה היא להיכנס לסביבה של המשתמש כדי להבין טוב יותר את הבעיות שלו.
השיטה הזו בדרך כלל כוללת עבודה שמתבצעת לאורך זמן, ודורשת חוקר שיוביל את החלק הזה בפרויקט. אבל היא אולי הכי מעמיקה, כי אתם רואים את קבוצת האנשים שאתם חוקרים בסביבה הטבעית שלהם.
סיכום של כל המידע
אחרי שסיימתם את תקופת הלמידה של הפרויקט, אתם צריכים להסתכל פעם אחרונה על האתגר. האם אתם במסלול הנכון? יש משהו שצריך לשנות? כתבו את כל הדברים שלמדתם וקבצו אותם לקטגוריות. הם יכולים להפוך לבסיס של תכונה או תהליך, בהתאם לבעיה שאתם פותרים. הם יכולים גם לשמש לעדכון ולשינוי של האתגר.
אחרי שאספתם מספיק משוב ותובנות, הגיע הזמן להשתמש בידע הזה כדי ליצור מפת פרויקט.
מפת הפרויקט
הבעיה שאתם מנסים לפתור בדרך כלל מורכבת מסוגים שונים של אנשים (או שחקנים), שלכל אחד מהם יש אינטרס בתהליך של הפרויקט. על סמך מה שלמדתם, אתם צריכים לפרט את השחקנים האפשריים. זה יכול להיות סוג משתמש או בעל עניין, למשל: "רופא שמטפל בקלאב פוט", "מטופל עם קלאב פוט", "מטפל שדואג למטופל" וכו'. כתבו כל שחקן בצד ימין של דף נייר או על לוח מחיק, אם יש לכם גישה לאחד כזה. בצד שמאל, כותבים את המטרות של כל שחקן.
בסוף, לכל שחקן, תכתבו את מספר הצעדים שנדרשים כדי להגיע ליעד. לדוגמה, עבור "רופא שמטפל בקלאב פוט", המטרה תהיה "לרפא מטופל עם קלאב פוט", כך שהשלבים יכולים להיות "לרשום את המטופל במערכת", "להתחיל איתו תוכנית רפואית", "ליצור מחזור בדיקה של מצבו הבריאותי" ו"לבצע הליך רפואי".
התוצאה היא מפת פרויקט עם השלבים העיקריים בתהליך. אפשר לחשוב על זה כסקירה כללית של הפרויקט בלי יותר מדי פרטים. היא גם מאפשרת לחברי הצוות להחליט אם המפה תואמת לתיאור האתגר. בהמשך, כשנפרק כל שלב, יהיו יותר פרטים. אבל בינתיים, מפת פרויקט נותנת לכם פירוט ברמה גבוהה של השלבים שמשתמש יבצע כדי להשלים את המטרה הסופית שלו.
שרטוטים וסטוריבורד
שמונה משוגעים
לשם כך, אני ממליץ על שיטה שנקראת "8 משוגעים" שכוללת קיפול של פיסת נייר פעמיים כך שיהיו לכם שמונה פאנלים. בכל משבצת מציירים רעיון שמבוסס על כל מה שלמדתם עד עכשיו. הקציבו לעצמכם עשר דקות כדי להעלות רעיונות למילוי כל שמונה החלוניות. אם תתנו לעצמכם יותר מ-20 דקות, אתם עלולים להתחיל להתמהמה, להכין לעצמכם קפה, לבדוק אימיילים, לשוחח עם הצוות שלכם ובאופן כללי להימנע מביצוע העבודה. בשלב הזה כדאי ליצור תחושת דחיפות, כי היא מאלצת אתכם לעבוד מהר וביעילות.
אם אתם עובדים עם צוות, בקשו מכל אחד מחברי הצוות לעשות את אותו הדבר. התהליך הזה יפעיל את המוח שלכם ויגרום לכם לחשוב על האתגר. בדרך כלל, השרטוט יהיה תרשים של עיצוב הממשק.
אחר כך, אתם וכל מי שבצוות שלכם מציגים את הרעיונות שלכם לקבוצה. כל אחד צריך להסביר בפירוט כל אחד משמונת הרעיונות שלו ולמה הוא בחר ללכת בדרך מסוימת. הזכירו לכל חבר בצוות להשתמש בתובנות כדי להצדיק את הרעיונות שלו. אחרי שכולם הציגו את הרעיונות שלהם, הגיע הזמן להצביע. כל משתתף מקבל שתי נקודות דביקות ויכול להצביע לכל רעיון. הם יכולים לתת את שני הקולות לרעיון אחד אם הם ממש אוהבים אותו.
שיפור העיצוב
אחרי ההצבעה, קחו את הרעיון שקיבל הכי הרבה קולות ושרטטו רעיון סופי. אתם יכולים גם לשאול רעיונות ששמעתם מהקולגות שלכם. תנו לעצמכם עוד עשר דקות כדי להשלים את המשימה הזו. אחרי שתסיימו, הציגו שוב את הרעיונות לצוות והצביעו כמו קודם.
יצירת סטוריבורד לרעיון
אחרי שהעיצוב מוכן, הגיע הזמן ליצור תרחיש של האינטראקציה שלו עם המשתמש. בשלב הזה, כבר הייתם אמורים לחשוב על השלבים השונים שהמשתמש מבצע. הרבה פעמים משלבים בתהליך גם עיצוב של אחד מהקולגות. אתם רוצים ליצור תהליך ברור עם שלבים, שכולל כמה נקודות שבהן המשתמשים יכולים לבחור בין כמה אפשרויות. כדאי לחזור למפת הפרויקט כדי לוודא שהעיצוב תואם ליעד.
יצירת אב טיפוס
המטרה של יצירת אב טיפוס היא לא ליצור את הקוד המושלם, אלא ליצור משהו שנראה אמין כשמישהו משתמש בו. הכלים שמשמשים ליצירת אב טיפוס משתנים מאדם לאדם. יש אנשים שמעדיפים Keynote או PowerPoint כי הם מאלצים אותם לחשוב על הזרימה ולא על פרטי העיצוב. כדאי להשקיע זמן בלמידת כלים כמו Balsamiq, Marvel או Framer, שיכולים לתת לכם יותר שליטה על ההתנהגות. לא משנה באיזה כלי אתם משתמשים, ודאו שהוא מאפשר לכם להתמקד בתהליך ונראה אמיתי. צריך לבדוק את אב הטיפוס על אנשים אמיתיים, אז הוא צריך להיות אמין ככל האפשר, אבל באותו זמן לא צריך להשקיע שבועות של עבודה כדי ליצור אותו.
יצירת אב טיפוס היא איזון בין זמן למציאות, אז היזהרו לא לנטות יותר מדי לאחד מהקצוות. כך או כך, אתם עלולים לבזבז זמן.
בדיקת נוחות השימוש בעיצובים שלכם
אם יש לכם מעבדת בדיקות, זה מצוין. אם אין לכם, לא קשה ליצור אחד, כל עוד אתם מקפידים ליצור סביבה נוחה למשתמשים שלא מסיחה את הדעת. בדרך כלל, הבדיקה כוללת את המשתמש ושני אנשים מהצוות שלכם, אחד שרושם הערות והשני ששואל שאלות. דרך טובה לעשות את זה היא להשתמש באפליקציה כמו Hangouts ולהקליט את הפעולות שלהם. זה גם שימושי אם רוצים ששאר חברי הצוות יצפו מהצד מחדר אחר. זה יכול להיות די מפחיד בשבילנו כמפתחי אפליקציות, כי אנחנו רואים את העיצובים שלנו בעולם האמיתי. זו יכולה להיות חוויה מרעננת וגם חוויה שגורמת להתפכחות.
שאלות שכדאי לשאול
כשאתם בודקים את העיצוב, בקשו מהמשתמש לבצע משימות באפליקציה, לדבר בקול רם ולתאר מה הוא עושה ולמה. זה אולי נשמע מוזר, אבל זה עוזר לכם לשמוע מה הם חושבים. נסו לא להפריע או להגיד להם מה לעשות כשהם נתקעים. פשוט שואלים אותם למה הם בחרו בתהליך מסוים אחרי שהם השלימו אותו (או לא השלימו אותו).
מה שאתם צריכים לברר הוא:
- מה הם אוהבים באב הטיפוס?
- מה הם לא אוהבים באב הטיפוס?
- מהן הבעיות?
- למה תהליך עבד
- למה תהליך מסוים לא פעל
- מה הם רוצים לשפר?
- האם העיצוב או התהליך הכולל עונים על הצרכים שלהם?
בחינה מחדש של העיצובים וסבב בדיקות נוסף
יש לכם אב טיפוס עובד עם משוב. עכשיו הגיע הזמן לשנות את העיצובים ולנתח מה עבד ומה לא. אל תחששו ליצור תרחיש חדש לגמרי של תבנית דף ולבנות אב טיפוס חדש. אם מתחילים מחדש, אפשר ליצור זרימה טובה יותר מאשר אם מנסים להזיז דברים באב הטיפוס הקודם. נסו לא להיקשר אליו יותר מדי, כי זה רק אב טיפוס.
כשתהיו מרוצים מהעיצובים, תוכלו לבדוק אותם שוב ולשפר אותם עוד קצת. במקרים שבהם אב הטיפוס לא עמד בציפיות בכלל, יכול להיות שתחשבו שהפרויקט נכשל. בפועל, זה לא קרה. סביר להניח שהשקעתם פחות זמן בפיתוח מאשר אם הייתם בונים את העיצוב בפועל, ואתם יודעים יותר על מה שהמשתמשים באמת אוהבים. בשלבי התכנון, הגישה שלנו היא שאתם או מנצחים או לומדים, אז אל תתבאסו יותר מדי אם הרעיון לא עבד כמו שתכננתם.
יצירה!
בדקתם את הרעיונות שלכם. המשתמש אוהב אותם. בעלי העניין מושקעים בפרויקט כי הם מעורבים בו מההתחלה. עכשיו הגיע הזמן ליצור את הדבר עצמו. בשלב הזה כבר אמור להיות לכם מושג ברור מה צריך ליצור ומהן העדיפויות של החוויה. בכל שלב בפרויקט, כדאי לבצע בדיקות שימושיות כדי לאמת את העבודה ולוודא שאתם בכיוון הנכון.
חשוב מאוד לברר כמה שיותר לפני שמשקיעים הרבה עבודה, זמן ואנרגיה במשהו שאולי הוא לא הפתרון הנכון.
עכשיו, אחרי שקראתם את המאמר הזה, יש לכם בסיס להבנת חוויית המשתמש והחשיבות שלה. חוויית המשתמש היא לא משהו שצריך להתייחס אליו כתפקיד של מעצב או חוקר. למעשה, זו האחריות של כל מי שמעורב בפרויקט, אז אני ממליץ להיות מעורבים בכל הזדמנות.