Kitabı oxu: «UX/UI дизайн как система. Как принимать решения, работать с данными и не бояться команды»
Введение
Как перестать рисовать картинки, и начать решать задачи?
Ты когда-нибудь чувствовал, что твой дизайн похож на красивую открытку? Все восхищаются, но никто не понимает, как это работает.
Ты сдаёшь макет руководителю на проверку. Он смотрит на работу и задаёт вопросы, на которые у тебя нет ответов:
— Почему кнопка здесь? Почему такой цвет? Зачем этот элемент вообще нужен? Ты поворачиваешься к своему экрану, и внутри появляется холодок. Ты не знаешь ответа. Ты просто нарисовал «красиво».
А через месяц к верстке приступают разработчики. У них нет времени приходить к тебе с вопросами. Они просто додумывают то, что ты не отрисовал в макете: сами решают, каким будет состояние кнопки при нажатии, придумывают поведение формы при ошибке, адаптируют элементы под мобильные устройства. Они не дизайнеры, они инженеры. Их решения продиктованы тем, как проще написать код, а не тем, как удобнее пользователю. Дизайн начинает разваливаться в руках разработчиков, потому что он был картинкой, а не системой.
Позже ты открываешь готовый продукт и не узнаете свой дизайн. Кнопки другие, отступы съехали, состояний ошибок нет. Продукт выглядит сырым, и совсем не таким каким был на макете в Figma.
Знакомо?
Я видела это слишком много раз. В разных командах, на разных проектах, у специалистов разного уровня. Ошибки повторяются с пугающим постоянством. Не потому, что дизайнеры глупые или ленивые, а потому, что нас никто не учит мыслить системно.
Эта книга — именно о системе.
О чём эта книга
Эта книга — не просто о дизайне. Это система: пошаговый алгоритм, который превращает хаос в порядок.
Здесь нет абстрактных теорий и сложной терминологии — только конкретные ошибки, проверенные решения и план действий. Она для тех, кто хочет не просто рисовать макеты, а принимать осознанные продуктовые решения. Для новичков, которым нужна опора, и для опытных специалистов, которые стремятся систематизировать свою работу.
Я — UX-методолог. Моя первая книга, «Методы UX-исследований. 25 методов с примерами и метриками», стала справочником по инструментам работы с данными UX-исследований.
Эта — совсем другая книга. Без лишней теории я покажу главные барьеры и страхи, которые мешают дизайнерам расти, и дам алгоритмы их преодоления. Это путеводитель по реальным проблемам профессии: от непонимания бизнес-задач до страха перед AI и неопределенностью на рынке.
Внутри — не догадки, а выверенная методология. Система, которую я собрала по крупицам из реальных проектов, ошибок и побед.
Для кого эта книга
Для начинающих дизайнеров, которые хотят строить карьеру системно, а не наугад. Для тех, кто хочет научиться аргументировать свои решения так, чтобы работу принимали с минимальным количеством правок.
Для продуктовых менеджеров и тимлидов, которые хотят понимать, где в дизайн-процессе скрываются риски и как их предотвращать. Эта книга поможет тебе говорить с дизайнерами на одном языке и выстраивать эффективные процессы в команде.
Для предпринимателей и основателей стартапов, которые хотят понимать, как сделать дизайн так, чтобы он работал на бизнес, а не просто «красиво выглядел». Ты узнаешь, как оценивать качество дизайна и принимать правильные решения без лишних затрат.
Для всех, кто чувствует, что застрял — боится критики, не знает, как защищать свои решения, не понимает, как расти в профессии. Если ты хочешь перестать быть «дизайнером-исполнителем» и стать «дизайнером-партнёром» — эта книга тоже для тебя.
Как устроена эта книга
Книга состоит из шести частей, которые ведут от базовых ошибок к стратегическому мышлению и профессиональному росту.
Часть 1. Пять ошибок, которые убивают продукты (главы 1–5)
Это то, с чего мы начинаем. Пять системных ошибок, которые я вижу в работе дизайнеров снова и снова. Каждая глава — это один кейс. Я показываю, как ошибается Максим — дизайнер, который учится на своих провалах, и как правильно делает Алиса — дизайнер, который использует систему. Вы увидите контраст и поймёте, какой путь ведёт к результату. После прочтения первой части, ты:
перестанешь рисовать картинки и начнёшь решать задачи (глава 1);
научишься проверять гипотезы, а не выполнять задачи наугад (глава 2);
начнёшь задавать вопрос «Зачем?» и предлагать альтернативы (глава 3);
будешь начинать с простого, а не строить дворцы (глава 4);
станешь продумывать полноценные сценарии, а не только «счастливый путь» (глава 5).
Часть 2. Инструменты, которые делают тебя экспертом (главы 6–8)
Здесь я рассказываю о том, как перестать бояться исследований, задавать правильные вопросы и читать метрики. Как работать в условиях неопределённости и как принимать обратную связь так, чтобы она делала вас сильнее, а не больнее.
Ты научишься:
не бояться исследований — пять страхов и способы с ними справиться (глава 6);
задавать правильные вопросы — пять типов вопросов для любой ситуации (глава 7);
принимать решения на основе данных — пять основных метрик для дизайнера + дополнительные (глава 8).
Это превращает тебя из «дизайнера-исполнителя» в «дизайнера-партнёра», к мнению которого прислушиваются.
Часть 3. Как работать с неопределённостью и обратной связью (главы 9–10)
Здесь мы разбираем два самых сложных навыка, которые отличают джуниора от мидла и синьора: умение работать в условиях неопределённости (когда нет чёткого ТЗ) и умение принимать обратную связь (когда заказчик говорит «мне не нравится»).
Ты научишься:
работать с неопределённостью — пять страхов и способы с ними справиться (глава 9);
работать с обратной связью — пять типов критиков и стратегии работы с ними (глава 10).
Часть 4. Карьера и рынок (главы 11–14)
Это отдельный блок для тех, кто хочет не просто выжить в профессии, а строить карьеру осознанно. В 2026 году рынок дизайна изменился, и важно понимать, как оставаться востребованным.
Ты узнаешь:
пять побед Макса — как навыки превращают хаос в результат (глава 11);
как не выгореть на рынке 2026 года — карьерная стратегия и работа с тревогой (глава 12);
как собрать портфолио, которое продаёт — структура кейсов и работа с бизнес-контекстом (глава 13);
как использовать AI как инструмент — а не бояться, что он заменит тебя (глава 14).
Часть 5. Работа в команде (главы 15–16)
Здесь мы разбираем, как выстраивать эффективное взаимодействие с разработчиками и организовывать работу так, чтобы не утонуть в хаосе.
Ты узнаешь:
как подружиться с разработчиками — и говорить на одном языке (глава 15);
как создавать дизайн-системы — и не утонуть в компонентах (глава 16).
Часть 6. Продуктовое мышление (главы 17–18)
Это финальный блок, который превращает тебя из дизайнера, который «делает красиво», в дизайнера, который решает бизнес-задачи.
Ты узнаешь:
как мыслить, как продакт — понимать бизнес, формулировать гипотезы и влиять на продукт (глава 17);
как делать доступные интерфейсы — и почему это больше не опция, а обязанность (глава 18).
Эта часть — про твою ценность для бизнеса, про влияние на продукт и про то, как оставаться востребованным в меняющемся мире.
Как читать эту книгу
Можешь читать её последовательно — главу за главой, или открыть любую главу, которая сейчас интересует больше всего. Каждая глава — это самодостаточная история. Ты не потеряешь смысл, если начнёшь с середины.
В конце каждой главы я даю:
резюме — чтобы ты запомнил главное;
практическое задание — чтобы ты сразу применил знания;
чек-лист — чтобы проверить себя;
FAQ — я ответила на самые частые вопросы.
Это делает книгу не просто «интересным чтивом», а рабочим инструментом, который можно использовать в повседневной практике.
И ещё кое-что важное
Эта книга — не про то, как стать идеальным дизайнером. Идеальных не бывает. Но есть системные подходы, которые сводят количество ошибок к минимуму.
Эта книга — про то, как начать проектировать осознанно. Как превратить дизайн из «картинки» в рабочий инструмент, который решает задачи пользователей и приносит пользу бизнесу.
Хотите больше?
Если после прочтения появятся вопросы или ты захочешь обсудить что-то из книги — я всегда открыта для диалога.
А если хочешь углубиться в теорию — моя первая книга «Методы UX-исследований» уже ждёт на Litres. В ней я разобрала 25 методов, которые помогут вам принимать решения на основе данных, а не интуиции.
Две книги — два уровня.
Первая — про инструменты.
Вторая — про систему.
Вместе они дают полную картину: что делать и как думать. Как принимать решения и как их защищать. Как строить карьеру и как оставаться востребованным.
Ну что, поехали?
ГЛАВА 1. СИНДРОМ DRIBBBLE: КАК ПЕРЕСТАТЬ РИСОВАТЬ КАРТИНКИ И НАЧАТЬ РЕШАТЬ ЗАДАЧИ
1.1. Вступление
Эта глава — о самой массовой ошибке, которую я наблюдаю у дизайнеров на всех уровнях: от новичков до вполне опытных специалистов. Ошибка настолько типична, что в профессиональном сообществе у неё есть устойчивое название — «синдром Dribbble».
Сначала я расскажу две истории. В первой — дизайнер делает всё, как его учили на курсах по «красивому дизайну». Во второй — дизайнер делает всё, как учит системный подход. Посмотри, в ком ты узнаешь себя. И решай, какой путь тебе ближе.
1.2. История первая. Максим
Максим — начинающий дизайнер. Он получил первый серьёзный заказ — интерфейс для системы управления складским учётом. Не красивый сайт, а сложный технический инструмент: таблицы, графики, отчёты, фильтры.
Максим открывает Figma и начинает творить.
Ему кажется, что интерфейс должен быть стильный, современный, с градиентами, тенями и плавными анимациями. Он вдохновляется Dribbble и Pinterest: окошки с неоновыми подсветками, кнопки с эффектом стекла, анимированные иконки складов, которые летают при наведении.
Он работает три дня. Макет выглядит потрясающе. Это не просто интерфейс — это арт-объект.
Максим с гордостью отправляет макет заказчику.
Заказчик — мужчина лет под 60, с двадцатилетним стажем в логистике — открывает макет. Несколько секунд молчит. Разглядывает. Щурится. Потом нажимает на кнопку «Добавить товар» — она светится неоном, плавно увеличивается и издаёт воображаемый «пшик». А рядом нет ни поля для ввода артикула, ни кнопки «Сохранить», ни даже простой таблицы с товарами.
Ни-че-го.
Заказчик трёт переносицу:
— Красиво, но… где таблица? Где столбцы с артикулами и количеством? А где кнопка «Сохранить»? Мне не нужно угонять звездолёт, — шёпотом произносит он, переводя взгляд с одной светящейся и мигающей кнопки на другую. — Мне нужен экран, по которому мои кладовщики быстро проведут тысячу позиций. Чтобы я открыл — и увидел всё. Сразу. Без анимации. Без неона.
Максим смотрит на свой макет свежим взглядом — и его передёргивает. Он нарисовал новогоднюю ёлку, а не интерфейс для склада.
Он перерисовывает. Убирает неоновые подсветки, добавляет таблицу, делает кнопки плоскими. Но теперь у него 15 цветов на экране: зелёные кнопки «Добавить», красные «Удалить», синие «Редактировать», жёлтые предупреждения, фиолетовые баннеры… Глаза разбегаются.
Заказчик снова пишет: «Красиво, но я ничего не вижу. Всё такое яркое, ничего не могу разглядеть».
Максим убирает 70% декора. Оставляет чёрно-белую таблицу с четырьмя столбцами, серые кнопки, чёткую структуру.
Заказчик: «Вот теперь всё отлично. Спасибо».
Максим смотрит на свой минималистичный интерфейс и понимает: именно это и должно было быть с самого начала. Три дня потеряны. А могли бы быть три часа.
1.3. История вторая. Алиса
Алиса — дизайнер с системным подходом. Она тоже получила заказ на интерфейс для складского учёта. Но она начинает не с Figma, а с вопросов.
Она садится с заказчиком и выясняет:
Кто пользователи? Кладовщики, 20–50 лет, большая часть с бухгалтерским образованием. Им важна скорость. Им привычны таблицы.
Какая главная задача? Быстро найти товар по артикулу и отметить его количество.
Какие данные критичны? Артикул, наименование, остаток, место на складе.
Алиса берёт лист бумаги и рисует простую таблицу в четыре столбца. Без теней, без градиентов, без анимации. Показывает заказчику. Тот говорит: «Да, вот это понятно. А можно ещё кнопку "Редактировать" рядом с каждой строкой?»
Алиса добавляет кнопку. Всё.
Она открывает Figma и за 20 минут собирает чистый, понятный интерфейс: таблица, кнопка «Добавить товар», фильтры сверху, форма редактирования в модальном окне. Единый стиль. Чёткая иерархия.
Заказчик принимает макет с первого раза.
Алиса потратила на проект 4 часа. Максим — 3 дня и 2 итерации.
В чём разница?
Максим проектировал картинку. Алиса проектировала решение.
И эту разницу видят все: заказчик, разработчик, продукт-менеджер. Они не говорят: «Какая красивая страница!» Они говорят: «Я быстро нашёл, что хотел, и сделал то, за чем пришёл». Это и есть победа.
1.4. Что такое «синдром Dribbble» и почему он опасен
В профессиональном сообществе это явление называют «синдромом Dribbble» — и не случайно.
Dribbble — это платформа, где дизайнеры выкладывают свои «шедевры»: красивые, стильные, но часто абсолютно нежизнеспособные решения. Там можно зависнуть на час, вдохновляясь идеями, и незаметно для себя начать проектировать картинку, а не решение.
Это известная проблема, о которой говорят на конференциях, в блогах и в вакансиях. Работодатели всё чаще пишут: «Понимать, что дизайн — это не картинка, а инструмент решения задач». Заказчики жалуются на «красивые, но бесполезные макеты». Разработчики устали спрашивать: «Что здесь вообще происходит?»
В этом главная опасность: ты перестаёшь думать о пользователе и начинаешь думать о том, как бы сделать «вау». А «вау» — это не про UX. Это про искусство.
UX — про то, чтобы пользователь сделал то, зачем пришёл, не напрягаясь, без бесконечных поисков и переходов от одной страницы к другой.
Как выглядит синдром Dribbble на практике:
Элементы не связаны с задачами — кнопка есть, но она не видна или не понятна.
Визуальный шум — 15 цветов, 7 шрифтов, анимации на каждом элементе.
Декоративные элементы перебивают функциональные — картинка важнее кнопки «Купить».
Нет иерархии — глаза разбегаются, не понятно, куда смотреть.
Нет состояний — кнопка есть, но hover/active/disabled не проработаны.
1.5. Погружение в проблему
1.5.1. Почему дизайнеры попадают в «синдром Dribbble»
Причина №1. «Меня учили делать красиво»
На курсах и во многих обучающих методиках акцент часто делают на визуальную составляющую. Студентов учат подбирать цвета, работать с типографикой, создавать композиции, но редко учат задавать вопросы: «Кто пользователь?», «Какая задача?», «Что для них критично?»
Как с этим справиться:
Переключи фокус. Вместо «Как сделать красиво?» спроси себя: «Как сделать полезно?» Красота — это дополнение к решению, а не самоцель. UX-дизайн начинается с вопросов, а не с Figma.
Причина №2. «Вдохновляюсь картинками»
Дизайнер открывает Dribbble или Behance, видит красивые работы и начинает копировать стиль, не вникая в контекст. Он не знает, кто пользователи, какая задача, какие ограничения.
Как с этим справиться:
Вдохновляйся решениями, а не картинками. Смотри не на то, как красиво, а на то, как это работает. Какие задачи решает данный интерфейс? Как он помогает пользователю? Если ты не знаешь ответа — это просто картинка.
Причина №3. «Хочу впечатлить»
Дизайнер боится, что его работу сочтут слишком простой. Он добавляет сложные анимации, нестандартные шрифты, множество цветов — чтобы показать, что он «профессионал», что ему платят не зря его зарплату.
Как с этим справиться:
Простота — признак профессионализма. Самый сложный навык — сделать интерфейс понятным и чистым. Заказчик и разработчики оценят не сложность, а удобство.
1.6. Решение и инструменты
1.6.1. Шаг первый. Тест на пять секунд
Это самый простой, но самый мощный инструмент, который я знаю. Он не требует специальных знаний, дорогих программ или подготовки респондентов. Он занимает ровно пять минут, но спасает от недель переделок и неловких моментов на презентациях.
Как это работает:
Ты показываешь свой макет человеку, который никогда его не видел, ровно на пять секунд, а потом закрываешь и задаёшь вопросы.
За пять секунд человек не успевает разобраться в деталях — он видит только общую картину. И именно это нам и нужно: мы проверяем, понятно ли с первого взгляда, что тут происходит и куда нажимать.
Пошаговая инструкция:
Найди человека, который не участвовал в проекте. Это может быть коллега из другого отдела, друг, любой человек, который согласится потратить пять минут. Важно: он не должен был видеть этот макет раньше и знать, о чём проект. Это даст честную реакцию.
Открой макет на весь экран.
Засеки пять секунд и покажи макет. Ничего не объясняй! Человек должен увидеть всё сам.
Закрой макет и задай три вопроса:
«Что ты запомнил?» — Если запомнил кнопку «Купить», цену или заголовок — ты молодец. Если запомнил красивую картинку или анимацию — ты создал шум.
«Как ты думаешь, что здесь самое главное?» — Если говорит про то, что ты считаешь главным — иерархия работает. Если говорит про второстепенное — пересматривай приоритеты.
«Куда бы ты нажал?» — Если на нужную кнопку — отлично. Если на декоративный элемент — переделывай.
Три сценария, когда тест на пять секунд спасает тебя.
Сценарий пепвый. Перед показом заказчику.
Ты уверен, что всё круто. Но тест на пять секунд может выявить то, чего ты сам не замечаешь, потому что привык к своему макету.
Если друг говорит: «Я не понял, куда нажимать» — ты слышишь это до того, как показал заказчику. Ты можешь спокойно переделать, не краснея на презентации.
Когда ты показываешь макет заказчику впервые, у тебя есть один шанс произвести впечатление профессионала. Если заказчик сразу увидит, что главная информация потерялась, он подумает: «Дизайнер не видит очевидных вещей». А если он увидит чистый, понятный макет — он скажет: «Вот это профессионал».
Сценарий 2. Перед передачей разработчикам.
Разработчики — твои главные партнёры. Они искренне радуются, когда открывают макет и видят не кучу разбросанных цветов, шрифтов и карточек, а чёткую систему.
Когда ты заранее продумал все состояния, проставил отступы и определил главные элементы — разработчики не задают вопросов. Они просто берут и делают.
А когда макет перегружен, стили разрознены, а главная кнопка спрятана — разработчики начинают задавать вопросы. Много вопросов. Каждый вопрос — твоя недоработка. Ты теряешь время на объяснения и переделки. Переживаешь и нервничаешь, всё ли в порядке теперь или будут еще вопросы. И в этом режиме проводишь каждый день до полной сдачи проекта! Команда начинает сомневаться в твоём профессионализме, как и ты сам.
Тест на пять секунд помогает избежать этого задолго до того, как макет попадёт в руки разработчиков.
Сценарий 3. Когда ты сам сомневаешься.
Ты сидишь над макетом несколько часов. Перекладываешь элементы, меняешь цвета. Ты перестаёшь видеть дизайн свежим взглядом.
Тест на пять секунд — твой спасательный круг. Найди любого человека, покажи на пять секунд. Ответы могут подтвердить, что ты всё сделал правильно, — и ты выдохнешь. Или покажут, что ты упустил очевидное, — и ты исправишь это до того, как кто-то ещё увидит макет.
Это отрезвляет. Когда ты сомневаешься, мозг рисует страшные картинки: «А вдруг я ничего не понимаю?» Тест на пять секунд даёт объективные данные. Ты понимаешь: либо всё хорошо, либо есть конкретная точка для доработки. Это снимает тревогу и возвращает уверенность.
Нюансы и подводные камни
Что делать:
Показывать макет новому человеку, который не видел его раньше.
Ничего не объяснять перед показом — человек должен увидеть всё сам.
Записывать ответы дословно, чтобы не потерять детали, лучший вариант — на диктофон или видео.
Тестировать на трёх–пяти добровольцах, чтобы увидеть паттерны.
Чего не делать:
Не показывать макет тому, кто уже видел его — они не будут объективны.
Не говорить: «Сейчас проверим, видна ли кнопка» — это наводит на ответ.
Не интерпретировать ответы «на ходу» — это искажает результаты.
Не останавливаться на одном мнении — оно может быть случайным.
Как интерпретировать ответы, «что запомнил/куда нажал бы»:
Чек-лист для самопроверки перед тестом:
Перед тем как показывать макет, проверь себя по этому списку. Если хоть один пункт вызывает сомнение — лучше внести изменения сразу и тестируй максимально приближенную к рабочей версию проекта.
Я знаю, какое действие пользователь должен совершить в первую очередь.
Это действие визуально выделено (цвет, размер, положение).
На макете не больше 2-3 акцентных цветов.
Все элементы имеют свою иерархию (заголовки, подзаголовки, текст).
Кнопки понятны без подписей (или подписаны понятно).
Я продумал хотя бы одно состояние ошибки или пустого экрана.
Я могу объяснить, зачем каждый элемент на экране.
1.6.2. Шаг второй. Визуальная иерархия
После теста на пять секунд ты узнаешь, есть ли проблема. А этот шаг поможет тебе исправить её, даже если ты не учился на художника.
Законы визуальной иерархии (для тех, кто не любит теорию):
Как проверить иерархию без специальных знаний?
Самый простой способ — отвернуться от экрана на две секунды, быстро повернуться и посмотреть на макет ровно одну секунду. А потом закрыть глаза и ответить на вопрос: «Что я запомнил?»
Если это кнопка «Купить» или другая важная информация — иерархия работает.
Если это второстепенная картинка, анимация или фон — что-то точно нужно менять.
1.6.3. Шаг третий. Сетка и модульная система
Когда ты работаешь над интерфейсом, хаос возникает там, где нет системы. Сетка — твой главный помощник в борьбе с хаосом.
Раздели экран на колонки (8, 12 или 16 — зависит от сложности) — это помогает выровнять элементы и не плодить случайные отступы.
Задай базовый шаг (4, 8 или 10 пикселей) — все отступы и размеры должны быть кратны базовому шагу.
Всё, что можно выровнять — выровняй — это снижает когнитивную нагрузку на пользователя.
Не используй больше 2 шрифтов — для читаемости и консистентности.
Все кнопки одного типа — одинаковые — пользователь привыкает и не переучивается.
1.6.4. Шаг четвёртый. Состояния элементов
Это то, что отличает профессиональный макет от любительского: продуманные состояния.
1.6.5. Шаг 5. Проверка на доступность (Accessibility)
Это не «дополнительная опция». Это обязательная часть работы. 15–20% пользователей имеют особенности зрения, и, если ты игнорируешь доступность — ты теряешь до 20% аудитории.
Минимальный набор для проверки:
