עיצוב UX למציאות מדומה: ההחלטות שקובעות אם זה יעבוד

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

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

לפני שמעצבים: משימה, משך ותנוחה

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

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

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

עיצוב ממשק במציאות מדומה: בעולם, על היד או מול העיניים

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

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

איך המשתמש זז בלי אי-נוחות: תנועה, סיבוב ומצלמה

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

1. תנועה קדימה: תנועה פיזית בחדר לא יוצרת פער בין מה שרואים למה שמרגישים, אבל מוגבלת בגודל החדר. טלפורט, קפיצה לנקודה שנבחרה, מקטין את הפער. תנועה רציפה עם ג'ויסטיק מרגישה חופשית יותר, אבל קשה לחלק מהמשתמשים, ולכן כדאי לתת לה חלופה.
2. סיבוב: סיבוב בקפיצות קבועות (snap turn) נוח בדרך כלל לרבים יותר מסיבוב רציף. אם יש סיבוב רציף, כדאי לאפשר לבחור ביניהם.
3. מצלמה: לא להזיז או לסובב את נקודת המבט של המשתמש בלי פעולה שלו. מעבר מצלמה אוטומטי, קטע מתוסרט או האצה שהמשתמש לא יזם הם מקורות נפוצים לאי-נוחות. מעבר סצנה עם דהייה לשחור אינו נחשב תנועת מצלמה.
4. אפשרויות נוחות: בתנועה רציפה, מקובל להציע הצרה של שדה הראייה בזמן תנועה (vignette) ומהירות קבועה בלי האצה, ולתת למשתמש לכבות או להפעיל אותן.

גם יציבות התצוגה היא חלק מהנוחות. במשקפיים עצמאיים בודקים את הביצועים על המכשיר עצמו ולא על מחשב הפיתוח. לפי Meta - מדידת ביצועים ב-Quest Developer Hub, הכלי Performance Analyzer מציג מדדים מהמכשיר בזמן אמת, וכך אפשר לחקור בעיות ביצועים לפי מדידה. על אבחון מפורט ראו אבחון ביצועים על Quest 3.

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

טקסט, קול ומשוב: איך המשתמש יודע מה לעשות

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

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

בדיקות שימושיות ב-VR: מה בודקים, עם מי ומתי

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

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

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

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