Превращаю сложную бизнес-логику в понятные B2B-продукты. 3+ года в продуктовом дизайне. Два собственных B2C-проекта довела от идеи до MVP. B2B Interfaces · Design Systems · 0→1 Products · User Research · Fintech · Logistics · Analytics
Единственный дизайнер на четырёх внутренних B2B-продуктах: логистическая платформа, кабинет продавца, курьерская доставка, аналитика больших данных. Работаю со сложными сценариями — ролевые модели, большие таблицы, много состояний. Собираю интерфейсы, которыми сотрудники МТС пользуются каждый день.
2025 — н.в.
Запуск продуктов 0→1
ВШЭ · проектная работа
Собираю свои продукты с нуля. Прохожу весь путь: от кастдева и гипотез до прототипов, лендингов, рекламы и первых лидов. Понимаю изнутри, как устроен запуск.
Маркетинговая стратегия, SEO/SMM, первые UI/UX-задачи для HR-tech стартапа. Международная команда.
2020 — 2022
Graphic Designer
Фриланс
Печатная продукция, соцсети, сайты на Tilda, презентации. Полный пакет Adobe.
2019
Motion & Illustration
Курсы, личные проекты
Анимация, иллюстрация, первые работы. Творческий проект @someforu.ru.
Образование2019 → 2027
2025 — 2027
Магистратура
ВШЭ · Дизайн и продвижение цифрового продукта
Продуктовое мышление, customer development, запуск продуктов с нуля. Учусь параллельно с работой.
2019 — 2023
Бакалавриат
РГУ им. Косыгина · Социология
Социология дала главное, что сложно добрать в дизайне, — умение слышать людей. Качественные интервью, наблюдение, способность отличить, что человек говорит, от того, что он делает на самом деле.
НавыкиЧто умею
Product Design
Проектирование интерфейсов
UX Research & CustDev
Сложный B2B / таблицы
Customer Journey Map
Design Systems
Работа с разработкой
Инструменты
Figma
FigJam
Tilda
Adobe Illustrator
After Effects
Notion / Miro
Сферы
B2B Internal Tools
0→1 Product Launch
Fintech / Payments
Logistics & Ops
Маркетинг / Брендинг
Motion & Illustration
Дополнительно03 категории
◎
Анимация
Motion-дизайн и иллюстрация: видео для NovaML, творческие анимации @someforu.ru
◻
Веб-дизайн
Лендинги и брендинг: Roofly, Start, eCompass Capital — от идеи до готового сайта
◈
Презентации
Investor decks, шаблоны для МТС, питч-материалы. От структуры до визуального языка.
Собрала работу логиста из пяти систем и Excel в одно рабочее место
Log Platform МТС — внутренняя платформа доставки клиентам товаров МТС (симки, роутеры, смартфоны): логисты принимают заказы из разных каналов, собирают маршруты, распределяют по подрядчикам и следят за доставкой. Раньше всё это жило в пяти ИТ-системах и Excel.
Спроектировала автоматизированное рабочее место логиста, где он ведёт заказ целиком, не прыгая между системами. Единственный дизайнер на продукте: разбиралась в логистике с нуля, собирала сценарии и состояния, передавала в разработку.
Роль
Продуктовый дизайнер
Скоуп
0→1
Пользователи
Логисты МТС
Команда
Product Designer1
Front-разработчик1
Back-разработчики8+
ТехЛид1
Системные аналитики4
Проблема
Операционный хаос, который тормозил логистику МТС
Логистика держалась на ручной работе: строки в Excel, переписки в мессенджерах, звонки, чтобы уточнить статус. Данные по заказам, маршрутам и подрядчикам лежали в разных системах и между собой не дружили.
Логист тратил часы, чтобы собрать табличку. А если ошибся при создании маршрута — узнавал об этом уже в доставке, когда исправить сложно и дорого.
Моя боль на проекте
Сама превращала техзадачи в продуктовые Команда инженерная, задачи приходили на языке системных аналитиков — без ответа на главный вопрос: зачем это логисту и что он должен сделать.
Поэтому перед проектированием я сама дособирала задачу: что болит у логиста, в какой момент он приходит на этот экран, что ему нужно на выходе. Иначе в разработку уходили бы экраны, в которых невозможно работать.
Так мне передавали задачи
01 — Dashboard
Это экран для быстрого ответа на вопрос: что сейчас происходит с логистикой и где болит
Логистам и руководителям постоянно нужно было смотреть одно и то же: что происходит с заказами, где проседает доставка, какие маршруты проблемные, как работают подрядчики. Раньше эту инфу собирали руками из разных мест.
Я собрала её в дашборд: с первого экрана видно, где всё нормально, а куда нужно провалиться и разобраться.
DashboardSLAОтчёты
02 — Маршруты
Сделала так, чтобы сложный и объемный маршрут можно было найти быстро
Маршрутов в системе много, и логисты ищут их по-разному — у каждого свой сценарий работы.
Я спроектировала таблицу так, чтобы логист сам настраивал нужные колонки, быстро фильтровал список и открывал нужный маршрут. Главная идея — таблица должна помогать работать, а не просто показывать данные.
ТаблицаФильтрыКолонки
03 — Создание маршрута
Разложила сложное создание маршрута по шагам, и сократила количество ошибок
В создании маршрута десятки зависимостей и ограничений, которые влияют друг на друга. Если показать всё одной длинной формой, логист легко теряется и пропускает важное.
Я разбила создание на понятные блоки и добавила навигацию слева. Логист видит, где он сейчас, какие разделы уже заполнены, где ошибка и что нужно поправить перед сохранением. Это снижает риск собрать маршрут с неправильными условиями.
ФормаШагиВалидация
04 — Карточка заказа
Собрала всю инфу по заказу в одном месте и разбила по вкладкам — логист перестал тонуть в данных, а быстро находит нужное
Чтобы понять, что происходит с заказом, логисту нужен не один статус, а весь контекст вокруг него.
Я разложила карточку по вкладкам, чтобы на первом экране не было свалки из данных. Главное видно сразу, детали лежат в понятных разделах. Логист не бегает по системам и не собирает заказ по кускам — открывает карточку и сразу понимает, что с ним и где искать проблему.
КарточкаИсторияДокументы
05 — Бизнес-продукт
Показала связи, которые раньше держали в голове, и ошибки из-за забытых зависимостей ушли
Маршрут зависит не только от адреса. На него влияет много связанных условий, и раньше эта логика жила в документах, таблицах или просто в голове опытных сотрудников.
Я вынесла эти связи в интерфейс. Логист видит, с чем связан маршрут, какие условия на него влияют и почему он работает именно так. Решение пришло после общения с пользователями, которые жаловались, что сложно держать всё это в голове.
ДоговорыСвязиКонтекст
06 — Полигоны
Зоны доставки стало видно на карте, а работа с географией перестала быть гаданием по координатам
Зоны доставки плохо читаются списком координат. Логисту нужно видеть карту: где проходит граница, какие районы попадают в зону, нет ли пересечений.
Я добавила работу с полигонами: можно загрузить GeoJSON, увидеть зону на карте и проверить, как она связана с маршрутом. География перестала быть набором непонятных чисел и стала рабочим инструментом.
КартаGeoJSONЗоны доставки
Дизайн-система
Достроила недостающее в дизайн-системе МТС
Собирала интерфейс на дизайн-системе МТС. Чего в ней не хватало, доделывала сама в той же стилистике и со всеми состояниями, чтобы всё жило как единая система.
User flow
Разобрала продукт целиком до того, как рисовать экраны
Разобралась, как продукт работает целиком: что происходит на каждом шаге пользователя и что стоит за этим в системе. Так проектировала под то, как всё устроено на самом деле, а не под идеальный сценарий.
Результат
Процессы, которые раньше решались звонками и Excel, теперь управляются в реальном времени — через интерфейс, который логист освоил без инструкции
Пересобрала ключевые сценарии продаж вокруг задач продавца, почти не трогая бэкенд
Внутренний продукт МТС для продажи B2B-оборудования: продавец ведёт всю сделку от подбора клиента до резерва, закупки и списания. Над сделкой работают три роли, и решения одной сразу влияют на других.
Пришла на редизайн действующего продукта. Им пользовались каждый день, но на сложных сценариях часто ошибались. Нашла, где интерфейс мешает работать, и пересобрала сценарии так, чтобы ошибаться было сложнее.
Роль
Продуктовый дизайнер
Скоуп
Редизайн
Пользователи
Продавцы и пресейлы B2B
Команда
Product Designer1
Front-разработчик1
Back-разработчики2
Продакт-менеджеры2
Проблема
Три роли, общий поток данных и ошибки, которые всплывают слишком поздно
Сделка идёт через несколько этапов и трёх пользователей: то, что сделал один, становится основой для следующего. В старом интерфейсе эти связи были не видны: продукт не вёл по сценарию, часть состояний терялась, а ошибки замечали уже в конце, когда исправлять дорого.
Моя боль на проекте
Макеты пришлось пересобирать с нуля Мы не смогли получить доступ к Figma предыдущей версии продукта. Интерфейс восстанавливала с нуля.
Пробовала ускориться нейросетями, но на сборку компонентов и возвращение их к дизайн-системе МТС всё равно ушло много времени.
Аудит
Начала с аудита интерфейса
Перед проектированием разобрала весь продукт по экранам. Узнала, где путается пользователь, какие есть идеи и вопросы к команде. Так собрала картину проблем и поняла, что чинить в первую очередь.
Редизайн
01 — Карточка резерва
Сократила путь менеджера в карточке резерва без пересборки бэкенда
Ключевые данные и ежедневные действия собрала на одном экране, а редкие функции убрала из основного сценария.
Контекст
Менеджеры используют карточку, чтобы контролировать срок и состав резерва, проверять клиента и корректировать товары. На рабочих созвонах я наблюдала, как они проходят сценарий, и выяснила, что время теряется на поиске данных, открытии модалок и повторных подтверждениях.
Ограничение
Нужно было ускорить ежедневную работу, сохранив текущие сущности, бизнес-правила и доступные операции. Поэтому я не проектировала процесс заново, а перестроила информационную архитектуру и приоритет действий на уровне интерфейса.
Результат редизайна
Типовой сценарий стал короче: менеджер быстрее считывает состояние резерва и выполняет основные операции с меньшим количеством переходов. Изменения реализованы преимущественно на уровне интерфейса, без пересборки бэкенда.
Было
Ключевые данные скрыты в модалках; действия с резервом и товарами смешаны; редко используемые функции занимают место в основном сценарии.
Стало
Статус, срок, клиент и связь с заявкой видны сразу. Действия распределены по объектам, а вторичная информация раскрывается только по запросу.
01
Две модалки вместо пяти
Менеджер сверяет состояние резерва постоянно, но часть данных пряталась в модалках, и картину приходилось собирать по кусочкам, упуская важное. Я подняла данные на экран, а модалки оставила только для подтверждений отмены и продления.
02
Отмена резерва отделена от работы с товарами
Отмена резерва необратима: один случайный клик, и клиент теряет зарезервированный товар, а сделку собирают заново. Раньше эта кнопка стояла вплотную к частым действиям по резерву и товару. Я развела их, чтобы рутина не могла задеть необратимое действие.
03
Одно сохранение вместо серии подтверждений
В резерве бывают десятки позиций, и раньше каждое изменение количества подтверждали отдельно, превращая работу в конвейер кликов, где легко сбиться. Я собрала изменения в одно действие с одним сохранением: быстрее и меньше ошибок.
02 — Поиск товара
Перестроила поиск товаров: склад стал фильтром, а не точкой входа
Раньше поиск начинался с пустого экрана и обязательного выбора склада. Я развернула сценарий вокруг товара: продавец сразу ищет позицию и видит всё для решения прямо в выдаче.
Контекст
Со страницы «Товары» начинается один из основных рабочих сценариев: продавец ищет позицию, оценивает её доступность и переходит в карточку товара.
Раньше сценарий начинался не с товара, а со структуры хранения. Даже если продавец не знал, на каком складе лежит позиция, система сначала требовала выбрать склад, а до этого показывала пустой экран.
Ограничение
Данные, бизнес-логика и права доступа уже существовали. Я не меняла их, а перестроила точку входа и информационную архитектуру на уровне интерфейса.
Поэтому задача была не добавить экранов, а вынести на поверхность то, что уже есть в системе, и убрать лишние шаги до этого.
Результат редизайна
Продавец ищет сразу по всей номенклатуре и с первого экрана видит наличие, резервы и ожидаемые поступления по каждой позиции. Склад и категория стали фильтрами, а не условием входа. Плотность здесь работает на задачу: товар находится и оценивается за меньшее число шагов.
Было
Пустой экран и обязательный выбор склада на входе. Пока склад не выбран, список показывал «Нет данных», выглядел сломанным, а поиск был недоступен.
Стало
Поиск по всей номенклатуре сразу. Наличие, резервы и поступления видны в выдаче, а фильтры по складам и категориям и сортировка помогают быстро сузить 2 450 позиций.
01
−1 обязательный шаг
Убрала выбор склада на входе в сценарий. Продавец ищет товар сразу, а склад и категория уточняют выдачу только при необходимости.
02
Всё для решения в выдаче
Наличие, резервы и ожидаемые поступления вынесла в сам список. Чтобы сравнить позиции и выбрать, продавцу больше не нужно открывать каждый товар.
03
Любой товар легко найти
Поиск по наименованию и коду, фильтры по складам и категориям, сортировка колонок. Большой каталог стал быстрым инструментом, а не длинным списком.
03 — Главная
Превратила пустую главную в ролевую точку входа
Вместо экрана без содержания пользователь сразу видит доступные ему рабочие сценарии и понимает, с чего начать.
Контекст
После входа пользователь попадал на полностью пустую страницу. Она выглядела как ошибка или незавершённая загрузка и не помогала понять возможности платформы. Чтобы начать работу, нужно было знать структуру разделов и самостоятельно искать нужный модуль в верхнем меню.
Ограничение
Существующие процессы, модули и модель прав доступа уже были определены. Я не меняла продуктовую логику, а пересобрала точку входа вокруг целей конкретной роли.
Результат редизайна
Объединила разрозненные разделы в понятные рабочие сценарии. Состав главной зависит от роли: пользователь видит только доступные ему задачи и не сталкивается с нерелевантными разделами.
Было
Пустой экран после входа, похожий на ошибку или недогруз.
Стало
Ролевая главная: доступные сценарии сразу на входе.
Результат
Почти не трогая бэкенд, пересобрала ключевые сценарии вокруг задач продавца: убрала лишние шаги, снизила цену ошибки и сократила путь до продажи на ≈ 30%*
5 сценариев
упростила по продукту в целом
≈ −30%* времени
на оформление продажи, по словам продавцов
* По словам продавцов. Точные метрики пока в процессе замера на пилоте.
20 интервью развернули соседскую соцсеть в спокойный сервис для дома
Мобильный сервис для жителей многоквартирных домов: важное о доме отдельно от шума, бытовые задачи со статусом и безопасный контакт с соседями. Личный 0→1-проект во ВШЭ: за полтора месяца от исследования до MVP.
Роль
Продуктовый дизайнер, автор продукта
Скоуп
0→1 · CustDev · Тест спроса
Проблема
Домовой чат стал главным инструментом соседей и плохо с этим справляется
В одном потоке вперемешку уведомления управляющей компании, бытовые просьбы, объявления и конфликты. Важное теряется, у запросов нет статуса, а написать незнакомому соседу неловко. Проблема не в нехватке общения, а в шуме и отсутствии структуры.
CustDev · 20 респондентов
Проверяла три гипотезы в глубинных интервью
Разговаривала с жителями многоэтажных домов Москвы, преимущественно миллениалами.
«Хочется отфильтровать и видеть только то, что мне интересно: уведомления я выключила, устала от всего подряд.»
Подтвердилось
Контакт нужен, но начинать проще с конкретного дела, а не со знакомства.
«Написала в чат: „Мужчины, кто поможет перенести шкаф?“ Сосед потом подошёл: „Я бы помог, ещё нужна помощь?“»
Не подтвердилось
Доверия между незнакомыми соседями достаточно, чтобы помогать и просить.
«Стучу к соседу: „У вас тоже воды нет?“, и каждый раз неловко, как будто пришёл занимать деньги.»
Поворот продукта
Соседи не хотят общаться между собой, но им нужно вовремя узнавать важное о доме, а сейчас оно тонет в спаме. Поэтому продукт стал тихим утилитарным инструментом: мягкий онбординг, важное отдельно от шума, простая публикация и знакомство с соседями от дела, а не от болтовни. Это определило все решения ниже
Решения
01 — Онбординг
Без регистрации находишь свой дом, настраиваешь ленту под себя и включаешь уведомления только о важном для дома и района
Первый вход объясняет пользу и настраивает ленту под человека, не требуя регистрироваться сразу: житель указывает адрес дома, выбирает важные темы и включает уведомления только по делу. К ленте он приходит уже с настроенным «важным», а не с пустым шумным потоком.
OnboardingLocationNotifications
02 — Лента и вход
Сначала оцениваешь пользу ленты, где важное отфильтровано, и шум ушёл в комментарии, а регистрируешься, только когда сам захочешь писать
Ленту видно без регистрации, поэтому пользу человек оценивает сразу. Чтобы писать и публиковать, он регистрируется по номеру (соседи его не видят) и заполняет профиль.
FeedAuthProfile
03 — Лента и публикация
К посту можно не только оставить коммент, но и напрямую связаться с автором, а чтобы опубликовать свой, достаточно написать запрос, заголовок и категорию подберёт ИИ
По тапу на любой пост открываются профиль автора и личный чат, поэтому до нужного соседа один шаг. А своя публикация работает как запрос: описываешь, что нужно, добавляешь фото, а заголовок и категорию собирает ИИ.
FeedComposeAI
04 — Соседи под задачу
Нужного соседа находишь по делу, а не через неловкое знакомство
У каждого соседа профиль с профессией и навыками, а эксперты (педиатр, электрик) отмечены значком. Ищешь по запросу и умению «чем могу помочь», открываешь профиль и пишешь напрямую в личный чат. Полезное рядом находится за пару шагов, без общего шумного чата. А ещё так закрывается тихая боль большого города: живёшь рядом с сотней людей и не знаешь никого. Общение здесь начинается с дела, поэтому в него легко войти без неловкости.
Весь проект уложился в полтора месяца: за этот срок прошла путь от идеи до теста: исследование, дизайн и продвижение. Вела соцсети (Телеграм, Нельзяграм, Дзен), собрала лендинг и запустила рекламу, чтобы понять, как люди реагируют на идею и нужна ли она.
Аудитория откликалась на боль «важное о доме тонет в шуме»: 71 подписчик, 92 посетителя лендинга и 32 заявки на ранний доступ. Реакция подтвердила, что проблема считывается и доводит до целевого действия. Выборка маленькая, о product-market fit говорить рано, но гипотеза оправдала следующий шаг.
Результат
Развернула шумный домовой чат в тихий утилитарный продукт и проверила, что он нужен, ещё до кода
32 заявки
на ранний доступ за 1,5 месяца
5 флоу
спроектированы 0→1 вместе с прототипом, компонентами и дизайн-системой
20 интервью развернули «каталог мест» в сервис, который закрывает выбор за компанию
Мобильный сервис для компаний друзей: за 30 секунд собирает три варианта вечера под настроение и вкусы всех, а спорный выбор закрывает голосованием. Командный 0→1-проект во ВШЭ: я вела исследование и продукт, а напарница отвечала за продвижение и экономику.
Роль
Продуктовый дизайнер: исследование и продукт
Скоуп
0→1 · CustDev · UI · Тест спроса
Проблема
Пока компания час выбирает в чате, вечер срывается, а организатор выгорает
Договориться о совместном плане всегда сложно: предпочтения у всех разные, важное тонет в переписке, решение затягивается. В итоге один человек становится организатором, тратит силы на сбор хотелок и выгорает. Связь ослабевает, и встречи откладываются на «как-нибудь потом».
Откуда взялась идея
Идея выросла из трёх сигналов рынка, а не из догадки
Перед продуктом изучили тренды по отчётам ВЦИОМ, РБК Трендов, СберАналитики и Gitnux: молодёжь устала от думскроллинга и хочет живых встреч, тратит деньги на впечатления, а не на вещи, и спокойнее относится к ИИ-подсказкам, если те дают быстрый понятный ответ. На этом пересечении и родилась гипотеза: людям нужен не ещё один каталог, а инструмент, который помогает выйти из экрана и реально встретиться.
Запрос на живые встречи
Одиночество и цифровая усталость: люди хотят чаще видеться офлайн, но собраться всё труднее.
Усталость от лент
Запрос на осознанное время: сервис должен помогать действовать, а не удерживать в экране.
ИИ как норма выбора
Готовый короткий ответ с объяснением ценится выше, чем ручной поиск по спискам.
CustDev · 20 респондентов
Проверяла три гипотезы: почему компаниям так трудно договориться
Разговаривала с теми, кто регулярно собирается компанией, преимущественно с молодёжью крупных городов.
Главная боль — закрыть решение, а не придумать варианты: идей и так много, они тонут в чате.
Подтвердилось
Людям сложно сформулировать свои желания и границы, поэтому процесс буксует ещё до выбора места.
Подтвердилось
Выбор несёт эмоциональный риск, поэтому его перекладывают на одного, и именно он выгорает.
Поворот продукта
Люди приходят не за идеями, а чтобы снять с себя риск и ответственность за выбор. Поэтому продукт закрывает решение за компанию: быстрая подборка под настроение и вкусы всех, а спорный выбор закрывает короткое голосование, которое снимает вину с организатора. Это определило все решения ниже
Артефакты
USER FLOW
Схема пользовательских сценариев · скоро
CJM
Карта пути пользователя · скоро
JTBD
Работы, на которые «нанимают» продукт · скоро
ДИЗАЙН-СИСТЕМА
Компоненты и токены · скоро
Решения
01 — Онбординг
Анкета и друзья за пару тапов поднимают точность подборки ещё до первой встречи
Вход через привычные сервисы, анкета интересов и приглашение друзей. Прогресс-бар наглядно показывает, как точность подборки растёт с 10% до 45%, поэтому заполнять профиль хочется. К главному экрану человек приходит уже с настроенным контекстом, а не с пустым сервисом.
OnboardingInterestsInvite
02 — Сбор встречи
Настроение и состав компании задаются за 30 секунд, и сервис сразу выдаёт три варианта вечера
С главного экрана человек запускает сбор встречи, двигает точку по шкале настроения и отмечает, с кем идёт. На основе анкеты, контекста дня и геолокации сервис подбирает три места, а не бесконечный список, поэтому выбор закрывается быстро.
HomeMoodAI-подбор
03 — Голосование
Спорный выбор закрывает анонимное голосование и снимает ответственность с одного человека
Если компания не сходится, организатор отправляет подборку на голосование. Ответ анонимный, поэтому никому не неловко, а итог виден всем: побеждает вариант большинства, дата фиксируется, событие создаётся. Решение принимает группа, а не один человек.
VotingGroupResult
04 — История
Каждую встречу можно сохранить с фото и оценкой, а статистика превращает прошлые вечера в повод собраться снова
После встречи пользователь оценивает её, добавляет впечатления и фото или заводит своё событие вручную. Сервис копит историю и показывает статистику: сколько встреч прошло, с кем чаще всего и в каком настроении. Прошлые вечера жалко терять, а цифры возвращают желание собраться снова.
HistoryStatsRetention
Проверка спроса
Проверили спрос ботом, лендингом и рекламой ещё до разработки
Чтобы понять, нужен ли продукт, собрали Telegram-бота с логикой подбора, лендинг с квизом и запустили рекламу. Продвижение и экономику вела напарница, я отвечала за продукт и исследование.
Отклик подтвердил, что боль считывается: бота прошли 56 человек за два месяца, лендинг собрал 421 переход и 15 прохождений квиза. Выборка маленькая, о product-market fit говорить рано, но гипотеза оправдала следующий шаг.