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

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

«На это уйдет слишком много времени. Когда мы сможем увидеть готовый результат?»

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

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

Еще дизайн часто ассоциируют только с итоговым продуктом или решением, потому что подготовительная работа не видна (и снова хороший пример — управление продуктом). Отсюда и неверные обобщения — «продакт-менеджеры всё время составляют Roadmap и ставят тикеты в Jira», а «дизайнеры только рисуют дизайн-макеты».

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

Дорога в ловушку форм-фактора вымощена оптимизацией

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

Руководители всегда хотят скорее перейти к «ощутимым» результатам, которые можно увидеть и оценить. Всё, что идет до — они стремятся оптимизировать или попросту сократить. Это та самая часть процесса, которая «занимает слишком много времени» и кажется неважной: зачем она нужна, если дизайнеры всё равно сдадут готовый дизайн и без нее?

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

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

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

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

И вот в итоге у нас получается красивый, но не до конца продуманный дашборд. Пользователь не может получить релевантную информацию, чтобы совершить то или иное действие в нужный момент, потому что мы сократили часть процесса, которая отвечала на важный вопрос: «Что это значит и как понять, что мы всё делаем правильно?»

Готовые визуальные артефакты — не равно готовый дизайн

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

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

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

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

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

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

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

Эмпатия к пользователям, эмпатия к коллегам

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

Такая точка зрения неверна и непродуктивна. Дизайнеры не рождаются более проницательными и эмпатичными, и они не единственные, кто «ищет лучшие решения для клиента» — в бизнесе к этому стремятся все. На этом основан и метод Agile — быстрее сделать готовое решение, чтобы убедиться в его ценности. Программисты работают по нему еще со времен, когда слово «дизайн» в заказной разработке мелькало только при упоминании принципа Big Design Up Front.

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

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

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

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

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

Не придумывайте решения — сначала продумайте основные преимущества для пользователя

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

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

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

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

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

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

Еще выше по тексту мы говорили о дашборде с продуманным визуалом и непродуманным концептом. Как раз он не дает никакой явной ценности для пользователя. Нам ответят: «Но ведь у пользователя будет дашборд!». Проблема в том, что такое определение ценности говорит об ее отсутствии. Эта концепция явно не готова — чтобы это понять, ее даже не нужно воплощать в жизнь и тестировать.

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

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

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

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

В первом эпизоде говорили с Олегом Рудаковым, руководителем Data Scientist в крупной FMCG-компании, а скоро обсудим найм продактов и продуктовые стратегии с Павлом Аксеновым, ex CPO «Самолет Плюс». Следите за анонсами выпусков в нашем Телеграм-канале.