Русский
Русский
English
Статистика
Реклама

Product design

Перевод 20 психологических уловок в дизайне продуктов

31.08.2020 14:14:39 | Автор: admin

Совершенствование продуктов с применением когнитивных искажений и моделей убеждения.



Несколько лет назад коллега из моей бывшей компании (BlaBlaCar) познакомил меня с игрой Mental Notes. Разрабатывая какую-либо функцию, мы вместе с несколькими менеджерами по продукту, дизайнерами и разработчиками делали поведенческий анализ, во время которого старались понять, как и какие принципы поведенческой психологии можно применить в проекте.

Прошло несколько лет, и я до сих пор регулярно использую эти принципы в проектах, над которыми работаю как внештатный специалист по продуктам. В этой статье я поделюсь несколькими конкретными примерами того, как эти принципы применяются в реальных продуктах. Надеюсь, это поможет и вашим проектам!

Для справки: представленные далее темы и их описания взяты из колоды карт Mental Notes.


Социальное доказательство


В новых и незнакомых обстоятельствах мы склонны следовать образцам поведения тех, кто на нас похож.

Если в приложении нужно, чтобы пользователь выполнил необычное действие или завел новую некомфортную привычку, часто используют социальные доказательства: например, комментарии, оценки, отзывы и т. д.

Возьмем приложение для медитации Petit BamBou: оно в реальном времени показывает, сколько человек медитирует или медитировали за последние неделю, месяц, год и т. д. таким образом нам хотят показать, что медитация доступна каждому, и препятствий для занятий ею быть не должно.


Приложение для медитации Petit BamBou

Бесчисленные примеры социальных доказательств можно найти по мере приближения ко дну воронки покупок: например, соответствующие элементы часто расположены на странице с ценами:


Страницы с ценами в мобильных приложениях The Athletic и MasterClass

У более дорогого варианта часто бывает метка Самый популярный; иногда приводятся отзывы клиентов, призванные убедить купить наконец-то продукт или услугу.


Любопытство


Если человека подразнить интересной информацией, он захочет узнать больше!

Именно это делает фитнес-приложение Strava в своей функции Анализ темпа: вам дают предпросмотр того, как выглядит график, но не более того. Чтобы увидеть подробный анализ, нужно купить подписку Summit.


Анализ темпа в Strava триггер, побуждающий подписаться на премиум-версию

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


Веб-сайт Wall Street Journal

Показываемый небольшой отрывок должен быть достаточно интересным, чтобы посетители захотели стать подписчиками.


Узнать проще, чем вспомнить


Пережитое ранее легче узнать, чем вспомнить.

Именно по этой причине многие продукты дают пользователям выбор, а не просят вспомнить всё самостоятельно.

Например, Airbnb дает восемь различных критериев оценки места, где вы останавливались. Это позволяет получить от гостя достаточно количественной информации в случае, если он не даст словесный отзыв. Кроме того, благодаря такому подходу гостям проще вспомнить определенные моменты своего опыта. Если бы Airbnb не предлагал все эти категории, то оценки наверняка были бы менее аккуратными: гости оценивали бы только самые приятные и неприятные впечатления, а про середину забывали бы.


Система оценок Airbnb

Поэтому и страховой стартап Lemonade предлагает несколько предопределенных категорий дорогостоящих предметов.


Последний этап процесса запроса расценок в Lemonade

Благодаря такому подходу пользователям намного проще вспомнить, какие из их вещей могут стоить больших денег. Без визуальных подсказок вспомнить может быть сложнее поэтому в результате некоторые выпадут из процесса, и конверсия будет ниже.


Приятные моменты


Мы вспоминаем и положительно реагируем на небольшие, неожиданные и веселые приятные моменты.

Например, приложение для передачи геоданных Zenly отправляет пользователям множество комплиментов (Вы, пожалуй, здесь красивее всех) и пасхалок (лыжные склоны на карте) благодаря этому приложение очень любят в социальных сетях.


Скриншоты приложения Zenly

Внушительный список интерфейсных мелочей и пасхалок, которые могут вызывать приятные эмоции, можно найти на странице Little Big Details. Например, вот одна из моих любимых:


Если включить композицию из плейлистов Звездных войн на Spotify, то панель воспроизведения превратится в световой меч.


Привязка и приспосабливание


Принимая решения, мы чересчур полагаемся или привязываемся к одному аспекту или фрагменту информации.

Например, при покупке ноутбука на сайте Apple.com вам предлагают множество вариантов (200 $ мощнее процессор, 100 $ лучше видеокарта, 400 $ больше объем диска, 299,99 $ предустановленный Final Cut Pro X, 199,99 $ Logic Pro X). Если брать по отдельности, то за всё получится внушительная сумма. Но вы уже сделали мысленный скачок и платите за ноутбук 2799 $, поэтому кажется, что каждая опция не так уж и дорого, верно?



Тот же подход применим, когда вы платите 150 $ за продукты на кассе, и вам предлагают пожертвовать на благотворительность 0,50 $ не такая уж и большая сумма относительно всего чека, верно?


Умеренные трудности


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

По этой причине приложение для изучения языков Duolingo начинается с тестового задания чтобы первые уроки соответствовали вашему уровню и вы не заскучали.




Эстетика как удобство использования


Эстетичный дизайн часто воспринимается как более удобный в использовании.

Привлекательные элементы воспринимаются нами как более удобные в использовании. Приложение-календарь Sunrise, купленное Microsoft в 2015 г. за более чем 100 млн долл., на тот момент было лучшим в своей категории на платформах iOS и Android: тысячи пользователей хвалили его за понятный и удобный интерфейс.



Но действительно ли возможности Sunrise такие уникальные? В приложении было несколько удобных функций например, интеграция с событиями в Facebook. Но ничего сверхнеобычного там не было в том числе ничего, что календари от Apple или Google не могли бы скопировать за пару недель.

Пьер Валад, основатель Sunrise, ярый приверженец качественного дизайна продуктов. Он хотел сделать самое красивое приложение-календарь в мире именно поэтому Sunrise так полюбился пользователям.


Установление ценности


Мы ценим то, что стоит дороже.

Стоимость может выражаться и в деньгах, и во временных затратах.

В отношении денег можно привести множество не самых интуитивных примеров, когда компании повышали конверсию и (или) доход, просто подняв цены. В книге Не сходите с ума на работе Джейсон Фрайд и Дэвид Хайнемайер Хенссон рассказывают, что повышение начальной цены Basecamp с 29 $ до 99 $ в месяц позволило привлечь новых клиентов: иногда чем выше стоимость, тем более полезным кажется продукт.


Страница с ценами Basecamp

Если же рассматривать временную стоимость, то это основном актуально для мобильных игр или приложений, использующих геймификацию. В условно-бесплатных играх с покупками получение определенной функции или возможности может занимать много времени, поэтому она воспринимается как более ценная соответственно, за нее и платить будут готовы больше.


Боязнь потери


Мы не любим терять или упускать то, что уже имеем (даже если есть возможность получить больше).

Хороший пример этого психологического трюка часто можно увидеть при отмене подписки на некоторые сервисы. Например, если вы решите отменить тарифный план Adobe Creative Cloud, вы увидите следующее:


Процесс отмены подписки на Adobe Creative Cloud

Вам перечисляют всё, что вы потеряете и в смысле финансов (из-за платы за досрочную отмену), и в смысле функций (которыми вы больше не сможете пользоваться).

Боязнь потери широко используется в продуктах, которые можно попробовать без регистрации, частый случай в мобильных приложениях: например, если не зарегистрироваться в Angry Birds, вы потеряете весь ход игры.



Так же сделано и в Duolingo: если не зарегистрироваться, вы потеряете всю введенную исходную информацию, а также результаты первого пройденного вводного теста.

Боязнь потерь также широко эксплуатируется в условно-бесплатных приложениях с подпиской. Предположим, вы запустили вводный курс медитации в Headspace. Если вы прошли 10 занятий, можно сказать, что вы определенно намерены научиться медитации. Но если не оформить платную подписку, вы не сможете продолжить и потеряете накопленный момент.


Контраст


При анализе новой визуальной информации наше внимание притягивает то, что выделяется на фоне окружения.

Чтобы проиллюстрировать эту мысль, сравним этап заполнения сведений о пассажире двух сервисов покупки авиабилетов. С одной стороны у нас Opodo туристическое онлайн-агентство, созданное несколькими европейскими авиакомпаниями; с другой стороны Ulysse французский стартап, который стремится изменить подход к покупке авиабилетов.



Что нужно пассажиру на этом этапе? Спокойно указать свои данные, при необходимости добавить пару услуг и поскорее перейти на страницу оплаты.

На сайте Ulysse следующий шаг вполне очевиден оплата: при прокрутке страницы вниз синяя боковая панель остается на месте, цветовой контраст также отражает описанный приоритет намерений пользователя.

А вот в Opodo иерархия действий не очень хорошо отражена контрастом: разделы выбора места, отправки по электронной почте, добавления багажа и входа в учетную запись выделены так же, как переход к следующим этапам. Даже если такая иерархия направлена на увеличение дополнительных продаж (скорее всего, так и есть), она с большой вероятностью приведет к снижению общей удовлетворенности пользователей.


Регулярные события


Повторяющиеся события вызывают постоянный интерес, формируют ожидание и дают чувство принадлежности.

По этой причине в Headspace внедрили групповую медитацию: каждый день в определенное время все премиум-пользователи Headspace могут объединиться и вместе медитировать. Утверждается, что такая групповая медитация поощряет формирование и соблюдение режима медитации. Но еще это отличный способ обеспечить долгосрочное удержание пользователей и дать им чувство общности.




Последовательность действий


Мы с большей вероятностью выполняем сложные действия, если она разбиты на более мелкие задачи.

Хороших примеров разбиения сложного действия на последовательность простых бесчисленное множество. Продуктам часто удается разбить сложные процессы на удобные и быстрые действия. Например процесс публикации в Airbnb или процесс перевода денег в TransferWise.

В этой статье я рассмотрю процесс регистрации в онлайн-банке N26: выделив каждому этапу регистрации отдельный экран, разработчики создают впечатление, что открыть банковский счет проще простого!


Процесс регистрации в N26 в 2018 г.

На веб-сайте они даже дают такую рекламу: Банковский счет в N26 за 8 минут.



Конечно, сделать сложный процесс удобным для пользователя не значит просто выделить на каждое действие один экран. Нужно учитывать и другие принципы но эту тему я разберу в другой статье.


Ограниченный выбор


Мы с большей вероятностью сделаем выбор, когда вариантов меньше.

В последние годы некоторые компании смогли сформировать свое ценностное предложение на упрощении количества предлагаемых вариантов.

Например, прокат автомобилей Virtuo строит бизнес на том, что предлагает в каждом случае всего несколько автомобилей премиум-класса.


Результаты поиска в приложении Virtuo

Если вам дается ограниченный выбор, вы с большей вероятностью примете решение.

То же самое и с французской компанией по медицинскому страхованию Alan, подход которой к ценообразованию противоположен традиционной в этой отрасли модели, где всё запутанно и сложно. Alan дает единственное предложение, которое рассчитывается на базе возраста клиента. Философия простота прежде всего один из аспектов, за которые клиенты любят Alan.


Репутация


Мы больше заботимся о своем поведении, когда это может повлиять на то, как нас воспринимают сверстники и общество.

В качестве примеров продуктов, опирающихся на понятие репутации, можно назвать Reddit и StackOverflow: за публикации и комментарии пользователи либо зарабатывают репутацию (получая положительные голоса, значки, трофеи, медали), либо теряют ее (получая отрицательные голоса).



В результате каждый пользователь стремится не только публиковать актуальную информацию, но и приносить пользу другим, а также вести себя вежливо и общаться конструктивно.


Авторитет


Мы предпочитаем следовать примеру и советам признанного авторитета.

Некоторые продукты зарабатывают тем, что дают пользователям компетентную информацию в областях, где те разбираются не очень хорошо.

Например, AirHelp помогает клиентам затребовать компенсацию за задержку или отмену авиарейса. Юристы сервиса знают законодательство различных стран мира (относящееся к авиасообщению) и помогут вам затребовать как можно больше денег. Но как можно быть уверенным, что кто-то, кого вы не знаете лично, может помочь вам вернуть деньги?

AirHelp понимает эту проблему поэтому они добавляют в процесс запроса элементы, обосновывающие его авторитетность:

  • Они упоминают регламент EC261.
  • Они дают возможность пообщаться с человеком: Джейн ваш помощник в AirHelp.



Первая страница процесса оформления заявки на компенсацию на сайте AirHelp

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


Ограниченный доступ


Мы естественным образом хотим то, что считаем эксклюзивным или принадлежащим избранному обществу.

Думаю, не нужно напоминать о шумихе, которая возникла вокруг Inbox альтернативного приложения электронной почты от Google: когда оно вышло в ограниченный доступ пару лет назад, каждый пытался заполучить приглашение.



Приложение Inbox в итоге кануло в лету: компания Google закрыла его в 2019 г. Сервис предлагал пару новых (в сравнении с Gmail) функций, но ожидаемой революции в электронной почте он не произвел. Тем не менее, продвижение этого продукта на рынке было успешным. Подобный ажиотаж сейчас наблюдаются вокруг Superhuman и Clubhouse.

Еще один пример ограничения доступа сообщество дизайнеров Dribbble.


Главная страница Dribbble

Просматривать страницы Dribbble может кто угодно, но чтобы опубликовать свою работу, нужно получить приглашение от участника платформы это помогает не только поддерживать определенный уровень качества, но и придает сервису Dribbble эксклюзивности по сравнению с другими сообществами.


Самовыражение


Мы ищем возможность выразить свою личность, свои чувства и мысли.

Это очень мощный принцип, который работает во всех возрастных группах.

Приложения, ориентированные на подростков, почти всегда дают возможность настроить профиль: изменить цвета, аватар, добавить классные аксессуары и т. д. Примеры Pokmon Go, Snap (с Bitmoji) и (совсем недавно) Stadium Live.


Настройка аватара в Stadium Live

Поэтому и Facebook придумал функцию Рамки чтобы пользователи могли выражать себя: добавлять рамки профиля и таким образом демонстрировать поддержку спортивной команды, благотворительной деятельности или чего-либо еще.


Настраиваемые рамки для фото в профиле Facebook

Среди SaaS-инструментов также можно найти такие примеры: Trello дает пользователям возможность менять цвет и изображение фона, Slack предлагает множество тем для настройки интерфейса.

Использование принципа самовыражения укрепляет связь между продуктом и пользователями.


Дефицит


Если что-то ограничено в доступности или рекламируется как дефицитное, мы склонны придавать этому более высокую ценность.

Безупречное мастерство в применении этого принципа демонстрирует Booking.com: при просмотре гостиниц на странице поиска нередко можно увидеть несколько визуальных подсказок, указывающих на дефицитное предложение.



В этом разделе следующая информация указывает на то, что гостиница скоро будет полностью забронирована:

  • Забронировано 27 раз за последние 6 часов (эта фраза также применяет принцип социального доказательства).
  • Большой спрос: на сайте осталось всего 7 номеров!

В целом на сайтах, где что-то продается, эта уловка часто используется, чтобы подтолкнуть к незапланированной покупке и повысить конверсию.


Юмористический эффект


Поданная с юмором информация запоминается легче и радует пользователя.

Citymapper приложение для навигации по городу, альтернатива Google Картам. Множество своих поклонников сервис заполучил отчасти благодаря юмору и причудливым формулировкам.

Например, при поиске маршрута из пункта А в пункт Б иногда можно использовать функции Телепорт, Катапульта или Реактивный ранец и тогда Борис Джонсон переместится из А в Б менее чем за 5 секунд.


Предложение катапультировать Бориса Джонсона и правда звучит забавно.

Citymapper и платную подписку строит частично на таком юмористическом подходе.


Платная подписка Citymapper Citymapper CLUB

Один из аргументов в пользу платной подписки Citymapper CLUB поддержка разработчиков в том, что они делают, в том числе, чтобы они могли сохранять свои причуды ведь это тоже важно.


Непредсказуемые вознаграждения


Случайные вознаграждения сильные мотиваторы: они кажутся редкими и отличаются непредсказуемостью (а также реже противоречат внутренней мотивации).

Один из элементов, благодаря которым Snapchat завоевал пользователей, это трофеи.


Трофеи в Snapchat

В разделе трофеев представлены награды, собранные вами в зависимости от ваших действий. Но вам не говорят ни как получить более крупный трофей за определенное действие, ни какие еще трофеи можно выиграть это и делает их непредсказуемыми вознаграждениями. Snapchat награждает трофеями за необычное использование приложения например за отправку снимка между 4 и 5 часами утра или с фильтром, показывающим температуру ниже нуля.

Другие приложения например, Tinder, в своей стратегии по дифференциации тоже сделали ставку на непредсказуемые вознаграждения. Листая Tinder, вы никогда не знаете, что увидите дальше: заложив таким образом непредсказуемость в саму основу приложения, разработчики сделали его очень затягивающим.

Подробнее о непредсказуемых вознаграждениях и геймификации в этой колоде в целом пишет Mozza: Mobile Gamification How The Best Apps Nailed It (Waze, Duolingo, Tinder, Snapchat, LinkedIn, Zenly).



Надеюсь, вам понравились эти примеры! Может, и вы знаете примеры реализации психологических принципов в дизайне продукта? Расскажите о них!

Если вас заинтересовали Mental Notes и соответствующая карточная колода, то, к сожалению, заказать ее уже нельзя. Но похожую информационную подборку можно найти здесь: плакат Persuasive Patterns Poster от UI Patterns.

Если вам понравилась эта статья и вас интересует применение психологии в дизайне продуктов, я рекомендую зайти на отличную страницу Growth.design The Psychology of Design, где составлен еще более длинный список (101 пункт!) когнитивных искажений и принципов, влияющих на удобство пользования.


О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее
Подробнее..

Перевод Каждый дизайнер желает знать какая память бывает и в чем ее несовершенство

02.10.2020 12:06:25 | Автор: admin

Случалось ли вам забывать пароль, который только что придумали? Попадались ли вам мобильные и веб-приложения, пользоваться которыми было легко и удобно с первой же минуты? У каждого из нас ежедневно случаются провалы в памяти той или иной степени. И дизайнеры должны понимать, как работает человеческая память и как учитывать в дизайне кривую забывания и кривую обучения пользователей.

Возможности человеческой памяти ограничены

Мы должны признать, что наша память несовершенна. У памяти и внимания, как и у зрительной системы, есть сильные и слабые стороны.

У человека два вида памяти.

Первый рабочая память: кратковременное хранилище небольшого количества информации.

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

Часто говорят, что рабочая память это временное хранилище активной информации, которая либо поступает из окружающей среды, либо извлекается из долговременной памяти. А долговременная память это относительно пассивное хранилище информации, которое активируется только при необходимости.

Рабочая память малоемкая и неустойчивая. Специалист по когнитивной психологии Джордж Миллер в 1956г. в книге о волшебном числе 7 предположил, что средний человек может удерживать в краткосрочной памяти около 7объектов (плюс-минус 2).

Если дизайн разработан таким образом, что пользователю в рабочей памяти требуется в течение более чем 7секунд держать более 3объектов или 1объект в течение более чем 70секунд, то будут появляться ошибки: информация в рабочей памяти очень легко теряется.

Если объекты в рабочей памяти не группируются и не повторяются, они исчезнут из фокуса внимания. Исчезновение объектов из рабочей памяти это забывание: например, вы пошли за чем-то в другую комнату, но, оказавшись на месте, не можете вспомнить, зачем туда шли.

У долговременной памяти множество слабых мест и она ненадежна. Память этого вида во многом отличается от рабочей. Объекты в долговременной памяти хранятся в мозгу, распределенные по многим его участкам. Хранящаяся в долговременной памяти информация не исчезает, но постепенно затухает, теряя силу. (Джонсон, 2014; подробнее в книге.)

  • Подверженность ошибкам. Наша память кодируется сетями действующих совместно нейронов, а большое количество нейронов это множество различных их комбинаций, поэтому долговременная память может давать несколько версий событий и получается, что она не представляет собой высококачественную запись пережитого. С помощью своеобразного сжатия, при котором отбрасывается большой объем информации (изображения, концепции, события, ощущения, действия) запоминаемый объем сокращается до комбинаций абстрактных объектов.

  • Определение веса эмоциями. Бывало ли такое, что вы увидели кошку во дворе и сразу же вспомнили, что у вас была похожая в детстве? У человека, особенно взрослого, сильные воспоминания часто эмоционально привязаны к объекту увидев такой объект, вы наверняка вспомните связанные с ним события.

  • Изменения задним числом. Некоторые детали в долговременной памяти при извлечении могут отбрасываться, поскольку не соответствуют вашему общему представлению о событии.

Факторы, влияющие на работу памяти

Понимание характеристик рабочей и долговременной памяти поможет дизайнеру понять, как проектировать пользовательский интерфейс с учетом особенностей механизмов запоминания, свойственных человеку.

Перечислю некоторые факторы, которые влияют на рабочую память:

  • Количество объектов. Если требуется запомнить много предметов, сделать это сложно если только вы не примените высокоуровневую стратегию, которая поможет консолидировать объекты и освободить место в рабочей памяти. Консолидацию можно провести объединением объектов в порции, с чем наш мозг отлично справляется. Объединение в порции основной метод уменьшения количества объектов в рабочей памяти и увеличения ее практической емкости.

На этих рисунках одинаковое количество букв. Какой из них запомнить легче: левый или правый?На этих рисунках одинаковое количество букв. Какой из них запомнить легче: левый или правый?
  • Сходство и путаница. Если объекты похожи, их можно легко объединить в одну порцию.

Какое изображение запомнить легче: левое или правое?Какое изображение запомнить легче: левое или правое?
  • Повторение. Повторение объектов может приводить к ошибочному воспоминанию в рабочей памяти. Например, если нужно запомнить число 5774, вы можете запомнить его как 5744.

С другой стороны, если многократно повторять информацию в рабочей памяти, она с большей вероятностью перейдет в долговременную, и ее можно будет извлекать оттуда, когда понадобится. Кроме того, такое повторение помогает сформировать привычку вспоминать эту информацию.

  • Прерывание. Прерывание мешает вносить информацию в рабочую память особенно когда внимание нарушается во время работы с информацией.

Факторы, влияющие на получение информации из долговременной памяти:

  • Сила объектов в долговременной памяти. Сила определяется востребованностью и актуальностью информации. Востребованность это то, как часто информация используется или извлекается из долговременной памяти. Актуальность определяется тем, как давно вы извлекали эту информацию из долговременной памяти последний раз.

  • Связи между объектами в долговременной памяти. Если нужная информация связана с другими объектами в памяти, то вероятность ее получения выше.

  • Когда информация повторяется в неизменном контексте в течение некоторого времени, то ее воспоминание с большей вероятностью превратится в привычку. Привычка может развиваться через повторение и постоянное извлечение информации в определенном контексте с течением времени и с участием вознаграждения.

Подходы в дизайне интерфейса, облегчающие работу памяти

Мы уже выяснили, что рабочая память хранит мало и недолго, а у долговременной памяти много слабых мест и на первых этапах запоминания она ненадежна. Дизайнер должен помочь пользователю запомнить важную информацию до момента, когда она понадобится. Нельзя требовать запоминать состояние системы или выполненное действие. Вот некоторые подходы, которые помогут снизить нагрузку на рабочую память пользователей (Lee, Wickens, Liu, Boyle, 2017; подробнее в книге):

  • Снижение нагрузки на рабочую память. Как правило, следует избегать длинных строк, в том числе из произвольных цифр. Если есть возможность быстрее разгрузить рабочую память, ей следует воспользоваться. Например, после того как пользователь ввел поисковый запрос и открылись результаты, его внимание естественным образом переключается с запроса на результаты неудивительно, что при этом пользователь часто забывает, что конкретно он искал. Поэтому при оформлении результатов поиска нужно в поле поиска давать только что введенный пользователем запрос это снизит нагрузку на рабочую память.

Примеры отображения предыдущих поисковых запросов в Google Картах и Pinterest.Примеры отображения предыдущих поисковых запросов в Google Картах и Pinterest.
  • Визуальное эхо. Пользователь с легкостью может повторно просмотреть визуальный материал. Поэтому, давая звуковой контент, необходимо также делать визуальное эхо, передающее то же сообщение: визуальный материал можно легко повторно просмотреть, а звуковой нет.

  • Подсказки для задач из нескольких этапов. Если задача выполняется в несколько этапов, нужно давать визуальное напоминание о том, какие этапы уже пройдены. Если действия или их результат похожи, визуальные напоминания будут очень полезны.

Автор Vishnu Prasad, источник https://dribbble.com/shots/9866905-Final-steps-in-OnboardingАвтор Vishnu Prasad, источник https://dribbble.com/shots/9866905-Final-steps-in-Onboarding
  • Буквы вместо цифр. Обычно буквы человеку запомнить проще, чем цифры. Поэтому, например, рабочий номер телефона лучше записывать не как 467-968-2378, а как 467-YOU-BEST.

  • Снижение путаницы в рабочей памяти. Чтобы снизить путаницу, можно обеспечить пространственное разделение. Например, при проектировании интерфейса его можно разбить на части таким образом мы даем мозгу зацепку для различения сигналов и снижения путаницы между объектами.

  • Избегайте отрицательных указаний. В дизайне следует давать утвердительные указания и избегать отрицательных: отрицание это дополнительная порция, которую необходимо хранить в рабочей памяти, даже если она нормально воспринимается при чтении. Пользователь забудет отрицательное указание с большей вероятностью, чем утвердительное.

Чтобы дизайн помогал работе долговременной памяти, нужно в первую очередь избегать разработки систем, которые повышают нагрузку на память этого вида. Для этого можно применять следующие подходы (Lee, Wickens, Liu, Boyle, 2017; подробнее в книге) как вы увидите, именно так работают многие интерактивные системы.

  • Поощряйте пользователей использовать информацию регулярно. Частое воспоминание повышает силу информации в долговременной памяти.

  • Стандартизируйте шаблон проектирования. Стандартизация позволяет создавать более запоминающиеся схемы и ментальные модели. Если элементы управления, панели, символы и рабочие процедуры можно каким-либо образом стандартизировать, пользователь с большей вероятностью восстановит их из долговременной памяти.

  • Давайте напоминания в электронном или печатном виде. Например, можно сформировать контекст для командных языков и меню. Если пользователь не может вспомнить пароль, дайте возможность обратиться в поддержку или запустить процедуру восстановления.

Примеры из Google и Instagram.Примеры из Google и Instagram.
  • Развивайте полезные привычки. Разрабатывая интерфейс, мы учитываем его контекст, повторяемое использование функций и вознаграждаем пользователей, с тем чтобы закрепить нужное поведение и пресечь нежелательное.

  • Поддерживайте правильные ментальные модели. Обеспечив в дизайне очевидную и понятную работу функций, мы поможем пользователю построить ментальные модели.

  • Единообразная работа в рамках системы и с другими приложениями. Чем единообразнее работа разных функций и действия с объектами разных типов, тем меньше пользователю нужно запоминать. В интерфейсе со множеством исключений и низким уровнем единообразия между функциями и объектами различных типов пользователю приходится хранить в долговременной памяти особенности каждой функции и каждого типа объектов, а также правильный контекст использования. Необходимость запоминания большого количества информации затрудняет изучение таких интерфейсов. (Джонсон, 2014; подробнее в книге.)

Дизайн должен соответствовать знакомой пользователю ментальной и концептуальной модели. Простой пример: круглые переключатели позволяют выбрать один вариант, флажки в квадрате несколько. Источник https://www.justinmind.com/blog/mental-models/

Литература:

John D Lee, Christopher D. Wickens, Yili Liu, Linda Ng Boyle (2017). Designing for People: An Introduction to Human Factors Engineering 3rd Edition.

Джефф Джонсон (2014). Умный дизайн. Простые приемы разработки пользовательских интерфейсов.

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимаетсялокализацией игрприложений и сайтовна 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаемрекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее..

Из песочницы Наука о пользовательском опыте. Использование когнитивных искажений в разработке качественных продуктов

28.07.2020 18:07:12 | Автор: admin
image

Содержание


Введение. О чем эта статья
Цели и дисклеймеры
Часть 1. Хороший продукт
Часть 2. Пользовательский опыт (UX). Что это?
Часть 3. Архитектура выбора
Часть 4. Архитектор выбора
Часть 5. Когнитивные искажения и Пользовательский опыт
Ссылка на полную версию UX CORE (105 примеров использования когнитивных искажений в менеджменте команд и продуктов)
Часть 6. Наши дни
Часть 7. Не только искажения
Часть 8. Эпилог
Часть 9. Материал, качественно дополняющий эту статью

Введение. О чем эта статья


В этой статье мы поговорим о когнитивной психологии, поведенческой экономике и об ошибках (искажениях) нашего мозга. Мы посмотрим как понимание ошибок мозга и моделей человеческого поведения может помочь нам обеспечить высококачественный пользовательский опыт (UX) в цифровых продуктах. В основном, мы поговорим о программном обеспечении для мобайл и десктоп платформ. Внимательный же читатель сможет применить эти знания широко за рамками как этих платформ, так и программного обеспечения вообще.

Последние десять лет моим основным хобби было изучение того, как люди принимают решения. Этот путь привел меня к изучению широкого спектра когнитивных наук, в частности, когнитивной психологии и неврологии.

В какой-то момент своей жизни я перепрофилировался из технического специалиста в IT-сфере, коим я проработал около 6 лет (LAN/WAN/DevOps/InfoSec), в Product Manager-а. Моей основной деятельностью на этой должности является анализ ожиданий и принятых решений пользователей с целью создания более комфортного и желанного продукта.

Проверка и оценка практической пользы информации этой статьи заняла около пяти лет работы в разных компаниях и проектах различной степени сложности (от вебсайтов-визиток, до разработки первой в мире левитирующей камеры, экосистемы для киберспортивных дисциплин, тотализатор для киберспорта, ПО для гражданской авиации и крупнейшей в мире платформы цифрового издательства). В сумме я проработал более чем с сотней специалистов различного профессионального уровня, что принесло колоссальную пользу в виде ряда подтвержденных и опровергнутых концептов; лишь полезная часть которых будет описана далее.

Цели и дисклеймеры


Изложенный здесь материал лучше всего будет понятен опытным специалистам в IT-сфере, занимающимися разработкой и дизайном ПО на регулярной основе. Тем не менее, пользу от этого материала почерпнет любой читатель вне зависимости от рода деятельности.
Цели, которыми я задаюсь в этой статье выглядят так:

  • показать четкие доказательства важности глубоких знаний в психологии для работы в качестве менеджера по продукту;
  • дать определение понятию UX (Пользовательский опыт) с позиции психологии и поделиться наиважнейшим источником знаний для создания качественного UX;
  • показать механизм оценки грамотности продакт менеджеров (и не только);
  • побудить инвесторов больше инвестировать в продукты, в основе которых лежит когнитивная психология и поведенческая экономика;
  • предоставить продакт менеджерам дополнительные аргументы в поддержку их идей, которые, часто являясь верными, увы, блокируются техническими специалистами из-за непонимания полной картины и технического склада ума;
  • показать с другого угла скучные исследования, которые пылятся на полках библиотек, акцентируя чрезвычайную важность этих материалов для будущего разработки ПО;
  • побудить психологов и экономистов взглянуть в сторону продакт менеджмента как возможной опции смены карьерного направления. Мир IT нуждается в вас гораздо больше, чем в диванных аналитиках и псведо-менеджерах с MBA и PMP.

Я намеренно опускаю такие бизнес вопросы как целесообразность создания продукта, анализ рынка, анализ конкурентов и прочие, так как они имеют мало общего с UX. Продукт может быть качественным вне зависимости от спроса, от целесообразности его выпуска на рынок и силы конкурентов.

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

Размер статьи выдался куда больше, чем я ожидал. Тем не менее, вы получите доступ к синопсисам наиважнейших исследований в неврологии и когнитивных науках, проведенных за последние 70 с лишним лет. Детальное изучение этих исследований и сопоставление их с условиями реального мира заняло бы у вас, по меньшей мере, два года регулярного обучения.

Часть 1. Хороший продукт


Мы не будем вдаваться в абстрактные рассуждения о том, что такое продукт, а-ля это то, что приносит пользу его владельцу, рынку и конечным потребителям. Много людей будут не согласны с идеей, что качественный продукт может оставаться качественным даже провалившись на рынке, поэтому я отдельно скажу пару слов об этом.

Итак, чуть выше я убрал вопросы про рынки, конкурентов и целесообразность продукта, потому что я исхожу из того, что качественный продукт это, прежде всего, продукт без внутренних противоречий. Такой продукт идеально связан как идеологическими его составляющими (история создания, его миссия, все использованные изображения, текстовые и печатные материалы используемые для его разработки и продвижения и прочее), так и техническими (back end, пользовательский интерфейс, элементы взаимодействия и дизайн, бизнес цвета, инструкции для работы службы поддержки клиентов, tone of voice of the company и много другого).

При всем при этом важно понимать, что качественный продукт может выйти на рынок, оказаться никому не нужным, стать историей и тем не менее быть качественным продуктом.
Причин неудачи может быть широкое множество, например:

  • неудачный тайминг (изменилась коньюнктура на рынке, люди еще не осознали всю серьезность проблемы, решаемой продуктом и т.п.);
  • человеческий фактор (утечки внутри компании, уборщица, опрокинувшая ведро рядом с серверами в день релиза и т.п.);
  • слабые управленческие навыки руководства (основатели компании слишком поздно начали обсуждать распределение прибыли, что создало конфликты; чрезмерный нажим на команду разработчиков повлек массовые увольнения и сорвал переговоры об инвестировании и пр.)
  • банальное невезение, важность которого повально игнорируется как новичками, так и экспертами в бизнесе (Черные Лебеди Н. Нассима Талеба).

Поэтому, для того, чтобы не вдаваться в унылые философские спекуляции по бизнес вопросам, в этой статье мы будем о них помнить, временами будем к ним прикасаться, но не будем на них фокусироваться.

Часть 2. Пользовательский Опыт (UX). Что это?


Так как на данный момент понятие UX гораздо чаще относят к UI дизайну, моим оппонентом в обсуждении данного вопроса будет Джо Натоли. Джо ветеран-дизайнер с опытом работы более 30 лет, один из самых популярных в мире IT экспертов по UXD (User Experience Design), автор ряда книг, а также самых популярных видео-курсов по UX на Udemy. Натоли провел более тридцати лет консультируя по вопросам дизайна пользовательского опыта (UXD) компании из списка Fortune 100, 500 и правительственные организации. На своем вебсайте он называет себя User Experience Evangelist, значит, я могу ссылаться на его утверждения, высказанные публично в его книгах и видеоуроках.

В одном из своих уроков, где господин Натоли объясняет понятие User Experience, он ссылается на Питера Мерхольца:

Питер Мерхольц, который является деловым партнером Джесси Джеймса Гарретта (автора термина Пользовательский опыт и книги Элементы пользовательского опыта Библии UX всех времен), говорит, что пользовательский интерфейс (UI) является компонентом пользовательского опыта. Но есть гораздо больше, и это гораздо большее включает в себя вещи, которые имеют отношение к когнитивной науке. Это связано с людьми: что они хотят, что им нужно, что они хотят использовать и почему они реагируют на вещи так, как они реагируют.

Другой UXD эксперт Билл ДэРушэ (Старший продакт менеджер / Workflow Experience Lead at Zendesk). В обсуждении UXD говорит следующее: Для UXD даже не нужен экран. UXD это любое взаимодействие с любым продуктом, любым элементом, любой системой .

Просмотрев все доступные материалы выше упомянутых, а также ряда других UXD специалистов, я заметил одну важную закономерность они постоянно используют научные достижения когнитивных психологов, неврологов и поведенческих экономистов. Практически вся идеологическая часть, весь back end их речей основывается на когнитивных науках, однако, на это редко делается акцент. Чаще всего они не хотят усложнять материал для слушателя и слишком часто используют фразы, типа мы используем те вещи, которые понимаем, что ставит грубые рамки, не позволяющие учитывать множество важных факторов.

К примеру, даже, если у нас есть доступ к приложению, мы практически никогда не будем его использовать, если ожидаемые от нас действия идут в разрез с ценностями социально-культурной среды, с которой мы себя отождествляем. Другой же UXD специалист может тонко заметить это, сказав: Чтобы быть приемлемым, визуальный дизайн должен соответствовать социально-культурным ценностям, что звучит красиво, однако, не показывает всей картины, которую нужно учитывать в принятии решений по продукту.

Прошу заметить, я ни в коем случае не говорю, что книги и видеоуроки бесполезны. На данный момент, для того, чтобы человек понял что такое UX и как с ним работать, ему необходимо пройти через множество разбросанных материалов в книгах и видеоуроках. Я же в этой статье хочу показать научные истоки, на основе которых все эти книги и уроки создаются.

Итак, практически все UXD эксперты сходятся во мнении, что UX это понятие, выходящее широко за рамки интерфейсов. Их общее мнение сводится к тому, что UX это фактический опыт, получаемый пользователем при его интеракции с продуктом/компанией.

В силу же того, что опыт- это результат интерпретации чувств, возникающих у человека при интеракции с продуктом/компанией, создание пользовательского опыта это психологическая игра с целью подталкивания пользователя к определенной мысли, эмоции, действию или выбору. И здесь мы вплотную подходим к такому понятию как архитектура выбора.

Часть 3. Архитектура Выбора


Понятие архитектура выбора популяризировалось после совместного труда Ричарда Талера и Касса Санстейна над Теорией Подталкивания. Вместе они написали книгу Подталкивание (англ. Nudge Theory), которая позволила множеству разных специалистов, ответственных за создание выбора для пользователей, взглянуть на свою работу под новым углом. Чтобы читатель понимал значимость вышеуказанных персон, приведу здесь их краткое описание:

Касс Санстейн со-автор теории подталкивания. После выхода книги Подталкивание президент Обама предложил Санстейну место в Отделе информации и регуляторной политики. Это дало исследователю широкие возможности внедрять идеи психологии и поведенческой экономики в работу правительственных учреждений. 10 сентября 2009 года Санстейн был назначен на пост главы OIRA, которое является частью Административно-бюджетного управления Администрации президента. OIRA осуществляет надзор за реализацией государственной политики и рассматривает проекты нормативных актов. Пост главы OIRA считается одним из наиболее влиятельных, учитывая его возможность влиять на тексты принимаемых законов. СМИ неофициально называют этот пост regulatory czar. OIRA Санстейн возглавлял до 21 августа 2012 года.

В августе 2013 года Санстейн вошел в состав комиссии по надзору за АНБ (англ. Review Group on Intelligence and Communications Technology). Кроме него в комиссии еще два бывших работника Белого Дома: крупейший специалист по контртерроризму и кибервойнам Ричард Алан Кларк и бывший заместитель директора ЦРУ.

Ричард Талер автор Теории Подталкивания, лауреат премии по экономике памяти Альфреда Нобеля 2017 года за вклад в область поведенческой экономики. При правительстве Великобритании было создано новое подразделение, чья цель применять принципы поведенческой науки к решению государственных задач. Официальное название подразделения Группа поведенческого инсайта, но чаще и в правительстве, и за его пределами ее называют Группа подталкивания. Талер является одним из советников этой группы.

Итак, эти господа много лет работали над теорией, в которой тщательно описали как можно подтолкнуть человека к определенному выбору, используя когнитивные искажения (о них мы поговорим совсем скоро). Идея и описанные методы настолько понравились руководствам разных стран (не только США и Англии), что были созданы специальные гос.подразделения с целью редактирования законопроектов для подталкивания граждан к более здоровому образу жизни и более здоровой пище не ограничивая их в выборе.

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

Фактически, архитектура выбора это описание мыслей и когнитивных искажений, которым подвержена целевая аудитория с одной стороны, и решения по расстановке элементов участвующих в выборе с другой.

image

При грамотном понимании обеих частей этого уравнения, архитектор выбора может плавно подтолкнуть пользователя/потребителя в нужном для компании направлении.

Часть 4. Архитектор Выбора


Понятие Архитектор выбора ввели Санстейн и Талер, описав его следующим образом:
Архитектор выбора это тот, кто отвечает за организацию контекста, в котором человек принимает решения.

Талер и Санстейн доказывали эффективность подталкивания на примере принятия решений при разработке законопроектов. В таком контексте, работа архитектора выбора крайне сложна, так как на него налагаются колоссальные юридические и моральные ограничения.

Нас же с вами интересует IT сфера, в частности, разработка разного рода приложений. В этой сфере тоже имеются определенные ограничения, однако, их гораздо меньше, что дает возможность архитектору выбора реализовать весь свой научный потенциал.

В такой компании несложно понять, кто является архитектором выбора. Это тот, кто занимается организацией контекста, в котором человек (пользователь) принимает решения в приложении, либо просто Product Manager.

Организация контекста, в котором пользователи принимают решения это ключевая обязанность Product Manager-а. Для создания лучших условий для выбора и подталкивания пользователей к выбору выгодному бизнесу, Product Manager обязан знать модели человеческого поведения и, что наиболее важно, отклонения в этом поведении. Именно такие систематические отклонения в восприятии, мышлении и поведении человека называются когнитивными искажениями. Их можно считать bug-ами, потому что бОльшая часть этих искажений описывает сбои в обработке и анализе информации.

Часть 5. Когнитивные Искажения и Пользовательский Опыт


Итак, мы дошли до основного материала статьи.

Далее я выложу ряд известных науке когнитивных искажений, которые были научно выведенны и задокументированны. Отдельной ссылкой я выложил онлайн инструмент, который я назвал UX CORE. В нем вы сможете найти 105 когнитивных искажений с примерами их использования в менеджменте и в разработке приложений.

Для структурирования материала я использовал Кодекс когнитивных искажений, категоризированный и структурированный Бастером Бэнсоном в 2016м году (по ссылке выше дизайн Джона Манукяна III). Помимо новой формы презентации искажений, к каждому из них я добавил пример использования в разработке программного обеспечения, а в некоторых случаях- в управлении командой. Были учтены самые современные практики по управлению командами и компаниями (PMP, PMI ACP), а также разработке продукта.

Многие примеры, которые я описал далее, довольно радикальны. Это было сделано намеренно, т.к. в соответствии с эффектом контраста, такие примеры запоминаются лучше. Основная цель примеров дать пищу для размышлений. Я не стремился добиться их абсолютной точности, т.к. для такого примера необходимо тщательное описание рабочей ситуации и поставленной задачи, а это заняло бы десятки страниц материала. Я глубоко убежден, что данная работа поможет читателям узнать для себя много нового и сделать определенные выводы.

Клики на названия искажений в таблице открывают поп-апы. Все ссылки в поп-апах открываются в новых вкладках браузера, поэтому можете серфить контент спокойно, не беспокоясь случайно что-то закрыть.

Итак, как верно заметил Бастер Бенсон, суть изложенных когнитивных искажений в том, чтобы помочь нам решить 4 проблемы:

  • Работа с большим объемом данных. Когда много информации;
  • Расплывчатость, недостаточность данных. Когда не хватает смысла;
  • Недостаточно времени. Когда быстро реагируем;
  • Разные приоритеты по информации. Когда запоминаем и вспоминаем.

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

#1 Эвристика доступности [P]
Процесс, при котором человек оценивает частоту или вероятность события по легкости, с которой примеры или случаи приходят на ум, т.е. легче вспоминаются.

В разработке приложений понимание этого искажения необходимо для последовательного проектирования интерфейсов, дизайна контента и коммуникации с пользователем. Если действие, которое нам нужно, чтобы пользователь совершил, ассоциируется у него с чем-либо негативным (особенно, если это освещается или освещалось в СМИ не так давно), вероятность того, что действие будет совершено сильно снижается. Понимание этого позволяет проектировать контент (текст, изображения и т.д.), так, чтобы он ассоциировался у человека только с тем, что нам нужно. Это же искажение позволяет нам задуматься над текущей коньюнктурой в мире и на рынке, чтобы выбрать наиболее удобную тональность наших сообщений.

Другой пример: биткоины и разного рода ICO. Тема криптовалют так часто негативно форсировалась в СМИ, что в какой-то момент инвесторы просто решили избегать всего, что с этим связано, не вдаваясь в детали. Простые же пользователи поняли, что их ослепленность повышенной волатилностью этих рынков не привела ни к чему хорошему. Хайп по этой теме сошел на нет, а множество действительно качественных блокчейн-проектов столкнулись с серъезными сложностями в развитии из-за сильно искаженной репутации всего, что ассоциируется с блокчейном, биткоином и крипто в целом.

Последний пример это то, что я выбрал тему проектирования ПО и блокчейн технологий для описания эвристики доступности. Первая тема очевидна для меня в силу моей профессии (product manager), вторая же тема просто с легкостью пришла мне на ум, когда я задал себе вопрос: Какое направление в IT было полно хайпа, а потом быстро сошло на нет?.

#4 Эффект знакомства с объектом [P]
Психологический феномен выражения симпатии к объекту только на основании имеющегося знакомства с ним. Чем чаще человек видит кого-то, тем приятнее и привлекательнее ему кажется этот человек.

Важно подчеркнуть, что речь идет не только о людях, а об объектах вообще.
Предположим, у нас есть успешное приложение, которое мы хотим продвинуть в Испании. Если мы используем в наших цифровых промо-материалах описание нашего приложения в цветах Испанского флага (ненавязчиво, конечно), это даст ощущение знакомого у испаноязычных читателей. Другой пример мы размещаем очень блеклое, монохромное изображение Саграда Фамилия на фон белой страницы, на которой на испанском описываются преимущества нашего приложения. Если в текст добавить величественные, высокопарные слова вкупэ с фоновым изображением, они вполне дадут эффект знакомства и повысят вероятность конвертации потенциальных пользователей в фактических.

Другой пример: мы используем в нашем приложении стандартные кнопки, стандартных для нас цветов и размеров, и весь наш интерфейс универсален. Приходит день, когда нам нужно оповестить наших пользователей о новых функциях приложения. Мы можем сделать это ненавязчиво, используя стандартный pop-up, с такими же кнопками которые используются в других частях приложения. Либо, наоборот, если нам нужно заострить внимание пользователя таким образом, чтобы у него было стойкое чувство новизны мы отходим от нашей стандартной системы и используем слегка другой цвет окна и слегка другой размер кнопок в поп-апе. При виде такого окна, самое первое что придет в голову нашего пользователя это ощущение новизны, интенсивность которого будет пропорциональна тому, как долго пользователь использует наше приложение.

#6 Забывание без подсказок [P]
Является неспособностью вспомнить воспоминание из-за отсутствия стимулов или сигналов, которые присутствовали во время кодирования памяти.

В контексте приложения мы можем использовать наши знания об этом искажении с целью напоминаний пользователю о том, что он может сделать с системой.

Приведу простой пример на онлайн тотализаторе, где множество пользователей делают ставки. Очевидно, что средний пользователь как выигрывает, так и проигрывает. В интересах бизнеса правильно будет поддержать такого пользователя в тот сложный момент, когда он все проиграл. Так как в сознании игрока, который пережил серию поражений одни поражения, система может напомнить ему о целом ряде побед по некоему паттерну, оживив в нем всю ту серию хороших воспоминаний, которые он испытал. Это может быть сделано ненавязчиво, сообщением типа Уважаемый %username%, мы просто хотели напомнить вам о невероятно успешной серии ваших побед, продлившейся три дня подряд на играх %game_names%. Навязчиво? Возможно. Изменим сообщение на Вы попали в топ 20% наших игроков, благодаря вашей серии побед в %game_name%!. Уже не так навязчиво, это уже статистика . Конечно, делать это не этично с точки зрения морали. Поэтому букмекерские конторы и казино, работающие под лицензиями Malta Gaming Authority (MGA), Кюрасао и других, заранее соглашаются, что не будут подталкивать игроков к острым азартным действиям. В любом случае, приведенный пример наглядно иллюстрирует как можно извлечь пользу для бизнеса, зная о такой простой ошибке нашего мозга.

#11 Ошибка базового процента [P]
Это ошибка в мышлении, когда сталкиваясь с общей информацией о частоте некоторого события (базовый процент) и специфической информацией об этом событии, человек имеет склонность игнорировать первое и фокусироваться на втором. Например: люди верят показаниям теста, сигнализирующем о наличии редкой болезни, сразу, не принимая во внимание, что редкая болезнь, вообще говоря, редкая. Либо другой пример: страх террористов и полетов на самолете. Суть в том, что наш мозг склонен преувеличивать частный случай в ущерб статистике.

Понимание этой ошибки дает нам возможность более внимательно подходить к разработке текстового контента для приложений. Так, сообщение, описывающее потенциально негативный исход в случае выполнения какого-либо действия, будет по-разному воспринято пользователями:

Вы собираетесь запустить процесс дефрагментации диска. С вероятностью 99% операция пройдет успешно.

Вы собираетесь запустить процесс дефрагментации диска. Есть 1% вероятности, что жесткий диск будет уничтожен, а ваши данные безвозвратно потеряны.

Кстати, именно по этой причине очень важно предоставлять качественную техподдержку. Разочарованный пользователь, который не смог найти разумное объяснение происшедшей ошибке в программе, может оставить негативный отзыв о приложении. И это нанесет гораздо более крупный вред продукту, чем может показаться на первый взгляд.

Когда люди видят 15,800 хвалебных отзывов и 50 крайне негативных отзывов в перемешку с ними, они склонны считать продукт менее ценным, непропорционально тому факту, что негативных отзывов меньше 0.1%.

#13 Эффект юмора [P]
Смешные вещи легче запомнить, чем не юмористические, что может быть объяснено увеличенным временем когнитивной обработки, чтобы понять юмор, или эмоциональным возбуждением, вызванным юмором.

Лучший пример использования юмора это вездесущие мемы. Множество крупных IT-компаний используют мемы для того, чтобы продвигать свои продукты, и эффект юмора это именно то, на что они делают ставку.

Здесь очень важно понять, что речь идет о запоминании юморных вещей, но не о позитивном отношении к ним. Так, если в процессе работы над важным действием (заполнение формы, сохранение данных), пользователь попадает на страницу ошибки (500 (Internal server error), 502 (Bad gateway), 503 (Service unavailable), 504 (Gateway timeout) ), то юмор типа Хо хо! Наши пираты работают над ошибкой и скоро все будет восстановлено! будет не к месту. В этом случае юмор будет замечен, запомнен, и, вероятнее всего, вызовет гнев пользователя так, что это событие запомнится лучше. Если подобное событие произойдет несколько раз за месяц, в соответствии с эвристикой доступности, в следующий раз подумав о качестве нашего продукта пользователь с высокой вероятностью даст негативную оценку. Даже если в 99% случаев приложение справлялось с задачей (ошибка базового процента).

Хорошим пользовательским опытом в данной ситуации будет считаться страница с ошибкой, где компания принимает вину на себя, объясняет суть ошибки и оповещает о том, что скоро все восстановится и страница сама обновится.

#21 Ошибка различения [P]
Это тенденция рассматривать два варианта как более отличительные при оценке их одновременно, чем при оценке их отдельно.

Понимание этой ошибки дает нам возможность по-разному подходить к разработке информационной структуры для нашего приложения. К примеру, если мы хотим, чтобы пользователь четко видел отличия одного сервисного плана от другого, мы можем поместить сервисные планы в ряд с указанием характеристик и цены каждого (вы видели такое на многих вебсайтах в разделе Цена). Если же нам нужно, чтобы пользователь считал наши сервисные планы почти одинаковыми (не важно по какой причине), тогда мы можем вместо размещения их горизонтально в таблице, разместить их вертикально друг под другом. Это не позволит пользователю одновременно оценивать отличия сервисных планов, т.к. придется скролить страницу, и тем самым повысится вероятность того, что мы добъемся своей цели. Эта ошибка также является одной из причин, по которой онлайн тотализаторы и разного рода казино не показывают сумму депозита, выигрыши и проигрыши на одной странице. Это удобно для пользователя, но не отвечает бизнес целям проекта, т.к. пользователь будет придавать бОльшее значение различиям между победами и поражениями. При этом не важно, чему он придаст бОльшее значение. Сам факт того, что у пользователя появятся чувства и мысли, которые не поддаются контролю, создаст риски для бизнеса.

#36 Пренебрежение вероятностью [P]
Когнитивное искажение, согласно которому человек склонен к игнорированию малых вероятностей при принятии решений в условиях неопределенности. Небольшие риски обычно либо полностью игнорируются, либо сильно недооцениваются. Континуум между крайностями игнорируется. Как объясняет Рольф Добелли, причина, по которой это происходит, заключается в том, что мы не обладаем интуитивным пониманием риска и поэтому плохо различаем разные угрозы. По сути, чем более серьезна угроза и эмоциональнее тема (напр. Радиоактивность), тем менее обнадеживающим представляется снижение риска.

Использование этого искажения ежедневно приносит сотни миллионов долларов разным казино и тотализаторам по всему миру. Это искажение также является причиной, по которой мы склонны нажимать на Я принимаю условия лицензионного соглашения по факту его не прочитав. Понимание этого искажения позволяет компаниям доносить важную информацию до пользователей в такой форме, при которой он с высокой вероятностью проигнорируют риск. Либо, наоборот, мы можем подтолкнуть пользователя к нужным нам действиям используя специфические формулировки.

К примеру, зная что наши пользователи игнорируют вероятность полной потери данных, мы можем подтолкнуть их к созданию бэкапов сообщением вида Уважаемый %user_name%, в последний раз вы создавали бэкап ваших данных 571 день назад. Мы настоятельно рекомендуем создать бэкап чтобы избежать риска полной безвозвратной потери ваших данных.. Здесь мы ничего не говорим о вероятности потери. Она могла постоянно быть равной 0.1%, но написав сообщение с призывом к эмоциям (полной безвозвратной потери ваших данных) и конвертируя условные 19 месяцев в 571 день, мы с большей вероятностью добьемся действия пользователя (бэкап системы).



Ссылка на полную версию UX CORE (105 примеров использования когнитивных искажений в менеджменте команд и продуктов)


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

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

В завершении, я бы хотел рассказать об ошибке GI JOE задокументированной профессором Лори Сантос буквально несколько лет назад. Ошибка касается широко распространенного утверждения, что знать это уже пол дела, что, однако, не имеет научных оснований и является ложным утверждением. На самом деле, одного лишь знания недостаточно, чтобы изменить модель нашего поведения. Настоящие перемены невозможны без наших целенаправленных действий. Вы можете выучить наизусть все когнитивные искажения и механизм их работы, но, если вы не меняете модель своего поведения под полученными знаниями, ценность ваших знаний снижается. Более того, подобное знание не будет крепким, вам придется регулярно возвращаться к таблице и повторять написанное, чтобы не забыть. Если же вы не только поймете, но и предпримите определенные действия для усвоения материала, изменения вашего образа мыслей, вашей жизни, тогда самые лучшие решения по продукту, удивительным образом станут для вас крайне очевидными.

Часть 6. Наши дни


К сожалению, нехватка хороших продакт менеджеров является главным препятствием для создания качественных продуктов на рынке. Ситуация усложняется тем, что большинство компаний еще не до конца понимают разницу между Product Manager-ом и Product Ownerом, иногда, даже, прописывая их в вакансиях через /.

На данный момент, взглянув на рынок и на требования к продакт менеджерам лучших компаний, можно обнаружить описания и опросники, на которые ответит почти каждый, кто прошел PMI-ACP. По сути, отсутствие четкого понимания роли Product Manager-а приводит к тому, что на них вваливаются обязанности Project Managerов, Scrum Master-ов, и других.

Оговорюсь, что речь идет в первую очередь о странах СНГ, хотя на европейском рынке абсолютной ясности по поводу продакт менеджеров; как их найти, как интервьюировать, и чего от них ожидать тоже нет.

Полагаю, с США дела обстоят лучше, т.к. развитие продакт менеджмента идет именно оттуда.

Другая проблема на пути к созданию качественных продуктов это, конечно же эго непосредственных руководителей, под которыми работают продакт менеджеры. Раздутое эго особенно часто встречается у технических специалистов со-владельцев продукта. Такие менеджеры обычно, полагают, что их знания программирования позволяющие написать функциональную часть продукта, также являются доказательством того, что они хорошие продакт менеджеры. По сути, такое руководство чаще других подвергается эффекту Даннинга-Крюгера и эффекту слепого пятна. Работа с таким руководством по-умолчанию увеличивает сложность работы продакт менеджера. Теперь, когда ему нужно разработать решение для задачи, помимо выполнения фактической работы, он, заодно, вынужденно придумывает велосипед и соус, под которым все это дело нужно закрутить и подать руководству так, чтобы их хрупкое эго могло согласиться с предлагаемым решением.

Также я бы хотел показать другую сторону когнитивных искажений, а именно: их колоссальный, недооцененный потенциал который они таят в себе для HR специалистов. Хотя, увы, у меня не было возможности поработать с грамотными HR специалистами, я уверен, что они где-то есть и при внимательном изучении искажений, им удастся создать новые процедуры для более качественного отбора кадров. Полагаю, наиболее бюрократизированным организациям будет сложно представить, как можно интегрировать когнитивные искажения в процесс поиска сотрудников. Однако, для более свободных компаний, готовых эксперементировать, я бы порекомендовал использовать знания искажений для выявления слабых мест кандидатов. Помимо этого, эти знания дадут возможность определить гибкость кандидата. В определенных случаях, можно даже проанализировать хрупкость эго кандидата, проверив его склонность к эффекту слепого пятна.

Вообще, такие искажения как эффект сверхуверенности, иррациональное усиление и эффект обратного действия, довольно просто могут быть протестированы, и в случае адекватной реакции кандидата, с высокой вероятностью, смогут сэкономить очень много человекочасов поисков нужных людей. Видя все эти возможности и понимая, что они не используются из-за дичайшей человеческой лени, становится грустно, и тем не менее, я уверен, что найдутся люди, публичные авторитеты, которые смогут подтолкнуть наше IT сообщество к развитию в нужную сторону, подальше от бюрократии и поближе к науке.

Часть 7. Не только искажения


Я бы также хотел затронуть те аспекты знаний продакт менеджера, которым в этой статье было уделено мало внимания, но, которые не менее важны для понимания, чем искажения.

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

Так, менеджеру не следует забывать о важности бизнеса и выгоды, которую бизнес преследует. В основе любого бизнес продукта лежит стремление увеличить прибыль либо уменьшить издержки. И понимание того, как именно компания хочет это сделать, очень важно для продакт менеджера при проектировании любого решения. Для этого продакт менеджер должен следить за решениями компаний-партнеров и конкурентов, изучать их стиль ведения работы; то, как они поддерживают коммуникацию с пользователями и как пользователи эту коммуникацию воспринимают. Если продукт нацелен на получение прибыли, необходимо понимать механики ценообразования, существующие бизнес модели, их преимущества и ограничения.

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

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

В определенных случаях, менеджеру могут даже понадобиться знания о существующих вооруженных и/или идеологических конфликтах в регионах.

Также, очевидно, продакт менеджер должен быть более чем продвинутым пользователем современных вебсайтов и мобильных приложений, иметь хорошее представление и опыт работы с принципами и практиками Agile, а также понимать техническую составляющую проекта. Технические знания- такие, как основы front-end и back-end программирования и систем работы баз данных, тоже очень важны, потому что решения, разрабатываемые с учетом технических тонкостей проекта, в конечном итоге экономят десятки, а в некоторых случаях сотни человекочасов.

Все это и многое другое те самые детали, которые важно учитывать с самого начала, и отсутствие которых, часто, выясняется слишком поздно и стоит дорого.

Без внимания к деталям, невозможно добиться высокого качества.

Важность деталей и умение с ними работать в наше время гораздо более важны, чем общие идеи.

Часть 8. Эпилог


В заключительной части я бы хотел объяснить, почему из всех знаний, которые важны для продакт менеджера, я особенно выделил психологию, в частности, критическую важность понимания когнитивных искажений.

Причина же в том, что из всех перечисленных выше аспектов знаний продакт менеджера, психологическая составляющая это не что-то, что можно легко понять, принять и стать лучше. У широкого множества людей, которые захотят использовать знания когнитивных искажений в своей регулярной работе возникнут внутренние противоречия, борьба со своими прежними установками. Иными словами, человеческое эго не позволит принять легкие и очевидные правильные ответы, так как для их принятия придется менять устоявшуюся модель мышления и поведения выходить из зоны своего психологического комфорта.

Попробую объяснить иначе. Вне зависимости от идеологической составляющей вашей жизни, вашего стиля и публичного образа, вы можете в любой момент записаться на курсы по SCRUM, изучить этот фреймворк, почитать о нескольких других, понять идеи Agile и устроиться работать проект менеджером в какую-то компанию. Вы также можете пройти пару онлайн курсов и подтянуть ваши знания по front-end и back-end программированию, понять принципы работы баз данных, и это займет у вас буквально месяц. Еще за месяц вы можете сами выучить HTML и CSS, поиграть с разметкой, собрать несколько макетов и понять общую идею работы Javascript.

По сути, вы можете месяца за три собрать достаточно знаний для понимания технической составляющей проекта, и этого более чем хватит для начинающего продакт менеджера. Для понимания трендов вы можете скачать самые последние приложения, пройти по списку самых популярных онлайн платформ, зарегистрироваться на producthunt, betalist, techcrunch и всегда быть в курсе происходящего. Новостной информационный пробел легко восполнить регулярно читая Google News и hackernoon.

Однако, когда мы затрагиваем психологическую составляющую работы, ситуация немного меняется. Решения по разрабатываемым особенностям продукта принимаются, в первую очередь, с опорой на понимание наших пользователей, их ожиданий и забот. Здесь психология играет ключевую роль, поэтому абстрактное понимание вопроса (как в случае с тех. составляющей) не подойдет. Для применения когнитивных искажений совершенно не достаточно прочесть эту статью или просмотреть их все в таблице. Не хватит даже чтения нескольких книг или просмотра пары видео курсов.

Чтобы по-настоящему применить эти знания и создать красивое решение, которое учтет ошибки нашего мозга, необходимо не просто помнить об этих ошибках, но и вовлечь их в свою жизнь. А подобное вовлечение, не может не привести к изменению своей линии поведения, идеологии и жизненных взглядов.

Именно поэтому тем, для кого эта статья была просто прикольной статьей, будет лучше продолжать жить так же, как они жили, а те, для кого бОльшая часть написанного здесь была очевидной из-за своей логичности, могут задуматься над тем, чтобы построить свою карьеру вокруг продакт менеджмента. Именно вы являетесь теми, кто в какой-то момент поможет перевернуть страницу черствого, грубого софта, который заполонил рынок и приведет всех нас в новый мир, где проектировка любого продукта начинается с чувств эмпатии и сострадания к пользователям. Именно вы способны создавать революционные продукты, методологии и практики разработки качественного ПО.

Завершить статью я хочу провокационной мыслью.

А что, если изучение когнитивных искажений в раннем возрасте (скажем, в университетах) это прямой способ сделать наше общество более сознательным, чувственным и сопереживающим?
Что, если именно изучение искажений и пользовательского опыта, является ключом к обеспечению рациональности (суть отсуствие противоречий по Д. Канеману) индивида?
Как говорит сам Д. Канеман: Чем бы ни занималась организация, она является фабрикой по производству суждений и решений. И рано или поздно, из-за необходимости повышения качества этих производимых суждений и решений, подход к разработке продуктов и менеджменту компании будет базироваться на эмпатии и сострадании, а методы сухого анализа данных будут применяться гораздо реже.

Человек же, по количеству произведенных суждений и решений не уступает ни одной компании в мире (вопрос сознательности оставляем за рамками). Нам не обязательно ждать, когда крупные компании дадут публичное добро на использование когнитивных искажений как основны для разработки разных решений. Мы можем использовать эти знания для изменения нашей жизни уже сейчас.

В любом случае, для того, чтобы идеи стали популярны, их должны обсуждать общепризнанные авторитеты. Обсуждать чаще и больше. Вреда от этого точно не будет, а потенциальную пользу переоценить невозможно.

Большое спасибо за проявленный интерес.

Искренне надеюсь, что эта статья дала вам пищу для размышлений.

Я буду очень рад познакомиться с людьми со схожими интересами, поэтому, если вы изучаете когнитивные науки и/или их применение в разработке продуктов добавляйтесь ко мне в LinkedIn или Facebook.

Также я всегда открыт для обсуждения новых идей. Чем амбициознее, тем лучше. Пишите.
Буду рад помочь всем, что в моих силах.

Часть 9. Материал, качественно дополняющий эту статью


  • Даниел Канеман Думай медленно Решай быстро;
  • Николас Нассим Талеб Черный Лебедь;
  • Касс Санстейн и Ричард Талер Подталкивание;
  • Ричард Дэвидсон Как эмоции управляют мозгом;
  • Михай Чиксентмихайи Поток;
  • Джим Коллинз От хорошего к великому;
  • Jesse James Garrett The Elements of User Experience (2nd Edition);
  • William Lidwell Universal Principles of Design;
  • James Clear Atomic Habits;
  • Erin Meyer The Culture Map;
  • Joe Natoli UX Design Fundamentals Udemy Video;
  • Joe Natoli UX & Web Design Master Course: Strategy, Design, Development Udemy Video;

Эта статья была написана в период объявленного карантина из-за пандемии коронавируса (COVID-19) в Армении, г. Ереван. Я очень рад, что статья оказалась полезна многим людям, которые успели ознакомиться с разными частями написанного материала в период моей работы над ней.

Оригинал статьи
Английская версия

По любым вопросам и предложениям пишите, буду рад помочь: alexanyanwolf@gmail.com / www.linkedin.com/in/alexanyan / www.facebook.com/AlexanyanWolf
Подробнее..

Ваш дизайн говно! гайд по созданию дизайн-принципов для продуктовой компании

24.02.2021 12:05:30 | Автор: admin

Делимся алгоритмом работы над созданием дизайн-принципов, который сработал для нас и может пригодиться кому-то ещё.

Интродакшн

Раньше дизайнеры в нашей компании работали в едином отделе по принципу студии. Руководитель распределял задачи по навыкам, загруженности и грейдам. Но по мере роста и развития компании и команды, стали менять и подходы к проектированию. Поэтому осенью 2020 года мы поменяли оргструктуру и выслали в каждую продуктовую команду выделенного дизайнера для бОльшего погружения в продукт.

Работая по старой схеме в первой половине 2020 года, мы научились коммуницировать между собой удаленно. Но когда отсортировали людей по продуктовым командам, у дизайнеров стало меньше времени на общие демо и синхронизации, а сессии дизайн-критики стали затягиваться.

Проблема, которую мы решали

Стало очевидно, что у нас отсутствовал единый вектор мышления. Обратная связь друг другу была основана на личном мнении и ретроградном Меркурии. Поэтому мы решили создать несколько принципов, которые задавали бы нам общий вектор хорошего дизайна. В результате группа людей с персональным мнением должна была превратиться в команду с общими точками зрения и подходами.

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

Небольшое отступление про компанию и команду

Kolesa Group продуктовая IT-компания, основанная в Казахстане. Мы создаем и развиваем классифайды сервисы для публикации объявлений для людей и компаний в Казахстане и Узбекистане.

У нас 4 основных продукта:

  • Kolesa.kz классифайд в категории Авто с MAU в 5 млн пользователей. Это 32 % всех интернет-пользователей в стране.

  • Krisha.kz классифайд в категории Недвижимость с MAU 3.5 млн пользователей. Это 23 % всех казахстанских интернет-пользователей.

  • Market.kz классифайд для всех категорий товаров и услуг. Ежемесячная аудитория более 2 млн человек.

  • Avtoelon.uz автоклассифайд в Узбекистане. MAU 2 млн пользователей.

Процесс

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

Шаг 1. Рисерч и поиск референсов

Вначале мы подглядели готовые базы принципов разных команд, потому что хотели узнать, как это устроено у других. Принципы многих команд очень схожи между собой и часто пересекаются.

Вот подборка ресурсов, где собраны референсы от других команд:

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

Шаг 2. Исследование внутри компании и создание опросов

Для проведения объективного брейншторма нужны были качественные данные, поэтому мы решили снять температуру и опросить нескольких сотрудников компании.Мы сделали опросник, понимая, что качество ответов может не соответствовать ожиданиям, но нам нужен был взгляд со стороны и понимание настроя людей.

В опроснике были вот такие открытые вопросы:

  1. Перечислите через запятую характеристики интерфейсов и процессов разработки, которые уже работают хорошо в наших продуктах.

  2. Напишите, что именно хочется исправить в наших продуктах и какие характеристики интерфейсов или процессы разработки хочется добавить.

  3. Приведите примеры продуктов и процессов разработки в командах, которые вас вдохновляют, и опишите, чем именно они вас вдохновляют.

Кроме внутреннего опроса, мы собрали распространенные проблемы в продуктах из базы службы заботы о пользователях (звонки, письма, отзывы в app-маркетах). Это помогло сегментировать проблемы, например, технического или интерфейсного характера.

Примеры проблемПримеры проблем

Шаг 3. Подготовка к шторму

Когда мы определились с целями всей этой затеи, побежали делать доску в Miro и назначать дату брейншторма.

На доске подготовили такие штуки:

  • Вытащили примеры принципов некоторых дизайн-команд, которые покрывали наши проблемы.

  • Вытащили результаты опросов.

  • Подготовили площадку для боя. В этой области будет проходить брейншторм. У нас это проходило в Miro.

Шаг 4. Собственно брейншторм

Сам брейншторм был строго ограничен по времени и разделен на этапы. Прежде всего мы обсудили 3 главных вопроса:

  • Почему мы создаем принципы?

  • Для кого мы их создаем?

  • Как те, для кого они будут сделаны, смогут их использовать?

Обсудив вопросы, модератор брейншторма обозначил правила игры, и все участники приступили к штурму.

  1. Сначала каждый участник писал на стикерах ПЛОХИЕ реализации и характеристики интерфейса или пользовательских качеств в продуктах. Ставили таймер на 10 минут.

  2. Затем рядом с каждой плохой реализацией каждый участник должен написать решение проблемы, чтобы ПЛОХОЕ стало ХОРОШИМ 20 минут.

3. Затем нужно было структурировать карточки и найти связи, при этом мы использовали результаты опроса и продуктовых запросов из базы службы заботы, которые заранее подготовили на доске 20 минут.

4. В итоге у нас вышло несколько категорий, которые мы тоже объединили в сегменты:

A) человекоориентированность, прозрачность и честность в продуктах;

B) осознанность в проектировании, консистентность, качество продукта, эстетичность;

C) контроль состояния, понятная коммуникация, простота и очевидность;

D) командность.

5. Затем каждый участник отдал голос наиболее важным, на его взгляд, категориям 3 минуты.

6. После мы разложили варианты, набравшие наибольшее количество голосов, по пирамиде дизайн-принципов.

Что осталось?

  1. Осталось придумать названия для принципов и их описания. Нам важно, чтобы названия были запоминающимися и их описания развернуто объясняли суть.

    Времени на встрече осталось не так много, и креатив немного охладился, поэтому мы договорились взять домашнюю работу по неймингу и вернуться на следующую встречу со своими вариантами.

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

3. Так мы зафиксировали важные моменты, на которые всегда нужно обращать внимание при проектировании, и выставили их по пирамиде, в которой самый важный принцип находится в самом низу и является фундаментом всего.

Вот что у нас получилось:

[Сначала люди]

Делаем продукты и сервисы, которые ежедневно помогают миллионам разных людей. Мы уважаем их время, желания и свободу выбора, поэтому наши продукты и сервисы, как и мы, честные, прозрачные и всегда дают обратную связь.

[Сознательный подход]

Проектируя, мы опираемся на исследования и наблюдения. Мы принимаем решения только после подтверждения наших предположений и качественно их реализуем

[Очевидность]

Наши интерфейсы и внешние коммуникации едины, понятно объясняют, на каком шаге находится человек сейчас, и помогают, если что-то пойдёт не так.

[Коллаборация]

Мы объединяем продуктовый дизайн, контент дизайн, исследования, маркетинг и технологии разработки для единой синергии и улучшения опыта использования наших продуктов и сервисов.

[Инновации]

Создаем передовые методы, инструменты и технологии для развития дизайн-процессов и качества продуктов. Делимся экспертизой с людьми, которые создают полезные продукты и сервисы для людей во всем мире.

Корабль поплыл

Наши дизайн-принципы зафиксированы в Figma. Уже сейчас они упрощают нам сессии дизайн-критики, поскольку фидбек основывается на четкой аргументации, а не на абстракциях. При этом ошибок встречается все меньше, ведь дизайнеры, проектируя, сразу пропускают свои решения сквозь призму принципов, что позволяет на ранних этапах избегать непонятных формулировок и текстов или неочевидного поведения интерфейса.

Наша следующая цель распространять принципы по всей компании, ведь в создании продуктов участвует множество отделов, и их можно применить практически в любой сфере и компетенции. Например, QA при тестировании продукта тоже защищает сторону пользователя и принципы помогут объективно оценить важность исправить что-то до релиза.

Теперь во время дизайн-критики мы стараемся аргументировать фидбек, исходя из принципов, при этом иногда в сессиях участвуют разработчики и менеджеры, что дает эффект распространения метода фидбека в другие отделы.

Заметить эффективный рост качества продукта только от внедрения таких принципов сразу невозможно, пока мы только следим за показателями NPS и внешним feedback loop (звонки, письма, отзывы в app-маркетах).

Дизайн-принципы пишутся не один раз и на всю жизнь. Они должны решать вашу конкретную проблему в данный момент. Мы уверены, что в будущем будем пересматривать свои принципы, когда осознаем, что текущие стали обыденностью, будем строить новые принципы вокруг наших продуктов. Но это будет уже следующий этап стратегии развития дизайна продуктов.

Подробнее..

UX Кейс Защита от компульсивных трат в банковском приложении

02.12.2020 22:20:51 | Автор: admin

Компульсивные траты это покупки "на эмоциях", которые в определенных случаях могут привести к серьезным финансовым трудностям.Опросболее 5000 человек с ментальными расстройствами показал, что 93% из них тратят больше в периоды обострения болезни. Например, люди с биполярным расстройством склонны тратить значительно больше во время маниакальной фазы, в результате чего у них накапливается огромный долг.Как банковские приложения могут помочь уязвимым клиентам избежать таких ситуаций.

Исследование

Я поговорила с тремя людьми с биполярным расстройством о том, как они справлялись с маниакальными тратами. Их опыт указал на следующее: чем легче было совершить покупку, тем труднее им было остановиться и обдумать свои финансовые решения.

Добавление positive friction

Основываясь на исследовании, я выдвинула гипотезу: перед тем, как списать деньги со счета,банк может просить пользователя отменить или подтвердить покупку на следующий день.

Сначала пользователь включает функцию в настройках и устанавливает лимит.

Включение функции "Safe spending"Включение функции "Safe spending"

Затем выбирает магазины, в которых он склонен слишком много тратить. Я выбрала магазины, а не категории, потому что на платформах e-comm, таких как Amazon или eBay, банки не могут определить, к какой категории относится покупка.

Выбор онлайн магазиновВыбор онлайн магазинов

После оформления заказа пользователь получает уведомление о том, что покупка заморожена до завтра. На следующий день банк спросит, что делать с незавершенной покупкой отменить ее или оплатить. Благодаря этим сдерживающим факторам пользователь сможет принять более осознанное решение.

Ревью вчерашнего заказаРевью вчерашнего заказа

Выводы

Конечно, это не единственное решение проблемы компульсивных покупок. Но эта функция может стать небольшим шагом к более осознанному распоряжению деньгами и защитить уязвимых пользователей в сложный период.

Подробнее..

Из песочницы Product Manager amp Product Designer поиск сходств и отличий

16.08.2020 00:12:08 | Автор: admin
Меня зовут Ростислав Салата, я работаю в киберспортивной организации без малого три года. Пришел в компанию на должность проектировщика интерфейсов, дорос до UX-лида, и в настоящее время являюсь продуктовым менеджером.

Задачи продуктового менеджера и подход к работе у нас сильно отличаются от обязанностей продуктовых менеджеров в других компаниях. Это значит, что в вашей компании представления о функционалах и наборе скилов для продуктового менеджера и дизайнера могут отличаться. Например, в некоторых компаниях продуктовый менеджер проектирует интерфейсы, а у нас нет.

Почему я поднял эту тему? Мы провели очень много собеседований с продуктовыми дизайнерами. Опираясь на свой опыт и опыт коллег, могу смело сказать, что вопрос о круге обязанностей задает каждый претендент. Разное понимание зон ответственности может впоследствии привести к конфликтам, которые пагубно повлияют на продукт.

Ниже не будет чек-листов и стопроцентной инструкции о том, как перейти в менеджмент. В первой части статьи я развею мифы о кажется, я уже продакт. Во второй части расскажу о реальных задачах менеджера по продукту. Точнее о тех, с которыми я сталкиваюсь ежедневно и которые должны развеять идеалистическое представление о том, что такое продуктовый менеджмент.

Часть 1. Я и мой продакт-менеджер выполняем похожие задачи. Получается я продакт-менеджер?


Есть качества, отличающие опытного продуктового дизайнера от начинающего. Поэтому предлагаю обсудить черты тех специалистов, которые на глубинном уровне понимают дизайн, замеряют его эффективность и влияние на решение бизнес-задач. Почему-то обязанности сильных дизайнеров часто путают или пытаются добавить к задачам продуктового менеджера. Следующие шесть пунктов это частые ошибки в понимании задач этих специалистов. По сути это функционал сильного продуктового дизайнера, но почему-то многие считают, что, если он так думает и поступает, то автоматически становится менеджером.

1. Из твоего лексикона пропадают фразы это не моя работа или это не моя зона ответственности


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

Ловишь себя на мысли, что перестаешь говорить всем подряд, что они недостаточно компетентны. Вместо этого находишь способы тактично донести конструктивную критику до каждого. Многие дизайнеры, да и другие специалисты индустрии могут подумать, что это первые шаги на пути к менеджменту. И да, и нет.

Кто говорит, что продуктовый дизайнер несет меньшую ответственность за продукт, чем продуктовый менеджер? Продуктовым дизайнерам никто не запрещает (даже наоборот!) замечать глюки, давать советы, помогать строить или дополнять командные процессы. Хорошего продуктового дизайнера и отличают те модели поведения, которые я описал ниже.

2. Начинаешь самостоятельно искать инсайты и их источники


В большинстве случаев принятие решения о реализации того или иного функционала остается за продуктовым менеджером. Очень часто дизайнеру, в том числе и продуктовому, приносят список проблем и болей пользователей, которые нужно решить с помощью дизайна. Если же ты сам находишь эти проблемы, задачи, потребности или боли, возникает мысль: а не должен ли этим заниматься продуктовый менеджер? Если кратко, то да. И не только этим.
Определение проблем пользователей часть дизайн-процесса. Интерфейсная экспертиза, безусловно, очень важна, но она должна сопровождаться постоянной работой с пользователями. Правда, чаще выходит, что именно дизайнер, а не продакт, находит большинство инсайтов и внедряет их в продукт.

3. Понимаешь, что внедряемая фича влияет не только на пользователя


Дизайнеры часто аргументируют свои предложения пользовательским фидбэком из анкетирования, интервью, комментариев в социальных сетях и запросов в support, говоря о том, что пользователи наше всё. Без сомнения, так и есть. От пользователей можно и нужно черпать инсайты. Но не пользователем единым.

Когда ты начинаешь думать, что разрабатываемая фича Х может использоваться в разных каналах коммуникации, влиять на финансовую модель продукта, юридические правила и политику его использования, стратегические цели продукта и компании в целом, то становишься намного ценнее и полезнее для продукта и команды в целом. Это очень хороший маркер твоего дизайнерского хард-скила.

Многие дизайнеры знакомы с понятием омниканальности. В работе над продуктом стоит отталкиваться от этого понятия и тщательно продумывать предложенные пользовательские фичи. Почему же дизайнер не должен думать о влиянии внедряемых решений на продукт во всех точках его контакта с пользователями? Если ты продуктовый дизайнер, то это просто must have. Консистентность, детализация и продуманность дизайн-решений на всех уровнях это топ-скилы дизайнера.

4. Смещение фокуса с дизайна в привычном для всех понимании


Дизайнер в первую очередь работает с интерфейсом продукта. Результатом его работы должен быть визуально приятный и удобный интерфейс. Об этом не стоит забывать, ведь перевод фокуса на глубинный анализ может принести больше вреда, нежели пользы. Иногда дизайнеры настолько погружаются в ресерч, аналитику и другие продуктовые вопросы, что забывают о важности первого впечатления пользователя о продукте.

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

5. Появляется ощущение, что предлагаемые фичи не несут пользу продукту


С этим ощущением надо быть аккуратным, так как оно может быть связанным с чувством собственной важности (ЧСВ). Бывает, что внедрение фич обосновывают лишь я так считаю, мне виднее или пользователям так точно будет удобнее.

Хорошо уметь анализировать фичи с точки зрения пользы для продукта или компании. Как это сделать? Провалидировать и аргументировать идею. Занимаются ли этим только продуктовые менеджеры? Хороший вопрос.

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

6. У тебя меняется отношение к продуктовым метрикам


Зачастую метрики уже сформированы. Вся команда работает над их достижением, и дизайнер не исключение. Круто, когда у тебя появляются мысли о том, что текущие показатели можно пересмотреть, доработать для более правильной интерпретации, в крайнем случае создать или добавить новые.

Смотреть на продуктовые показатели под другим углом хороший навык. Но говорит ли наличие этого навыка о том, что ты на пути к продуктовому менеджменту? Скорее нет, чем да. Будучи продуктовым дизайнером, ты можешь (должен?) проверять свои решения на соответствие метрикам, и, вероятнее всего, научишься смотреть на показатели эффективности шире.

Добавление новых фич или итерации существующего функционала должны соответствовать целям продукта или компании. Продуктовый дизайнер должен опираться на метрики и смотреть на них в более широком контексте. Это не указывает на то, что специалисту пора переходить в менеджмент.

И правда, получается, что обязанности продуктового дизайнера и продуктового менеджера во многом пересекаются. Чем тогда на самом деле занимается продуктовый менеджер?

Часть 2. Какие задачи решает продуктовый менеджер в реальной жизни?


Будем откровенны: чаще всего продуктовый менеджер занимается чем угодно, кроме своих прямых задач. Если ты продуктовый менеджер и дочитал до этого раздела, то точно улыбнешься, вспомнив себя в роли маркетолога, дизайнера (особенно графического), продажника, разработчика, проектного менеджера, пиарщика и т. д. Да, я тоже был во всех этих ролях, но чего уж там, дизайнер из меня не получается и не получится никогда.

Ниже я собрал основные векторы, в рамках которых продуктовые менеджеры выполняют свои незаметные задачи с невидимыми результатами работы.

1. Фокус, консолидация, коммуникация.


Фокус. Продуктовый менеджер должен быть сфокусирован на получении прибыли от своего продукта. Другими словами, на заработке денег для компании. Стремление сделать проект прибыльным должно быть здравым, а не фанатичным.

Фанатизм рассмотрим на примере вывода нового продукта на рынок. Менеджер должен понимать: если его продукт нестабилен и не покрывает базовых потребностей своего рынка, то ни о какой монетизации не может быть и речи. Почему? Если требовать с пользователей плату лишь за отличительные ценности, не покрывая их базовые потребности, высока вероятность напортачить в самый важный момент.

Консолидация. Продуктовый менеджер должен быть source of truth для команды. Продакт как сито он собирает тонну информации, просеивает ее и передает команде в виде понятного технического задания.

В качестве примера рассмотрим работу с sales-менеджерами или маркетологами на этапе внедрения или валидации какой-либо гипотезы. Перед тем, как передать гипотезу в работу другим отделам, ты должен проработать информацию. С одной стороны, не придется отвечать на наводящие вопросы. С другой стороны, ты задашь стратегический вектор, в рамках которого нужно будет копать.

Коммуникация. В моем идеальном мире работа продуктового менеджера должна распределяться так:

  • 30%: свои задачи;
  • 40%: коммуникация с командой;
  • 30%: one-to-one встречи с сотрудниками.

Как видим, 70% времени составляет коммуникация, хотя первые 30% задач тоже так или иначе с ней связаны.

Коммуникация это налаживание процессов, решение внутренних проблем в команде, встречи с представителями других департаментов, включая маркетинг и т. д. Очень часто в развитии продукта помогают хорошие soft skills, даже если ты начинающий продакт.

Один из важных результатов работы продуктового менеджера выстроенная коммуникация. Это одна из сложнейших частей работы, поскольку нет результата, который можно пощупать.

2. Сотрудничество с отделом продаж (Business Development)


Большинство продуктов рано или поздно выходят на стадию монетизации. Так как главная задача продуктового менеджера создание прибыли, общение с отделом продаж поможет лучше понять продукт и рынок в целом. Некоторые компании не всегда дают возможность общаться с отделом Business Development, но мне повезло.

Совместная работа с менеджерами по развитию бизнеса создает условия для более качественной продажи вашего продукта. Sales менеджеры должны понимать продукт, знать сильные и слабые стороны, а также болевые точки пользователей. Тогда они сделают upsell в нужный момент.

3. Организация кросс-командных процессов


Если у вашей компании достаточно ресурсов для того, чтобы задействовать несколько команд для решения задачи, нужно наладить обмен информацией, чтобы согласовывать действия. Процесс рутинный, но без него не обойтись. Возьмите на себя ответственность и создайте регулярные мероприятия для коммуникации разных команд.

Да, это не быстро. Да, это сложная коммуникация. Да, вероятность игнора высока. Но отношение коллег и доступ к своевременной информации стоят. Этот кейс хорошо описывает задачу взаимодействия в кросс-командах.

4. Правильная постановка целей и задач для команды


Цели. Каждый член продуктовой команды должен понимать, для чего мы это делаем и куда идем. Неважно, что это: апдейт текущей фичи, разработка нового сценария или выход еще на один рынок. Интересоваться видением команды по поводу целей продукта в неформальной обстановке это хорошая практика.

Задачи. Как продуктовый менеджер ты должен быть уверен, что тебя понимают так же, как ты понимаешь себя сам. Достаточно часто я сталкивался с тем, что мои ожидания не всегда очевидны для команды. Поэтому перед постановкой задачи стоит удостовериться, все ли понимают, что должно получиться в итоге, и зачем вообще делать эту работу. Такой себе definition of done, отвечающий на вопрос что? со стороны продукта. Команда же ответит на вопрос как?.

5. Аргументация и навязывание


В нашей команде любые доработки проходят через стадию аргументации. Даже если решение пришло сверху, команда должна понимать и разделять его. Понимание задач в целом и погружение в детали это инвестиция в развитие продуктового мышления у всех участников. Если инвестировать в это время, мы получим очень здравую внутреннюю группу валидаторов, которые не пропустят какую-то дичь к пользователям. Иначе команда будет просто исполнителем.

Кому-то это подходит, кому-то нет. В моей компании любой из членов команды является полноправным участником продуктовой разработки и может критиковать предложенные подходы или предлагать свои.

6. Управление продуктовой командой


Важно не теоретическое понимание процесса разработки, наличие сертификата по Agile от Coursera, а то, готов ли ты организовать команду и взять ответственность за эффективность и результат её работы.

Важно чувствовать, в какие моменты нужно поддержать участников команды, попросить о помощи, а когда спросить их мнение. Может показаться, что это полная чепуха. Но понимая настроение коллег, зная их ритуалы, ты получишь тонну инсайтов для построения крутой команды.

Продуктовые менеджеры до последнего шатают предлагаемую гипотезу перед тем, как добавить новую фичу или улучшить что-то работающее: проверяют корнер-кейсы, ищут сильные аргументы в пользу внедрения гипотезы в работу. Еще продакт выясняет, с помощью каких KPI будет измеряться результат предполагаемых изменений, если гипотезу примут, а также в рамках какой цели ее будут проверять.

6.1 Стоимость команды и внедряемых решений
Теперь не о романтике. Помимо стандартной эстимации, как продакт-менеджер ты должен просчитывать финансовую эффективность ресурса, который планируешь потратить. Понимая стоимость часа твоей команды, начинаешь смотреть через призму финансовой эффективности на любое предложение и гипотезу.

Стоимость разработки и ожидаемая прибыль от изменений в функционале играют не последнюю роль в принятии решений. Думаю, что знание финансовой стороны работы команды усиливает главный скил продуктового менеджера: умение говорить нет.

6.2. Кадровая эффективность
В некоторых компаниях продуктовый менеджер участвует в регулярных ревью членов команды. По объективным причинам обсуждение технических скилов на уровне ревью находится вне зоны влияния менеджера (если ты, конечно, не Technical Product). А вот оценка персональной эффективности и ее влияния на работу в команде самое то.

Продуктовый менеджер может и должен влиять на оценку эффективности сотрудника в команде. Звучит немного эгоистично, но команда это ресурс, который должен самоотверженно и эффективно работать на благо продукта.

Для оценки и обсуждения факторов, влияющих на эффективность работы сотрудника, можно использовать следующие подходы:

  • регулярные one-to-one встречи;
  • наблюдение при решении спорных моментов;
  • предрелизная реакция;
  • коммуникация с коллегами из других команд.

Не создавай вибрации. Создавай ценность

6.3. Подбор сотрудников, расширение команды
Продуктовый менеджер также влияет на подбор сотрудников в свою команду. Помимо технических скилов и опыта работы, важны совместимость с командой и соответствие ценностям компании. Проводить собеседования отдельное мастерство.

Лучше познакомиться с рекрутерами и узнать об их tips and tricks. Если перенять опыт не от кого, остается только учиться на своих ошибках. Наём человека это процесс: онбординг, адаптация, испытательный срок. За 23 месяца нужно убедиться, что это именно тот человек, поскольку ответственность на ну, сами знаете, на ком.

6.4. Увольнение
В каких-то компаниях менеджер может отстранить участника команды, а в некоторых только повлиять на увольнение. Суть не меняется. Увольнение человека наверное, одна из сложнейших задач менеджера в коммуникации (по крайней мере, для меня). Главное быть уверенным в причине, вооружиться аргументами, несколько раз проанализировать ситуацию, которая привела к необходимости расстаться и сообщить коллеге, что он уволен.

7. Общение с топ-менеджментом (уровень С, executives, founders, investors)


Для себя я определил, что данный пункт был и порой до сих пор является сложнейшей из задач продуктового менеджера. Сложность заключается в мышлении и принятии решений на совсем другом уровне абстракции. Говоря на языке agile, это общение на уровне тем (themes) или инициатив (initiatives).

Здесь больше о стратегии, чем о тактических действиях. Взаимодействие с топ-менеджментом решение задач с множеством неизвестных переменных, что сильно выводит из зоны комфорта и расширяет взгляд на многое в продукте и компании.

Если кратко, то вся работа сводится к исследованиям рынка или ниши, поиску инсайтов, вычитки бизнес-отчетов, и т. п. Все эти действия нужны для того, чтобы подкрепить заданный уровень абстракции цифрами и фактами. чтобы в будущем преобразовать его в тактические задачи.

Выводы


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

Дизайнер, выполняя задачи, входящие в компетенцию продуктового менеджера, делает две вещи:
прокачивается в скилах, которых ему может не хватать;
снимает с продуктового менеджера часть нагрузки и дает ему возможность эффективнее выполнять свои задачи.

Если вы задумались о романтике продуктового менеджмента, представьте себя решающим задачи в рамках одного из векторов, описанных выше. Представили? А теперь забудьте, потому что в течение дня продуктовый менеджер переключается между этими векторами очень часто.

Случай, когда ты делаешь одну задачу в конкретный период времени, не переключаясь, роскошь. Хорошо это или плохо? Сложно ответить. Скорее всего это задачи разного типа. Если ты сразу проскролил статью вниз, то сделаю здесь затравку, чтобы тебе захотелось вернуться как минимум ко второй части.

Готов ли ты как дизайнер или любой другой специалист менять контекст в течение дня по несколько раз? Готов ли ты к тому, что 7080% твоего времени составляет коммуникация? Готов ли ты к тому, что результаты твоей работы не всегда сразу можно увидеть и пощупать?

Тогда, если есть цель, к ней стоит стремиться. Главное учитывать все нюансы.
Подробнее..

Fatal Fight How weve got 5 million organic installs?

12.10.2020 14:18:52 | Автор: admin
Fatal Fight Android game

The story of Fatal Fight started in 2015. The time when going global and having 5 million downloads on Google Play Store seemed to be a dream of every game developer.

In this article, I will talk about the way we converted the dream into our actual reality. To make it super understandable, find a guide below where I will cover all the stages of development of Fatal Fight and even more.


Research


The idea of Fatal Fight hasn't just come from nowhere. Before understanding what game to develop, we needed to research what are the current gaps in the mobile games market. And, to come to this point, we took several steps.

First, we analyzed what are the most searchable mobile games in the Google Play Store. It turned out, the top 3 mobile games that users were looking for were the following:

  • Puzzle Games
  • Car Games
  • Fighting Games

Here we narrowed down our research. We were playing most downloaded games from each category to figure out if those games meet users needs while trying to answer what kind of challenges they have with those games.

As a result, Puzzle and Car Games had a wide range of mobile games with pretty nice UI/UX design and other characteristics. However, during the testing of the fighting games, the picture was quite different.

We were surprised by the fact that we could not find any proper games with satisfactory features. And I believe, not only we but also the dozens of users who were craving for favorable experience while playing a fighting game.

While asking ourselves the question Why? we found out that the main reason was the gameplay. The interaction between users and the games was complex. It was not comfortable to manage punching, kicking, jumping and other possible moves separately or even all at once on a smartphone.

Well, all of these for us was a subtle reference to a glaring fact. Fighting Games was not meeting the needs of existing users in the mobile games market.

Moreover, according to Google Play Store search rankings the keyword addictive games was one of the top ones. It showed us that users want something that will excite them to play the game on an everyday basis. This information was an added value to the conclusion that we came up with by that time:
We need to create an enjoyable fighting game with easy-to-use gameplay that will retain users

We wanted to come up with the gameplay that would not be complex for users in the first place. Once we give ourselves a question What if we will duplicate the gameplay of a PC fighting game?. This question seemed controversial, but it was raised because we explored the One Finger Death Punch PC game.

This fighting game had simple gameplay. You could literally manage the game only by clicking to the right and left sides of the mouse. This type of gameplay was an absolute match to what we were envisioning in our mobile fighting game. As a result, we took it as a good case practice and added Right and Left taps on mobile as an alternative to the same thing on the mouse.

Though we were grateful for the gameplay we could apply for our game, there was nothing else to take as a good case practice from this game. Even the name of the game was screaming I am the name of the game that no one ever will remember. We got for ourselves that probably their marketing strategy was not set up.

We created the prototype of the game to be sure that the gameplay we created was actually fit users needs. You can see in the picture that I inserted below that graphics were not the main thing we wanted to test there, the main focus of ours was to understand either the interaction between users and the game itself is comfortably managed.
"image

Winning the Google Play Store Optimization


Naming is another important point to take into account while developing a mobile game. It needs to be easy to remember and tailored to Play Store Optimization. The reason why we named our game Fatal Fight was the popular game Mortal Kombat. Yes, the game that won the admiration of billions was an inspiration for us in many ways.

Back then (in 2015 for those, who might have forgotten) there was no mobile version of Mortal Kombat. However, again the keyword Mortal Kombat had high rankings in Google Play. This means a lot of people were searching for this game on mobile but could not find it.

The truth is: If SEO (or Play Store Optimization) cannot find the exact keyword it always looks for synonyms.

Based on that, we decided to use synonyms for the words Mortal and Combat and combine them. And eventually Fatal Fight naming was created.

It meant to us that the audience that was looking for Mortal Kombat would find the Fatal Fight in the first pages on Google Play Store. It was a huge thing that we explored. Felt like a big responsibility at some point, we did not want to disappoint the Mortal Combat lovers, but to surprise them with a universal mobile fighting game in all senses.

Another thing that was inspired by Mortal Combat was the graphics. We were encouraged by some heroes such as Lui Kang. Raiden, Kung Lao, etc. in our game as well. It was one of the ways we could meet the expectations of Mortal Kombat lovers who were actively searching for this game online in the mobile version.


Once finished with all that, we had one aim We want to go global.

Soft-launch


Before opening up to the whole world, we made a soft-launch. Soft-launch is testing your product in a market that you are not really interested in. The reason is building up a feedback loop where you get the reviews from the users while developing the product according to the users needs.

Another thing that needs to be tracked during this period is the following key metrics in the Play Store:

  • LTV Lifetime Value
  • ARPU Average Revenue Per User
  • ARPPU Average Revenue Per Paying User


LTV metrics is the one that evaluates the average revenue that the user brings throughout its lifespan. Returning users to your app (in other words those who do not delete games right after the first try, but in long-term perspective consistently being involved with the game) are in the interests of the Play Store. Active users who constantly use the app bring the revenue due to the advertisement featuring in the apps through AdMob (which is the product of Google too). This is where the increment of ARPU metrics happen. By all means in the same way it also influences the AVPPU metrics. While tracking these metrics, we could evaluate whether we are developing the game in the right direction. The better metrics, the higher probability that your app will appear on the first page of Google Play Store.

We launched the game in Azerbaijan where we aimed to get as much feedback as possible. This was the way we wanted to fix all the bugs that they could face and be better prepared for the market that we consider as a target one. As a result, we fixed all major bugs in the app and got a 4.8 mark in the Play Store.

The soft-launch stage could finish there, but no, it did not. We entered another alternative market Russia. The different cultures, possible different habits of the users, and other factors made us understand that we need to try soft-launch in a new country. Another reason behind this was the scale. In Russia in 2015, the number of smartphone users was around 51.3 million people. We considered this market as a good platform where we could test our app.

In a few weeks, after launching the game in the new market, we started to receive negative reviews while losing the traffic. All of them was regarding one thing:

Most of the Russian users did not have a Facebook account where they needed to invite their friends or were not willing to pay $1 (one of these was required to proceed to pass to the next stage once they reached the 10th stage).

It made us understand that we need to come up with something universal in this stage of the game. We replaced Facebook invitations to gain 30 starts during the first 10 stages and be able to pass to the next stages once reached the 10th one kind of solution.

As a result of all these procedures with soft-launching, we got pretty high metrics in the Play Store that impacted our Play Store Optimization. We appeared on the first page of the Play Store.

Google Play Store is giving you a rate based on the countries that you already launched the app before. If you soft-launched the mobile app in specific markets first and got good marks from the users it equals the fact that when you will launch the game for the global market it will already have high Google Play Store rates. That was something that was supporting our vision.

Wise Choice of Operating System


You might notice that so far in the article I was mentioning everything about Android and its Play Store. And that was not an accident.

Usually, developers first launch mobile apps on IOS OS. The argument behind it is that the majority of people are IOS users or the purchasing power of this particular segment is higher rather than the one that Android users have. We questioned this understanding because for us it seemed like a myth.

We compared the metrics Average Revenue Per Paying User and Average Revenue Per User
Besides. For both operating systems it was the same amount. In our case, the weight of Fatal Fight was heavy and would only work on flagship smartphones that anyways cost a lot.

Besides that, we had several other reasons why we consciously choose Android over IOS:

Market Share. Sensor Tower reports that the Google Play Store pulled in approximately 75.7 billion first-time apps installed worldwide in 2018. Comparatively, the App Store only drove 29.6 billion.

Fast process. The updates on Android are being approved faster than on IOS. When giving our first build to IOS it took the game 3 months to be added to the App Store.

The difference in algorithms. Google Play Store is more generous with organic traffic. If you have built a great app, it will reward you with organic traffic. However, in IOS this picture differs. You need to buy traffic for money. For a long time, making apps popular through incentivized traffic was the leading strategy for Apple App Store. It involves some negatives including low lifetime value for the users. When users are incentivized by a reward, they are more likely to install your app without actually wanting it. This often makes it easier for them to uninstall your app after a few days. We wanted users to authentically choose us. Users who choose to involve themselves with the app due to personal interest was the priority both for our team and apparently for Android. This is why we love Google Play Store over Apple App Store.

Going Global


When we finally published Fatal Fight on IOS, Apple featured us in the Top new games'' category. It was not just a matter of luck. The game was developed using the Unity 3d engine, so we were using the same code for both platforms. The secret was the whole journey that this product passed with Android. The huge number of available devices in Android OS allowed us to face a variety of bugs and as a result, we have launched a polished product in the App Store.

Famous British blogger Deji also featured the game in his Paintball Challenge video on YouTube. Right after that, we were on top rankings in the USA and UK.

Now when we were in both stores and going global consequently our aim was to be the most agile with the feedbacks that we were receiving to keep the high ratings in both Google Play and App Store. We were pretty successful in the beginning. However, there were some bugs we could not fix.

Once we started to receive a series of feedbacks. All of them had the same issue I cannot hear the music and the sounds users were reporting. Samsung smartphones were the devices from where the reports were coming. We had several Samsung devices in the house. There were no issues with the sound in these devices. Then we noticed another pattern. All the feedback was coming from one model of Samsung Galaxy Tab 2. It turned out, specifically this type of device was not producing the sound. We bought a Galaxy Tab 2 and reproduced the bug and as a result, we fixed it and released the update.

Time passed, and we faced the major crush that came with the new update we released. All the users of Fatal Fight lost their game progress. Does not matter the number of stages the user might pass, it all crashed down.

Imagine losing the progress of a game where you spent your time, energy, and also money on digital goods. In other words, millions of users had to give up on the mobile game that already became a part of their lifestyle.

After 3 years in the market, we sold Fatal Fight to ITech Media Solutions in Estonia. Later they entered the Chinese market and released it on taptap.com which was one of the biggest Android mobile apps markets in the country. Fatal Fight became the number 1 most downloaded app on taptap.com.

This long journey with Fatal Fight made me face the major issues when it seemed that all the risks were minimized. While reflecting, I figured out that if there could be any platform where all the types of devices would be available for testing, any game would succeed.

The realization was a turning point for me and an inspiration for my next startup.

I have built Buglance to help other developers to release better mobile apps. It includes a network of 50k testers worldwide representing 10k+ unique devices. Here you are free to choose the type of device, country, demographics to test your app to make sure it works best for your audience. In other words, we built a product that could save Fatal Fight.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru