Как дизайнеру работать с гипотезами: от идеи до проверки

В работе дизайнера часто бывает так. Есть задача, есть макет, есть обоснование «мне кажется, так будет удобнее». Но когда доходит до дела, никто не может ответить на простой вопрос: почему мы уверены, что это изменение сработает?

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

Гипотеза не значит «давайте попробуем». Гипотеза это предположение, которое можно проверить. Если мы меняем что-то в интерфейсе, у нас должна быть причина, ожидание результата и способ убедиться, что результат действительно есть.

Что такое гипотеза в дизайне

Гипотеза это предположение о том, как изменение в продукте повлияет на поведение пользователя или метрики. Она переводит разговор из плоскости «мне нравится / не нравится» в плоскость «если сделать так, ожидаем такой результат».

У гипотезы всегда есть три элемента:

• Изменение. Что именно мы собираемся сделать в интерфейсе;
• Ожидание. Что должно произойти с поведением пользователя;
• Критерий проверки. Как мы поймём, что результат достигнут.

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

Как формулировать гипотезы

Самый простой способ, использовать структуру «Если…, то…, потому что…»:

Если мы [изменение], то [ожидаемый результат], потому что [причина].

Например:

Если мы добавим кнопку «Купить сейчас» на карточку товара, то конверсия в заказ вырастет, потому что пользователю не придётся искать корзину.

В Lean UX есть более развёрнутый шаблон, который сразу включает метрику проверки:

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

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

Откуда брать гипотезы

Гипотезы не рождаются из воздуха. Они появляются из данных. Вот четыре основных источника:

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

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

Приоритизация гипотез

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

ICE: Impact, Confidence, Ease (влияние, уверенность, простота). Каждый критерий оценивается по шкале от 1 до 10. Среднее значение это приоритет.

RICE: Reach, Impact, Confidence, Effort (охват, влияние, уверенность, трудозатраты). Более точный фреймворк, потому что учитывает, сколько пользователей затронет изменение.

Оба метода помогают перевести субъективные «мне кажется, это важно» в измеримые приоритеты.

Как проверять гипотезы

Когда гипотеза сформулирована и приоритизирована, её нужно проверить. Есть три основных способа:

• A/B-тест. Две версии интерфейса показываются разным группам пользователей. Смотрим, какая даёт лучший результат по выбранной метрике;
• Юзабилити-тест. Пользователи выполняют задачу в новом интерфейсе. Смотрим, справляются ли они быстрее и с меньшим количеством ошибок;
• Анализ метрик. Сравниваем ключевые показатели до и после изменения. Конверсия, время выполнения задачи, количество ошибок, отвалы.

В SaaS-продуктах часто используют комбинацию A/B-теста и опроса пользователей (например, UEQ), чтобы оценить не только поведение, но и субъективное восприятие интерфейса.

Метрики для проверки гипотез

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

• Conversion Rate (CR). Доля пользователей, совершивших целевое действие;
• Task Success Rate. Процент пользователей, успешно выполнивших задачу;
• Time on Task. Время, затраченное на выполнение задачи;
• Error Rate. Количество ошибок на пути к цели;
• Drop-off Rate. Доля пользователей, ушедших на определённом шаге.

Для субъективного опыта можно использовать стандартизированные опросники: SUS (System Usability Scale), UMUX-Lite, NPS. Они дают числовую оценку, которую можно сравнивать до и после изменений.

5 ошибок при работе с гипотезами

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

• Гипотеза без метрики. «Мне кажется, так будет лучше» это не гипотеза. Нужен измеримый критерий;
• Слишком общая гипотеза. «Улучшим интерфейс» это не гипотеза. Нужно конкретное изменение;
• Проверка на маленькой выборке. Результат может быть случайным. Нужно рассчитать размер выборки заранее;
• Остановка теста раньше времени. Результат может измениться. Нужно дождаться статистической значимости;
• Игнорирование результатов. Если гипотеза не подтвердилась, это тоже результат. Не нужно «спасать» решение, если данные говорят обратное.

В итоге

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

Гипотезы это мост между дизайном и бизнес-результатом. Они помогают:

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

Продуктовый дизайн не только про «красиво». Он про результат. А результат можно измерить только тогда, когда есть гипотеза, метрика и способ проверки.

Хороший дизайнер не просто проектирует интерфейс. Он проверяет, что этот интерфейс действительно работает.