You are currently viewing UX-дизайн в разработке игр

UX-дизайн в разработке игр

Наступило понимание того, что поста с этим заголовком не избежать. Огромное количество сотрудников из GameDev всех уровней имеют крайне смутное представление о том, что такое UX-дизайн. Ответ на простой с виду вопрос «Чем занимается UX дизайнер» занимает львиную часть собеседования, если не прибегнуть к чудовищным упрощениями. Полное перечисление «UX»-связанных активностей приводит к округлению глаз интервьюера и последующей фрустрации.

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

Упрощенное определение UX-дизайна

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

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

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

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

Цели UX дизайна

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

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

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

Пользователь — обязательный компонент

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

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

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

Связь сервисных методик и методик дизайна игровых продуктов

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

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

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

Не все в наших силах

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

Замечу, что случаи такого перетягивания, на самом деле, редкостью не являются. Эксклюзивные для платформы игры, MAC-ориентированный дизайнерский софт — примеры платформо-образующих разработок.

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

UX-дизайн продуктовая дисциплина

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

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

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

UX-дизайн — знамя продуктового подхода в разработке

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

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

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

Возможные UX-активности в разработке игровых продуктов

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

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

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

Обязательно упомяну, что почти всегда, нанятый в середину разработки UX-дизайнер, не имеет возможности оказывать влияние на верхне-уровневые продуктовые решения. По большей части высокую текучку на UX-позициях в крупных компаниях с инертным бюрократизированным продуктовым штабом, отчасти объясняет такой подход к интеграции UX. Для работы UX-дизайнера поддержка (или участие) продуктовых ролей — необходима.

Этап разработки концепции продукта

Гипотезы по составу аудитории

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

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

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

Идеально работает связка — продуктовый менеджер (один из продюсеров, как вариант) + UX-дизайнер. Конечно, не плохо, если это будет один и тот же человек, такое уже не редкость.

Карта-фичей первой очереди

Коллегиально приняв карту-основу, можно скорректировать план реализации фичей первой очереди. Каждому значимому сегменту (о не значимых сегментах на этом этапе нам, скорее всего, известно мало) нужно дать механики, которые могут обеспечить стартовые продуктовые показатели. Такие как: retention 3-7, процент игроков совершивших приобретение и т. п.

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

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

Участие в формировании интерфейсной аналитической поддержки

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

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

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

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

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

Этап производства первых версий

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

Проектировка UI концепции интерфейсов игры и навигации

Когда известен стартовый состав продукта, можно продумать организацию UI экранов и создать черновой UI guide. Как будут организованы интерфейсные HUB’ы (не путать с хабами внутри игрового мира), какую сложность будут иметь агрегаторы и рубрикаторы, основные элементы управления подходящие под заложенную сложностью. Как будет поддерживаться добавление фичей второй и последующих очередей — все эти вопросы легко фиксируются в черновике и становятся годны к предметному обсуждению с коллегами.

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

Проектировка фичей

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

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

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

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

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

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

Первичные исследования

Результаты первых тестов — первый бой наших гипотез с реальностью. Выявиться может все, что угодно от несостоятельности наших гипотез о ЦА, до отсутствия возможности реализовать задуманное в должном виде. Провести первые тесты и сделать корректировку плана по полученным выводам, жизненно важная для продукта активность, которую UX-дизайнер должен провести или организовать и проконтролировать.

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

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

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

Поддержка первых версий

Проверка гипотез по сегментам аудитории

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

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

Итеративные изменения состава фичей до готовности

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

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

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

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

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

Подготовка продукта к оперированию

Участие в создании стратегии оперирования

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

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

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

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

Этап оперирования

Участие в формировании концепций проектов фичей

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

Итеративная проектировка UI фичей на протяжении жизни проекта

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

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

Я практикую и стараюсь внедрить в команды раздельные активности: отдельное создание UX концепций и черновиков, и чистовой UI дизайн. Где проектировка и концепции делаются загодя, а к UI дизайну приступают при приближении срока разработки. Время необходимое на оформление макетов можно довольно точно прогнозировать при наличии продуманного черновика. И наоборот, время на создание UI-дизайна, если он должен вместить в себя и продумывание концепции, совершенно не предсказуемо. Пытаясь сделать концепцию сразу в финальном виде (за один проход), вы почти гарантировано делаете бесполезную первую итерацию, т. к. успеть и продумать и отрисовать и запрограммировать одним наскоком невозможно. Правда, можно и не торопиться — тогда сказанное выше теряет актуальность.

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

Уточнять и уточнять

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

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

Связки с другими специализациями

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

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

Сложно! Простота не проста!

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

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

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

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


This Post Has One Comment

  1. Артём

    Спасибо за подробный материал! Очень доступно подано. Единственное, слово “проектировка” сильно режет глаз)

Leave a Reply

%d bloggers like this: