על תרחישים, מקרי שימוש וסיפורי משתמשים

על תרחישים, מקרי שימוש וסיפורי משתמשים

 

 

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

כדי לתאר את התהליכים שעוברים המשתמשים שלנו נשתמש בסוגי נרטיבים שונים כמו: סיפורי משתמשים (User Stories), תרחישים (Scenarios) ותיאורי מקרה (Use-Cases)

User Stories

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

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

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

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

סיפורי המשתמשים יעזרו לכם לצמצם את רשימת ה- Requirements למה שהמשתמשים שלכם באמת צריכים.

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

במונחים של אלן קופר, סיפורי משתמשים מתייחסים ומתארים את מטרות-קצה (End-Goals) של המשתמשים, שהן הדברים שהמשתמש רוצה לעשות. בעיניי מדובר על המטרות החשובות ביותר שמאפיינת חוויית משתמש צריכה להסתכל עליהן, שכן הן הסיבות לשמן הגיע המשתמש למוצר או לשירות מלכתחילה. הנוסעים המגיעים ל- Uber עושים זאת משום שמטרתם היא, לפני הכל, להגיע מ- A ל- B במהירות ומוניות – ובפרט אלו של Uber – לא רק עוזרות להגשים את מטרת הקצה הזו, אלא גם להגשים את מטרות החווייה (Experience-Goals: "איך המשתמש רוצה להרגיש"), קרי לא לנסוע עם אנשים נוספים באותו רכב, להעביר את הדרך עם מוזיקה נעימה וכדומה. אבל לפני הכל נזכור שהם רוצים להגיע מ- A ל- B במהירות. סיפור המשתמש במקרה של Uber יהיה (למשל):

כאיש עסקים בעל לוח זמנים עמוס,

אני מעוניין להגיע לפגישה הבאה לפחות 10 דקות לפני הזמן,

כדי שלא אצטרך לדחות את הפגישות הבאות בלו"ז שלי.

Scenarios

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

תרחיש שימוש כולל את:

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

 

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

 

    • המטרות אותם הוא מנסה להגשים באמצעות המערכת שלנו.

 

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

 

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

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

 

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

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

דוגמאות לתרחישים לפי פרסונות. מקור: http://ryanpainterdesign.com/images/goodreads/user_personas-01.jpg

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

דוגמא לתרחיש:

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

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

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

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

Use-Cases

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

בבואנו לכתוב מקרה-שימוש נרצה להתייחס:

    • למשתמש. אם נוכל להתייחס לפרסונות – מה טוב.

 

    • למטרה אותה הוא מנסה להשיג.

 

    • לתהליך השגת המטרה – הצעדים שהוא מבצע בדרך להשגת הפעולה.

 

    • למצב שקדם לתהליך. ההמלצה שלי במקרה כזה תהיה להתייחס למקרה-שימוש שקדם ולא סתם למצב המערכת. כלומר איזה use-case צריך להקדים את ה- use-case הנוכחי כדי שהוא בכלל יתקיים.

 

    • לתגובת המערכת לכל אחת מהפעולות שלו.

 

    • למצב המערכת או הסיטואציה כפי שיהיה לאחר שהמשתמש יצליח לבצע את הפעולה.

 

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

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

הנה use-case לדוגמה על בסיס Google Maps:

    • מקרה-השימוש: חישוב המרחק של מסלול (ריצה)

 

    • משתמש: אפרת, אצנית חובבת לאחר שסיימה ריצת ערב

 

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

אם נשבור את מקרה-השימוש הזה לחלקים, זה ייראה כך:

    • אפרת נכנסת לאתר (Google Maps)

 

    • בוחרת נקודת התחלת מדידה

 

    • לוחצת על הכפתור הימני בעכבר

 

    • בוחרת באפשרות 'מדידת מרחק'

 

    • ולוחצת על הנקודה השנייה במסלול (וכך הלאה עבור שאר הנקודות)

 

  • לוחצת על נקודת ההתחלה

אולם סביר כי ישנם מקרים אלטרנטיביים שצריכים להילקח בחשבון, למשל:

    • אפרת מזהה כי הנקודה השלישית אינה מדויקת

 

    • היא לוחצת עליה לחיצה ממושכת (Click & Hold)

 

  • היא גוררת את הנקודה למיקומה המדויק

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

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

והפשט?

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

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

http://gestal.co