שימושיות: ראיון ג'ייסון שקלאר

ג'ייסון שקלאר: הרגע של "אוי הלוואי שהייתי יכול לעבוד בתעשיית המשחקים" עבורי הגיע ב-1999. קלטתי גם Halflife וגם Planescape Torment על סמך ציוני ביקורת. לא שיחקתי במשחקי וידאו כבר כמה שנים -- ואיזו ברוכה הבאה! המשחקים האלה שינו את חיי ועזרו לי להניע אותי למצוא דרך כלשהי להיכנס לתעשיית המשחקים.

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

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

RPS: אתה עושה את זה עכשיו על בסיס ייעוץ עצמאי - מה גרם לך להחליט לעשות את הקפיצה לשם?

ג'ייסון שקלאר: עבדתי עבור כמה חברות גדולות ועם כמה אנשים נהדרים. Microsoft Game Studios, Big Huge Games, Amazon.com. לכולם היה תפקיד חשוב בהתפתחות המקצועית שלי. הבעיה היא שאני אוהב לעשות כל מיני עבודה ונשרף אם אני רק עושה את אותו הדבר שוב ושוב. ניהול העסק שלי מאפשר לי לעשות כל מיני דברים שונים עם כל מיני אנשים מעניינים. בטח, אני צריך להשקיע יותר זמן בנטוורקינג ופיתוח עסקי ממה שהייתי רוצה, אבל זה שווה את זה. פגשתי המון אנשים מעניינים ונחשפתי לכמה פרויקטים ממש מסודרים.

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

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

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

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

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

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

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

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

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

RPS: מותו של המדריך במשחקים. לָדוּן.

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

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

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

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

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

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

כל המעצבים הנהדרים שעבדתי איתם משתוקקים למשוב מהסוג הזה. מַדוּעַ? כי המשחק עדיין בייצור ויש להם הזדמנות לתקן אותו. אף אחד לא רוצה לעשות משחק מבאס באמת. נכשל מוקדם, נכשל לעתים קרובות, ונכשל מול משתתפי שימושיות שנמצאים תחת NDA, בניגוד לכשל מול אנשים ששילמו $50 כדי לקנות את המשחק שלך.

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

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

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

RPS: ושם אתה מאבד 3/4 של ה-RPS הבריטי להחריד עם המטאפורה הזו של מחבט לכדור. תודה על הזמן שלך, ג'ייסון

אתה יכול לעקובג'ייסון שקלאר בבלוג שלו.