הפקת לקחים: בניית משחקים וסיפורים למסכים חכמים

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

הגדירו ציפיות במבוא

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

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

למצוא את האיזון בין מגע לאינטראקציות קוליות

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

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

להקפיד שהמרת טקסט לדיבור (TTS) תהיה קצרה

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

בדיקה של משתמשים חדשים ומשתמשים חוזרים

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

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

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

חשוב להפעיל את המיקרופון בצורה תקינה

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

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

מה כן לעשות: " יש לי אדום, ירוק או כחול. באיזה מהם אתה רוצה?"

מה לא לעשות: "איזה צבע היית רוצה? יש לי אדום, ירוק או כחול."

הדגשת שאלות

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

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

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

כדאי להתכונן לשגיאות מסוג "ללא התאמה" ולמקרי קצה

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

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

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

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

  • "יציאה / יציאה"

    סגירת הפעולה.

  • "לחזור / לומר את זה שוב"

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

  • "אני רוצה לשחק שוב"

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

  • “Help”

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

  • “Pause, Continue”

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

  • "דילוג"

    מעבר לנקודת ההחלטה הבאה.

  • 'דף הבית / תפריט'

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

  • "חזרה"

    מעבר לדף הקודם בסטורי אינטראקטיבי.

הקפדה על תוכן קריא וקריא

המסך החכם הוא מכשיר נייח, וניתן להשתמש בו מרחוק בתרחישי שימוש רבים. מומלץ להשתמש בגופנים גדולים יותר כדי להבטיח קריאוּת – לפחות 32 נקודות לטקסט הראשי ו-24 נקודות לטקסט משני.

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

איך מספקים משוב חזותי

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

הפחתת העומס הקוגניטיבי

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

רשימת המשימות

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

הגדרת ציפיות

למצוא את האיזון בין מגע לאינטראקציות קוליות

להקפיד שהמרת טקסט לדיבור (TTS) תהיה קצרה

בדיקה של משתמשים חדשים ומשתמשים חוזרים

חשוב להפעיל את המיקרופון בצורה תקינה

הדגשת שאלות

כדאי להתכונן לשגיאות מסוג "ללא התאמה" ולמקרי קצה

הקפדה על תוכן קריא וקריא

עיצוב ברור לניווט

איך מספקים משוב חזותי

הפחתת העומס הקוגניטיבי

משאבים נוספים

הקודם
משחקים מעולים