7 типових помилок у розробці ігрових інтерфейсів

Привіт, мене звуть Саша, я Senior UX/UI в Ubisoft. Уже шостий рік створюю інтерфейси ігор: брав участь у розробці останніх трьох частин Far Cry, а зараз працюю над Beyond Good and Evil 2. У цьому матеріалі хотів би поділитись своїми спостереженнями щодо основних помилок у розробці інтерфейсів ігор як розробник, а також як гравець, у якого замість топографічного кретинізму — UI-кретинізм :) Ця стаття може бути корисна не тільки UI-дизайнерам і художникам, а й менеджерам, тестувальникам, та й взагалі всім членам команд великих ігрових компаній чи лампових інді-студій.

Помилка 1: Нехтування стадією досліджень

Основна мета UX-дизайну — вирішити потреби, задачі гравців, побудувавши найкращий для них досвід. З UX-дизайну випливає його компонента — інтерфейс, засіб і правила взаємодії людини з машиною.

Що ж робить інтерфейс і досвід поганими? Насамперед недостатнє розуміння користувача, його цілей, задач і потреб, а також фізичних і когнітивних особливостей. Іншими словами, ми його просто не знаємо! Якщо глянути ширше, здається, ця теза правдива не тільки для ігор чи інформаційних технологій, а й для дизайну інтер’єрів, промислового та сервіс-дизайну.

Чому ж ми не знаємо нашого користувача? Тому що справжня стадія досліджень та аналізу складна. Треба докласти зусиль, аби будувати та перевіряти гіпотези, взаємодіяти з гравцями, проводити інтерв’ю, опитування, аналізувати зворотний зв’язок.

Більш спокусливий шлях — зупинитись на своїх перших ідеях, заснованих на упередженнях. А потім увімкнути трек «Try walking in my shoes» Depeche Mode і стрибнути зразу в стадію «рухаємо пікселі». Замість фактів, цифр і статистики спілкуватись мовою «це краще рішення, я сам граю», «я емпат, юзеру буде зручно»... Та чи ефективно це?

Крім того, клієнт/менеджер чи потенційний роботодавець часто розглядають лише кінцевий результат, дивляться на картинки інтерфейсу, керуючись принципом «гарно/негарно», а не з погляду досвіду користувача та розв’язання його задач.

На жаль, ми, дизайнери, ніколи не будемо усіма нашими користувачами, не зануримось у їхній контекст і середовище, не зможемо повністю відобразити їхні думки. Пропущена стадія дослідження — це майже 100% шанс звернути не туди вже на самому початку розробки функцій чи всього продукту.

Помилка 2: Упередження

Упередження можуть серйозно вплинути на ваші дослідження та продукт. У кожного з нас є усталені переконання та стереотипи — це частина людської природи. Дизайнерам важливо знати, як передбачити, виявити та подолати свої упередження у роботі. Розглянемо декілька з них:

Підтверджувальне упередження (англ. confirmation bias) — це тенденція шукати або інтерпретувати інформацію таким чином, щоб вона підтверджувала власні переконання або гіпотези. Припустимо, у вас є упередження, що амбідекстери більш креативні, ніж правші чи шульги. Досліджуючи це, ви будете схильні тяжіти до доказів, які підтверджують це переконання, і використовуватимете їх для побудови своєї аргументації, навіть якщо це не обов’язково відповідає дійсності.

Ефект хибного консенсусу (англ. false consensus bias) — це упередження, при якому ми схильні переоцінювати ступінь, наскільки наші думки, уподобання, звички та цінності є нормальними й типовими для інших. Наприклад, ми схильні перебільшувати кількість людей, які погодяться з нашою ідеєю чи дизайном. Це веде до консенсусу, якого не існує, «хибного консенсусу».

Ефект первинності (англ. primacy bias) — це упередження, коли людина пригадує початково надану їй інформацію краще, ніж інформацію надану після того. Наприклад, під час серії інтерв’ю користувачів перший учасник може справити найсильніше враження, тому що ви перебуваєте в новій ситуації або маєте новий досвід.

Ефект нещодавності (англ. recency bias) — схильність краще пам’ятати й приділяти надмірну увагу речам, які ми почули наприкінці співбесіди, розмови, виступу, оскільки це нещодавні спогади. Наприклад, останні дії гравця в серії інтерв’ю можуть спонукати дизайнерів ірраціонально вважати, що подібна поведінка з більшою ймовірністю повториться, ніж її об’єктивна ймовірність.

І як результат усіх перерахованих когнітивних ефектів і упереджень вишенькою на торті додаємо:

Оманливий ефект незворотних витрат (англ. sunk cost fallacy) — ми більш схильні продовжувати діяльність, якщо вже витратили гроші, зусилля чи час. Що глибше ми йдемо в проєкт, то важче потім змінити курс без відчуття невдачі та жалю, що ми втратили ресурси. Така поведінка може бути описана як «важко нести, шкода лишити». Стосується це не лише інтерфейсу чи частини гри, жертвами цього упередження стають цілі проєкти великих ігрових студій. Процес розробки ААА-ігор дуже інертний та з високим рівнем бюрократії.

У результаті ви витрачаєте багато грошей і кілька років свого життя на розробку нікому не потрібного продукту. Було випущено безліч довгоочікуваних ААА-ігор, які не відповідають очікуванням гравців та геть неприбуткові. Гейм-індустрія знає і контрприклади. Компанії вирішують «обмежитись лиш тими збитками, яких уже завдано» та скасовують проєкти, як-от Halo MMO ($90 млн на розробку) чи Fable Legends ($75 млн).

Щоб нівелювати ефект незворотних витрат, навіть свою частину роботи спробуйте розділити на менші етапи, окресліть точки, де ви зможете вирішити, продовжувати далі чи ні. Це дозволить повернутися, перш ніж робота зайде надто далеко, а гра перейде на крейсерську швидкість розробки.

Також для розв’язання деяких проблем гри можна застосувати дизайн-спринт. Цей інтенсивний процес, пронизаний духом дизайн-мислення, складається з п’яти етапів: визначення проблем, генерування ідей, вибір найкращих, прототипування, тестування. Ці кроки зазвичай розподіляються на п’ять повних восьмигодинних днів. Мета дизайн-спринтів — розв’язувати важливу проблему дизайну, підтвердити концепцію або просто перевірити нові ідеї.

Чим може бути корисний цей підхід?

• Дизайн-спринти економлять час.
• Вони визначають пріоритет користувача, ставлячи його потреби на перший план.
• Дизайн-спринти дають змогу швидко перейти до наступних етапів, протестувати і отримати зворотний зв’язок гравців, перш ніж ухвалювати будь-які дорогі рішення.
• Команда може скоротити процес ухвалення рішень з кількох місяців до кількох тижнів.

Багато компаній використовують дизайн-спринти (наприклад, Google), щоб визначити напрями продукту, міжкомандні стратегії чи побудувати корпоративну культуру.

Помилка 3: Нуль гравців дають нуль інсайтів

Тестування дизайну є важливою частиною розробки інтерфейсу користувача. Однак багато дизайнерів згадують про цей етап надто пізно або зовсім пропускають, довірившись тестувальникам, які більш зосереджені на функціональних проблемах гри. Дизайнери втрачають багато інформації про свою роботу та користувачів.

Звичайні коридорні тестування (англ. Hallway Usability Testing) — швидкий і дешевий спосіб перевірити свої гіпотези. Побігавши кілька хвилин в офісі з роздрукованими ч/б екранами чи в месенджері з цифровим прототипом, можна вже на початкових стадіях виявити проблеми дизайну та власні хибні ідеї про взаємодію. Тести з колегами з різних команд, профілем роботи, геймерським досвідом та без нього допоможуть знайти підводні камені та навіть інсайти.

Згідно з деякими дослідженнями, найкращі результати можна отримати від тестування за участі близько п’ять користувачів і проведення якомога більшої кількості невеликих тестів. Декілька тестів з п’ятьма учасниками дають значно кращий результат, ніж один з 15 користувачами.

Ваші упередження можуть значно впливати на якість тестів, тому важливо:

• Мати чіткий план і дотримуватися його, щоб опитувати кожного учасника однаково.
• Ставити відкриті запитання та активно слухати.
• Робити детальні нотатки, записи, щоб ви могли переглянути все, що сталося, а не згадувати згодом.

Усе це полегшує порівняння результатів, підвищує ймовірність того, що ви знайдете незвичайні та важливі моменти, які відбуваються під час вашого дослідження. Після тестів можна об’єднати замітки та створити різні категорії, наприклад: що пішло добре, а що ні; проблеми, які виникли; коментарі; запитання. Усе це потім занести на дошку в Miro та розмістити біля екранів, яких це стосується.

Дуже важливо в тестах інтерфейсу враховувати платформу та середовище (пристрої введення, виведення та їхню відстань до гравця). «ПК бояри» можуть насолоджуватися крихітними шрифтами на екрані, надзвичайною точністю миші та широким набором кнопок клавіатури. Водночас консольним гравцям потрібно кілька функцій на обмеженій схемі керування геймпаду та навігаційні рішення для стиків. А ще є мобільні телефони, Steam Deck, Stadia, Nintendo Switch... ой, краще не починати.

Дизайн — це неперервний процес досліджень, ітерацій, тестувань, який може тривати навіть після закінчення життєвого циклу продукту. Для сфери цифрових інтерфейсів влучною здається фраза: якщо дизайнери дивляться на свою роботу з тим же захватом і любов’ю, що й рік тому, та не мають жодних припущень чи ідей, як покращити продукт, вони провели цей рік на планеті Міллера з фільму «Інтерстеллар», де одна година зараховується за сім земних років.

Помилка 4: Неузгодженість

«The details are not the details. They make the design», — Чарльз Імс

Чи помічали ви коли-небудь якусь непослідовність, хаотичність в інтерфейсі гри? Коли на одних екранах вас вчили грати за одними правилам взаємодії, а на інших змушують опановувати нові. Та ще й розташування елементів стрибає, як кардіограма.

Такий асинхрон може бути значною проблемою великих проєктів, коли гру розробляє водночас декілька студій, аутсорс. Та ще й культурні відмінності та різні часові пояси вносять свою лепту.

Дизайн-система допомагає команді спілкуватись однією мовою та налагодити роботу, але потребує детальної підготовки та підтримки. Наприклад, до дизайн-системи можна додати такий набір:

• Палітра;
• Типографіка;
• Бібліотека компонентів (кнопки, слайдер, таби з усіма станами тощо);
• Бібліотека шаблонів (хедер, футер, спливні вікна, віджети з усіма варіантами використання тощо);
• Сітка;
• Відступи;
• Мікровзаємодії (micro-interactions);
• Анімації з таймінгами чи кількістю кадрів;
• Приклади, як варто та не варто робити;
• Кожен UI-елемент, що якимось чином відхиляється від дизайн-системи, повинен мати чіткі обґрунтування;
• Мікрокопії (англ. UX microcopy) — це прості та доступні слова, речення в інтерфейсі продукту. Наприклад, написи на кнопках, повідомлення про помилку, підказки та сповіщення.

При розробці дизайн-системи слід враховувати:

• Закони Фіттса, Хіка, евристики Нільсена, гештальт-принципи дизайну;
• Платформи, для яких розробляють гру;
• Локалізацію (тексти можуть займати на 30% більше місця. А для арабської — в ідеалі дзеркально відобразити увесь макет сторінки, а не тільки текстові поля);
• Стиль спілкування (tone of voice вашого проєкту та жанру гри).

Можна спробувати створити одну дизайн-систему як базис. Так на початку проєкту дизайнери можуть зекономити масу зусиль, використавши цей шаблон. Сама система має бути досить гнучкою, щоб її змінювати, доповнювати уже для визначеної гри. Крім того, так ви можете узгодити один UX/UI-підхід серед декількох ігор компанії. Послідовні та чіткі правила UI-дизайну допоможуть гравцям значно швидше освоїти інтерфейс і саму гру.

Помилка 5: Вважати, що ігровий UI — це лише екрани з кнопками

Дизайн мобільних застосунків, вебсайтів — це не лише стокові зображення та векторні примітиви. Так само ігровий інтерфейс — не картинка, обмазана пензлями фотошопу і шрифтами, ціною в пів бюджету гри.

До прикладу, гра Inside, яка отримала безліч номінацій та нагород. У ній взагалі немає інтерфейсу. І справді, коли взаємодія настільки інтуїтивна, найкращий інтерфейс — невидимий інтерфейс. Не варто всілякими екранами заважати зануренню гравця.

У грі Before your Eyes взагалі весь геймплей побудований на кліпанні очей гравця.

Можна розглянути дієгетичний інтерфейс, коли елемент вбудований безпосередньо у світ гри. Як-от стан здоров’я на спині в персонажа Dead Space чи карта в Metro Exodus. А для меню інвентарю в цих іграх поєднали одразу два підходи: звичайний та дієгетичний.

Є ще безліч альтернативних варіантів взаємодії з гравцем. Наприклад, тач-панель геймпадів Sony використовується для навігації в меню Days Gone. A в Horizon Forbidden West за допомогою неї можна вмикати HUD. З гіроскопом геймпаду можна малювати графіті в Infamous Second Son або підводити приціл в The Last of Us Part II.

Адаптивні тригери теж сприяють більшому зануренню в гру, наприклад симуляція опору натягнутої стріли в Kena: Bridge of Spirits. У FIFA тригери інформують про витривалість футбольних гравців: що більше втомлений, то більший опір курка. Це особливо корисно, оскільки постійно нагадує про стан кожного гравця. А ще ж є віртуальна реальність, яка містить океан можливостей та викликів для дизайнера.

Важливо розглядати, «набивати око» рішеннями з інших ігор, продуктів. Найкраще — це грати самому, не обов’язково витрачати десятки годин, аби пройти всю гру, особливо якщо не цікаво, але корисно ознайомитись, посмакувати інтерфейс, як сомельє. Варто аналізувати рішення гри: чому саме така навігація, структура меню, HUD, як інформаційна архітектура впливає на візуальну ієрархію тощо? Це допоможе краще орієнтуватись у підходах взаємодії, стилях графічного дизайну, та розуміти, як все це випливає з жанру гри, позиції на ринку та ігрової платформи.

Поєднання різних підходів взаємодії сприяє імерсійному досвіду, підсилює відчуття контролю, допомагає гравцям побачити результати своїх дій. А фразу «One of my most productive days was throwing away 1000 lines of code» Кена Томпсона можна застосовувати не тільки до коду, а й до екранів інтерфейсу.

Помилка 6: Не зважати на доступність гри

Багато хто не надає значення цьому аспекту або думає, що «доступність» передбачає вирішення лише однієї проблеми — збільшення шрифту чи контрасту, хоча і це досить часто недоступно в іграх.

На початку визначмо поняття disability, що тісно пов’язане з доступністю. Як дизайнери, ми розглядаємо це поняття з погляду соціальної моделі. Disability — це обмеження, спричинені тим, як організовано суспільство або як розроблені продукти, а не здібностями чи відмінностями людини. Тобто це несумісність між людиною та середовищем, що її оточує.

Ці обмеження бувають:

• Постійними (я погано розрізняю відтінки червоного й зеленого, тому в FIFA футболісти в червоній формі Манчестер Юнайтед для мене як хамелеони на фоні зеленого поля);
• Тимчасовими (невдало покатався на велосипеді, й наклали гіпс на великий палець лівої руки);
• Ситуативними (у вас зайнята одна рука, бо на ній заснув кіт, та ще й ви не чуєте звуків із гри через низьку гучність).

Я був здивований, дізнавшись, що понад мільярд людей у всьому світі мають disability, із них 400 мільйонів грають в ігри. Тож ми втрачаємо величезну аудиторію гравців, якщо не думаємо про доступність в продуктах, не надаємо різні способи взаємодії.

Крім того, створення функцій та опцій, призначених для певної групи гравців, часто забезпечує кращий досвід для всіх гравців — solve for one, extend to many. Цей феномен називають ефектом пандуса (англ. Curb cut effect). Завдяки пандусам люди з візками чи милицями можуть рухатися з більшою свободою. Але їхні переваги поширюються на всіх: від людей з дитячими візками, до велосипедистів, вантажників і літніх людей.

Субтитри в іграх з’явилися, аби зробити цей досвід доступним для гравців із порушеннями слуху. Але вони також допомагають гравцям, які легко відволікаються, пропускають звукові сигнали в гучному оточенні, або тим, хто вивчає іноземну мову.

Інклюзивний дизайн — це підхід, що дозволяє грати у вашу гру якомога більшій кількості гравців із найширшим спектром можливостей. Важливо враховувати унікальний досвід гравців, щоб надати ефективні рішення. У результаті від цього виграють всі.

Помилка 7: Нехтуванням контролем за імплементацією

Хоча цей технічний аспект має величезний і прямий вплив на досвід гравця з інтерфейсом, ним часто нехтують. Є ризик, що без вашої участі дизайни, красиві концепти, прототипи так і не стануть частиною продукту чи гри. І ваша робота не дійде до гравців — замість цього у них буде якийсь Франкенштейн з нотками programmer art.

Не бійтесь засукати рукава та працювати з рушієм гри. Дізнаватись, як будується інтерфейс, як показуються картинки, анімації, як і що можна/потрібно оптимізувати, автоматизувати для гри. Звісно, інструменти та рушій гри, особливо якщо це власна розробка компанії, не такі дружні та милі, як Figma. У той час як веброзробники копіюють сайт конкурентів за один день, у геймдеві в межах однієї компанії та рушія перенесення одного екрану меню в іншу гру може займати тижні.

Але не слід сприймати це як даність, тут можна побачити можливість: впливати, давати зворотний зв’язок щодо інструментів і самому робити процес розробки більше ефективними. Питань виникає тьма, тож не соромтесь запитувати у колег. Помітивши вашу справжню зацікавленість, вони охоче поділяться своїми знаннями й досвідом. Якщо щось досі не ясно, запитуйте доти, аж доки не дійдете до основи проблеми. Можна застосувати техніку «п’яти чому». Одночасно нове дізнаєтесь й інтерв’ю користувача проведете.

Ви адвокат користувача і продаєте рішення команді. Коли вона повністю впевнена в дизайн-рішенні, це надихає її. Тестувальники допоможуть знайти невідповідності у грі та дизайн-документах, менеджери не закриють цей баг через низьку пріоритетність, а програмісти проактивно допоможуть виправити. Тому що всі зможуть побачити та зрозуміти цінність для гравця.

Висновок

Дякую, що знайшли час на прочитання! Сподіваюсь, стаття була корисною, ви ознайомилися з помилками, нюансами розробки ігрових інтерфейсів та дізналися кілька шляхів, як їх усунути.

Досвід взаємодії гравця з інтерфейсами потребує постійної уваги та вдосконалення. Стежте за новими технологіями та підходами в різних галузях.

Будьте спостережливі як дизайнер, орієнтовані на розв’язання проблем, звертайте увагу на те, як ви та інші люди взаємодієте з фізичними й цифровими продуктами та послугами.

Інтерфейси — це значна частина нашого життя. Вони оточують нас усюди, починаючи від дверної ручки, кавоварки й авто і завершуючи платіжною системою і платформою реєстрації на прийом до лікаря.

Корисні посилання

• Як проводити Design Sprint 2.0, або Створюємо та тестуємо продукт
• The Design Sprint
• Overcoming Cognitive Bias in User Research
• Бібліотеки UI-рішень з ігор GamesWatch і Game UI Database
• Курс Gaming accessibility fundamentals від Microsoft
• Game Accessibility Guidelines

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини.