Один день UI/UX-дизайнера: между логикой продукта и правками руководителя
Если верить курсам, рекламным роликам и людям, которые видели Figma два раза, UI/UX-дизайнер проводит день примерно так: садится у окна с красивой чашкой, двигает несколько аккуратных прямоугольников, подбирает оттенок зелёного, а затем получает благодарность от бизнеса, пользователей и, вероятно, самой цивилизации. К вечеру продукт становится удобнее, конверсия растёт, разработчики аплодируют стоя. Всё это существует. Обычно в презентации курса, на слайде перед стоимостью обучения.
В реальной компании дизайнер начинает день не с творчества, а с расследования. У него есть сообщение руководителя из трёх слов, задача в трекере из пяти слов, макет прошлой версии, который давно не совпадает с работающим продуктом, и десяток людей с разными представлениями о том, что вообще нужно сделать. Один хочет увеличить продажи. Второй хочет, чтобы было «как у Apple». Третий уже пообещал клиенту релиз в пятницу. Четвёртый пришёл сообщить, что на разработку есть два дня и один уставший программист. Пользователь в этом собрании не участвует. Он вообще редко получает приглашение на встречу, посвящённую его счастью.
Поэтому обычный день UI/UX-дизайнера находится не между красивым и некрасивым. Он находится между логикой продукта, ограничениями разработки, цифрами бизнеса, привычками пользователей и вкусом человека, у которого в календаре написано «утвердить дизайн». Последний фактор иногда весит больше остальных вместе взятых. Не потому, что руководитель обязательно плохой или глупый. Просто должность обладает собственной гравитацией: чем выше человек находится в структуре, тем быстрее его личное «мне не нравится» превращается в задачу на два рабочих дня.
Разберём один такой день без декоративной дымовой завесы. Не образцовый день из методички и не катастрофу, после которой дизайнер обновляет резюме в туалете. Обычный рабочий день в продуктовой команде, где люди в целом компетентны, сроки в целом существуют, а требования в целом напоминают живой организм, который питается комментариями и размножается делением.
08:47. Сначала дизайнер узнаёт, что вчерашнее решение уже устарело
Рабочий день начинается с мессенджера. Пока Figma загружается, дизайнер видит сообщение, отправленное в 22:36: «Посмотрел ещё раз. Кажется, надо полностью пересобрать первый экран». В 22:41 к нему добавилось уточнение: «Только без сильных изменений, сроки оставляем». Это важный жанр корпоративной литературы. В двух предложениях автор уничтожает вчерашний день и одновременно запрещает тратить новый.
Рядом лежат комментарии от продакт-менеджера, разработчика и маркетолога. Продакт просит упростить сценарий регистрации. Разработчик пишет, что предложенная проверка данных потребует дополнительного метода на сервере. Маркетолог хочет добавить ещё три преимущества, промокод и яркую плашку, потому что пользователь, судя по всему, обязан войти в продукт уже информированным, мотивированным и слегка ослеплённым. В макете появляются разноцветные курсоры. Каждый курсор представляет человека, который пришёл сделать интерфейс понятнее. Интерфейс начинает выглядеть как место происшествия.
Первое профессиональное действие дизайнера состоит не в том, чтобы открыть нужный фрейм. Сначала он восстанавливает контекст. Что изменилось после вчерашнего обсуждения? Появились новые данные или кто-то просто посмотрел макет свежими глазами? Какое решение уже согласовали? Кто имеет право его отменить? Есть ли техническое ограничение или только тревога перед непривычным вариантом? Если начать исправлять всё сразу, к полудню получится безупречный ответ на вопрос, которого никто не задавал.
Здесь проходит первая граница между человеком, умеющим пользоваться графическим редактором, и дизайнером продукта. Первый реагирует на входящий комментарий. Второй выясняет, какое событие этот комментарий отражает. Фраза «сделайте первый экран убедительнее» может означать низкую конверсию, страх руководителя перед запуском, жалобу одного важного клиента, новый рекламный оффер или личную неприязнь к пустому пространству. Визуально эти проблемы могут выглядеть одинаково: кто-то просит добавить большую зелёную кнопку. По сути это пять разных задач, и только одна из них, возможно, лечится кнопкой.
Дизайнер открывает аналитику, задачу, запись вчерашней встречи и рабочий продукт. Уже прошло двадцать минут. Ни одного прямоугольника не нарисовано. Со стороны кажется, что работа ещё не началась. На самом деле именно сейчас решается, придётся ли команде через неделю переделывать экран целиком.
09:15. Дейлик, где каждый говорит две минуты, а дизайнер получает работы на полдня
Ежедневная встреча нужна, чтобы команда быстро синхронизировалась. В теории каждый сообщает, что сделал, что будет делать и что ему мешает. На практике разработчик рассказывает о проблеме с авторизацией, аналитик ищет нужный отчёт, продакт вспоминает вчерашний разговор с руководителем, а дизайнер понимает, что его макет уже обсуждали без него. Это не заговор. Заговоры обычно организованы лучше.
На дейли выясняется, что первый экран хотят изменить из-за новой гипотезы: пользователи не понимают ценность функции до регистрации. Доказательств пока нет. Есть несколько обращений в поддержку, наблюдение отдела продаж и уверенность руководителя. Отмахнуться от этого нельзя. Поддержка и продажи часто первыми видят реальную проблему, пока продуктовая команда любуется чистыми дашбордами. Принимать формулировку буквально тоже нельзя. Пользователь может понимать ценность функции и всё равно не регистрироваться, потому что форма требует номер телефона, пароль, подтверждение почты, имя кота и согласие получить новости до конца естественной жизни.
Дизайнер задаёт вопросы. На каком шаге люди уходят? С какого источника они приходят? Что обещает реклама? Есть ли записи сессий? Что говорят пользователи, которые всё-таки зарегистрировались? Можно ли показать функцию до создания аккаунта? В этот момент он рискует показаться человеком, который усложняет простую просьбу. Просьба ведь была понятной: сделать убедительнее. Только «убедительнее» нельзя поместить в макет. Это не компонент, не состояние и не свойство текста. Это слово, которым удобно закрывать отсутствие диагноза.
Хороший дизайнер на встрече не защищает каждый пиксель как семейную реликвию. Он защищает связь между проблемой и решением. Если команда доказала, что выбранный сценарий не работает, макет нужно выбросить без траурной церемонии. Если решение меняют потому, что участнику встречи стало скучно, дизайнер обязан это заметить. Иначе продукт постепенно превращается в археологический слой из чужих настроений.
К концу дейли появляется рабочая договорённость: сначала проверить воронку и обращения, затем предложить два варианта первого экрана. Один минимально меняет текущий сценарий, второй позволяет попробовать функцию до регистрации. Срок не исчез, разработчик не размножился, а значит второй вариант пока существует в статусе «разумная идея, которую бюджет может задушить голыми руками».
09:45. Задача наконец перестаёт быть набором пожеланий
Самая недооценённая часть UX-работы называется скучно: постановка задачи. В ней нет градиентов, анимации и красивых мокапов смартфона, зато есть шанс не потратить неделю на бессмысленную конструкцию. Дизайнер записывает, кто сталкивается с проблемой, в каком месте сценария она возникает, что мешает человеку продолжить и какое поведение продукта должно измениться после релиза.
Это звучит элементарно, пока не приходится делать в реальности. Бизнес говорит: «Нужно повысить регистрацию». Пользователь говорит: «Я просто хотел посмотреть, что внутри». Разработка говорит: «Гостевой режим затронет права доступа». Безопасность говорит: «Никакого гостевого режима». Маркетинг говорит: «Нам нужна форма, чтобы собирать лиды». Все говорят правду, просто каждый держит в руках отдельный кусок животного и уверенно описывает его целиком.
Задача дизайнера состоит не в том, чтобы выбрать самого громкого участника. Нужно собрать ограничения в одну модель и понять, где находится реальный выбор. Возможно, продукту выгоднее потерять часть регистраций, но получить качественные контакты. Возможно, обязательная регистрация действительно убивает знакомство с функцией. Возможно, проблема вообще начинается в рекламе, которая обещает бесплатный инструмент, а приводит на страницу с тарифами. Тогда новый интерфейс станет дорогой салфеткой, аккуратно положенной на протекающую трубу.
В нормальной постановке появляются критерии. Пользователь должен понять ценность сервиса до ввода персональных данных. Основной сценарий должен занимать не больше определённого числа шагов. Команда должна видеть, как меняется переход к регистрации. Решение не должно требовать полной перестройки системы прав. Эти ограничения не делают работу менее творческой. Они сообщают, в какой именно комнате разрешено двигать мебель, а где за стеной проходит газовая труба.
Параллельно дизайнер проверяет, что уже есть в дизайн-системе. Может ли нужный сценарий собраться из существующих компонентов? Есть ли подходящий шаблон? Как ведут себя поля, ошибки, подсказки и модальные окна? Новичок часто воспринимает библиотеку компонентов как скучное препятствие между собой и самовыражением. Опытный дизайнер видит в ней инфраструктуру. Каждый новый уникальный элемент выглядит безобидно только в макете. После релиза он получает мобильную версию, тёмную тему, локализацию, состояния загрузки, документацию и пожизненное содержание. Так маленькая авторская кнопка обзаводится расходами, как породистая лошадь.
К десяти часам задача становится точнее. Дизайнер ещё почти ничего не нарисовал, зато уже знает, чего рисовать не следует. Это одна из главных форм профессиональной эффективности. Её трудно положить в портфолио, потому что пустое место плохо смотрится в кейсе, хотя иногда именно оно сэкономило компании месяц разработки.
10:20. Исследование, которое редко выглядит как исследование
Слово «исследование» вызывает образ лаборатории, длинного отчёта и людей, которые произносят «выборка» с выражением государственной важности. В продуктовой работе исследование часто выглядит скромнее. Дизайнер открывает записи обращений в поддержку, смотрит несколько сессий, читает отзывы, сравнивает поведение сегментов и созванивается с аналитиком. Иногда для решения есть неделя и отдельный исследователь. Иногда есть сорок минут и сотрудник поддержки, который помнит пользователей лучше, чем система аналитики.
Главная опасность здесь состоит не в недостатке данных. Недостаток хотя бы заметен. Гораздо хуже данные, которые отвечают не на тот вопрос. Например, команда видит, что половина посетителей не заканчивает регистрацию. Это факт. Дальше начинаются версии: форма слишком длинная, ценность неясна, люди боятся оставлять телефон, кнопка недостаточно заметна. Последняя версия обычно получает удивительно много сторонников, потому что кнопку легко перекрасить и приятно обсудить. Страх пользователя, качество трафика и соответствие обещаний требуют менее фотогеничной работы.
Дизайнер смотрит записи сессий. Часть людей несколько раз нажимает на неактивный элемент. Другие возвращаются вверх, чтобы перечитать описание. Третьи уходят после поля с телефоном. Несколько пользователей проходят всё без затруднений. Из этого уже нельзя честно сделать один вывод. Зато можно разделить проблему: ценность действительно считывается не сразу, а обязательный телефон создаёт дополнительный барьер. Перекрасить кнопку всё ещё можно, если в команде скучный квартал и осталась лишняя краска.
Затем дизайнер читает обращения. Пользователи не говорят на языке продуктовой команды. Они не пишут: «Информационная архитектура нарушает мою ментальную модель». Они пишут: «Где посмотреть пример?», «Почему сразу нужен номер?» или «Я нажал и ничего». Работа UX-дизайнера начинается с перевода этих фраз в системные проблемы. При этом нельзя превращать каждую жалобу в отдельную функцию. Один человек может попросить выгружать отчёт в редком формате, печатать его на пергаменте и присылать голубем. Это обратная связь. Это ещё не стратегия.
Качественное исследование не гарантирует однозначного решения. Оно сокращает пространство для фантазий и показывает, какие допущения команда делает сознательно. По итогам дизайнер формулирует гипотезу: если до регистрации показать короткую интерактивную демонстрацию и объяснить, зачем нужен телефон, больше целевых пользователей дойдёт до создания аккаунта. Теперь макет можно оценивать не по уровню коллективного восторга, а по тому, помогает ли он проверить эту гипотезу.
11:10. Пользовательский сценарий: та часть работы, которую не выложишь в красивую карусель
До интерфейса нужно построить путь. Дизайнер раскладывает сценарий: вход со страницы, выбор примера, короткое действие внутри демонстрации, показ результата, предложение сохранить его после регистрации. Затем добавляет ответвления. Что произойдёт, если данные не загрузились? Если пользователь вернулся назад? Если пример недоступен? Если он уже зарегистрирован? Если открыл ссылку на маленьком экране? Если соединение решило проверить его характер?
Вот здесь интерфейс перестаёт быть картинкой. Картинка существует в одном идеальном состоянии: данные загрузились, пользователь всё понял, сервер бодр, текст помещается, имя человека состоит из семи букв. Продукт существует во всех остальных состояниях. Он должен пережить пустые результаты, ошибки, длинные фамилии, повторные нажатия, истёкшую сессию, медленную сеть и человека, который игнорирует инструкцию, потому что люди именно для этого и получают инструкции.
Дизайнер рисует схему не ради ритуала. Она показывает, сколько решений скрывается за одним экраном. Кнопка «Продолжить» кажется простой, пока не нужно определить, когда она активна, куда ведёт, что сохраняет, как реагирует на двойное нажатие и что сообщает при ошибке. Каждый неотвеченный вопрос позже получает ответ от разработчика. Это не обязательно плохой ответ. Просто он будет принят в момент, когда человек занят кодом и меньше всего мечтает обсуждать психологию кнопки.
В сценарии обнаруживается конфликт. Интерактивная демонстрация даёт пользователю ценность до регистрации, но для точного результата серверу нужны данные, которые доступны только в аккаунте. Можно сделать ограниченный пример на подготовленном наборе. Можно показать видео. Можно сократить форму регистрации. Можно оставить текущий порядок и лучше объяснить ценность. Вариантов несколько, и каждый платит своей валютой: временем, точностью, конверсией, доверием или сложностью поддержки.
Дизайнер обсуждает развилку с продактом и техническим специалистом. Они выбирают ограниченную демонстрацию на готовом примере. Это не самое эффектное решение и не самое полное. Зато его можно выпустить, измерить и при необходимости развить. Продуктовый дизайн вообще часто состоит из решений, которые выглядят скромно, но выживают после знакомства с реальностью.
К одиннадцати сорока появляется черновой поток и несколько грубых экранов. Они серые, местами некрасивые и полезные. Серый прямоугольник позволяет спорить о порядке действий. Идеально отрисованная карточка заставляет людей обсуждать радиус углов. Мозг любит цепляться за то, что легче оценить. Поэтому ранний макет должен быть достаточно понятным для проверки логики и достаточно непривлекательным, чтобы никто не начал утверждать оттенок тени.
12:05. UI начинается не там, где выбирают цвет
Когда сценарий собран, дизайнер переходит к интерфейсу. Здесь человеку со стороны наконец становится спокойнее: на экране появляются знакомые элементы, сетка, типографика, кнопки, карточки. Кажется, что началась настоящая работа. Предыдущие три часа, видимо, были разминкой, во время которой дизайнер профессионально смотрел в монитор.
UI решает гораздо больше задач, чем украшение. Визуальная иерархия показывает, что важно, что связано и что можно сделать дальше. Размер, контраст, расстояние и положение элементов управляют вниманием. Текст объясняет последствия действия. Состояния сообщают, что система услышала пользователя. Если интерфейс красивый, но человек не понимает, где он находится и что произойдёт после нажатия, перед нами качественно оформленная растерянность.
Дизайнер собирает экран из компонентов системы. Проверяет сетку, отступы, длину строк, контраст, размеры зон нажатия. Смотрит, что произойдёт на мобильном устройстве. Не все пользователи сидят перед дизайнерским монитором, хотя некоторые макеты ведут себя так, будто это условие прописано в пользовательском соглашении. На экране телефона исчезает роскошное свободное пространство, длинный заголовок занимает четыре строки, а две кнопки начинают бороться за территорию.
Затем приходит текст. В плохом процессе его добавляют в конце, как петрушку на готовое блюдо. В нормальном процессе текст является частью сценария. Формулировка «Начать» не объясняет, начнётся ли регистрация, демонстрация, платный период или новая глава в отношениях с отделом продаж. Подпись под полем телефона должна честно сообщить, зачем он нужен. Ошибка должна помочь исправить действие, а не просто объявить пользователя виновным красным цветом.
Дизайнер пишет несколько вариантов, сокращает, проверяет на реальных данных и зовёт редактора, если он есть. Если редактора нет, дизайнер временно становится им. Затем он временно становится аналитиком, специалистом по доступности и человеком, который напоминает, что интерфейс переводят на другие языки. Профессия называется UI/UX-дизайнер, но внутри неё регулярно открываются бесплатные вакансии на полставки.
К половине первого основной вариант готов. Он не является произведением искусства и не должен им быть. Он показывает ценность функции, позволяет пройти короткую демонстрацию, объясняет регистрацию и использует знакомые компоненты. Теперь решение нужно вынести к людям. Именно там у него начинается взрослая жизнь.
13:00. Обед, который формально существует
В календаре есть час на обед. В реальности за пять минут до него приходит сообщение: «Можно быстро посмотреть макет?» Слово «быстро» в продуктовой команде не описывает продолжительность. Оно снижает чувство вины у человека, который ставит встречу на время, когда вы уже открыли доставку еды.
Дизайнер отправляет ссылку и пытается уйти от экрана. Через минуту появляется первый комментарий: «А почему здесь так много пустого места?» Через две минуты второй: «Мне кажется, главный блок теряется». Через три минуты продакт предлагает созвониться после обеда. Организм получает пищу, мозг продолжает раскладывать аргументы. Так выглядит корпоративный велнес: человек жуёт суп и мысленно защищает вертикальный отступ.
Здесь полезно понимать одну вещь. Дизайнер не обязан считать каждое замечание нападением. Люди действительно замечают проблемы, которые автор макета перестал видеть. После нескольких часов работы глаз адаптируется, логика кажется очевидной, а знакомый текст читается быстрее, чем его прочтёт новый пользователь. Свежий взгляд ценен. Даже фраза «что-то не то» может указывать на реальный дефект, просто говорящий пока не умеет его назвать.
Однако комментарий не равен решению. Если человеку кажется, что блок теряется, это повод выяснить, какой элемент он считал главным и куда посмотрел сначала. Просьба увеличить заголовок является одной из возможных реакций, а не готовым техническим заданием. Дизайнеру платят в том числе за то, чтобы не путать симптом с назначением.
После обеда он делает быструю самопроверку. Убирает один второстепенный текст, усиливает связь между демонстрацией и результатом, корректирует отступ. То есть меняет макет до встречи, потому что часть замечаний справедлива. Профессиональная позиция не состоит в торжественном отказе двигать пиксели. Она состоит в способности отличить обоснованное улучшение от движения мебели во время пожара.
14:05. Дизайн-ревью: восемь человек смотрят на один экран и видят восемь продуктов
На встрече присутствуют дизайнер, продакт, руководитель направления, разработчик, маркетолог, аналитик и два человека, чья роль сначала неясна. Один из них позже задаст больше всех вопросов. Так работает природа: свободная ниша быстро заполняется.
Дизайнер начинает не с демонстрации макета, а с контекста. Какая проблема обнаружена, что показывают данные, какую гипотезу проверяет решение, какие ограничения учтены. Это не бюрократическая прелюдия. Без неё участники оценивают экран как афишу: нравится или не нравится. С контекстом появляется шанс обсуждать, решает ли интерфейс задачу.
Первые минуты проходят продуктивно. Аналитик уточняет событие, по которому будут измерять прохождение демонстрации. Разработчик замечает, что одно состояние нельзя реализовать в текущей архитектуре. Маркетолог предлагает точнее сформулировать ценность. Дизайнер фиксирует изменения. Потом руководитель спрашивает: «Почему кнопка не зелёная?»
Вопрос нормальный. Цвет может влиять на заметность, соответствие бренду и распознавание действия. Проблема начинается, когда за вопросом нет критерия, кроме того, что зелёная кнопка кажется руководителю более продающей. Дизайнер объясняет, что основной цвет уже используется для другого типа действия, а новая кнопка находится в зоне высокого внимания и имеет достаточный контраст. Руководитель смотрит ещё несколько секунд и говорит: «Всё равно хочется зелёную».
В комнате возникает знакомая пауза. Формально идёт обсуждение дизайна. Фактически команда определяет, имеет ли система правил больший вес, чем интуиция человека, отвечающего за результат. Дизайнер может немедленно уступить, может начать лекцию о когнитивной нагрузке, а может задать полезный вопрос: какую проблему должна решить смена цвета? Если кнопку не замечают, это можно проверить. Если она выглядит недостаточно важной, можно усилить иерархию несколькими способами. Если зелёный нужен из-за новой коммуникационной кампании, это уже системное изменение.
Руководитель отвечает, что экран выглядит слишком спокойным и не подталкивает к действию. Это уже лучше. Теперь обсуждается не любимый цвет, а интенсивность акцента. Дизайнер показывает вариант с более выраженным контрастом, сохраняя логику системы. Команда соглашается проверить оба решения на прототипе. Зелёная кнопка временно возвращается в лес, где ей и положено жить до появления доказательств.
Затем начинается обсуждение демонстрации. Один участник предлагает добавить больше подсказок. Второй считает, что подсказки перегружают экран. Третий просит показать все возможности сразу, чтобы пользователь точно понял ценность. Это популярный способ объяснения: если человек не понял одну вещь, нужно одновременно показать ему девять. По той же логике заблудившемуся туристу следует выдать все карты города и слегка встряхнуть.
Дизайнер возвращает разговор к последовательности. На первом шаге человек должен увидеть один понятный результат. Остальные возможности можно раскрыть после действия. Иначе демонстрация превратится в экскурсию по складу функций. Продакт поддерживает решение, маркетолог просит сохранить одну дополнительную фразу, разработчик напоминает о сроке. Через сорок минут макет получает список изменений, два открытых вопроса и статус «в целом согласовано». В корпоративном языке это означает, что конструкцию пока не снесли, но строительная техника остаётся рядом.
15:00. Правки руководителя: где заканчивается обратная связь и начинается управление тревогой
После встречи приходит личное сообщение от руководителя: «Давай всё-таки попробуем вариант поярче. И можно сделать современнее?» Слово «современнее» занимает почётное место рядом с «дороже», «легче» и «вау». Все понимают направление эмоции, никто не знает единицу измерения.
Правки руководителя часто раздражают дизайнеров не потому, что руководитель вмешивается в священную область цвета. Раздражает разрушение причинно-следственной связи. Дизайнер несколько часов собирал данные, сценарий и ограничения, а затем решение может измениться из-за впечатления, которое возникло за семь секунд. Это похоже на работу архитектора, которому после расчётов сообщают, что лестница должна выглядеть бодрее. Возможно, просьба разумная. Только сначала хочется убедиться, что слово «бодрее» выдерживает вес людей.
При этом у руководителя есть то, чего может не быть у дизайнера: ответственность за коммерческий результат, знание переговоров с партнёрами, понимание стратегии, опыт прошлых запусков и информация, которую ещё не успели занести в задачу. Его интуиция не обязательно является капризом. Иногда это сжатый опыт, который человек пока плохо развернул в объяснение. Работа дизайнера состоит не в автоматическом сопротивлении власти, а в извлечении критерия из расплывчатой формулировки.
Он задаёт вопросы. Что именно выглядит недостаточно современно: типографика, плотность, иллюстрация, характер компонентов? С какими продуктами руководитель сравнивает решение? Какое впечатление должен получить пользователь? Что сейчас мешает этому впечатлению? После нескольких сообщений выясняется, что руководитель недавно показывал продукт потенциальному партнёру, а тот назвал интерфейс «слишком утилитарным». Теперь вся компания лечит прилагательное, сказанное одним человеком на встрече.
Игнорировать сигнал нельзя. В B2B-продукте восприятие партнёров может влиять на продажи. Но и перестраивать пользовательский сценарий ради неопределённой «современности» опасно. Дизайнер предлагает разделить задачу: оставить логику демонстрации, а визуальную подачу усилить через типографику, графику результата и характер акцентной зоны. Затем показать вариант руководителю и маркетингу, не затрагивая компоненты, от которых зависит весь продукт.
Так выглядит здоровая переработка правки. Не «я художник, я так вижу» и не «начальник сказал, значит красим». Сначала дизайнер определяет источник запроса, затем переводит его в наблюдаемое качество, после этого меняет минимально необходимый уровень системы. Если проблема в восприятии бренда, не нужно ломать сценарий регистрации. Если проблема в конверсии, новый градиент сам по себе вряд ли станет коммерческим директором.
Бывает хуже. Руководитель может настаивать на конкретном решении и не обсуждать критерии. Тогда у дизайнера остаются три обязанности. Первая состоит в том, чтобы ясно обозначить риск. Вторая состоит в том, чтобы зафиксировать принятое решение. Третья состоит в том, чтобы выполнить его профессионально, если оно не нарушает закон, этику и базовую работоспособность продукта. Работа по найму не предоставляет дизайнеру право вето на каждую спорную кнопку.
Это неприятная, но взрослая часть профессии. Дизайнер влияет на решение, однако редко владеет им единолично. Чем крупнее продукт, тем больше у него владельцев, ограничений и людей, которые могут сказать «нет». Если специалисту нужна абсолютная художественная автономия, продуктовая команда станет для него сложным открытием. Здесь даже ошибка с текстом может потребовать согласования у юриста, а цвет иконки иногда обсуждают дольше, чем условия её появления.
С другой стороны, постоянное молчаливое выполнение любых правок быстро превращает дизайнера в графический терминал. Руководитель вводит команду, система выдаёт макет. Такой специалист удобен до первого серьёзного провала, после которого внезапно выясняется, что именно он «должен был предупредить». Поэтому возражать нужно не громко, а точно. Не доказывать, что руководитель не разбирается в дизайне, а показывать последствия: этот блок сдвигает ключевое действие ниже первого экрана; этот текст обещает функцию, которой нет; эти два одинаковых акцента конкурируют; этот паттерн противоречит поведению остальных разделов.
Хорошая аргументация не гарантирует победу. Она делает решение прозрачным. В продукте это уже много. Команда хотя бы понимает, какую цену платит и почему. И если через месяц эксперимент провалится, обсуждение начнётся с данных, а не с попытки найти человека, который недостаточно вдохновенно выбрал синий.
15:45. Перерисовка, где меняется двадцать процентов экрана и сто процентов деталей
Дизайнер возвращается в Figma и создаёт новый вариант. Сохраняет сценарий, усиливает акцентную зону, меняет масштаб заголовка, перерабатывает графику результата. Параллельно проверяет, не развалилась ли адаптивная версия. Любое «чуть крупнее» живёт в цепочке зависимостей. Заголовок переносится на дополнительную строку, карточка становится выше, следующий блок уезжает вниз, на маленьком экране кнопка исчезает из видимой области. Один комментарий тянет за собой макет, как нитка старый свитер.
Затем нужно привести в порядок компоненты. Если изменить только конкретный экран, разработчик получит уникальное исключение. Если изменить основной компонент, обновятся другие места продукта. Дизайнер проверяет варианты, свойства и вложенные элементы. Это работа, которой не видно на финальном изображении, зато её отсутствие отлично видно через два месяца, когда в файле лежат двадцать почти одинаковых кнопок с названиями «Button final», «Button final 2» и «Button new real».
Версии вообще являются отдельной формой корпоративной археологии. Нужно сохранить исходный вариант, новый вариант, согласованный вариант и вариант, который руководитель попросил вернуть после просмотра нового. Если не поддерживать порядок, макет начинает хранить историю решений лучше, чем команда. По слоям можно определить периоды: ранний минимализм, эпоху большой зелёной кнопки, краткое господство иллюстраций и великий возврат к версии со вторника.
Пока дизайнер работает, приходит комментарий от разработчика: выбранная анимация результата займёт больше времени, чем планировалось. Её можно упростить или перенести. Дизайнер оценивает, несёт ли анимация смысл. Если она показывает переход между состояниями и помогает понять результат, нужно сохранить хотя бы базовый принцип. Если она существует для приятного покачивания карточки, карточка переживёт неподвижность. Пользователь тоже. Возможно, даже быстрее завершит задачу.
К половине пятого готов вариант, который учитывает запрос руководителя и не разрушает логику. Он отправляется на короткое согласование вместе с пояснением: что изменено, что сохранено и какие риски остаются. Это важно, потому что ссылка без контекста снова запускает конкурс личных впечатлений. Дизайн нельзя полностью защитить пояснениями, но можно хотя бы не бросать его одного в комнату с восемью курсорами.
16:35. Состояния интерфейса, о которых вспоминают после релиза
Основной экран согласован. Начинается работа, которую любят переносить на потом: состояния и исключения. Что видит пользователь до загрузки? Во время загрузки? При ошибке? При пустом результате? После завершения? При повторном входе? Что происходит, если демонстрация недоступна на конкретном тарифе? Как выглядит длинное системное сообщение? Может ли человек повторить действие?
В презентации продукта обычно показывают счастливый путь. Пользователь приходит, нажимает, получает результат и улыбается в сторону конверсии. В реальном продукте он забывает пароль, закрывает вкладку, запрещает cookies, вставляет пробел в номер телефона и нажимает кнопку три раза. Интерфейс обязан иметь план на эту жизнь, даже если команда предпочитает её не представлять.
Дизайнер добавляет состояния загрузки, ошибки и пустого результата. Проверяет тексты. Сообщение «Что-то пошло не так» честно описывает эмоциональное состояние системы, но бесполезно для человека. Нужно сказать, что именно не удалось, сохранились ли данные и что можно сделать дальше. Если исправить проблему невозможно, не следует предлагать «попробовать снова» бесконечно. Это уже не помощь, а маленький цифровой ритуал отчаяния.
Отдельно проверяется доступность. Контраст, фокус с клавиатуры, подписи для элементов, порядок чтения, понятность ошибок без опоры только на цвет. Доступность часто воспринимают как дополнительный слой для редкой группы пользователей. На деле временные и ситуационные ограничения возникают у всех: яркое солнце, травма руки, медленная сеть, усталость, маленький экран, плохой звук. Дизайн, рассчитанный исключительно на здорового, внимательного человека в идеальной обстановке, рассчитан на персонажа из технического задания. В природе его наблюдают редко.
Здесь снова возникает конфликт со сроком. Полный набор состояний требует времени, а разработка хочет начать сегодня. Дизайнер передаёт основной сценарий и критические ошибки, затем договаривается о времени для остальных состояний. Это допустимый компромисс, если он явный. Если просто отправить один красивый экран и надеяться, что детали материализуются сами, они действительно материализуются. Только выберет их тот, кто первым устанет ждать.
17:10. Передача в разработку: момент, когда картинка должна стать поведением
Фраза «макет готов» ничего не значит, пока разработчик не может по нему собрать продукт. Для передачи нужны не только размеры и отступы. Нужны правила: как меняется блок, какие данные обязательны, что происходит после действия, какие состояния существуют, где используется готовый компонент, а где появляется новый. Хороший handoff снижает количество догадок. Плохой превращает разработчика в соавтора интерфейса без выделенного на это времени.
Дизайнер приводит файл в порядок, называет фреймы, связывает прототип, добавляет пояснения. Проверяет, что макеты для разных размеров не противоречат друг другу. Указывает поведение элементов при изменении ширины. Прикладывает тексты и требования к графике. Это не бюрократия ради эстетики слоя. Разработчик не обязан угадывать, какая из четырёх версий была согласована и почему одна карточка случайно стоит на семь пикселей левее.
Затем проходит короткий созвон. Разработчик задаёт вопросы, которые мгновенно находят слабые места. Откуда приходит этот параметр? Можно ли повторно открыть результат? Что делать, если пользователь уже начал регистрацию в другой вкладке? Почему на мобильном устройстве порядок блоков меняется? Дизайнер отвечает на часть, по остальным возвращается к продакту. Макет снова оказывается не финалом, а формой разговора.
В зрелой команде разработчик подключается раньше, поэтому больших сюрпризов меньше. В незрелой команде дизайн передают как заказ в ресторан: вот красивая фотография, приготовьте к пятнице. Потом выясняется, что ингредиентов нет, кухня устроена иначе, а фотография вообще создана для рекламной съёмки и не предполагала употребления внутрь.
К шести часам задача уходит в разработку. В трекере появляется статус, который создаёт приятную иллюзию завершения. Дизайнер знает, что впереди ещё проверка реализации. Интерфейс в Figma ведёт себя безупречно, потому что пиксели дисциплинированы и не работают с базой данных. Настоящее испытание начнётся, когда решение встретится с кодом.
18:00. Дизайн-ревью реализации: «почти как в макете» и другие единицы измерения
Разработчик присылает ссылку на тестовую сборку другой задачи, переданной несколько дней назад. Нужно проверить реализацию. На первый взгляд всё похоже. На второй становится видно, что заголовок имеет другой вес, контейнер уже, иконка съехала, текст ошибки отличается, а кнопка прыгает после загрузки. Ни один дефект отдельно не выглядит смертельным. Вместе они создают интерфейс, который словно помнит макет по рассказам родственников.
Здесь дизайнеру важно не составлять список из сорока замечаний одинаковой срочности. Критическая ошибка сценария и отличие отступа на два пикселя не должны стоять рядом как равноправные угрозы человечеству. Сначала проверяется логика, доступность действия, корректность состояний и соответствие контента. Затем визуальная иерархия, адаптивность и консистентность. Мелкие расхождения исправляются, если влияют на качество или накапливают системный долг, а не потому, что дизайнеру нужен повод закончить день в состоянии праведного истощения.
Одна проблема оказывается серьёзной: после ошибки введённые данные сбрасываются. Пользователю придётся заполнить форму снова. Разработчик объясняет техническую причину и предлагает исправление в следующем спринте. Дизайнер показывает последствия: ошибка может произойти после нескольких шагов, потеря данных повышает вероятность ухода и разрушает доверие. Продакт меняет приоритет. Это и есть дизайн-работа, хотя в ней снова нет выбора шрифта.
Другую проблему решают компромиссом. Анимация отличается от прототипа, но сохраняет смысл и работает быстрее. Переделывать её ради точного сходства не нужно. Способность принять хорошую реализацию, которая выглядит иначе, важнее способности измерить каждую длительность перехода. Дизайн-система нужна для последовательности, а не для создания маленького тоталитарного государства внутри интерфейса.
Замечания фиксируются в задаче со скриншотами и приоритетами. Разработчик уточняет два пункта. Дизайнер отвечает без формулировки «ну это же очевидно». Если что-то очевидно только автору макета, оно не очевидно. Телепатия по-прежнему не входит в стандартный набор инструментов команды, хотя многие процессы на неё оптимистично рассчитаны.
18:40. Рабочий день заканчивается, а оценка чужих решений остаётся в голове
К концу дня дизайнер сделал не один экран. Он разобрал противоречивый запрос, собрал данные, построил сценарий, договорился о техническом компромиссе, оформил решение, выдержал дизайн-ревью, перевёл субъективную правку в рабочий критерий, подготовил состояния, передал макет и проверил другую реализацию. Если смотреть только на финальный интерфейс, объём работы кажется подозрительно маленьким. На экране всё ещё несколько блоков и одна кнопка. Просто теперь известно, почему они находятся именно там и что случится после нажатия.
Психологически эта профессия устроена странно. Дизайнер должен вкладываться в решение достаточно глубоко, чтобы увидеть детали, и одновременно быть готовым выбросить его после новых данных. Нужно иметь позицию, но не превращать её в религию. Нужно принимать критику, не соглашаясь автоматически. Нужно отличать замечание о макете от оценки себя, хотя макет несколько часов находился прямо внутри головы и вышел оттуда без защитной упаковки.
Постоянная обратная связь создаёт усталость особого типа. Результат работы публично разбирают на встречах, в комментариях и на тестах. Пользователь нажимает не туда, аналитика показывает падение, разработчик находит противоречие, руководитель просит переделать. Здесь нельзя годами поддерживать образ человека, который всегда сразу знает правильный ответ. Продукт быстро проводит вскрытие этой легенды.
Поэтому устойчивый дизайнер не тот, кому безразлично качество. Безразличие даёт не устойчивость, а плохие макеты. Устойчивый дизайнер умеет разделять три вещи: собственную ценность, качество текущего решения и ограничения процесса. Решение может быть слабым, потому что не хватило данных. Оно может быть разумным, но проиграть бизнес-приоритету. Оно может быть хорошим и всё равно не сработать. Пользовательское поведение не подписывает договор о соответствии ожиданиям команды.
Перед закрытием ноутбука дизайнер записывает открытые вопросы на завтра. Нужно проверить события аналитики, закончить второстепенные состояния и посмотреть обновлённую сборку. В мессенджере появляется новое сообщение от руководителя: «Посмотрел вариант. Стало лучше. А можем всё-таки попробовать зелёную кнопку для сравнения?» Конечно можем. Наука требует контрольной группы, а корпоративная жизнь требует смирения, желательно с сохранённой версией файла.
Чем отличается день junior, middle и senior-дизайнера
Junior чаще получает ограниченную часть сценария и работает внутри уже принятых решений. Его главная задача состоит в том, чтобы научиться видеть систему: использовать компоненты, учитывать состояния, задавать вопросы, объяснять выбор и не прятать пробелы под красивой графикой. Проблема многих новичков в том, что они пытаются доказать ценность оригинальностью экрана. Команде в этот момент нужнее предсказуемость, аккуратность и способность довести решение до разработки.
Middle ведёт задачу целиком. Он умеет отделить запрос от проблемы, собрать контекст, предложить варианты, провести ревью, договориться с разработкой и проверить результат. Его оценивают не по тому, насколько эффектно выглядит отдельный фрейм, а по качеству цепочки решений. Middle уже должен понимать, когда стоит спорить, когда проверять гипотезу и когда принять ограничение, которое ему не нравится.
Senior работает не только с интерфейсом, но и с условиями, в которых интерфейс появляется. Он влияет на постановку задачи, качество данных, порядок принятия решений, дизайн-систему и взаимодействие функций. Он раньше замечает, что команда лечит не ту проблему, и умеет сказать об этом так, чтобы встреча не превратилась в публичное выяснение интеллектуального превосходства. Старший дизайнер не обязан выдавать самый красивый вариант быстрее всех. Его ценность часто состоит в том, что команда не начинает дорогую бессмысленную работу.
Чем выше уровень, тем меньше времени может оставаться на спокойное рисование. Добавляются встречи, синхронизации, разбор чужих решений, планирование и ответственность за целостность продукта. Человек получает больше влияния и одновременно больше способов провести день без единого нового экрана. Для тех, кто шёл в профессию ради восьми часов наедине с визуалом, карьерный рост иногда выглядит как очень качественно спроектированная ловушка.
Кому эта работа подойдёт, а кому быстро испортит характер
UI/UX-дизайн подходит людям, которым интересно разбирать неясные задачи, наблюдать поведение, собирать систему из ограничений и постоянно уточнять собственные решения. Здесь полезны любопытство, терпимость к неопределённости, внимание к деталям и способность разговаривать с очень разными специалистами. Любовь к визуалу важна, но сама по себе не вытянет день, половина которого проходит в вопросах, аргументах и проверке исключений.
Работа будет тяжёлой для человека, которому нужна постоянная внешняя похвала. Большинство хороших решений пользователи не замечают. Они просто проходят сценарий без ошибок. Руководитель редко пишет: «Сегодня я особенно оценил последовательность состояний формы». Зато сломанная кнопка собирает аудиторию быстрее бесплатного концерта. Обратная связь распределяется неравномерно: нормальная работа молчит, дефект включает сирену.
Сложно будет и тому, кто воспринимает каждую правку как вторжение в личную территорию. Продуктовый макет принадлежит команде и бизнесу, а после релиза ещё и встречается с пользователями, которые не обязаны беречь авторский замысел. При этом полное отсутствие позиции тоже разрушительно. Если человек готов бесконечно передвигать элементы без вопроса «зачем», он быстро устанет и перестанет расти.
Наконец, профессия не подходит тем, кто хочет однажды выучить правильные правила. Правила меняются вместе с платформами, продуктами и контекстом. Даже устойчивые принципы требуют интерпретации. Нельзя механически поставить главную кнопку справа, сократить сценарий до трёх шагов и объявить победу. Иногда дополнительный шаг повышает доверие. Иногда привычный паттерн не работает для конкретной аудитории. Иногда лучший экран тот, который команда решила не создавать.
Так что же дизайнер делает весь день
Он превращает туманную просьбу в задачу, задачу в гипотезу, гипотезу в сценарий, сценарий в интерфейс, интерфейс в договорённость, а договорённость в продукт, который должен пережить разработку и реальных людей. Между этими превращениями он объясняет, спорит, сокращает, проверяет, документирует и иногда красит кнопку в зелёный, потому что эксперимент тоже требует материала.
Работа UI/UX-дизайнера находится не между логикой и правками, словно одно является благородным ремеслом, а второе бессмысленным наказанием. Правки тоже несут информацию. Они показывают страхи бизнеса, пробелы в аргументации, скрытые ограничения и разницу между тем, что команда собиралась сказать, и тем, что увидел другой человек. Проблема начинается только тогда, когда информация не разбирается, а сразу превращается в пиксели.
Профессионализм здесь измеряется не количеством отбитых комментариев и не послушанием. Он измеряется качеством решений после столкновения с реальностью. Сильный дизайнер способен защитить принцип, изменить слабый вариант, признать недостаток данных, зафиксировать риск и довести компромисс до рабочего состояния. Иногда после этого получается заметное улучшение продукта. Иногда получается зелёная кнопка.
На следующий день аналитика ещё ничего не покажет, руководитель принесёт новый пример конкурента, разработчик найдёт дополнительное ограничение, а пользователь сделает то, чего не было ни в одном сценарии. Дизайнер снова откроет файл и начнёт выяснять, что именно происходит. Потому что интерфейс можно закончить к сроку. Понимание продукта к сроку не заканчивается.
