Нашел подборку из 40 советов по тому, что стоит учитывать при работе над текстами в приложении. Выборочно приведу самые полезные или наименее банальные на мой взгляд:
1. Писать максимально кратко, сохраняя смысл, избегать больших блоков. Пользователи читают 20%-28% больших блоков текстов в вебе, отчасти это репрезентативно и для телефонов
2. Не быть слишком серьезным и злоупотреблять техническими терминами. Это актуально и для сообщений об ошибке
3. Писать числа цифрами, а не числительными
4. При возможности использовать сегодня, завтра и вчера вместо дат
5. Использовать текст на кнопках с конкретными действиями вместо yes и no
6. Закладывать локализацию в самом начале, немецкий к примеру в 2 раза длиннее английского в написании
7. Начинать работу над макетами с текстом как можно раньше, он акцентирует внимание на проблемах дизайна
8. Использовать выравнивание по центру для маленьких блоков текста и по левому краю для больших
9. Если заголовки слишком длинные - дробить использую eyebrow заголовок
10. Делать междустрочные интервалы на 2-5pt больше, чем размер шрифта
11. Вместо черного использовать темно-серый, он меньше утомляет глаза
12. Для того, чтобы выделить текст не злоупотребляя болдом - увеличить отступ и взять больший шрифт
13. Не доверять эмуляторам в моментах связанных с текстом
14. Загружать текст с сервера, чтобы иметь возможность исправить ошибки не пересобирая билд
Источник (англ.): http://www.mobilespoon.net/2018/11/ux-writing-comprehensive-guide-for.html
1. Писать максимально кратко, сохраняя смысл, избегать больших блоков. Пользователи читают 20%-28% больших блоков текстов в вебе, отчасти это репрезентативно и для телефонов
2. Не быть слишком серьезным и злоупотреблять техническими терминами. Это актуально и для сообщений об ошибке
3. Писать числа цифрами, а не числительными
4. При возможности использовать сегодня, завтра и вчера вместо дат
5. Использовать текст на кнопках с конкретными действиями вместо yes и no
6. Закладывать локализацию в самом начале, немецкий к примеру в 2 раза длиннее английского в написании
7. Начинать работу над макетами с текстом как можно раньше, он акцентирует внимание на проблемах дизайна
8. Использовать выравнивание по центру для маленьких блоков текста и по левому краю для больших
9. Если заголовки слишком длинные - дробить использую eyebrow заголовок
10. Делать междустрочные интервалы на 2-5pt больше, чем размер шрифта
11. Вместо черного использовать темно-серый, он меньше утомляет глаза
12. Для того, чтобы выделить текст не злоупотребляя болдом - увеличить отступ и взять больший шрифт
13. Не доверять эмуляторам в моментах связанных с текстом
14. Загружать текст с сервера, чтобы иметь возможность исправить ошибки не пересобирая билд
Источник (англ.): http://www.mobilespoon.net/2018/11/ux-writing-comprehensive-guide-for.html
Из подкаста выкинул часть внутренней кухни переводчиков - практически большую часть второго часа подкаста. Главный вывод со своей стороны - плотнее работайте с переводчиками, они тоже люди, подготавливайте необходимую информацию в удобном виде и результат будет лучше.
Очень часто переводы делаются под соглагением о неразглашении(nda).
MLV - multi language vendor - по сути агрегатор субподрядчиков с которым работает разработчик, чтобы снизить нагрузку на менеджера по переводам внутри компании. MLV дробит большой заказ на много языков и передает небольшим узкоспециализированным агенствам, которые в свою очередь передают фрилансерам.
Локализация игр может быть ориентирована на максимальное соответствие первоисточнику, либо на лёгкость восприятия целевой аудиторией (адаптация).
Возникают сложности с разным культурным багажом пользователей, например при локализации для западных пользователей восточной игры с отсылками к троецарствию, важно взаимодействовать с разработчиком и упрощать некоторые моменты.
2 подхода к переводу цитат - дословный перевод и подбор аналога из культуры пользователя (к примеру замены цитаты Пушкина на подходящую по контексту цитату Шекспира)
Контекстуальные ошибки вызваны недостатком материалов у исполнителя. Фрилансеры в большинстве неохотно играют в билды.
При наличии разветвлений в диалогах есть смысл написать софт, чтобы экспортировать в виде дерева, либо в экселе с ссылками на следующую ячейку (так делался ведьмак).
Волонтерские переводы, они же переводы через комьюнити - есть шанс, что будет хорошо, но чем больше продукт, тем их меньше. Плюсы - бесплатно, минусы - неконтролируемые сроки, качество и неконсистентность, если работает более одного человека.
Есть 2 рабочих схемы: русский переводчик + англоязычный нэйтив редактор, либо англ. носитель переводчик + русскоязычный редактор.
Источник (подкаст на 2 часа): https://www.youtube.com/watch?v=HmgKVyPtTTc
Очень часто переводы делаются под соглагением о неразглашении(nda).
MLV - multi language vendor - по сути агрегатор субподрядчиков с которым работает разработчик, чтобы снизить нагрузку на менеджера по переводам внутри компании. MLV дробит большой заказ на много языков и передает небольшим узкоспециализированным агенствам, которые в свою очередь передают фрилансерам.
Локализация игр может быть ориентирована на максимальное соответствие первоисточнику, либо на лёгкость восприятия целевой аудиторией (адаптация).
Возникают сложности с разным культурным багажом пользователей, например при локализации для западных пользователей восточной игры с отсылками к троецарствию, важно взаимодействовать с разработчиком и упрощать некоторые моменты.
2 подхода к переводу цитат - дословный перевод и подбор аналога из культуры пользователя (к примеру замены цитаты Пушкина на подходящую по контексту цитату Шекспира)
Контекстуальные ошибки вызваны недостатком материалов у исполнителя. Фрилансеры в большинстве неохотно играют в билды.
При наличии разветвлений в диалогах есть смысл написать софт, чтобы экспортировать в виде дерева, либо в экселе с ссылками на следующую ячейку (так делался ведьмак).
Волонтерские переводы, они же переводы через комьюнити - есть шанс, что будет хорошо, но чем больше продукт, тем их меньше. Плюсы - бесплатно, минусы - неконтролируемые сроки, качество и неконсистентность, если работает более одного человека.
Есть 2 рабочих схемы: русский переводчик + англоязычный нэйтив редактор, либо англ. носитель переводчик + русскоязычный редактор.
Источник (подкаст на 2 часа): https://www.youtube.com/watch?v=HmgKVyPtTTc
Немного геймдизайна, про один из способов углубления меты. Некоторые выводы не подходят для хардкорных игр.
Основные моменты:
Стоит сделать часть навыков не при старте, а приобретаемыми. Это:
1. Упростит онбординг
2. Вынудит игрока пробовать различные способности по мере прокачки
3. Дает дополнительную цель
4. Добавляет реиграбельности
Советы:
- по возможности уменьшить количество количественных навыков с процентами и добавить новые способности (dishonored, god of war)
- учитывать темп игры и подстроить прокачку навыков под неё, для динамичной аркады выбор из двух вариантов при прохождении миссии, а не древо, которое приложено перед статьей
- создать дефицит, чтобы повысить важность выбора (при обычном прохождении пользователь не должен открыть все скиллы к концу игры, assains creed origins)
- создать моменты в игре, когда использование скиллов открывает новые варианты или меняет отношение к тебе (deus ex, prey)
Способы введения в игру
- скиллпоинты за игровые активности, например прохождение миссий
- прокачка навыков за определенные действия
- поиск предметов для прокачки навыков
- выбор скилла за прохождение уровня
Источник (англ., скорость 1.25-1.5): https://www.youtube.com/watch?v=wsmEuHa1eL8
Основные моменты:
Стоит сделать часть навыков не при старте, а приобретаемыми. Это:
1. Упростит онбординг
2. Вынудит игрока пробовать различные способности по мере прокачки
3. Дает дополнительную цель
4. Добавляет реиграбельности
Советы:
- по возможности уменьшить количество количественных навыков с процентами и добавить новые способности (dishonored, god of war)
- учитывать темп игры и подстроить прокачку навыков под неё, для динамичной аркады выбор из двух вариантов при прохождении миссии, а не древо, которое приложено перед статьей
- создать дефицит, чтобы повысить важность выбора (при обычном прохождении пользователь не должен открыть все скиллы к концу игры, assains creed origins)
- создать моменты в игре, когда использование скиллов открывает новые варианты или меняет отношение к тебе (deus ex, prey)
Способы введения в игру
- скиллпоинты за игровые активности, например прохождение миссий
- прокачка навыков за определенные действия
- поиск предметов для прокачки навыков
- выбор скилла за прохождение уровня
Источник (англ., скорость 1.25-1.5): https://www.youtube.com/watch?v=wsmEuHa1eL8
Рано или поздно большинство из нас сталкивается с запуском нового продукта. Чтобы минимизировать риски и определиться с сеттингом автор рекомендует использовать FB Audience. Я сильно покромсал практическую часть, но на самом деле она составляет самую мякотку, так что рекомендую ознакомиться с оригиналом перед применением.
Задачи, которые можно решить с FB Audience:
- выбрать сеттинг для игры;
- найти свободную нишу для сеттинга;
- найти свободную нишу для жанра;
- посмотреть, сколько игроков игры «А» в игре «Б»;
- посмотреть лояльность сеттинга/жанра к третьим брендам;
- выбрать наилучший IP для игры;
- посмотреть, какие жанры и сеттинги лучше не смешивать.
Для ответа на любой из этих вопросов, достаточно посмотреть на размер получившейся аудитории. И решить стоит ли вообще запускать разработку.
Иногда на рынок выходит новая игра, которая:
1. Удачно совместила несколько жанров, поджанров, механик;
2. Заработала деньги.
В этом случае вопрос «Клонировать или нет» не встаёт. Вопрос в каком сеттинге её клонировать?
Кейс с обрывками практики
2017 год. Только что «взлетел» Playerunknown’s Battlegrounds (PUBG), решаем сделать клон, стоит выбор сеттинга для Battle Royale
Используем FB Audience.
Делаем описание аудитории жанра:
1. Опишите уже готовую аудиторию PUBG в разделе Интересы.
2. Измерьте аудиторию.
3. Посмотрите на демографию.
4. Добавьте целевые страны для вашей игры (без них нельзя сохранить аудиторию).
5. Сохраните аудиторию для дальнейших исследований.
Для этого примера я выбрал только США, в которой насчитывается 600 тыс. — 700 тыс. активных пользователей, в чьи интересы входит PUBG.
Описание аудитории сеттинга:
Тут та же история, только в интересах надо отметить игровой сеттинг.
Для примера я возьму:
-Звёздные войны
-Последнюю фантазию
-Властелина колец
-Minecraft
Для каждого из сеттингов настраиваем следующее:
- Интересы (сеттинг). Их описывайте максимально плотно, Facebook сам отфильтрует дубликаты.
- Географию. Она должна совпадать с географией жанра (в моем случае — США).
Смотрим на демографию. Если её величина нас устраивает, то сохраняем аудиторию в отдельную группу.
Проделываем это для каждого интересующего сеттинга.
Детальная настройка аудитории
Этот блок с картинками стоит смотреть в статье, формат короткого поста не раскроет всего наслаждения работы в интерфейсе FB, удобство которого всегда вызывало массу споров.
Теперь ваши аудитории готовы к сравнительному анализу.
К примеру, мы видим, что месячная аудитория интересующихся «Властелином Колец» насчитывает 5,8 млн человек. Нас интересует, сколько из них лояльны и PUBG?
Сравнение аудиторий
1. Выбираем две аудитории (галочкой). Одна аудитория — жанра, а другая — сеттинга.
2. Во вкладке «Действия» выбираем опцию «Пересечение аудиторий».
3. Смотрим на результат.
4. Жмём внизу на «Добавьте другую аудиторию» и добавляем все наши ЦА.
5. Получаем аналитику по пересечению жанра и сеттингов.
Выводы по кейсу:
Есть смысл делать «Королевскую битву» в сеттинге Minecraft.
К тому же выводу пришли тогда - Grand Battle Royale, Guns Royale и многих других.
Источник(рус.): https://app2top.ru/marketing/kak-proanalizirovat-auditoriyu-i-vy-brat-pravil-ny-j-setting-131085.html
Задачи, которые можно решить с FB Audience:
- выбрать сеттинг для игры;
- найти свободную нишу для сеттинга;
- найти свободную нишу для жанра;
- посмотреть, сколько игроков игры «А» в игре «Б»;
- посмотреть лояльность сеттинга/жанра к третьим брендам;
- выбрать наилучший IP для игры;
- посмотреть, какие жанры и сеттинги лучше не смешивать.
Для ответа на любой из этих вопросов, достаточно посмотреть на размер получившейся аудитории. И решить стоит ли вообще запускать разработку.
Иногда на рынок выходит новая игра, которая:
1. Удачно совместила несколько жанров, поджанров, механик;
2. Заработала деньги.
В этом случае вопрос «Клонировать или нет» не встаёт. Вопрос в каком сеттинге её клонировать?
Кейс с обрывками практики
2017 год. Только что «взлетел» Playerunknown’s Battlegrounds (PUBG), решаем сделать клон, стоит выбор сеттинга для Battle Royale
Используем FB Audience.
Делаем описание аудитории жанра:
1. Опишите уже готовую аудиторию PUBG в разделе Интересы.
2. Измерьте аудиторию.
3. Посмотрите на демографию.
4. Добавьте целевые страны для вашей игры (без них нельзя сохранить аудиторию).
5. Сохраните аудиторию для дальнейших исследований.
Для этого примера я выбрал только США, в которой насчитывается 600 тыс. — 700 тыс. активных пользователей, в чьи интересы входит PUBG.
Описание аудитории сеттинга:
Тут та же история, только в интересах надо отметить игровой сеттинг.
Для примера я возьму:
-Звёздные войны
-Последнюю фантазию
-Властелина колец
-Minecraft
Для каждого из сеттингов настраиваем следующее:
- Интересы (сеттинг). Их описывайте максимально плотно, Facebook сам отфильтрует дубликаты.
- Географию. Она должна совпадать с географией жанра (в моем случае — США).
Смотрим на демографию. Если её величина нас устраивает, то сохраняем аудиторию в отдельную группу.
Проделываем это для каждого интересующего сеттинга.
Детальная настройка аудитории
Этот блок с картинками стоит смотреть в статье, формат короткого поста не раскроет всего наслаждения работы в интерфейсе FB, удобство которого всегда вызывало массу споров.
Теперь ваши аудитории готовы к сравнительному анализу.
К примеру, мы видим, что месячная аудитория интересующихся «Властелином Колец» насчитывает 5,8 млн человек. Нас интересует, сколько из них лояльны и PUBG?
Сравнение аудиторий
1. Выбираем две аудитории (галочкой). Одна аудитория — жанра, а другая — сеттинга.
2. Во вкладке «Действия» выбираем опцию «Пересечение аудиторий».
3. Смотрим на результат.
4. Жмём внизу на «Добавьте другую аудиторию» и добавляем все наши ЦА.
5. Получаем аналитику по пересечению жанра и сеттингов.
Выводы по кейсу:
Есть смысл делать «Королевскую битву» в сеттинге Minecraft.
К тому же выводу пришли тогда - Grand Battle Royale, Guns Royale и многих других.
Источник(рус.): https://app2top.ru/marketing/kak-proanalizirovat-auditoriyu-i-vy-brat-pravil-ny-j-setting-131085.html
В уходящем 2018 hypercasual игры начали привлекать к себе всё больше внимания, чаще фигурировать в отчета sensortower и прочно заняли место в пантеоне успешных категорий. Типовой пайплан состоит в топ, что берутся несколько идей, быстро собираются прототипы (время измеряется неделями, если не днями), всё это дело поливается трафиком и при отрицательном результате повторяется снова и снова. Сразу возникает вопрос - откуда у них трафик?
Tenjin выпустили отчет на основе суммарных затрат в 48 миллионов долларов на продвижение игр (240 миллионов установок) в 36 странах в первой половине 2018 года.
Суть из отчета (одолжил у apptraktor):
- Установка гиперказуальных игр стоит в 7-13 раз меньше, чем «нормальных» игр.
- Средняя стоимость установки на Android – 16 центов.
- Средняя стоимость установки на iOS – 28 центов.
- Самая дешевая страна – Колумбия, где Android-установка стоит 2 цента, а установка на iOS – 8 центов.
- Самая эффективная рекламная сеть – Facebook со средней ценой 9 и 19 центов соответственно.
- Лучшая страна для софтлонча гиперказуальной игры – Бразилия, где большая аудитория, стоящая относительно дешево.
- Гиперказуалки хорошо подходят для запуска на совершенно разные мировые рынки, благодаря нетребовательности к локализации, но по географии есть своя специфика (лучше посмотреть в источнике).
Источник (англ, графики любопытные) : https://cdn2.hubspot.net/hubfs/4079671/Tenjin%20Hyper-Casual%20Games%20CPI%20Benchmark%20Report%20-%202018.pdf
Tenjin выпустили отчет на основе суммарных затрат в 48 миллионов долларов на продвижение игр (240 миллионов установок) в 36 странах в первой половине 2018 года.
Суть из отчета (одолжил у apptraktor):
- Установка гиперказуальных игр стоит в 7-13 раз меньше, чем «нормальных» игр.
- Средняя стоимость установки на Android – 16 центов.
- Средняя стоимость установки на iOS – 28 центов.
- Самая дешевая страна – Колумбия, где Android-установка стоит 2 цента, а установка на iOS – 8 центов.
- Самая эффективная рекламная сеть – Facebook со средней ценой 9 и 19 центов соответственно.
- Лучшая страна для софтлонча гиперказуальной игры – Бразилия, где большая аудитория, стоящая относительно дешево.
- Гиперказуалки хорошо подходят для запуска на совершенно разные мировые рынки, благодаря нетребовательности к локализации, но по географии есть своя специфика (лучше посмотреть в источнике).
Источник (англ, графики любопытные) : https://cdn2.hubspot.net/hubfs/4079671/Tenjin%20Hyper-Casual%20Games%20CPI%20Benchmark%20Report%20-%202018.pdf
И снова отчет, на этот раз от ребят из deltaDNA. На графике выше можно посмотреть как распределились предпочтения по типам рекламы. Полезными могут быть также значения количества показов на сессию и работа с источнками, но обо всём по порядку.
Они провели исследование на 336 разработчиках, из которых:
- 55% специализируются на казуалках (из них 95% используют ads ), а 45% на мидкоре/хардкоре (76% ads)
- 55% имеют более 100k dau
- 87% используют ту или иную форму рекламы
Стратегии показов:
- всё меньше разработчиков ( 33% стараются показывать по одной на сессию, в прошлом году таких был 41%.
- растет количество разработчиков, готовых показывать 5 и более за сессию (~15%->21%)
- также растет количество показывать рекламу на первую сессию (~19%->23%)
- и количество показывающих плательщикам тоже выросло (~77->81%)
Выше указаны средние значения, казуалки более агрессивны, мид и хардкор менее.
Выручка - 56% разработчиков получают менее 40% своего дохода от рекламы, 16% разработчиков (только казуальные) - получают практически весь свой доход от рекламы. По остальным можно глянуть график в источнике, но польза сомнительна.
В работе с источниками рекламы сравнительно равнопопулярны 4 подхода:
- комбинация сеток с собственной медиацией
- использование admob, mopub и им подобных
- использование индивидуальной сетки
- работа с партнером медиатором
По количеству сеток большинство по-прежнему использует от 2х до 5ти, но в этом году наметился некоторый рост использующих 1 (от себя добавлю, что скорее всего из-за гиперказуалок, чтобы к примеру не встраивать монструозные api агрегаторов)
По отношению к рекламе всё больше разработчиков перестают воспринимать её как необходимое зло и относятся как к важной части экономики.
Источник (англ, можно позалипать в графики): http://go.deltadna.com/rs/554-FYX-755/images/deltadna-ad-survey-results-2018.pdf
Они провели исследование на 336 разработчиках, из которых:
- 55% специализируются на казуалках (из них 95% используют ads ), а 45% на мидкоре/хардкоре (76% ads)
- 55% имеют более 100k dau
- 87% используют ту или иную форму рекламы
Стратегии показов:
- всё меньше разработчиков ( 33% стараются показывать по одной на сессию, в прошлом году таких был 41%.
- растет количество разработчиков, готовых показывать 5 и более за сессию (~15%->21%)
- также растет количество показывать рекламу на первую сессию (~19%->23%)
- и количество показывающих плательщикам тоже выросло (~77->81%)
Выше указаны средние значения, казуалки более агрессивны, мид и хардкор менее.
Выручка - 56% разработчиков получают менее 40% своего дохода от рекламы, 16% разработчиков (только казуальные) - получают практически весь свой доход от рекламы. По остальным можно глянуть график в источнике, но польза сомнительна.
В работе с источниками рекламы сравнительно равнопопулярны 4 подхода:
- комбинация сеток с собственной медиацией
- использование admob, mopub и им подобных
- использование индивидуальной сетки
- работа с партнером медиатором
По количеству сеток большинство по-прежнему использует от 2х до 5ти, но в этом году наметился некоторый рост использующих 1 (от себя добавлю, что скорее всего из-за гиперказуалок, чтобы к примеру не встраивать монструозные api агрегаторов)
По отношению к рекламе всё больше разработчиков перестают воспринимать её как необходимое зло и относятся как к важной части экономики.
Источник (англ, можно позалипать в графики): http://go.deltadna.com/rs/554-FYX-755/images/deltadna-ad-survey-results-2018.pdf
Нашел еще пару отчетов, но сегодня предлагаю отвлечься от количественных исследований на качественные.
В разработке сложного продукта высока вероятность столкнуться с необходимостью сортировки сущностей по различным критериям. Руководствуясь своим здравым смыслом мы структурируем их, как считаем логичным. Это зачастую порождает проблемы у пользователей, когда ЦА мыслит совсем категориями.
В статье от nngroup приводится пример с автомобилями на сайте, но и в геймдеве достаточно частая ситуация. К примеру возьмем квесты обычные, ивентовые, ачивки, какой-нибудь лор, подсказки и кучу другой специфической инфы, - всё это нужно рассортировать.
Суть метода состоит в том, чтобы делегировать эту задачу непосредственно на представителей ЦА.
Общий алгоритм:
1. Выписываются все сущности, которые необходимо структурировать
2. Этот набор карточек отдается выборке пользователей (обычно требуется человек 15-20)
3. Им ставится задача рассортировать карточки по группам
4. А затем назвать эти группы
5. Расспросить пользователей какими принципами руководствовались, что вызвало сложности, есть ли элементы, которые никуда не попали или попадают сразу в две категории
6. Проанализировать результаты и адаптировать для продукта, если потребуется
Изначально данное исследование делалось с помощью бумажных карточек, но сейчас можно использовать цифровую версию, чтобы убрать потребность в физическом контакте. Простым бюджетным вариантом выглядит trello - создать доску с карточками и пусть пользователи создают колонки и раскладывают.
Есть 2 подхода к исследованию по работе с именованием групп:
- открытый (чаще всего используется), категории придумывают сами пользователи
- закрытый, когда категории заданы изначально
И по обсуждению результатов с пользователями:
- модерируемый, когда мы узнаем чем руководствовались пользователи в сортировке (больше инфы)
- немодерируемый, когда не проводим этот этап (дешевле)
Плюсы метода:
- простой и недорогой в проведении
- не требователен к навыкам испытуемого
- ориентирован на потребности пользователя
Минусы:
- игнорирует задачи продукта и результат может быть нерелевантен
- результаты могут варьироваться в каждом конкретном случае
Источник (англ.): https://www.nngroup.com/articles/card-sorting-definition/
и еще немного https://www.interaction-design.org/literature/article/the-pros-and-cons-of-card-sorting-in-ux-research
В разработке сложного продукта высока вероятность столкнуться с необходимостью сортировки сущностей по различным критериям. Руководствуясь своим здравым смыслом мы структурируем их, как считаем логичным. Это зачастую порождает проблемы у пользователей, когда ЦА мыслит совсем категориями.
В статье от nngroup приводится пример с автомобилями на сайте, но и в геймдеве достаточно частая ситуация. К примеру возьмем квесты обычные, ивентовые, ачивки, какой-нибудь лор, подсказки и кучу другой специфической инфы, - всё это нужно рассортировать.
Суть метода состоит в том, чтобы делегировать эту задачу непосредственно на представителей ЦА.
Общий алгоритм:
1. Выписываются все сущности, которые необходимо структурировать
2. Этот набор карточек отдается выборке пользователей (обычно требуется человек 15-20)
3. Им ставится задача рассортировать карточки по группам
4. А затем назвать эти группы
5. Расспросить пользователей какими принципами руководствовались, что вызвало сложности, есть ли элементы, которые никуда не попали или попадают сразу в две категории
6. Проанализировать результаты и адаптировать для продукта, если потребуется
Изначально данное исследование делалось с помощью бумажных карточек, но сейчас можно использовать цифровую версию, чтобы убрать потребность в физическом контакте. Простым бюджетным вариантом выглядит trello - создать доску с карточками и пусть пользователи создают колонки и раскладывают.
Есть 2 подхода к исследованию по работе с именованием групп:
- открытый (чаще всего используется), категории придумывают сами пользователи
- закрытый, когда категории заданы изначально
И по обсуждению результатов с пользователями:
- модерируемый, когда мы узнаем чем руководствовались пользователи в сортировке (больше инфы)
- немодерируемый, когда не проводим этот этап (дешевле)
Плюсы метода:
- простой и недорогой в проведении
- не требователен к навыкам испытуемого
- ориентирован на потребности пользователя
Минусы:
- игнорирует задачи продукта и результат может быть нерелевантен
- результаты могут варьироваться в каждом конкретном случае
Источник (англ.): https://www.nngroup.com/articles/card-sorting-definition/
и еще немного https://www.interaction-design.org/literature/article/the-pros-and-cons-of-card-sorting-in-ux-research
Название статьи "How to Effectively Predict Launch Week Installs on Mobile" намекает, что сейчас мы выясним как по-быстрому предсказать подходящий момент выпуска продукта, чтобы обмазаться траффиком с фичеринга. На самом деле всё не так просто, статья скорее про возможности предиктивной аналитики и подход к решению данной проблемы.
Всегда сложно предсказать как пройдет фичеринг. На деконстракторе ребята выложили исследование вокруг гипотезы - "существуют взаимосвязь между неделей запуска игры, местом в фичеринге, жанром и графическим стилем игры".
Для её доказательства:
1. Изучили 150+ игр в промежутке 02.04-27.09.2018 на ios используя данные платформы и app annie. Платные игры и продукты по большим франшизам исключили из исследования
2. Отсортировали по месту в фичеринге, жанру и стилю
3. Использовали для тестирования гипотезы Kruskal-Wallis (KW) Hypothesis Test
4. Построили линейную регрессионную модель, на вход которой подавали 3 гипотетических параметра из прошлого пункта, а на выходе получали ожидаемый объем инсталлов в зависимости дат выхода
Подробнее по доказательству:
Сортировка по параметрам.
Место в фичеринге на протяжении недели:
big - "Игра дня", верхний баннер в разделе игры и 1-3 верхняя иконка в блоке New Games We Love"
medium-big - верхний баннер в разделе игры и 1-3 верхняя иконка в блоке "New Games We Love"
medium-small - 4-6 верхняя иконка в блоке "New Games We Love"
small - 4-6 верхняя иконка в блоке "New Games We Love"
Стиль арта:
Realistic - реалистичный визуал
Cartoon - мультипликационный
Manga - анимешный
Pixel/retro - пиксель арт и стилизация под старые игры
Жанр.
Использовалась таксономия, разработанная Game Refinery and Michail Katkoff, где Категорией являются сущности типа "Казуальный", "Мидкор", "Казино", "Спортивные". Их подмножеством являются Жанры к примеру возьмем Puzzle для категории казуальных игр. Их мы используем в данном исследовании. Более мелкие подмножества под-жанров ("Match3 puzzle", "Action puzzle" и т.д.) могут быть использованы при более крупных выборках данных.
Доказательство гипотезы
Используя критерия критерий Крускала-Уоллиса изучили статистическую значимость перечисленных выше параметров, составили таблицу на которой соотнесли их с неделями и месяцами. В итоге получили, что наименьшее влияние оказывает графический стиль, но всё равно статистически значим. Используя эти параметры реализовали модель, предсказывающую зависимость места в фичере, от жанра, стиля, месяца и недели запуска.
Проверка.
Логичным этапом будет проверить эту гипотезу на практических данных. Собственно на картинке выше прикрепил графики худших и лучших результатов. Да, погрешность есть и ощутимая, но с другой стороны с этим уже можно работать, а используя больший набор данных и более точную модель можно получить лучшие результаты.
Источник (англ.): https://www.deconstructoroffun.com/blog/2018/12/10/are-launch-week-installs-even-predictable-on-mobile
Всегда сложно предсказать как пройдет фичеринг. На деконстракторе ребята выложили исследование вокруг гипотезы - "существуют взаимосвязь между неделей запуска игры, местом в фичеринге, жанром и графическим стилем игры".
Для её доказательства:
1. Изучили 150+ игр в промежутке 02.04-27.09.2018 на ios используя данные платформы и app annie. Платные игры и продукты по большим франшизам исключили из исследования
2. Отсортировали по месту в фичеринге, жанру и стилю
3. Использовали для тестирования гипотезы Kruskal-Wallis (KW) Hypothesis Test
4. Построили линейную регрессионную модель, на вход которой подавали 3 гипотетических параметра из прошлого пункта, а на выходе получали ожидаемый объем инсталлов в зависимости дат выхода
Подробнее по доказательству:
Сортировка по параметрам.
Место в фичеринге на протяжении недели:
big - "Игра дня", верхний баннер в разделе игры и 1-3 верхняя иконка в блоке New Games We Love"
medium-big - верхний баннер в разделе игры и 1-3 верхняя иконка в блоке "New Games We Love"
medium-small - 4-6 верхняя иконка в блоке "New Games We Love"
small - 4-6 верхняя иконка в блоке "New Games We Love"
Стиль арта:
Realistic - реалистичный визуал
Cartoon - мультипликационный
Manga - анимешный
Pixel/retro - пиксель арт и стилизация под старые игры
Жанр.
Использовалась таксономия, разработанная Game Refinery and Michail Katkoff, где Категорией являются сущности типа "Казуальный", "Мидкор", "Казино", "Спортивные". Их подмножеством являются Жанры к примеру возьмем Puzzle для категории казуальных игр. Их мы используем в данном исследовании. Более мелкие подмножества под-жанров ("Match3 puzzle", "Action puzzle" и т.д.) могут быть использованы при более крупных выборках данных.
Доказательство гипотезы
Используя критерия критерий Крускала-Уоллиса изучили статистическую значимость перечисленных выше параметров, составили таблицу на которой соотнесли их с неделями и месяцами. В итоге получили, что наименьшее влияние оказывает графический стиль, но всё равно статистически значим. Используя эти параметры реализовали модель, предсказывающую зависимость места в фичере, от жанра, стиля, месяца и недели запуска.
Проверка.
Логичным этапом будет проверить эту гипотезу на практических данных. Собственно на картинке выше прикрепил графики худших и лучших результатов. Да, погрешность есть и ощутимая, но с другой стороны с этим уже можно работать, а используя больший набор данных и более точную модель можно получить лучшие результаты.
Источник (англ.): https://www.deconstructoroffun.com/blog/2018/12/10/are-launch-week-installs-even-predictable-on-mobile
UPD. Комментарий специалиста: "Когда идет речь про применения критерия, всегда указываются полученные значения p-value. В данном тесте ребята брали significance level = 0.1 = alpha, что дает достаточно низкую точность. Возможно это обусловлено данными, с которыми работали. Для большинства случаев это очень мало, обычно берут 0.95, в точных тестах стараются брать 0.99 или 0.999."
Лекцию писал по памяти и фото, некоторые моменты опустил (непосредственно обучение бота - оно достаточно поверхностное, для того чтобы взять и запилить у себя инфы будет мало).
Любопытные моменты.
- Если конкретный пользователь не справляется с уровнем за N попыток - ему высылается zip с корректировкой баланса выпадающих гемов. Наконец хоть кто-то официально подтвердил эту инфу
- Уровни не тестируются на субъективные критерии типа интересности, данный момент проверяется уже по отвалам на продакшне.
- Новые механики изначально тестируются на дочерних проектах, затем на небольшой части аудитории и только потом становятся доступны всем игрокам.
- Уровни передаются на ферму тестировщиков в Канаде, где 500 человек пытается их пройти
- Хорошим считается уровень, который смогли пройти 80% тестировщиков, если не попали в сложность - level-дизы переделывают
- Используют облачную платформу от google
Подходы к реализации бота:
Heuristics - эвристики, самый простой и быстрый способ, бот совершенно не похож на человека, но позволяет проверить потенциальную проходимость уровня
Исследование дерева по методу Монте-Карло (MCTS) - бот перебирает все возможные комбинации, что очень долго. Можно сравнить с тем, как проходит человек
Deep learning - берутся накопленные данные по сессиям игроков и на них обучаем бота, быстрый как эвристики, точнее чем MCTS
Reinforcement learning - в бота закладываются базовые принципы, а дальше он сам обучается проходить уровни, что имитирует поведение человека. Основная проблема в том, что в определенный момент бот начинает слишком хорошо играть и по скиллу выбивается за 80% игроков, на которых ориентируемся
Сложности в создании.
- Визуальные эффекты и анимации были интегрированы в логику, это замедляет обработку
- Вопрос ответственности за бота размазывается между разработчиками, QA и аналитиками
- Необходимо иметь наработанные данные по пользовательским сессиям, свои или купить
- Непросто воспроизвести поведение человека, быть не лучше и не хуже
Результаты.
- Уменьшилось количество проблем с уровнями, ловятся вылеты на большой скорости ходов
- Упростилось тестирование и производство новых уровней
Плэйтесты проводятся за минуты (требуется пара секунд на попытку)
- Улучшилось понимание поведения пользователей. К примеру при прочих равных они будут матчить наверху уровня или внизу и т.д.
Источник (нормального пока нет, "текстовый camrip" в моём исполнении): https://telegra.ph/Ispolzovanie-AI-dlya-sborki-urovnej-match3-12-26
Любопытные моменты.
- Если конкретный пользователь не справляется с уровнем за N попыток - ему высылается zip с корректировкой баланса выпадающих гемов. Наконец хоть кто-то официально подтвердил эту инфу
- Уровни не тестируются на субъективные критерии типа интересности, данный момент проверяется уже по отвалам на продакшне.
- Новые механики изначально тестируются на дочерних проектах, затем на небольшой части аудитории и только потом становятся доступны всем игрокам.
- Уровни передаются на ферму тестировщиков в Канаде, где 500 человек пытается их пройти
- Хорошим считается уровень, который смогли пройти 80% тестировщиков, если не попали в сложность - level-дизы переделывают
- Используют облачную платформу от google
Подходы к реализации бота:
Heuristics - эвристики, самый простой и быстрый способ, бот совершенно не похож на человека, но позволяет проверить потенциальную проходимость уровня
Исследование дерева по методу Монте-Карло (MCTS) - бот перебирает все возможные комбинации, что очень долго. Можно сравнить с тем, как проходит человек
Deep learning - берутся накопленные данные по сессиям игроков и на них обучаем бота, быстрый как эвристики, точнее чем MCTS
Reinforcement learning - в бота закладываются базовые принципы, а дальше он сам обучается проходить уровни, что имитирует поведение человека. Основная проблема в том, что в определенный момент бот начинает слишком хорошо играть и по скиллу выбивается за 80% игроков, на которых ориентируемся
Сложности в создании.
- Визуальные эффекты и анимации были интегрированы в логику, это замедляет обработку
- Вопрос ответственности за бота размазывается между разработчиками, QA и аналитиками
- Необходимо иметь наработанные данные по пользовательским сессиям, свои или купить
- Непросто воспроизвести поведение человека, быть не лучше и не хуже
Результаты.
- Уменьшилось количество проблем с уровнями, ловятся вылеты на большой скорости ходов
- Упростилось тестирование и производство новых уровней
Плэйтесты проводятся за минуты (требуется пара секунд на попытку)
- Улучшилось понимание поведения пользователей. К примеру при прочих равных они будут матчить наверху уровня или внизу и т.д.
Источник (нормального пока нет, "текстовый camrip" в моём исполнении): https://telegra.ph/Ispolzovanie-AI-dlya-sborki-urovnej-match3-12-26
