Дэн Олсен – MVP. Как выводить на рынок товары и услуги, которые нравятся покупателям (страница 35)

Проектирование для экранов разных размеров

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

У вас может возникнуть вопрос: на какой размер экрана (большой или маленький) следует ориентироваться, начиная процесс разработки UX-интерфейса? Если вы изначально разрабатывали свой продукт под экран большего размера, адаптация его к меньшему экрану может оказаться непростой задачей. Созданный объем контента может просто не поместиться на маленьком экране, и вам придется делать трудный выбор – определить элементы, которые придется удалить. Вероятно, вы будете вынуждены изменить и систему навигации. Необходимо будет пересмотреть и переделать контент, размер которого слишком широк для маленького экрана. Поэтому в подобных случаях разработчики часто создают отдельный продукт, переписывая программный код. Однако такое решение не является идеальным. Во-первых, необходимость в дальнейшем каждый раз вносить изменения и дополнения в два отдельных фрагмента кода приводит к снижению эффективности и увеличению вероятности ошибок. Во-вторых, разработанные по отдельности мобильная и немобильная версии продукта часто оказываются настолько непохожими друг на друга, что это приводит к неорганичности пользовательского опыта, вызывая у клиентов непонимание и раздражение.

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

Копирайтинг также является частью UX-дизайна

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

«Команда “А”»

Как вы могли заметить по количеству тем, рассмотренных в данной главе, UX-дизайн подразумевает применение множества различных навыков. У многих компаний наблюдается «пробелы в дизайне» из-за нехватки специалистов, участие которых является необходимым для создания превосходного UX-дизайна. Во многих командах разработчиков дизайнеры просто отсутствуют. И даже если у вас есть дизайнер, он, вполне возможно, не владеет всеми аспектами UX-дизайна. Чаще всего такой специалист бывает силен либо в визуальном дизайне (в том, как выглядит продукт), либо в интерактивном дизайне (в том, как продукт работает). Для создания превосходного пользовательского опыта ваша команда должна быть талантливой в каждой из этих областей. Кроме этого, вам потребуется фронтенд разработчик, который сможет грамотно реализовать созданный дизайн, а также сильный менеджер по продуктам. Помимо того, что каждый член команды в отдельности обладает необходимыми навыками, крайне важно чтобы они могли эффективно работать вместе. Я называю команды, обладающие всем этим набором из четырех основных навыков – продакт-менеджмент, интерактивный дизайн, визуальный дизайн и фронтенд-разработка – «Командой “А”» (как в популярном сериале 1980-х годов)[17]. Очевидно, что для создания успешного продукта важны также и другие роли или навыки: бэкенд-разработчики, специалисты по обеспечению качества (QA), DevOps-инженеры и так далее. Но в деле создания превосходного пользовательского опыта наличие «команды “А”» имеет решающее значение.

UX – это то, что видит пользователь

В конце концов, вердикт о том, насколько хорош созданный вами пользовательский опыт, выносит пользователь, и это напрямую влияет на степень соответствия продукта рынку. Вспомните описанный в главе 3 «Жизненный цикл внедрения новых технологий», согласно которому, новаторы готовы мириться с недостаточно качественным пользовательским опытом прорывного продукта, ради получения предлагаемых им преимуществ. Но по мере продвижения по этому жизненному циклу и попыток проникновения в более широкие сегменты пользователей вы столкнетесь с тем, что они окажутся уже не столь терпимыми к недостаткам вашего UX, который одновременно будет становиться все более важным аспектом соответствия продукта рынку. Несмотря на то что создание превосходного дизайна требует большого мастерства и значительных затрат ресурсов, это ни в коей мере не оправдывает низкое качество пользовательского опыта вашего продукта. А, как я уже говорил ранее, для выявления любых проблем с продуктом лучше всего подходит тестирование на пользователях. О том, как протестировать прототип MVP на пользователях, пойдет речь в следующей главе.

Глава 9

Тестирование минимально жизнеспособного продукта (MVP) на пользователях (Шаг 6)

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

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

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