בדיקה וחזרה

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

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

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

שימוש באשף של ניסוי Oz

למה השם הזה נקרא? הקוסם מניסויים על אוז (WOZ) מקבל את שמו מהסרט הקוסם מארץ עוץ; הם מתייחסים לרעיון שיש אדם מאחורי הווילון שמושך את מעלותיהם.

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

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


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

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

לחוויה המציאותית ביותר, מדמים את התפקיד של הפרסונה על ידי משחק הבקשות של הפרסונה באמצעות סימולטור ה-TTS בפעולות ב-Google Developer Console. מורידים את האודיו כדי שיהיה מוכן להפעלה על פי דרישה.

לגרסה זו נדרשים ארבעה דברים:

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

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

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

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

מה צפוי לך ללמוד?

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

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

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

איך בודקים את הפעולות?

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

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

איילין אלטיוק וניק פלקר, בבדיקת הפעולות שלך ב-Google I/O 2018