UX/UI дизайн как система. Как принимать решения, работать с данными и не бояться команды

2.1. Вступление

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

Это не стыдно. Это значит, что ты растёшь.

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

Но есть ещё одна проблема.

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

Помнишь Максима из первой главы? После того как он переделал свой интерфейс для склада, он успокоился. Ему казалось, что теперь он всё делает правильно. Он даже немного загордился: «Всё, я понял, как надо. Теперь я профессионал».

А потом он получил новый проект. И снова попал в ловушку. Но на этот раз — другую.

2.2. История первая. Максим

«Я знаю, что им нужно. Я же сам пользователь».

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

После истории со складом Максим выдохнул, закрыл тот злополучный макет и подумал: «Всё, теперь я понял. Больше никаких неонов и градиентов, если в них нет необходимости. Только польза, только данные». Он даже записал себе на стикере: «Дизайн — это решение проблем», прилепил на монитор и почувствовал себя почти гуру.

Прошло время. Максиму дали новый проект — мобильное приложение для доставки еды. Он открывает Figma, смотрит на чистое поле и думает: «Ну, я же сам заказываю еду. Я знаю, что людям нужно. Всё просто: меню, корзина, оплата. Погнали».

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

Максим с гордостью показывает макет заказчику. Тот смотрит, кивает и говорит:

— Красиво, но… у нас целевая аудитория — люди 45+, они не пользуются голосовым поиском. И почему ты убрал фильтр по кухням? Мы его тестировали — он увеличивает конверсию на 20%.

Максим замирает. Он опять… Снова… Его «гениальные идеи» оказались никому не нужны. Он гадал. А заказчик — знал, потому что проводил исследования, и все данные приложил отдельным файлом к техническому заданию. Тот файл под скрепочкой… В самом конце письма.

И вот наш дизайнер снова сидит, смотрит на свой макет и чувствует, как внутри нарастает то самое холодное: «Ну как так? Я же хотел как лучше...»

2.3. История вторая. Алиса

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

Но она не открывает Figma. Она открывает данные.

Она смотрит аналитику: кто пользователи? Как они заказывают? Какие у них боли?

Она видит: целевая аудитория — люди 45+. Они не используют голосовой поиск. Им важны фильтры по кухням. Они привыкли листать меню.

Она спрашивает продакта: «Какие гипотезы вы уже проверяли? Что сработало, а что нет?»

Она узнаёт, что фильтр по кухням уже тестировали — он дал +20% конверсии.

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

Она показывает заказчику. Тот смотрит и говорит: «Да. Это то, что нам нужно. Ты поняла, кто наши пользователи».

Алиса потратила на исследование 2 часа, на дизайн — один день. Максим потратил 2 дня на рисование и получил переделку.

В чём разница?

Максим гадал. Алиса исследовала, и эту разницу видит вся команда. Когда ты приходишь с данными, тебя слушают. Когда ты приходишь с догадками — тебя переделывают.

2.4. Что такое «гипотезы вместо людей» и почему это опасно

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

Как выглядит «гадание вместо исследований» на практике:

Ты добавляешь фичи, которые нравятся тебе: «Это же удобно, я бы так сделал».

Ты не проверяешь гипотезы на пользователях: «Я и так знаю, что им нужно».

Ты игнорируешь данные: «Цифры не важны, главное — мой опыт».

Ты не умеешь формулировать гипотезы: «Мне кажется, они хотят голосовой поиск».

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

Почему это опасно:

Ты тратишь время на ненужные фичи — создаёшь то, что никто не использует.

Ты теряешь доверие команды — твои решения не работают.

Ты подводишь команду — они ждут результатов, а ты гадаешь.

Ты чувствуешь себя самозванцем — не можешь объяснить, почему сделал именно так.

Бизнес теряет деньги — клиенты уходят к тем, кто их понимает.

В этой главе мы разберём:

почему дизайнеры гадают вместо того, чтобы исследовать;

как перестать придумывать и начать узнавать;

три простых метода, которые заменят гадание на знание;

как защитить свои решения перед командой.

2.5. Погружение в проблему

Почему дизайнеры гадают вместо того, чтобы исследовать?

Причин несколько. И все они очень человеческие.

Причина №1. «Исследования — это скучно и долго»

Давай признаемся: исследования кажутся чем-то из разряда «научной фантастики». Это же надо составлять вопросы, искать респондентов, проводить интервью, анализировать данные… Гораздо веселее сразу открыть Figma и начать рисовать! Там же результат виден сразу, а в исследованиях — непонятно что.

Как с этим справиться:

Перестань воспринимать исследования как «большой и сложный проект». Начни с малого. Один опрос двух человек занимает 15 – 20 минут. Один разбор тикетов поддержки — 30 минут. Одно наблюдение за пользователем — 10 минут.

Это не «научная фантастика». Это просто разговор с людьми, которые пользуются твоим продуктом. И он занимает меньше времени, чем ты думаешь.

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

Причина №2. «Я же сам пользователь»

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

Как с этим справиться:

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

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

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

Запиши свои предположения и проверь их. Если ты думаешь, что пользователи хотят X — проверь это на 5–10 людях. Если они скажут «нет» — ты сэкономил неделю работы.

И помни: «Я бы так сделал» — это про тебя. «Они так делают» — это про пользователей. Не путай.

Причина №3. «У меня нет времени»

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

Но спешка — это путь к переделкам.

Как с этим справиться:

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

Один день на исследование → спасает неделю переделок.

Пятнадцать минут на опрос → спасает день на перерисовку.

Тридцать минут на анализ тикетов → спасает два дня на обсуждения с командой.

Возьми таймер. Установи себе пятнадцать минут на одно мини-исследование. Если ты уложишься — ты уже победитель. А если не уложишься — ты всё равно потратишь меньше времени, чем на переделку.

Причина №4. «Я боюсь услышать правду»

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

Как с этим справиться:

Это самый сложный страх. Он лежит не в логике, а в эмоциях. Но есть один приём, который помогает.

Спроси себя: «Что хуже — узнать правду сейчас или узнать её после того, как я потратил недели на дизайн?»

Если ты узнаешь правду сейчас:

ты сэкономишь время и нервы;

ты сможешь исправить ошибку до того, как её увидят заказчик и разработчики;

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

Если ты узнаешь правду позже:

ты потратишь недели на то, что не работает;

ты потеряешь доверие команды;

ты будешь чувствовать себя самозванцем.

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

2.6. Решение и инструменты

2.6.1. Шаг первый. От «гипотезы» к «вопросу»

Первый шаг — перестать думать в формате «Я знаю, как надо» и начать думать в формате «А что на самом деле?».

Что делать:

Вместо того чтобы сразу рисовать макет, сформулируй гипотезу в формате:

«Я предполагаю, что если мы сделаем [действие], то [пользователь] получит [результат], потому что [причина].»

Или, если проще:

«Я думаю, что пользователям нужен [функционал], потому что [причина]. Давайте проверим.»

Примеры:

Гадание: «Пользователям нужен голосовой поиск».

Гипотеза: «Мы предполагаем, что голосовой поиск увеличит конверсию среди пользователей 18–25 лет, потому что они привыкли к голосовым командам в соцсетях. Проверим это через опрос десяти пользователей этой группы».

Разница очевидна: второе — это не просто «мне кажется», это запрос на проверку.

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

Я использую этот шаблон всегда — он спасает от бесконечных споров:

«Если мы [сделаем Х],то [пользователи]смогут [сделать Y], что приведёт к [измеримому результату Z], потому что [причина].»

Пример для интернет-магазина сумок:

«Если мы добавим фильтр по цвету на главную страницу, то пользователи смогут быстрее находить нужную сумку, что сократит время поиска на 30% и увеличит конверсию, потому что 60% пользователей указывают цвет как главный критерий выбора».

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

2.6.2. Шаг второй. Три простых метода для проверки гипотезы

У нас нет бюджета на дорогие исследования? Не проблема. Есть три способа, которые работают и ничего не стоят.

Метод №1:Опрос пяти–десяти человек

Это самый простой способ. Ты берёшь свой вопрос и задаёшь его пяти–десяти людям из твоей целевой аудитории.

Что делать:

Сформулируй вопрос: «Пользуешься ли ты функцией Х?» или «Что для тебя важно при выборе Y?».

Задай его пяти–десяти людям.

Запиши ответы.

Сделай вывод.

Пример:

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

Нюансы:

Это не полноценное исследование, но оно даёт первичную информацию.

Важно спрашивать честно, не наводя на ответ.

Если восемь из десяти говорят одно — это уже сигнал.

Метод №2:Анализ тикетов поддержки

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

Что делать:

Попроси доступ к тикетам поддержки (обычно это легко сделать).

Собери пятьдесят–сто тикетов.

Выпиши повторяющиеся вопросы и проблемы.

Сделай вывод: что чаще всего беспокоит пользователей?

Пример:

Я анализирую тикеты поддержки интернет-магазина. Вижу: 30% вопросов — «Как отменить заказ?», 20% — «Не пришло письмо с подтверждением», 15% — «Не могу найти товар». Вывод: нужно сделать кнопку «Отменить заказ» заметнее, проверить работу писем и улучшить поиск.

Почему это работает:

Это бесплатно.

Это реальные данные от реальных пользователей.

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

Метод №3:«Shadowing» — посмотри на пользователя со стороны

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

Что делать:

Найди одного–трёх пользователей твоего продукта.

Попроси их выполнить конкретную задачу (например, «Найди товар и добавь в корзину») и комментировать свои действия.

Смотри молча. Не помогай. Не объясняй. Просто наблюдай.

Записывай моменты, где пользователь зависает, ошибается или делает не то, что ты ожидала.

Пример:

Я смотрю, как пользователь ищет телефон в интернет-магазине. Он набирает «iPhone 15» в строке поиска, жмёт Enter, видит двести результатов и зависает. Он не понимает, как отсортировать по цене. Я записываю: проблема — пользователь не видит сортировку. Через минуту я добавила кнопку «Сортировать по цене» в заметное место.

Почему это работает:

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

Это бесплатно.

Это занимает пятнадцать минут, а спасает от недель переделок.

2.6.3. Шаг третий. Как защитить свой дизайн перед командой, используя исследования

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

Вот твой скрипт для защиты дизайна:

«Мы проверили эту гипотезу через [метод], и выяснили: [факты]. Поэтому я предлагаю сделать [решение], потому что это решает проблему [пользователей].»

Пример:

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

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

2.7. Итог: алгоритм действий

Сформулируй гипотезу — не «я знаю», а «я предполагаю, проверим?»

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

Сделай вывод. Если гипотеза подтвердилась — двигайся дальше. Если нет — формулируй новую.

Защити своё решение перед командой — используй данные, а не фразу «мне кажется».

2.8. Резюме

Гадание — путь в никуда. Ты тратишь время на то, что никому не нужно, и подводишь команду.

Перестань придумывать, начни узнавать. Формулируй гипотезы в формате «Если мы сделаем Х, то получим Y, потому что Z».

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

Исследования — твоя броня. Они делают твой голос весомым и защищают от бесконечных правок.

Когда ты приходишь с данными, тебя слушают. Когда ты приходишь с догадками — тебя переделывают.

2.9. Практическое задание

Возьми свой текущий проект (или любой старый макет) и сделай три вещи:

Задание 1. Сформулируй гипотезу

Сформулируй одну гипотезу по шаблону:

«Если мы сделаем [Х], то пользователи смогут [Y], что приведёт к [Z], потому что [причина].»

Задание 2. Проведи опрос

Задай свой вопрос пяти–десяти людям из целевой аудитории. Запиши их ответы. Сделай вывод: подтвердилась гипотеза или нет?

Задание 3.Проанализируй тикеты (если есть доступ)

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

2.10. Чек-лист для самопроверки

□ Я сформулировал гипотезу, а не просто нарисовал макет.

□ Я проверил гипотезу на реальных пользователях (опрос, тикеты, наблюдение).

□ Я могу объяснить, почему я сделал именно так, опираясь на данные.

□ Я не добавляю фичи, которые «кажутся» удобными.

□ Я знаю, кто мои пользователи, и понимаю их боли.

2.11. FAQ

— А что, если у меня нет доступа к тикетам поддержки?

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

— А если у меня нет времени на исследования, дедлайн горит?

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

— А что, если я проведу опрос, а он скажет, что моя гипотеза неверна? Это же провал.

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

— А как быть, если команда не верит в исследования и требует сразу рисовать?

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

— А как понять, что я действительно исследовал, а не просто спросил у коллеги?

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

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

Как отличить коридорный тест от настоящего исследования:

Если ты просто спросил у коллеги «как тебе?» и он сказал «нормально» — это не исследование. Это мнение.

Если ты показал макет трём–пяти коллегам на пять секунд, записал, что они запомнили, и сделал выводы — это уже коридорный тест. Он даёт первичную информацию, но не заменяет разговор с реальными пользователями.

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

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

2.12. Связка с другими материалами

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