Разбираю сложную логику
Ролевые модели, таблицы на тысячи строк, статусы и платежи. Свожу их в понятные сценарии, которые не нужно объяснять.
Купол в Т1, vChain в Code PilotsПродуктовый дизайнер
Моя суперсила — сложные B2B-продукты: CRM, финансы, высоконагруженные интерфейсы с десятками тысяч объектов.
Дизайн-система с нуля, финансы, креативы и транзитная реклама для крупнейшего оператора наружной рекламы в России.
Продукт с нуля: JTBD, прототипы, A/B-тесты и 250+ экранов.
Полевое исследование, два терминала оплаты и кешбэк по QR в одном сценарии.
Аудит по Baymard, бонусная программа и оформление в три шага.
Лутбоксы, аналитика рынка и обучение новичков: год работы до закрытой беты.
Я продуктовый дизайнер с опытом 9+ лет. Проектирую B2B-сервисы, финтех и e-commerce: от интервью с пользователями до метрик после релиза. Живу в Санкт-Петербурге, работаю удалённо.
Четыре вещи, которые я делаю лучше всего и которые чаще всего нужны продуктовой команде.
Ролевые модели, таблицы на тысячи строк, статусы и платежи. Свожу их в понятные сценарии, которые не нужно объяснять.
Купол в Т1, vChain в Code PilotsИнтервью, прототипы и юзабилити-тесты на ранних этапах. Команда не тратит спринты на решения, которые не сработают.
Дискавери Купола в Т1После релиза смотрю на данные и нахожу, что улучшить дальше. Решения защищаю цифрами и результатами тестов.
A/B-тесты в Code Pilots и AimСобираю системы с нуля, чтобы продукт рос без хаоса, а разработка шла быстрее и дешевле.
RWB и PocmonsПрототип проходит через цикл «фидбек, улучшение, проверка» столько раз, сколько нужно, чтобы решение сработало.
↺ Шаги 03 и 04 повторяются: фидбек → улучшение → проверка
Уточняю бизнес-цели и собираю сценарии пользователей.
Интервью, аналитика и карта пути пользователя.
Формулирую гипотезы, делаю вайрфреймы и прототипы в Figma.
Проверяю решения на пользователях как можно раньше.
После релиза смотрю на данные и ищу, что оптимизировать.
Работаю с качественными и количественными методами, а экспертными быстро нахожу слабые места.
Кампании, бюджеты и рекламные поверхности по всей России. Внедрил дизайн-ревью и Discovery-подход, собрал библиотеку дизайн-системы для продуктовых команд.
Кейс Russ OnlineSaaS для DevOps-инженеров и SOC-центров. Спроектировал интерфейс с нуля: ролевые сценарии, политики, алерты и сложные таблицы.
Кейс КуполПереработал CRM vChain для международной логистики, сделал личный кабинет и маркетплейс для девелоперов.
Полный цикл от дискавери до релиза и кастомная дизайн-система, которая ускорила команду на 35%.
Кейс MONРедизайн строительных маркетплейсов, в том числе MGN, и лендинги для медицинских брендов.
Кейс MGNПроектировал интерфейсы для веба, мобильных и настольных приложений, работал с командами разработки и анализировал фидбек пользователей по метрикам и картам Hotjar.
Предложу, с чего начать, и расскажу, чем смогу помочь.
Как я перестроил продукт на новой дизайн-системе и спецификациях: фичи стали выходить быстрее и дешевле, а ручные операции с деньгами и креативами ушли из поддержки в интерфейс.
время создания кампании у менеджеров
ошибок при настройке кампании у внешних клиентов
технических обращений в поддержку
времени на распределение бюджетов
Группа Russ — крупнейший в России оператор наружной рекламы. Щиты, цифровые экраны и медиафасады в 150+ городах, аэропорты, вокзалы, метро, МЦК, МЦД и пункты выдачи Wildberries.
Russ Online — система, через которую проходят деньги и реклама всей этой инфраструктуры. Менеджеры и внешние клиенты заводят в ней кампании, загружают креативы, управляют бюджетами, выставляют счета и получают эфирные справки.
Любая ошибка в интерфейсе здесь — это либо деньги, списанные не там, либо экран, на котором не вышла оплаченная реклама.
Отвечал за продукт от постановки задачи до релиза. Подчинялся руководителю цифровизации и руководителю отдела дизайна.
Продукт собирали в начале 2000-х, и за 20 лет он оброс костылями. Остановить его и переписать было нельзя: бизнес рос и приносил новые задачи.
Если перестраивать продукт раздел за разделом на общей дизайн-системе и со спецификациями, каждая следующая фича будет дешевле предыдущей, а ручные операции можно убрать без риска для финансовой логики.
Прежде чем чинить сценарии, команде нужен был общий язык. За год я выстроил дизайн-систему Russ поверх Тайги.
С этого момента новая фича перестала быть «новым интерфейсом». Она собирается из уже сверстанных и протестированных блоков.
Главная проверка для системы случилась, когда компания вышла за пределы наружной рекламы: аэропорты, вокзалы, метро, МЦК и МЦД.
Внутри мы звали эту задачу «зоопарк экранов»: десятки форматов поверхностей со своими правилами. Работа заняла 5 месяцев от исследования до релиза.
Без дизайн-системы транзит пришлось бы делать отдельным продуктом. С ней он стал расширением существующего.
Транзит принёс десятки новых параметров: терминалы, направления рейсов, зоны, форматы экранов, дневные и ночные ставки. Старая форма создания кампании их не вмещала, и я спроектировал новый мастер — пошаговый сценарий с картой и живой статистикой.
Паттерны я искал у сервисов, где человек выбирает из тысяч объектов на карте и сразу видит, во что обойдётся выбор.
Из этих паттернов я собрал кликабельный прототип мастера из четырёх шагов: основные параметры, настройки размещения, выбор поверхностей на карте и бюджет.
Прототип я проверил на респондентах из числа менеджеров и агентств.
Карта со списком. Респонденты быстро находили нужные поверхности и понимали, что уже выбрано. Панель фильтров узнавали сразу: паттерн знаком по сервисам недвижимости.
Длина пути. Четыре шага с десятками полей — долго для опытных менеджеров: им важно видеть все параметры сразу и загружать готовые списки GID. Новичкам мастер понятнее, но чтобы это подтвердить, нужно было дополнительное тестирование, а времени на него не было.
Опытные менеджеры сейчас составляют 85% пользователей продукта, и решение делали для них. К тому же стоимость: карта с кластерами, фильтры, пересчёт статистики и ставки по каждому формату — несколько спринтов разработки, а транзит нужно было запускать сейчас.
Мы выбрали вариант для опытных менеджеров: одна страница вместо четырёх шагов. Слева форма с общей информацией, стратегией, географией, территориями и бюджетом, справа карта со статистикой. Этот сценарий показан на обложке кейса.
Концепт остался в запасе: карта, фильтры и ставки по форматам уже продуманы, и когда появится ресурс, их можно развивать, а не проектировать заново.
Как я веду задачу от идеи до второй версии — на примере калькулятора программатик-кампании.
С калькулятором клиент сам прикидывает объём и стоимость размещения на уличных экранах и в ПВЗ ещё до заявки: выбирает регион, тип конструкции, количество экранов, дни и часы показа — и сразу видит сумму.
Начинаю с референсов. Здесь это ипотечные и кредитные калькуляторы банков и сервисов недвижимости: как они раскладывают параметры, дают быстрые значения рядом со слайдером и показывают итог, которым можно поделиться.
По ходу работы собираю локальные компоненты — сетку часов показа, слайдеры с быстрыми значениями, карточку итога — и из них десктоп, телефон на 375 px и планшет на 800 px. На доске показываю все состояния: пустой расчёт, ошибки валидации, выпадающие списки, изменённую ставку, скопированную ссылку, PDF.
Логику работы и заметки для разработчиков пишу прямо на доске, в жёлтых стикерах. Это и есть спецификация: разработчик видит правило рядом с экраном, к которому оно относится.
При открытии страницы по ссылке сохранённые ставки сверяются с текущими минимальными: если сохранённые выше или равны минимальным — используются они, иначе подставляются актуальные минимальные, а в расчёте появляется комментарий об изменении.
При создании нового расчёта открываем его на новой странице.
Ссылку на онлайн-версию расчёта в PDF нужно сделать кликабельной.
Версию 1.0 выпустили в прод, после чего я провёл интервью и опрос менеджеров. Выводов было два:
Так появилась версия 2.0: слайдеры стали компактнее, быстрые значения переехали в строку заголовка, сетка часов — в две строки, а итог собран из карточек с главной суммой отдельным блоком. То же — в PDF.
Результат: ниже стоимость изменений, меньше нагрузки на поддержку, предсказуемые релизы.
Финансовая часть — самая чувствительная. Ошибка дизайна здесь превращается в неверный счёт или спор с клиентом.
Смена плательщика в постоплате. Раньше менеджер писал в поддержку и ждал. Я убрал два средних шага: теперь замена делается в один клик, с проверками внутри интерфейса.
Было до 1 часа через поддержку, стало мгновенно — самим менеджером.
Креативы — узкое горлышко запуска. Здесь менеджеры теряли больше всего времени, а клиенты — выходы рекламы.
| Сценарий | Было | Стало |
|---|---|---|
| Запуск кампании | Нужны все креативы | Достаточно одного согласованного |
| Правки креативов | Остановка кампании | Без остановки |
| Удаление поверхностей | Переход в другой раздел | Прямо в блоке креативов |
Старый блок креативов жил в модалке кампании: общие требования сверху, ряд селектов и длинная прокрутка, где у каждой поверхности свой креатив, свои серые кнопки и статус, который легко не заметить. Креатив из прошлого цикла приходилось заново отправлять на модерацию.
Эту версию я проектировал с оглядкой на сроки: бизнесу нужно было закрыть потребность к конкретной дате. Поэтому я оставил каркас модалки кампании и переработал только блок креативов — так вышло быстрее и дешевле для разработки, а пользователи получили главное уже в первом релизе.
Ключевой элемент — библиотека креативов. Материал из прошлого цикла подключается к новой кампании и сразу получает статус «Согласован», без повторной модерации. Именно так путь креатива из цикла сократился с часов до минут.
Второй этап — подключение нестандартных конструкций к RTB, автоматическому аукциону, где показы покупаются в реальном времени. Под это упростили массовое управление креативами, доработали поиск, фильтры и экспорт, автоматизировали синхронизацию поверхностей, и ручных операций стало меньше.
Дальше раздел развивали командой: у креативов появилась отдельная страница в меню с фильтрами по типу сделки, длительности и типу файла, а карточка показывает все параметры сразу. Статусы, библиотека и логика согласования из моей версии остались в основе.
Благодаря брейкпоинтам и карточкам адаптив не потребовал отдельного проекта.
Главная сложность — таблицы. На десктопе у кампании девять колонок, и на узком экране такая таблица либо уезжает в горизонтальный скролл, либо становится нечитаемой. Я адаптировал таблицы под карточки: строка превращается в карточку, где у каждого значения есть подпись.
Помимо таблиц, уже адаптированы шапка, авторизация и регистрация. На очереди фотоотчёты, каталог и справка.
Главный результат — поменялась экономика разработки. Каждая следующая фича стала обходиться дешевле предыдущей.
компонентов в дизайн-системе на базе Тайги, ей пользуются 5 продуктовых команд
экранов легаси переведено на новые компоненты, миграция в 2 раза быстрее
критичных багов на проде после внедрения дизайн-ревью
шагов при загрузке креативов
| Метрика | Было | Стало | Для бизнеса |
|---|---|---|---|
| Смена плательщика | До 1 часа | Мгновенно | Счета без задержек |
| Креатив из цикла | Часы | Минуты | Деньги в тот же день |
| Креативы для старта | Все | Один | Ранний запуск |
| Правки креативов | С остановкой | Без остановки | Реклама не простаивает |
Сложнее всего были не макеты, а споры о том, делать дешевле сейчас или дешевле на дистанции.
Аргумент «так удобнее» проигрывает. Аргумент «запуск за минуты вместо часов» — выигрывает.
Продукт с нуля: JTBD, прототипы, A/B-тесты и 250+ экранов.
Полевое исследование, два терминала оплаты и кешбэк по QR в одном сценарии.
Аудит по Baymard, бонусная программа и оформление в три шага.
Лутбоксы, аналитика рынка и обучение новичков: год работы до закрытой беты.
Спроектировал с нуля отечественную систему защиты контейнерных сред. Фичи рождались не из ТЗ, а из задач инженеров: от интервью до 250+ экранов.
время обработки уязвимостей и рисков
завершённость сценария: пошаговая настройка политик против единой формы
экранов, из них 120+ страниц десктопа с мобильной адаптацией
сценариев с ролевыми доступами и связанными сущностями
«Купол. Контейнеры» защищает всё, из чего состоит контейнерная платформа: образы, реестры, оркестраторы, контейнеры и ОС хоста — на всём цикле разработки ПО.
Раньше такие решения делали в основном иностранные вендоры. Компании получали регуляторные риски (ФСТЭК, CIS), непрозрачность и невозможность что-то настроить под себя. Цель бизнеса — заменить зарубежные решения и дать инженерам одно место для контроля уязвимостей, политик и конфигураций.
Я был ведущим дизайнером продукта. Моя задача была не рисовать интерфейс по ТЗ, а сформировать структуру будущих фич через логику пользователя.
У DevOps-инженеров не было единого инструмента безопасности. Приходилось держать несколько программ и вручную проверять каждую систему.
Если выводить фичи из реальных задач инженеров, а не из списка требований, продукт получит понятную и приоритезированную структуру, и инженеры быстрее примут ещё один инструмент.
На старте были только предварительные требования бизнеса и гипотезы команды. Структуру продукта я собрал из поведения пользователей.
«Когда я замечаю критическую уязвимость, я хочу быстро понять, где она, и назначить ответственного, чтобы снизить риск для продакшена»
Разобрал зарубежные CI/CD- и Kubernetes-инструменты, к которым инженеры уже привыкли: навигацию, подачу данных, алерты, настройку политик.
Решение: взял паттерны, к которым привыкли инженеры, но упростил язык и навигацию. Так снизился порог входа и сократился онбординг.
Мои пометки на интерфейсах конкурентов: зелёным — что забрал, красным — чего избегал.
На интерактивных прототипах прогонял ключевые сценарии: настройку политик, назначение ролей, реакцию на угрозы.
В A/B-тесте сравнил два способа настроить политику безопасности:
Каждую доработку я оформлял гипотезой: проблема, вариант реализации, макет «сейчас / гипотеза», прототип и ссылки на исследования. Гипотезы вели в общей базе со статусами, так команда видела, что уже проверено, а что в работе.
При принятии риска инженер выбирает десятки образов, и найти нужный в длинном списке трудно. Гипотеза: добавить поиск в блок «Выбранные образы» и в окно выбора.
Таблицы универсальны, но для анализа больших объёмов нужен компактный вид, а на небольших экранах — меньше прокрутки. Гипотеза: переключатель плотности «Компактный / Стандартный» в меню «Ещё» над таблицей.
В широких таблицах при горизонтальном скролле терялось, к какой строке относятся данные. Гипотеза: закрепить чекбоксы и первый столбец.
У разных ролей разные приоритеты в одной и той же таблице. Гипотеза: окно «Настройка столбцов» — скрыть лишние и перетащить нужные ближе к началу.
Результаты сканирования, импорта и экспорта приходят асинхронно, и пользователь их пропускал. Гипотеза: центр уведомлений в шапке с новыми и прочитанными.
При навигации с клавиатуры было не видно, какая кнопка активна. Гипотеза: заметное состояние фокуса для основных и второстепенных кнопок.
Инженерам передавали промежуточные версии прототипов и экранов, а потом разбирали, где они спотыкаются.
Продукт стал одним из первых полноценных отечественных решений в своей категории.
| Что изменилось | Как добились | Эффект |
|---|---|---|
| Обработка уязвимостей | Новая логика алертов и навигации | −25% времени |
| Настройка политик | Пошаговый сценарий по итогам A/B | +18% завершённость |
| Ошибки в политиках и ролях | Подтверждения, валидация, статусы, превью | Меньше ошибок конфигурации |
| Поддержка | Подсказки и понятные флоу | Реже вопросы про доступы и политики |
| Миграция с зарубежных решений | Знакомая структура, адаптированные термины | Комфортный переход для команд |
На пилоте пользователи говорили, что «работать стало проще и спокойнее».
Я спроектировал и мобильную адаптацию: 120+ страниц десктопа адаптированы под телефон. Навигация переехала в нижний таб-бар с кнопкой «Ещё», таблицы стали скроллиться по горизонтали с закреплённым первым столбцом, боковые панели — полноэкранными.
Дизайн-система с нуля, финансы, креативы и транзитная реклама для крупнейшего оператора наружной рекламы в России.
Полевое исследование, два терминала оплаты и кешбэк по QR в одном сценарии.
Аудит по Baymard, бонусная программа и оформление в три шага.
Лутбоксы, аналитика рынка и обучение новичков: год работы до закрытой беты.
Редизайн КСО для крупнейшей продуктовой сети Узбекистана. Флоу собран с нуля с учётом местных особенностей: два терминала оплаты и кешбэк 1% по QR-коду.
касс самообслуживания изучил в поле за один день
платёжных терминала в одном сценарии оплаты
кешбэк по QR-коду, встроенный во флоу
экранов за 140 часов работы
Клиент пришёл с устаревшей КСО: неудачный дизайн и запутанный опыт мешали людям быстро оплатить покупки.
Задача была не обновить визуал, а сделать кассу удобной и быстрой для всех. Главная местная особенность — два терминала оплаты на одной кассе. В российских КСО такого нет.
Работал в дизайн-студии с арт-директором и проджект-менеджером и отвечал за весь цикл.
Основная аудитория — люди до 40 лет, привычные к цифровым сервисам. Но касса должна быть удобной и пожилым.
Если спроектировать флоу с нуля на основе реального поведения людей у касс и дать подсказку на каждом шаге, покупатели будут реже звать сотрудника и быстрее проходить оплату.
Чтобы не гадать, как должна работать идеальная КСО, я пошёл смотреть на живых людей у касс.
За день посетил 8 точек: Перекрёсток, Пятёрочка, Лента, О'Кей, Леруа Мерлен, Бургер Кинг, KFC и «Вкусно — и точка». Наблюдал, где люди тормозят и какие экраны вызывают затруднения. Всё сфотографировал, записал и перенёс в Figma.
Параллельно разобрал текущий флоу клиента, который уже тестировали в нескольких магазинах. Вместе с заказчиком решили не латать старое, а спроектировать флоу заново.
Наблюдения разделил на удачные решения и повторяющиеся ошибки, чтобы не наступать на чужие грабли.
Из интервью с бизнесом и болей покупателей собрал job stories, а из них — набор UX-гипотез. На них опирался каждый экран.
Товар без штрихкода ищется по категориям и названию. Если что-то пошло не так, в шапке всегда есть «Инструкция» и «Вызов сотрудника».
Из интервью с бизнесом и болей покупателей собрал job stories. К каждой — гипотеза, как изменить опыт, и метрика, на которую она влияет.
Собрал карту всех экранов и переходов, чтобы у каждого сценария был понятный вход и выход.
Самый запутанный сценарий — карта лояльности. Разобрал, как её применяют на кассе и в мобильном приложении, и свёл в один путь.
По карте собрал вайрфреймы ключевых сценариев и связал их в прототип.
Собрал интерактивный прототип и проверил сценарии ещё до финального дизайна.
Люди из целевой аудитории проходили оплату, применяли карту лояльности, отменяли товар и звали помощь. Я смотрел, где они спотыкаются. По итогам перестроил блоки, упростил навигацию, уточнил формулировки и добавил подсказки.
Концепцию строил на брендбуке сети, чтобы касса стала частью экосистемы бренда.
Дизайн-система с нуля, финансы, креативы и транзитная реклама для крупнейшего оператора наружной рекламы в России.
Продукт с нуля: JTBD, прототипы, A/B-тесты и 250+ экранов.
Аудит по Baymard, бонусная программа и оформление в три шага.
Лутбоксы, аналитика рынка и обучение новичков: год работы до закрытой беты.
Полная пересборка сайта из начала 2000-х: исследование аудитории, UX-аудит по Baymard, новые продуктовые механики и 150+ экранов для десктопа и мобайла.
время оформления заказа
конверсия в заказ
обращений в поддержку
повторных заказов
MGN — британский маркетплейс стройматериалов, аналог Леруа Мерлен, OBI и Максидома. На старте это был интерфейс начала 2000-х без дизайн-системы и без проверки на пользователях.
Редизайн задумывался не как обновление стилей, а как пересборка продукта: удобство, современные паттерны и реальные задачи пользователей.
Сам выстроил процесс: вместо «перерисовать» — разобрать проблемы, найти метрики и сформулировать гипотезы.
Пользователи не доводили заказ до конца, а поддержка разбирала вопросы про корзину и доставку.
| Бизнес | Пользователи |
|---|---|
| Потери на этапе оформления | Сложно найти нужный товар |
| Высокая нагрузка на поддержку | Нет даже избранного |
| Уступает конкурентам визуально и функционально | Пустые карточки: нет отзывов и характеристик |
| Нет единого визуального языка | Низкий контраст, важное не выделено |
| Нет аналитики по ключевым действиям | Сайт плохо работает на телефоне |
Если сократить путь до заказа, наполнить карточки информацией и сделать мобайл удобным для работы на объекте, вырастет конверсия в заказ и снизится нагрузка на поддержку.
Основные пользователи — прорабы, снабженцы и небольшие строительные компании. Часто заказывают с телефона прямо на объекте.
Строители — ребята с крепкими руками и крупными пальцами. Это не шутка, а практическое UX-наблюдение из тестов.
Чтобы аргументы были весомее, проверил сайт по рекомендациям Baymard Institute.
Нашёл дублирующиеся действия, неочевидную иерархию в карточке, лишние переходы, сложную информацию о доставке и контраст ниже стандартов. Затем разобрал прямых конкурентов в России и Великобритании и косвенных — Ozon, Wildberries, IKEA.
Из интервью, обращений в поддержку и аудита собрал job stories. Каждая описывает ситуацию, мотивацию и то, что должен дать интерфейс.
| Job story | Мотивация | Что важно в интерфейсе |
|---|---|---|
| Когда я ищу нужный товар, я хочу быстро отфильтровать по параметрам, | чтобы не тратить время на просмотр нерелевантных позиций | Удобные фильтры, быстрый отклик, предварительный просмотр |
| Когда я собираю заказ для стройки, я хочу видеть всё в одной корзине, | чтобы ничего не забыть и удобно оформить доставку | Группировка по категориям, визуальные напоминания, автозаполнение |
| Когда я нахожусь на объекте с телефона, я хочу оформить заказ за 2–3 шага, | чтобы не отвлекаться от рабочего процесса | Упрощённый флоу, крупные элементы, минимум текста |
| Когда я выбираю товар, я хочу видеть отзывы и характеристики, | чтобы убедиться, что он мне подходит | Яркие табы, фильтр отзывов, примеры использования |
| Когда я оформляю заказ, я хочу понимать, где и как применяются мои бонусы, | чтобы максимально сэкономить | Видимая система бонусов, индикатор выгоды, расчёт скидки |
| Когда я делаю повторный заказ, я хочу просто нажать «повторить», | чтобы не собирать всё заново вручную | История заказов, быстрый доступ к часто покупаемым товарам |
| Когда я оформляю заказ, я хочу быть уверен, что ввёл всё правильно, | чтобы не пришлось обращаться в поддержку | Подсказки, валидации, проверка на последнем шаге |
По этим историям я приоритизировал сценарии вместе с владельцем продукта: сначала поиск, карточка и оформление заказа, затем бонусы и личный кабинет.
Кроме редизайна предложил бизнесу три механики, которые удерживают клиента внутри сервиса.
+18%повторных заказов
×2заказов из аккаунта
×3отзывов в карточках
+22%средний чек
+30%заявок на консультацию
+25%время на сайте
24%расчётов доходят до корзины
−15%дозаказов
−30%вопросов «сколько нужно»
По job stories пересобрал ключевые разделы маркетплейса.
Проект перевёл маркетплейс на продуктовые рельсы и дал бизнесу инструменты для роста.
Дизайн-система с нуля, финансы, креативы и транзитная реклама для крупнейшего оператора наружной рекламы в России.
Продукт с нуля: JTBD, прототипы, A/B-тесты и 250+ экранов.
Полевое исследование, два терминала оплаты и кешбэк по QR в одном сценарии.
Лутбоксы, аналитика рынка и обучение новичков: год работы до закрытой беты.
За год спроектировал с нуля площадку для торговли игровыми активами на шести блокчейнах: маркетплейс, личный кабинет, админку, лендинг и дизайн-систему в двух темах.
страниц: маркетплейс, кабинет, админка, лендинг
блокчейнов в одном интерфейсе
маркетплейсов разобрал в бенчмарке
темы на общей дизайн-системе
Проект под NDA, поэтому в кейсе я рассказываю про свой подход и дизайн-процесс. Экраны — только те, что заказчик разрешил опубликовать.
У компании есть свои NFT-игры. Игрокам нужно было место, где можно безопасно купить, продать и обменять игровые активы, не уходя на чужие площадки.
MON's задумывался как главный инструмент торговли между игроками и витрина для всей экосистемы: лутбоксы, коллекции, аналитика рынка и обучение новичков.
Отвечал за продукт целиком: структуру, сценарии, дизайн-систему и качество того, что уходит в релиз.
NFT-маркетплейсы обычно сделаны для тех, кто уже разбирается в криптовалюте. Наши пользователи часто приходили из игры.
Если спрятать сложность мультичейна за привычными паттернами, показать рынок прозрачно и добавить игровые механики, игроки начнут торговать внутри экосистемы, а не на сторонних площадках.
Разобрал больше десяти NFT-маркетплейсов: навигацию, карточки активов, покупку, подключение кошелька и подачу аналитики.
Главный вывод: аудитория уже привыкла к определённой структуре. Поэтому верхний уровень навигации построил на знакомых разделах — Explore, Marketplace, Create, Resources. Отличаться решили не структурой, а подачей: игровым визуалом, геймификацией и заботой о новичках.
Сложность мультичейна не должна ложиться на пользователя. Он всегда должен понимать, в какой сети находится и в чём цена.
Чтобы человек доверял площадке, он должен видеть, что рынок живой.
Спроектировал разделы Rankings и Metrics: графики объёма торгов и числа транзакций за выбранный период, подсказки с точными значениями на графике. Трейдер оценивает рынок за секунды, а новичок видит, что здесь действительно торгуют.
Торговля должна ощущаться как продолжение игры, а не как биржа.
Главную я пересобрал под телефон, а не просто сжал десктоп: у каждого блока свой мобильный паттерн.
Для инвесторов и игроков я спроектировал отдельный широкоформатный лендинг. Его задача — за минуту объяснить, что такое MON и зачем ему свой токен.
180+ страниц невозможно держать в одном стиле без системы.
Хороший макет ничего не стоит, если в продакшене он выглядит иначе.
За год продукт прошёл путь от идеи до закрытой беты.
| Что сделано | Зачем |
|---|---|
| Маркетплейс на 180+ страниц | Полный цикл торговли игровыми активами |
| Поддержка 6 блокчейнов | Игроки из разных сетей в одной экосистеме |
| Личный кабинет и админка | Управление активами и контентом |
| Мобильная версия и две темы | Торговля с телефона, комфорт в любое время |
| Лендинг в двух темах и широкоформатная версия | Привлечение игроков в экосистему |
Дальше: завершение беты, постепенное открытие функций и новые фичи по обратной связи сообщества.
Дизайн-система с нуля, финансы, креативы и транзитная реклама для крупнейшего оператора наружной рекламы в России.
Продукт с нуля: JTBD, прототипы, A/B-тесты и 250+ экранов.
Полевое исследование, два терминала оплаты и кешбэк по QR в одном сценарии.
Аудит по Baymard, бонусная программа и оформление в три шага.
Сайт использует cookies и Яндекс Метрику, чтобы понимать, какие кейсы читают.
120 × 120




Десктоп: состояния и заметки для разработки
Телефон, 375 px
Планшет, 800 px










Дашборды
Карта сети
Уязвимости
Карточка уязвимости
Комплаенс
Политики
Детали пода
Описание уязвимости
Леруа МерленВвод кода вручную без фото товара
ПятёрочкаВесы и товар без штрихкода прямо на старте
ПерекрёстокПомощь ассистента: как пользоваться кассой
ПерекрёстокОплата улыбкой
Бургер КингВыбор языка меню в отдельном окне
Вкусно — и точкаБаллы по QR и языки прямо на старте























