Вопрос 1. Опишите ваш опыт в Figma/Pixso (плагины, организация файлов, авто-лейауты)? Приведите пример сложного B2B-продукта (CRM, ЛК, корп. портал), который вы проектировали.

Мой основной инструмент — Figma. Про Pixso слышал, что это хороший китайский аналог. Использовали с командой его на прошлом месте работы лишь раз, когда решили на всякий случай продублировать все проекты, т.к. там идентичная логика авто-лейаутов, компонентов и плагинов. Но подробнее остановлюсь на Figma, с которой работаю с 2019 года. Если коротко, то поинты такие: pixel perfect, auto layout, components, styles, plugins (разработка макетов интерфейса сайтов и веб-страниц, дизайна презентаций для бизнеса или продукта, дизайна рекламных материалов для социальных сетей, вариантов прототипа или концепции дизайна, адаптация дизайна под разные платформы и устройства, разработка уникальных иконок и иллюстраций, составление роадмапов проектов). Путь естественный: начинал с простых макетов под собственную вёрстку в Tilda, затем, когда стал старшим дизайнером в компании, перешёл к полноценной проектной работе с передачей разработчикам.

Сейчас мой уровень — уверенный пользователь. Ключевой проект, с которого начался быстрый рост, — единоличный редизайн сайта «Нескучные финансы». Делал всё сам: от дизайн-системы и основных страниц до десятков шаблонных продуктовых страниц. Сейчас сайт в топе поисковой выдачи по релевантным запросам. Макеты передавал программистам на 1С-Битрикс через куратора, поэтому не мог рассчитывать на прямые вопросы от разработчиков. Это жёстко дисциплинировало, ведь я был как в том меме, где пилот истребителя прямо во время полёта читает руководство по использованию истребителя… В общем макет делал максимально самодостаточным, насколько мог— с понятным неймингом слоёв, компонентами, авто-лейаутами и логикой, которую можно считать без слов. Но изучать Figma, как говорится, никогда не заканчиваешь — с каждым проектом открываешь для себя новые артефакты. Ниже рассказываю про другие крупные проекты.

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

Плагины и инструменты помогают автоматизировать рутину и проверять качество. Среди устоявшихся:

• Figjam — для схематичных пользовательских путей;
• Figma Community — изучение крупных дизайн-систем;
• html.to.design — импорт HTML-кода любой веб-страницы в Figma в виде редактируемого макета;
• Isometric & Perspective Toolkit — работа с изометрией и перспективой
• Trace Image — преобразование растрового изображения в векторную графику.
• И много других…

1.2. Помимо основной работы над страницами в маркетинговом департаменте и работой по редизайну всего внутреннего продукта, я был привлечён в качестве усиления к проекту IT-департамента нашей компании — высоконагруженному корпоративному порталу для финансовых директоров. Команда дизайнеров продукта к тому моменту уже несколько лет развивала свою дизайн-систему, библиотеки компонентов и внутренние стандарты. Моей задачей было помочь в двух проблемных зонах:

1. Экран автоматической подборки рекомендованных специалистов. Пользователь получал список релевантных специалистов. Сложность заключалась в том, что каждая карточка специалиста должна была вмещать:

• краткую информацию (имя, роль, ключевые компетенции);
• развёрнутое описание опыта, реализованных проектов и отраслевой экспертизы;
• несколько уровней вложенности (сертификаты, публикации, отзывы);

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

2. Карточка партнёра. Аналогичная проблема — при большом объёме данных о партнёре (статусы сотрудничества, история взаимодействий, юридические детали) интерфейс становился «плоским», пользователи не считывали иерархию информации и пропускали критические блоки.

Что я сделал:

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

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

• Смотреть кейс (Figma: 4 вкладки внутри файла)

Вопрос 2. Какие методы сбора данных о пользователях применяли на реальных проектах (интервью, тесты, аналитика)? Опишите случай, когда исследование изменило итоговый интерфейс.

2.1. Сначала обозначу, что глубинные пользовательские интервью в классическом понимании не проводил (у нас не было прямого доступа к конечным пользователям), но выстроил систему сбора данных из доступных мне источников, которая напрямую влияла на дизайн-решения. Параллельно на небольших фриланс-проектах использовал подход, где источником информации о ЦА становился сам заказчик. Применял группы методов:

Количественная аналитика поведения:

1. Tilda CRM — отслеживал конверсию по каждому лендингу: доходимость до целевого действия, процент отказов, глубину скролла. Это давало объективную картину «где теряем пользователя».
2. Яндекс.Метрика (вебвизор) — регулярно запрашивал у маркетологов записи сессий, чтобы увидеть реальное поведение: куда кликают, на каких блоках зависают, где резко уходят. Это заменяло мне прямое наблюдение за пользователем.
3. A/B-тесты — просил запускать сплит-тестирования через сервисы маркетологов. Сравнивал текущую страницу с новой гипотезой: например, полностью переработанный визуал против старой версии с точечными правками.

Брифинг:

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

Анализ конкурентов и референсов:

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

Накопленное знание своей аудитории:

1. У меня сложилось устойчивое понимание сегментов ЦА: их боли, мотивация, типичные возражения. Это позволяло выдвигать обоснованные гипотезы даже при минимуме исходных данных.

2.2. Кейс, когда исследование изменило интерфейс:
Случай «от обратного" — работа над страницей услуги по финансовому моделированию от стажёра при наличии акции. Страница существовала давно, имела стабильный поток трафика. Подумали с маркетологами, что можно ещё лучше. Тем более дизайн данной страницы давно устарел и не вписывался в обновленный недавно брендбук компании. Я инициировал полный редизайн, сделал современный визуал, переработали с маркетологами структуру, добавили интерактивные элементы (карточки с наглядными фин. инструментами). Далее прогнали A/B-тест: 50% трафика — на старую страницу, 50% — на новую. Результат через две недели удивил: старая версия показывала конверсию в заявку на 18% выше.

• В итоге вернулся к старой структуре, обновил типографику, цвета и иллюстрации, сохранив привычное расположение смысловых блоков и формы. Эта история послужила тому, что сейчас я целенаправленно развиваюсь в сторону UX-исследований (интервью, юзабилити-тестирования), чтобы добавить к своей базе ещё и прямые качественные методы, необходимые в сложных B2B-продуктах.

Вопрос 3.  Опишите вашу роль в создании или развитии дизайн-системы: организация компонентов, документация, работа с состояниями, версионность.

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

Ранний этап: переработка брендбука в интерактивное руководство. Единолично переработал старый брендбук компании в многостраничный интерактивный сайт на Tilda. Расширил цветовой спектр проверенными на реальных лендингах оттенками, описал правила использования логотипа, типографики, композиционных сеток, привёл примеры корректного и некорректного применения. Разработал уникальный сет корпоративных иконок и дополнил им раздел графики. Фактически это был прообраз будущей дизайн-системы. Я не раз выступал с инициативой вырастить из этого полноценную экосистему, однако у компании не было IT-департамента со своим топ-менеджером.

Переход к UI-киту на проекте редизайна. Единственным проектом, где я смог реализовать почти всё задуманное на практике, стал масштабный редизайн корпоративного сайта. Без формальной задачи «создать дизайн-систему», но понимая, что макеты будут уходить разработчикам через посредника, я принял решение собрать мини-дизайн-систему (UI-кит), которая обеспечила консистентность, скорость передачи, а также ее престиж.

Организация компонентов:

• В отдельном фрейме создал базовые токены: цвета (семантическая палитра), типографика (стили с иерархией), отступы и радиусы скруглений (переменные);
• Собрал кнопки, инпуты, чекбоксы, радио-кнопки, иконки и т. д. Всё строилось на Auto Layout;
• Каждый компонент имел набор состояний: default, hover, active, disabled, error, loading. Переключение свойств в панели Variants показывало нужное состояние — это заменяло документацию.

Работа с состояниями и документация:

• Каждый компонент сопровождался краткой текстовой аннотацией;
• В рабочих макетах рядом с ключевыми блоками оставлял комментарии-пояснения: логика переключения, поведение при пустом поле, текст ошибки валидации.

Версионность. Формальной системы контроля версий на том проекте не вёл — это был единый UI-кит, который развивался итерационно. Если объект менялся, то просто вносил правку в мастер-компонент. Такой подход гарантировал консистентность, хотя и был ручным. В более зрелой команде я бы дополнил это хранением изменений в отдельном changelog-фрейме.

• Созданный UI-кит позволил мне обеспечить передачу без единого дополнительного вопроса от разработчиков.

Вопрос 4. Приведите пример использования продуктовых метрик для пересмотра дизайна. Фасилитировали ли воркшопы с заказчиком и разработкой — цель, формат, результат?

Какие метрики использовал:

• Конверсия в заявку (основная продуктовая метрика) — через Tilda CRM отслеживал целевое действие «отправка формы»;
• Глубина скролла и время на странице — чтобы понять, какие блоки реально просматривают;
• Записи вебвизора (Яндекс.Метрика) — для анализа реального поведения: куда кликают, на каких экранах уходят;
• Воронка по шагам формы — на каком поле пользователи отваливаются, если начали заполнять.

Что показали метрики на основе выше описанного примера (работа над страницей услуги по финансовому моделированию):
A/B-тест старой и новой версии дал неожиданный результат — старая страница конвертила на 18% лучше. Из-за более расширенной информации об услуге в пользу SEO и приоритизации блока о самой компании по инициативе SEO-специалиста и проект-менеджера глубина скролла на новой странице резко падала после второго экрана, а время на странице было выше, но без конверсионного действия — пользователи просто читали и уходили.

Как пересмотрели дизайн:
Я предложил не возвращать старый визуал, а пересобрать структуру старой страницы в новом стиле. Блок с преимуществами компании оставили, но сократили и перенесли ниже в пользу краткого, но содержательного описания самой услуги. А на основе вебвизора добавили конкретные цифры выгоды — ровно там, где раньше был резкий отток. После повторного теста конверсия выросла на 12% относительно исходной старой версии.

Фасилитация воркшопов:
Формальных воркшопов с заказчиком и разработкой не проводил, но на регулярной основе организовывал встречи, которые по сути были их аналогом. Цель — совместно с маркетологами разобрать данные, выдвинуть гипотезы и зафиксировать решения по интерфейсу. Формат: раз в две недели в свободной форме отмечал по запущенным в прод лендингам или прямо в макетах интерфейсов проблемные места с выжимкой ключевых метрик и скриншотами. Результат: каждое изменение дизайна имело цифровое обоснование. Команда видела прямую связь между интерфейсом и конверсией, что сильно упрощало приоритизацию задач.

• Такой подход я перенесу и в работу над сложными B2B-продуктами. У меня уже есть базовый сценарий, который легко масштабируется.

Вопрос 5.  Опишите, как адаптировали навигацию, жесты и компоненты под iOS/Android на примере проекта. Что из десктопного опыта переносили, а что перерабатывали с нуля?

Отмечу сразу, что прямого опыта проектирования нативных iOS/Android-приложений у меня пока нет. Однако при адаптации десктопных интерфейсов под мобильные устройства на практике освоил принципы touch-интерфейсов, жестов и навигационных паттернов.

Что переносил из десктопного опыта:

• Дизайн-систему и визуальный язык. Цвета, типографику, иконки, отступы — всё это сохранил, но перевёл в адаптивную шкалу (размеры текста и элементов плавно менялись в зависимости от ширины экрана, а не просто масштабировались);
• Компоненты. Кнопки, поля ввода, карточки — их логика и иерархия остались теми же, но изменились размеры и состояния под touch.

Что перерабатывал с нуля и почему:

• Навигация. На десктопе в шапке было развёрнутое горизонтальное меню с выпадающими списками. Для мобильных устройств это решение нежизнеспособно: мелкий шрифт, невозможность точно тапнуть по пункту. Полностью заменил на бургер-меню с крупными областями касания, простыми аккордеонами внутри, а ключевое CTA вынес отдельной кнопкой в видимую зону шапки, чтобы не терять основной сценарий;
• Блок с флагманскими услугами. На десктопе это были вертикальные табы с динамической сменой баннера справа (о чём подробнее рассказал в следующем вопросе). На мобильных экранах такой интерактив нереализуем без потери обзора и конфликта с вертикальным скроллом. Я переработал блок в горизонтальную карусель с карточками услуг. Каждая карточка получила полную информацию: название, краткий оффер, иконку и кнопку. Этот паттерн полностью сохранил сценарий «оценить и сравнить услуги», но уже в рамках удобного touch-взаимодействия.
• Формы и интерактивные элементы. На десктопе использовал hover-состояния и тултипы — всё это неприменимо на тач-устройствах. Заменил на явные состояния нажатия. Все инпуты, чекбоксы, радио-кнопки увеличил до комфортного размера, а отступы между ними сделал достаточными, чтобы исключить ложные нажатия. Кнопку отправки формы на длинных страницах закрепил внизу экрана — sticky-элемент, всегда доступный большому пальцу.
• Сетки и контентные блоки. Многоколоночные десктопные сетки заменил на одноколоночную с сохранением смысловой иерархии. Длинные таблицы (например, тарифы) трансформировал в карточки-аккордеоны, где каждая строка раскрывается по тапу, показывая детали. Так пользователь не теряется в горизонтальном скролле и видит информацию порционно.
• Сейчас я целенаправленно углубляю знания в iOS Human Interface Guidelines и Material Design, чтобы при необходимости сразу включиться в проектирование нативных B2B-приложений и применить эти же принципы уже в рамках конкретной экосистемы.

Вопрос 6. Приведите пример, когда техническое ограничение вынудило изменить интерфейс — как вы сохранили пользовательский сценарий?

Показательный случай — из того же проекта по редизайну корпоративного сайта «Нескучных финансов», который я вёл как единственный дизайнер.

Ситуация 1. Невозможность реализовать задуманный интерактив. На главной странице я спроектировал блок с тремя флагманскими услугами компании. По задумке блок состоял из двух половин: слева — вертикальные табы с полными названиями услуг, справа — динамический баннер, который менялся при клике на каждый таб. Баннер содержал графику, ключевой оффер, преимущества и CTA. Это давало пользователю быстрый и эффектный способ сравнить услуги, не покидая экран. Однако прямой связи с разработчиками не было: я передавал макеты через проект-менеджера. Уже в проде обнаружил, что интерактив не работает — баннеры не переключаются, блок выглядит «сломанным». То ли с учётом загрузки графикой и анимацией, то ли в целом данный функционал команда не смогла реализовать.

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

• отказались от динамической подгрузки баннеров
• перестроили блок в горизонтальные табы с карточками услуг: каждая карточка статично отображала всю ключевую информацию — название, короткий оффер, иконку и кнопку перехода
• визуально усилили первую карточку (самый востребованный продукт), чтобы сохранить фокус и не потерять «продающую» силу блока.

Пользовательский сценарий — быстро оценить флагманские услуги и перейти к целевой — был полностью сохранён. Более того, в статичном варианте информация считывалась ещё быстрее, а блок стал «легче» для мобильной адаптации.

Ситуация 2. Ограничение процесса передачи макетов. Я не мог лично комментировать логику разработчикам, поэтому изменил сам подход к оформлению макетов: наполнил все интерактивные элементы текстовыми аннотациями о поведении в разных состояниях, а компоненты собрал в UI Kit с вариантами.

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