Привет!
Вы в портфолио-пространстве. Здесь можно посмотреть опыт за последние 3 года и пообщаться со мной и агентом в чате.
используй мышь и клавиши · ↑︎ ↓︎ ←︎ →︎
Большое дизайн приключение — как дизайнер-технарь жил в одной main-ветке с инженерами и строил генераторы, дизайн-систему и бренд через Claude Code.
Три платформы, несколько брендов, единый язык дизайна. Pre-IPO редизайн веба и мобильных приложений, четырёхслойная архитектура токенов с нуля, и code-first процесс, где Figma и Claude наконец разговаривают друг с другом.
Три платформы, несколько брендов, единый язык дизайна. Pre-IPO редизайн веба и мобильных приложений, четырёхслойная архитектура токенов с нуля, и code-first процесс, где Figma и Claude наконец разговаривают друг с другом.
Ключевое решение, изменившее продукт, — разделение опыта клиента на фазы программы. Раньше клиент видел одинаковый UI на радикально разных этапах своего пути; я спроектировал отдельные интерфейсные состояния для каждой фазы — и из этого выросло остальное.
Net Promoter Score. План бизнеса — 70, сделали 78. +33 пункта к стартовой точке после редизайна и системы фаз.
Customer Satisfaction по 5-балльной. План — 4.2, сделали 4.5. Меньше тревоги — выше доверие.
Покомпонентно раскатили дизайн-систему вместе с командами разработки. Покрыли больше половины интерфейсов на трёх платформах.
Семь параллельных линий работы. Цвет полоски — про интенсивность: основное направление, продуктовая работа, фон или короткий заход. Многое шло параллельно — поэтому редизайн, дизайн-система и Community-трек пересекаются в одних периодах.
Americor — финтех в сфере debt relief. Помогает людям выходить из долгов через программы реструктуризации. Дочерние бренды в разных штатах со своей визуальной идентификацией — это связано с различиями в законодательстве. Продукт: веб-приложение (десктоп + адаптив) + мобильные приложения для iOS и Android.
Моя роль — Lead Product Designer. Репортил продакт-менеджеру (→ CPO). В команде junior-дизайнер — менторил, постепенно вовлекал в задачи возрастающей сложности.
Задача сразу была тройная: редизайн продуктовой линейки (компания готовилась к IPO); поднять NPS и CSAT; построить дизайн-систему с нуля и реально внедрить её в работу — не файл в Figma, а инструмент команды.
Единой дизайн-системы не существовало: переиспользуемые блоки лежали россыпью по файлам Figma, и при создании нового макета дизайнер собирал страницу из разрозненных кусков вручную. Поддерживать и масштабировать так — невозможно.
Предыдущая попытка фриланс-дизайнера на фирменный стиль провалилась — 40–50% за полгода, человек ушёл. Разработчики тратили недели на поиск «источника правды» для компонентов.
Главное: никаких артефактов о том, как устроен продукт, не существовало — ни user flow, ни process maps, ни документации. Понимание жило в головах отдельных людей.
Поскольку документации не было, я начал с интервью — с аналитиками, бизнесом, разработчиками. Восстанавливал логику продукта по кускам.
Чтобы валидировать понимание, собрал Product Flow Diagram — end-to-end карту со всеми флоу, ветвлениями по бизнес-правилам (Primary Flow для долгов > $7500, Secondary для меньших) и состояниями пользователя на каждом этапе. Это стало первым в компании единым источником правды.
Параллельно — аудит макетов и реальной сборки приложений (поставил тестовые билды, прошёл флоу сам). Опирался на здравый смысл, продуктовый опыт и UX best practices. Часть проблем была очевидной: где-то не хватало информации, где-то запутывали пользователя, где-то некорректно показывали данные, где-то не давали прозрачности по платежам. Проблем накопилось много.
Двухуровневая структура с разветвлением:
Параллельно реорганизовал структуру в Figma: итерации, ветки для разработки, понятная навигация. Покомпонентно раскатывали на текущие приложения вместе с командами разработки — покрыли ~50–60% интерфейсов.
Через ~3 месяца работы пришёл бизнес: компания готовится к IPO, нужен полный редизайн. Ситуация нетривиальная — система, спроектированная под существующий дизайн, должна была начать поддерживать новый. На этом этапе мной было принято и защищено решение унифицировать дизайны приложений, оставив разность лишь в нативной части. Работали вдвоём с middle-дизайнером — я вёл редизайн, контролировал качество, менторил.
Главная продуктовая находка — разделение опыта на фазы программы. Раньше клиент в разных фазах видел один и тот же UI, хотя его контекст и потребности радикально менялись. Я спроектировал систему фаз и отдельные интерфейсные состояния для каждой.
Параллельно с системной работой решал вопрос с графикой — иллюстрации для пустых состояний, онбординга, ключевых экранов; аватары для коммуникаций.
Сначала генерировал десятки вариантов в разных стилях через нейросети — нужно было найти стиль, который ляжет на бренд. Со временем вырос пайплайн через нодовый редактор: ComfyUI, позже Figma Weavy. Это позволило стабильно генерировать иллюстрации в едином стиле — не один раз случайно угадать, а превратить генерацию в управляемый процесс.
На финальном этапе — последний крупный проект, раздел Community. Группу на Facebook заблокировали, и мы решили построить аналог Reddit/Facebook внутри приложения. Поскольку это была фича с нуля, я попробовал на ней новый подход.
Базовый макет собрал в Figma, дальше попросил Claude собрать React-приложение с компонентами в Storybook во всех состояниях. Развитие продолжалось в коде: продуктовые гипотезы вшивались прямо в прототип — через иконку шестерёнки переключались варианты, сравнивались side-by-side.
Когда решение было готово, я просил Claude сгенерировать Figma-компоненты для разработчиков и тестировщиков (они работали в своём стеке) — в наших токенах, шрифтах, дизайн-системе. Передача проходила без расхождений.
Процесс перевернулся: вместо «дизайн → передача → разработка» стало «прототип в коде → валидация на работающем продукте → передача готовых компонентов».
Перед редизайном нужно было опереться на реальные проблемы пользователей, а не на догадки — поэтому пару инструментов я собрал сам.
Facebook Community Analyzer. В Facebook-группе компании годами копились тысячи живых сообщений от клиентов — самый честный источник про их боль. Я завайбкодил приложение: оно выгрузило все посты и комментарии (~80 000 сообщений), прогнало каждое через нейросеть с разметкой по теме (UX, поддержка, конкретная фича) и тональности и собрало всё в интерфейс с фильтрами. На выходе — ясная картина: что раздражает, чего не хватает, какие фичи просят. Эти выводы стали фактической базой решений по редизайну.
NSF Shortfall Simulator. У фичи прогноза нехватки средств на дату списания была запутанная бизнес-логика. Я собрал интерактивный симулятор, чтобы самому разобраться в механике, проверить пограничные сценарии и проектировать не на ощупь.
Оба инструмента остались в работе команды — ими пользовались не только дизайнеры.
Перетащи разделитель — слева как было, справа как стало.
Ниже — отдельные продуктовые истории, которые я раскрываю самостоятельными кейсами.
Снял сомнения и повысил понимание условий офера по урегулированию долга — больше осознанных решений и онлайн-принятий. +175% online acceptance.
Прозрачность процесса, динамика статусов и предсказуемость settlement-программы — выше доверие и вовлечённость пользователей в начале пути. +72% NPS.
Трёхуровневая архитектура токенов и общий компонент-spec для web / iOS / Android — мгновенная смена темы через Figma modes, Code Connect → React.
Как дизайнер с замашками разработчика работал в команде с бородатыми t-shape инженерами. Healthcare IT, FHIR-инфраструктура. Плоская культура — все сеньоры, нет PM/QA. Пришёл вторым дизайнером. AI-first с первого дня — сложные задачи сразу в React-демо.
Карточки расставлены по приоритетам из TL;DR. Нажми любую — провалишься в полный сабкейс с деталями.
Markdown-вход → брендированный лендинг за 2–3 дня. Библиотека блоков, DOM-aware Claude-чат «Fixik».
Два способа сборки: «кинул текст и получил» или конструктор. Три режима генерации.
Многослойная DS на shadCN, семантические токены, двунаправленная синхронизация Figma ↔ код.
Claude-скилл, который тянул компоненты из Figma на раннем этапе технологии, когда такого инструментария ещё почти не было.
PostHog встроен в шаблон. Каждый автор лендинга видит метрики без переключения вкладок.
Логотипы, иллюстрации, маскот, стиль диаграмм. Маскот стал основой кудос-генератора.
Обучен на бренд-маскоте, живёт в Telegram-боте для шеринга внутренней валюты за достижения.
Веб-приложение для healthcare-конференции в Португалии: голосование, расписание, подписки. Убедило C-level.
Рабочие прототипы вместо статичных мокапов, с первого дня. Кодом проверяю гипотезы быстрее чем дизайном.
Совместный редизайн UI флагманской FHIR-платформы.
Master Patient Index — матчинг записей, слияние, аудит изменений.
Дизайнер в продакшн-репозиториях, модель ветки и мержа. Дизайн как граф коммитов.
Восемь параллельных линий работы. Цвет полоски — про интенсивность: основное направление, продуктовая работа, фоновая активность или короткий заход.
Смена процесса · 3 месяца → 2–3 дня · 25+ новых лендеров
Когда я пришёл в компанию, нас со вторым дизайнером периодически просили помочь с новыми лендосами. Мы дизайнили новые, старые при этом оставались выглядеть по-старому. Чтобы сделать один лендинг, нужно было: созвониться с C-level и узнать, что они хотят. Потом созвониться с инженерами, чтобы понять, как они будут верстать. Свести всех на одну встречу почти никогда не получалось. Параметры менялись по ходу. После всех созвонов в дело подключался маркетинг — собирал контент. После утверждённого контента начиналась фаза сборки задизайненного лендоса в Webflow со всеми вытекающими (технические ограничения, design review…). В среднем один лендинг тянулся около 2–3 месяцев.
CTO сказал: «Ребята, это бред. Давайте автоматизируем это.» Так я приступил к созданию системы автоматической генерации лендингов в рамках нового стиля.
После v1 люди жаловались: «Нам не хватает визуальной обратной связи, мы не понимаем, какие блоки есть, мы не видим, как раскладывается контент.»
Поэтому я добавил отдельную страницу со всеми видимыми блоками, режим редактирования, «корзину» для блоков, экспорт JSON/MD → импорт в Claude. Для тех, кто хочет визуальный контроль вместо «скинь MD и получи что-то».
Весь сайт компании теперь работает на этой системе. Презентовался на конференциях.
Смена процесса · ~1 неделя → ~1 час · 30+ сгенерированных презентаций
Тот же подход, что у платформы лендингов, применённый к презентациям. Две точки входа (скинь-и-получи + визуальный редактор), три режима генерации (Normal / Variety / Madness). Около 30 сгенерированных презентаций, команда в восторге.
Проблема: много питчей, много презентаций. Все делали их в разных инструментах (Google Slides, Figma, PowerPoint, онлайн-сервисы), с разными стилями. Никакой системы, никаких общих стилевых констант, никакого переиспользования.
На разработку ушёл примерно месяц.
Скинь MD / текст / HTML / PDF в Claude → «сделай презентацию с помощью Presentation Builder Skill». Три режима:
Слайды + модули + JSON-структура → Claude рендерит управляемое решение. Для тех, кто любит контроль: готовые страничные паттерны, разные элементы (текст, иконки, текст-с-иконкой, карточки, разделители), импорт данных по слайдам.
Структура гибкая: каждый модуль — это JSON-узел с полями, визуальное представление позволяет редактировать контент прямо там или скачать сгенерированный JSON, отредактировать в своём редакторе и вернуть Claude.
Система · 2024 Q3 — продолжается · 4 слоя, мультипродукт
Многослойная дизайн-система поверх shadCN с семантическими токенами, кастомными состояниями и двунаправленной синхронизацией Figma ↔ код. Используется в продакшне всеми продуктовыми командами.
shadCN был выбран как основа — он даёт компоненты и свободу, не навязывая визуальный язык. Но shadCN — «свободный»: одна команда берёт кнопку и добавляет Tailwind-утилиты для своей версии, другая делает свою. При нескольких продуктах и командах эта свобода нуждалась в ограничениях.
Решение — семантический слой под shadCN:
Архитектурно: команды используют только наши компоненты с нашими токенами. shadCN остаётся основой, но не точкой расширения — расширение происходит только через семантический слой.
Компоненты сначала собирались в коде, потом возвращались в Figma. Обратный обычному порядок, и намеренно: код — источник истины, Figma — представление.
Инструменты · кастомный Claude-скилл · точность 70–80% с первого запуска
Кастомный Claude-скилл, который принимает Figma-интерфейс на вход, маппит его на компоненты дизайн-системы, определяет состояния, строит таблицу соответствий и задаёт уточняющие вопросы при неопределённости. Используется разработчиками в продакшне.
Собран тогда, когда аналогичных инструментов не было. Пайплайн:
Точность с первого запуска — 70–80%. Иногда ошибается в состоянии, паддинге или раскладке. Итеративно улучшал инструкции — качество росло. Теперь разработчики используют скилл в своей работе.
Инструменты · PostHog на каждой странице · ноль переключений контекста
Кнопка «Stats», видная только авторизованным сотрудникам на каждой странице экосистемы — лендинг, статья, кейс, документация. Клик открывает выдвижную панель с данными PostHog, нарезанными по конкретной странице. Никакого переключения инструментов, никакого поиска страницы в глобальном списке.
Стандартный аналитический рабочий процесс: открыть отдельный инструмент → найти страницу в списке всех страниц → загрузить дашборд для неё. Для компании с сотнями статей, лендингов, кейсов и документов — это трение.
Исправление: каждая страница знает свою область аналитики. Авторизованные сотрудники видят маленькую кнопку «Stats». Клик — выдвигается панель с данными PostHog, отфильтрованными по этой странице: трафик, источники, поведение, конверсии, несколько срезов.
Культурный эффект — аналитика стала частью ежедневного просмотра. Люди смотрят данные о производительности, читая свои статьи или лендинги. Авторы видят свою аудиторию без усилий.
Бренд · совместно с со-дизайнером · логотипы, иллюстрации, маскоты, диаграммы
Полный редизайн бренда в паре с со-дизайнером — логотипы для всех продуктов, система иллюстраций, маскоты, стиль диаграмм, маркетинговые шаблоны. Визуальный язык теперь используется по всей экосистеме.
Создано совместно с со-дизайнером. Результаты:
Инструменты · обучен на бренд-маскоте · ~200 генераций · ежедневное использование
Внутренняя «кудос»-валюта для благодарностей между сотрудниками работает через Telegram-бот. Создал генератор изображений на нейронной сети, обученной на бренд-маскоте компании — сотрудники пишут суть своей благодарности, сеть генерирует картинку маскота в этом сценарии. Используется ежедневно.
Система кудосов уже работала через Telegram, но сообщения были только текстовыми. Добавление изображения к каждому кудосу сделало жест более запоминающимся и личным.
Генератор:
Доказательство · разработка за 1 неделю · ~100 участников · FHIR Camp 2025, октябрь
FHIR Camp — крупное собрание лидеров healthcare-IT, организованное Health Samurai в Португалии — Microsoft и другие лидеры отрасли принимают участие. В предыдущие годы вся организация (круглые столы, темы обсуждений, навигация) работала на бумаге. Создал адаптивное веб-приложение за неделю. ~100 человек использовали его. Первая крупная история вайб-кода в продакшне для компании.
Фичи, задеплоенные за неделю:
Это было первое крупное доказательство для C-level, что вайб-код может поставлять продакшн-работу. После FHIR Camp поддержка масштабирования AI-пайплайн работы расширилась.
Доказательство · вайб-код как инструмент по умолчанию · множество прототипов
С первого дня сложные задачи (больше одного экрана или простого флоу) собирались в коде на React. Рабочие демо вместо статичных мокапов. JSON Parser был одним из видимых артефактов — прототип UI-гипотезы для Aidbox, использованный для валидации направления и презентации команде.
Вайб-код стал способом по умолчанию для валидации гипотез. Статичные мокапы пропускают вопросы, которые проявляются только во взаимодействии — производительность, граничные случаи, реальный ввод с клавиатуры, поведение скролла. Рабочие прототипы их ловят.
В компании, где дизайнеры не в комнате каждый день, рабочие код-прототипы давали продуктовым разговорам реальные артефакты для реакции. «Посмотри на это» бьёт «представь это».
Продукт · совместно с со-дизайнером · продолжающаяся миграция на DS
Улучшение UX и UI Aidbox — флагманской FHIR-платформы компании — изначально созданной инженерами без дизайнера. Работа в паре с со-дизайнером; постепенная миграция на новую дизайн-систему продолжается.
Модель парной работы: мой со-дизайнер ведёт вайрфреймы и первичное UX-исследование; я подключаюсь на сессии, миграцию дизайн-системы и конкретные флоу. Несколько часов сфокусированной парной работы ежедневно.
Конкретные улучшения — TBD по сабкейсу, но ключевые направления: очистка информационной архитектуры, паттерны основной навигации, UX представлений с плотными данными, UX форм.
Продукт · MDM Box / Master Patient Index
Редизайн продукта Master Patient Index — работа с вероятностным матчингом пациентов, рабочими процессами слияния / разделения и аудит-трейлами. Сложная предметная область, плотные данные, реальные ограничения рабочего процесса.
MPI Box управляет согласованием идентификаторов пациентов между системами. Основные рабочие процессы:
Подход: переработать существующие флоу, прототипировать новые, валидировать с инженерной командой и клиентами, мигрировать на новую DS.
Смена процесса · дизайнер в продакшн-репозиториях · ревью-и-мерж
Начинал с традиционных дизайн-сессий — «команда реализует потом». Эволюционировал в модель, где я клонирую репозиторий команды, делаю ветку, рефакторю и чиню UI напрямую в коде. Команда делает ревью и мержит. Стало возможным благодаря AI-first культуре компании.
Это работает, потому что:
Каждый сабкейс глубже, чем помещается на странице. Готов пройтись по любому — процесс, решения, что сработало, что нет, что бы сделал иначе.
Написать→Пришёл вторым дизайнером в команду бородатых t-shape инженеров. Healthcare IT, FHIR-инфраструктура, плоская культура — без PM, без QA, все сеньоры. С первого дня собирал не макеты, а работающие штуки в коде: генераторы лендингов и презентаций, дизайн-систему с мостом Figma ↔ код, бренд, и сейчас — Replit для healthtech.
Меня нанимали как дизайнера, который умеет писать код — больше технаря, чем «творца». Творчество, как выяснилось, тоже пригодилось. Что собрал за это время:
Восемь параллельных линий работы. Многое шло внахлёст: дизайн-система, генераторы и продуктовые редизайны пересекаются в одних периодах. Нажми любую полоску — раскроется, что это было.
Health Samurai — достаточно интересное место. Там работают “взрослые” сеньор-инженеры, t-shape-специалисты: помимо своей предметной области каждый прокачивает и смежные. В компании нет тестировщиков и нет менеджеров. Есть люди, готовые драйвить: кто-то берёт проект, который ему хочется и который он чувствует, что вытащит, инициализирует его по интересам — и вокруг собирается команда из всех, кому это интересно.
За ~15 лет команда наделала кучу продуктов вокруг FHIR-инфраструктуры — Aidbox и медицинский стек. Всё это создавалось без дизайнера, тогда ещё и нейронок не было, которые могли бы хоть немного помочь. Поэтому многие продукты с точки зрения дизайна выглядели, мягко говоря, так себе.
До меня за полгода взяли ещё одного дизайнера: он провёл интервью с пользователями и командой, собрал CJM и ревью, начал накидывать вайрфреймы. На этом этапе пришёл я.
С самого начала я вайб-кожу прямо в работе: гипотезу собираю сразу в коде, а не рисую очередной макет с бесконечными циклами. Живой POC проще и воспринимать, и тестировать — покликать, прогнать по реальным состояниям и сразу понять, работает идея или нет.
На этапе гипотезы важнее всего скорость и гибкость, поэтому беру чистый HTML — нулевой порог входа, мгновенно крутишь layout, состояния, поведение. Тяжёлый стек вроде React этого лишает: зависимости, обвязка, лишние слои.
От обычного процесса с Figma я ушёл сознательно — он закольцован. Нарисовал, показал, переделал, через пару итераций отдал разработчикам — и тут же лезут edge-кейсы, которых в статике не предугадать. В коде они вскрываются сразу: Claude на них утыкается и фиксит, я вижу странное поведение — чиним на месте, а не на третьей итерации макета.
Первый же таск в команде это подтвердил. Нужен был нормальный JSON viewer для Aidbox — вместо рисования в Figma я написал ТЗ для Claude, за пару дней собрал рабочий прототип и в пятницу показал на демо готовую штуку, куда можно грузить свои JSON-ы. Команда увидела, что дизайн способен двигаться быстрее, — это задало тон всей дальнейшей работе.
Из этого вырос и общий pipeline по продуктам. Разработчики сами правят продукты с Claude, я забираю их наработки прямо в коде и прохожусь по всему вместе с ним. Сложные интерфейсы импортирую через Penpot — у него JSON проще фигмовского, любой сайт затаскивается легче.
Сейчас я использую только Anthropic. Пробовал Codex, Gemini, Kimi, Grok — мне нравится Claude, для меня это топ. Начинал с Cursor, потом перешёл на Claude Code и в последнее время живу в терминале — больше ничего не нужно.
Соотношение по инструментам сместилось: раньше было больше Figma, сейчас процентов 70 — Claude, 30 — Figma.
Сайт Health Samurai исторически собирали разные люди в разные периоды — зоопарк дизайнов, каждая страница отличалась от соседней. Один лендинг проходил долгий путь: созвоны с C-level, с инженерами, маркетинг собирает контент, сейлзы вносят правки, вёрстка во Webflow с техническими ограничениями фрилансера — и дизайн «коцался» процентов на 30. В среднем один лендинг тянулся почти 3 месяца.
Сверху прилетела размытая задача: лендинги надо как-то ускорить и автоматизировать — а как именно, никто не знал. Дальше всё придумал и собрал я: взял наш стиль, обогатил его (графические элементы, константы, вертикальные ритмы, типографика) и скормил Claude вместе с правилами.
Дальше выросла целая платформа: библиотека из ~40 блоков, визуальный редактор, DOM-aware чат Фиксик для правок прямо в браузере, перенос старых лендосов с Webflow, блог, документация, диаграммы и встроенная статистика. Весь сайт компании теперь работает на ней.
Подробности — в отдельном кейсе Платформа генерации лендингов.
Когда лендинг-генератор взлетел, мы применили тот же подход ко второй вечной боли — презентациям. Раньше каждый делал их в чём попало (PowerPoint, Google Slides, Figma), без общих стилей и переиспользования.
Сделал генератор на том же домене: две точки входа (скинь-и-получи / визуальный редактор), три режима генерации, интерактивные слайды (каждый может быть мини-приложением с модалками, степперами, каруселями), богатый шаринг с UTM и трекингом. 50+ презентаций, все спикеры перешли на формат, даже думаем оформить как отдельный продукт.
Подробности — в кейсе Генератор питчей и презентаций.
Aidbox — продукт, на базе которого разные команды достраивают модули. Дизайн-системы не было: набор утилитарных Tailwind-классов и компоненты отовсюду. Даже внутри одного продукта встречалось несколько разных селектов и кнопок. Всех это бесило, особенно CTO.
Я взял shadCN как основу и надстроил семантический слой: палитра primary/secondary/tertiary, готовая типографика, переписанные компоненты с нашими состояниями, компонент Icon. Всё это — в Storybook как документация. Написал скилл, который конвертирует shadCN-компоненты в наши токены.
Дальше — ранний опыт, когда Claude собирал дизайн-систему в Figma из кода, когда инструментарий для этого только зарождался. Настроил двунаправленную синхронизацию переменных и переносил интерфейсы страница за страницей через маппинг-матрицы код ↔ Figma (скилл Figma → код, точность 70–80%).
Подробности — в кейсе Дизайн-система shadCN и мост Figma ↔ код.
В паре с со-дизайнером сделали полный редизайн бренда: фирстиль, логотипы всей линейки продуктов, систему иллюстраций, маскот, стиль диаграмм (со скиллом для SVG в нашем стиле). Выстроили пайплайн управляемой нейрогенерации графики — Gemini/Flux + Figma Weavy для рендера, не «один раз случайно угадали стиль», а повторяемый процесс.
Отдельная штука — генератор кудосов: нейросеть, дообученная на бренд-маскоте, живёт в Telegram-боте для шеринга внутренней валюты за достижения между сотрудниками. ~200 генераций, ежедневное использование.
Подробности — в кейсе Бренд, иллюстрации и генератор кудосов.
FHIR Camp BOF стал первым случаем, когда вайб-код ушёл в настоящий продакшн с живыми пользователями.
FHIR Camp — большое собрание лидеров healthcare-IT, которое проводит Health Samurai. Для формата BOF (Birds of a Feather) я за неделю собрал мобильное приложение голосования за темы: участник с телефона предлагает тему или присоединяется к чужой, организаторы модерируют, а на экранах в зале в реальном времени видно, какие темы набирают людей. Отработало на реальном мероприятии — 3 дня, 6 сессий, 94 участника, 56 тем, 153 присоединения.
После FHIR Camp поддержка code-first-подхода в компании заметно расширилась — первый крупный продакшн-пример, что вайб-код реален, а не побочный проект.
Подробности — в кейсе FHIR Camp BOF — система голосования.
Мой основной проект сейчас — мы пишем «Replit для healthtech»: для больших медицинских компаний, госпиталей и врачей, которым не хватает каких-то приложений. Под капотом — Claude SDK и Codex SDK. Врач описывает, что ему нужно, скиллы собирают FHIR-нативное приложение, которое потом интегрируется в его чарт.
Приложение может быть сколь угодно сложным: пользователи, workflow-движок, «тайм-машина» — можно гонять его по времени, местам и пользователям, чтобы тестировать, как работает весь workflow. Я систематизирую два разных дизайн-слоя: обвязку вокруг агента и внутреннюю часть генерируемых приложений. Живу в той же main-ветке, что и разработчики, — дожидаюсь, когда выкатят сложную бизнес-логику, прокручиваю, вношу свои изменения, обсуждаем (20% Figma / 80% Claude).
Подробности — в кейсе Replit для healthtech.
Большие направления раскрываю отдельными кейсами — нажми, чтобы провалиться в детали: что делал, какие решения принимал и чего достиг.
Markdown-вход → брендированный лендинг за пару дней. Библиотека блоков, визуальный редактор, DOM-aware Claude-чат Fixik. Весь сайт компании работает на ней.
Два способа сборки, три режима, интерактивные слайды-приложения и богатый шаринг. Все спикеры компании перешли на формат.
Семантический слой поверх shadCN, Storybook, скилл маппинга Figma → код с точностью 70–80%. Код — источник истины, Figma — представление.
Фирстиль, логотипы линейки продуктов, иллюстрации, маскот, стиль диаграмм и нейрогенератор кудосов в Telegram-боте.
Агент, собирающий врачам FHIR-нативные приложения по запросу. Workflow-движок, тайм-машина, два дизайн-слоя. Мой основной проект сейчас.
Мобильное приложение для офлайн-конференции: предложи тему или присоединись, модерация и живой экран в зале. Собрал за неделю с тестами — отработало на реальном мероприятии.
Каждый из кейсов глубже, чем помещается на странице. Готов пройтись по любому — процесс, решения, что сработало, что нет, что сделал бы иначе.
Написать→Claude-пайплайн создания лендингов превратил трёхмесячный цикл сборки лендинга в 2–3 дня. Весь сайт компании теперь живёт на этой платформе, а правки прямо в браузере делает DOM-aware чат Fixik.
Весь сайт Health Samurai был сделан исторически, разными людьми, в разные годы. Каждая страница отличалась от предыдущей — настоящий зоопарк дизайнов. И маркетинг периодически спрашивал: «А что у нас с лендосами?»
Меня, как дизайнера, просили заняться и лендингами тоже. Но проблема была не в дизайне — проблема была в процессе.
Маркетинг собирал контент-ядро, потом подключались сейлзы со своими правками, потом C-level, потом снова сейлзы — и через неделю выяснялось, что кого-то опять что-то не устраивает. Только подготовка контента для главной занимала минимум месяц.
Вся инфраструктура сайта жила на Webflow. Готовый дизайн уходил к фрилансеру-инженеру, который резал его техническими ограничениями: «так Webflow не умеет, тут мы ограничены». Пиксель-перфект таял, начинались ревью и споры.
Месяц на контент, неделя-две на дизайн с итерациями, ещё хвост на Webflow-сборку и ругань за пиксель-перфект. Один лендинг — почти три месяца.
«Ребята, что за херня. Мы в 21 веке делаем лендинг по три месяца только потому, что не можем договориться, что менять. Мы все инженеры — давайте сделаем простой flow: любой человек собирает лендинг за один день.»
Так появилась задача. Размытая: цель — ускорить создание лендингов, а как — никто толком не знал. Все понимали одно: нужно как-то «обучить» Claude нашему стилю. Тут включился я.
Я взял наш живой лендинг и разобрал его на блоки — по одному. На каждом блоке тут же фиксировал его правила: какой контент в него ложится, какие у него состояния и варианты — фон, число колонок, с иконками или без, с CTA или без. Параллельно вытащил всю визуальную основу — цвета, константы, вертикальные ритмы, типографику — и обогатил её графическими элементами. Так из живой страницы собралась библиотека блоков с правилами и стейтами, по которой Claude, получая что угодно на вход, верстает готовый лендинг.
Дальше две недели я описывал блоки так, чтобы Claude понимал не вёрстку, а смысл: какого рода контент в какой блок ложится и как маппить их друг с другом.
Чтобы эта свобода не превратилась в хаос, скилл устроен предельно дисциплинированно — на трёх простых идеях и одном детерминированном протоколе.
Агент может использовать только 40 блоков из каталога и семантические токены темы. Свобода ограничена намеренно — это и есть гарантия консистентности.
При активации грузится только SKILL.md (~1.7k токенов). Детали блоков подтягиваются по требованию — читаются лишь те reference-файлы, что реально нужны.
Структуру страницы агент предлагает и ждёт подтверждения прежде чем писать код. Никакой генерации «вслепую» — пользователь утверждает каркас.
Детерминированный 7-шаговый протокол. Каждый шаг загружает ровно столько контекста, сколько нужно — и не больше.
Что за страница, для какой аудитории, какая цель конверсии. Если запрос размытый — уточняющие вопросы.
Загружает references/catalog.md — таблицу всех блоков. Это весь доступный словарь.
Маппит требования на 4–8 блоков через intent-таблицу (RU/EN). Проверяет анти-паттерны порядка.
Открывает reference-файлы лишь для выбранных категорий. Остальное не грузит.
экономия контекста: ~4.5-9k vs ~15k токенов Показывает нумерованный каркас страницы и ждёт подтверждения. Код пока не пишет.
checkpoint: нужно одобрение пользователя Создаёт src/pages/<name>.tsx: вызовы блоков с реальным контентом, импорты из blocks.
Правки меняют только затронутый блок — переставить, добавить, убрать. Страницу целиком не переписывает.
Первую версию я показал в пятницу на демо. Прямо при команде за 10 минут собрал лендинг, который выглядел сильно лучше, чем всё, что было раньше. Часть лендингов я взял из входных данных по тому самому первому лендосу, часть — просто скормил старые страницы, и скилл переделывал их в новый сайт.
Лютый фурор. Посыпались просьбы попробовать. Все начали собирать лендинги сами — и пошли первые хотелки.
Быстро выяснилось, что пользователи разные. Одним легко собрать лендинг текстом в голове, накидать MD-шку и отправить. А другим нужно видеть структуру — понимать, как контент ляжет на конкретный блок. Они, естественно, попросили визуальный редактор.
Людям не хватало визуальной обратной связи: какие блоки существуют, как именно раскладывается их контент, что получится на выходе.
Весь сайт работал на HTMX — ни React, ни какого-либо фреймворка. Я разбил блоки на отдельные HTMX-компоненты и собрал, опять же в паре с Claude, самописный Storybook.
Все компоненты выложены, можно покликать, переключить любое property, увидеть все состояния.
Глобальная кнопка edit прямо в компоненте: вставляешь нужный текст, меняешь иконки на месте.
Понравилась раскладка — фиксируешь её, отдаёшь MD-шку Claude, и он со своим скиллом собирает лендинг за 5–7 минут.
По итогу получился богатый генератор, который умел работать в двух режимах: быстрый — кинул что-то и получил лендинг, и осмысленный — собрал из блоков ровно то, что хочешь. Всё сразу под адаптив: на мобилках смотрелось хорошо без отдельной работы.
Рано или поздно упираешься в нехватку блока под новый тип контента. Я собирал фидбэк от команд, готовил новые блоки — иногда брал готовые из shadcn, через Claude менял стек на наш, трансформировал. Для повторяющейся работы всегда писался отдельный скилл, чтобы было быстрее всем.
Завёл страничку блоков, где видно, что добавилось: новый блок, новое свойство у существующего («теперь этот блок можно выбрать на сером фоне»). Все видели апдейты.
Самая «вау» фича пайплайна. На любой странице — лендинге или презентации — справа выезжает чат с пикером. Нажимаешь на пикер, выбираешь кусок DOM прямо на странице и пишешь, что с ним сделать. Claude получает запрос и вносит изменения прямо при тебе.
Назвали эту штуку Fixik. С ней правки стало делать гораздо проще и быстрее — не нужно идти в код, описывать словами, какой именно элемент чинить. Ткнул и сказал.
Параллельно с улучшениями для пользователей я переносил все старые лендинги на новые рельсы. Схема была такая: беру сайт на Webflow, парсю его через Gemini, вытаскиваю весь контент — где-то в HTML, где-то в MD, в зависимости от того, как парсилась страница. Закидываю это в Claude, прошу применить скиллы — и сайт собирается со старого на новый за 10–15 минут.
Идеально, конечно, не было: куча старых иллюстраций, кусков видео, скринкастов — это приходилось перерисовывать и перерабатывать руками. Но львиная доля, процентов до 80, делалась очень быстро и чётко.
За две недели перенёс около 20 лендингов, ещё неделю допиливал их до приличного вида. По статистике они давали поисковый трафик, но почти не приводили лидов — задача была превратить «зоопарк» в что-то аккуратное, и она была решена.
Генератор лендингов живёт и работает до сих пор. Им пользуется вся команда — все наши лендинги, все события, весь сайт Health Samurai делается на нём. Это не разовый проект, а боевая платформа: библиотека блоков растёт, на ней живёт весь сайт компании.
Но главное — почему весь процесс реально ускорился, а не просто «дизайн стал быстрее». Раньше лендинг застревал в согласованиях: контент собирали неделями, потом круг правок от сейлзов и C-level, и так по новой. Теперь любой в команде закидывает идею текстом и за пару часов получает не макет, а готовую живую страницу. С ней в разы проще идти к C-level: показываешь реальный продукт, а не описание на словах, и правки вносите тут же, вместе — прямо в браузере. Согласовывать стало нечего: все сразу видят результат. Горлышко из согласований и техпрослойки просто исчезло.
Для меня это главный вывод проекта: дизайнер, который умеет в код и в Claude, чинит не отдельный экран, а целый процесс.
И это не единственное решение, которое я затащил под ключ — в одного, от идеи до прода. Например, целое веб-приложение для офлайн-конференции:
FHIR Camp BOF — система голосования за темыAddressing concerns and boosting understanding of debt-settlement offers — empower informed decisions and increase online offer acceptance.
Americor is a debt-settlement company that negotiates users’ debts to lower them. After negotiating a settlement, it is presented to a user for acceptance.
Americor only collects its fees and gets revenue once an offer is accepted.
The majority of settlements were accepted through phone calls — high-cost, resource-heavy, and a clear lack of self-service.
Users were reluctant to accept settlements online — gaps in understanding, motivation, or communication across touchpoints, worsened by dreary, underwhelming patterns.
Drive online acceptance through clarity, urgency and a more appealing experience across multiple touchpoints.
A more appealing UI to excite and engage users — removing easily dismissed and disruptive patterns.
Ensuring clarity and minimizing misconceptions through rejection guidance — enabling informed decisions.
Creating urgency and reminders through fixed banners visible on every screen.
The original design was an MVP that failed to account for user pain points and used outdated UI/interaction patterns.
Nothing significant in the UI indicated a pending offer besides the modal — users could close it and forget.
Modal appeared every login and external notifications existed, but nothing significant let users re-open it once closed.
Ongoing surveys with 500+ users revealed common misconceptions — a clear lack of understanding only addressable via phone calls today:
«Can I get a better settlement? I thought each one saved 50%.»
«Will I have to make more deposits to accept this settlement?»
«Will this increase how long I’m in the Americor program for?»
«Do I have enough funds to accept this offer?»
Use a fixed banner to allow visibility and access from all screens — ideating on different banner UIs.
Each design had interchangeable pros and cons — implementing all three to test conversion and pick the winner.
Option C had the highest conversion. All concepts saw an increase in settlement acceptance, but Option C converted 15% better than A and 3% better than B.
Post-release research showed high but delayed conversion — creating urgency through banners for faster acceptance.
Users did not accept offers immediately — some waited almost 3 weeks before accepting.
Offers expire in 1 month. Americor policy: customer service calls them a week before expiry — leading to loss in online acceptance.
Created urgency through banner UI and encouraged earlier acceptance by surfacing date of expiry at 2 weeks.
Users still lacked understanding — calling in or simply not accepting offers. Addressed misconceptions in the form of an FAQ.
Internal experience walkthroughs allowed quick feedback and iteration — quick MVP release to assess impact on conversion.
Participants were inclined to close offers without looking at FAQ.
Mandating FAQ by guiding users through it to close offers.
Data showed FAQs had a positive impact, but were often unread. Less than 35% of users that closed offers and got to the FAQ page actually opened and read them.
Multiple FAQs rely on users self-diagnosing their own misconceptions — higher cognitive load and user effort.
FAQs feel transactional — fail to show empathy, validate concerns, or guide users during an emotional, critical decision.
A static FAQ is not actionable — users skip it during decision-making, limiting effectiveness in guiding behavior.
FAQ limited to known hesitancies — no option for users to voice their own concerns directly.
Reframing FAQ into a questionnaire that slows users down to reconsider the offer in a more direct way.
Users don’t wait or take time to read FAQ.
→ Users are forced to select a reason, ensuring reconsideration.
FAQs can feel avoidant of actual user issues — like they’re trying to convince.
→ Asking users their thoughts directly makes them feel heard.
Users have to self-diagnose concerns in FAQ — high effort.
→ Framing it as why they’re not accepting aids their thought process and pinpoints the appropriate answer.
"Other Reason" expands to a text field — constant data collection, ongoing research into settlement acceptance.
Limited-group testing showed significant conversion going back to offers from rejection flow — +20% from static FAQ.
Led to +4% offer acceptance overall.
Concept testing with users to identify pain points and understand decision drivers for accepting a settlement.
1:1 semi-structured video calls — users walk through the prototype.
15 users who have accepted and rejected at least one settlement.
Decision factors · gaps in understanding · visual cues that drive acceptance.
Offer didn’t prioritize info that mattered most: settlement amount vs. original amount.
“Settlement rate”, “term”, “start date” — confusing to users.
Difficult to scan settlements quickly — had to look over the offer multiple times.
Felt overeager on the savings — failed to take fees into account, creating trust issues.
Users care about original vs. settled amounts → reorganized information hierarchy to prioritize decision-driving data points.
Users don’t understand some information → improved copy and added tooltips for unclear info.
Redesigned legacy UI → reorganized layout to feel more professional, added creditor logos for easier identification.
Avoided a misleading, overly promotional impression by removing the blue savings block — it excluded fees and felt salesy.
The savings block came off as “scam-like”.
→ Removed it. Highlighted the comparison between original vs. settlement amount.
FAQs and questions were limited to users rejecting offers.
→ Bringing FAQs to users who may not want to reject, but are reluctant.
Addressed the 5% of Americor users who never registered on the app/online portal. Unregistered users had to rely on phone calls — a workshop with internal teams unblocked them.
Solution: a tokenized email flow allowed offer acceptance without needing to register online — covering every user, online or not.
Qualitative testing with users directly was particularly difficult here. Pain points were easy to identify and resolve early on, but didn’t necessarily translate to equal conversion. Especially problematic when post-release testing presented gaps in results.
When user testing pre-release becomes ineffective, post-release testing is necessary — especially when the main outcome is conversion.
A significant number of identified problems and inherent solutions were based on hypothesis and design expertise — this study established a sense of design confidence in me.
When testing isn’t providing constructive results, it becomes apparent to test out ideas — throw things at the wall and see what sticks, as long as the things you throw are based in expertise or knowledge.
Improving progress visibility, clarity, and predictability of the debt-settlement process to boost user confidence and engagement.
Americor negotiates with creditors to settle users’ debts for less than they owe. Negotiation takes time — settlements emerge unevenly, often months apart.
Engagement nosedives 2–3 months in. Onboarding cost is paid up front; revenue only lands after a settlement — early disengagement is expensive.
Users start the program without clear expectations. Long quiet stretches breed confusion, frustration, and doubt — they stop believing deposits are doing anything.
Boost confidence and engagement by making the settlement process visible, predictable, and clear.
Cut steps in the settlement process and rewrite how it’s communicated.
Replace static creditor status with a dynamic progress signal.
Surface what changed since last login — no need to dig through every account.
Set realistic timelines so users know when to expect a settlement.
Existing data showed early-program turnover; interviews aimed to dig into the why.
Users couldn’t connect individual statuses to the bigger settlement picture. “How does my debt go from coming to Americor to being paid off?”
Months of deposits with no visible outcomes — “I’ve been depositing for so long, but nothing has happened.”
“I don’t know if I’m moving in the right direction.” First three months left users questioning whether the program was a scam.
The process was depicted exactly as it ran internally — overengineered for users.
Condense and simplify the negotiation flow for users — the literal version creates more confusion than confidence.
Reframed the UI as a timeline — moving through statuses instead of being parked in one.
Inlined descriptions — visibility without an extra interaction step.
Better understanding of each status. Better sense of moving step-to-step. UI was preferred. But — early users misread settlement as the final step, and the wholistic picture stayed fuzzy.
Reframe “process” as a creditor lifecycle — enrollment → paid off. Combine pre and post settlement under one continuous journey, then keep the same UI in both phases for consistency.
Real progress was slow and uneven — and the UI wasn’t helping users feel any of it.
Decouple early progress from deposit speed — let aging and saving move in parallel so all creditors show motion regardless of which finishes first.
Walkthroughs with stakeholders surfaced something deeper — progress was happening, just invisibly. The overview page lacked any signal that something had changed since last login. With no signal, users had to remember their previous status to perceive any progress at all.
Four directions explored — each with different tradeoffs.
Recent activity won — most honest, most immediate, doesn’t depend on memory.
“New” badge for everything that changed since last login — pulls attention without requiring users to recall their previous state.
Push notifications for activity events — immediate gratification for users with notifications enabled.
”This makes it really clear that something is actually happening. Before, I wouldn’t even notice."
"This is exactly what I want. When will I be able to see this on my app?"
"I’d check this all the time to see what’s changing.”
The overview page focused on a static status — no signal of progress, no context for new settlement steps.
Show progress, not status — hint at forward motion instead of advertising stasis.
Tie the progress visual to current status — context for where the user is in the wider journey.
Refresh the legacy UI around what users care about — pre and post settlement amounts on top.
Concept testing showed users with active settlements care about payment progress, not status progression — separate views for pre and post settlement, but only on the overview screen.
Pre-settlement overview shows 4 steps, process detail shows 6 — accepted minor discrepancy, telegraphed via a checkpoint flag matching the icon. Most users either didn’t notice or weren’t confused.
Initial interviews surfaced an even earlier problem — the debt overview was tuned for post-settlement progress. For early users, that meant a frozen progress bar and rising remaining-debt numbers. Users felt off-track before they had a chance to be on it.
Split the progress overview by phase — distinct views before and after the user’s first settlement.
No progress bar in pre-settlement — kills the expectation of movement that won’t happen yet.
Reframe “settlements” as “creditors” so users aren’t reminded of what they don’t have yet.
Drop “remaining debt”, focus on enrolled debt — remove the interest-driven negative signal.
These calls strip progress signals — but the signals were static anyway. Compensated by the new recent-activity feature.
Users wrongly anchored to specific dates and got frustrated when reality didn’t match. A projected timeline sets a realistic, flexible expectation.
Timeline + percentage format raised cognitive load — users misinterpreted the data. Stripped to require zero interpretation.
Users read early settlement projections as guarantees — added plain-text framing to position the data as a projection, not a promise.
Showing detailed information without losing the user. Early-stage and late-stage users wanted different things at different fidelities — finding the balance was the bulk of the project.
“Tell users everything” sounds responsible until you ship it. Information overload causes the same — sometimes worse — confusion as too little. For consumer products, simplifying complex data, sometimes hiding it, is often the right call.
Users’ needs shift inside a single goal-oriented product. What works for a 30-day user actively misleads a 12-month user. Different mental models for the same screens.
Test with the target audience and with the users who’ll be impacted as a side effect. Both groups change the answer.
Превратил зоопарк разрозненных презентаций в единый генератор — три режима, две точки входа, интерактивные слайды-приложения и шаринг с трекингом.
Была в компании боль с презентациями. Меня как дизайнера постоянно дёргали: сделать питч, причесать чужой, помочь с презой очередного продукта. Презентаций было очень много, делали их все по-разному, и каждый раз это превращалось в ручную работу с нуля.
К тому моменту у нас уже был генератор лендингов — весь сайт компании работал на нём. И когда мы увидели, как круто эта машина собирает по любым входным данным лендинг-пейджи, мы задумались — а почему бы не решить тем же способом вторую вечную боль компании.
/presentations.
Презентаций и питчей делалось очень много. Каждая команда собирала их в своём инструменте — Google Slides, PowerPoint, Figma, какой-нибудь онлайн-сервис. Нулевое переиспользование, разный уровень качества, бесконечные просьбы к дизайнеру «помочь причесать».
Просили набор блоков, паттернов и лейаутов — чтобы собирать осмысленно. Но набор лейаутов в Figma или «где-то визуально» никому не помогал: придерживаться его сложно даже дизайнеру. В итоге всё равно кто во что горазд.
У нас уже есть машина, которая круто собирает по любым входным данным брендированные страницы. Презентация — та же история, но с одним переворотом: на лендинге контент ложится в готовые блоки, а в презентации всё строится наоборот — от контента. Инфраструктуру переиспользуем, а модель генерации меняем.
Здесь — главное отличие от генератора лендингов, и его легко упустить. Лендинг собирается из готовых блоков: есть каталог, контент раскладывается по нему, и за каталог мы почти не выходим. Презентация устроена наоборот — всё строится от контента.
Я не перетащил блоки. Я перевернул саму модель: блоки описаны прозой, мета-смыслом, а не конкретной вёрсткой — «заголовок, описательный текст, три карточки с иконкой сверху», а не зафиксированный layout. Это снимает с агента рамку готового каталога и даёт свободу спроектировать слайд под смысл: список, сравнение, before/after, цитата, шаги — сначала суть, потом форма под неё.
Сначала смысл слайда — список, сравнение, before/after, цитата, шаги — потом форма под него. Никакого «впихнуть текст в готовый блок».
Заголовки, буллеты, цитаты переносятся verbatim: тон, пунктуация, эм-дэши, эмодзи. Слишком длинно — скилл останавливается и спрашивает, а не режет молча.
Свобода в layout, но не в стиле: только семантические токены и проектная типографика. Один стиль иконок на слайд, в проза-списках — простые буллеты.
Инфраструктуру при этом переиспользовал по полной: тот же домен и движок, что и весь сайт, навигация, меню и адаптив из коробки. На вход — что угодно (MD, свободный текст, PDF, ссылка на Google Slides), на выходе — слайды на нашем домене.
Раз форма не зашита в каталог, у агента появляется регулятор свободы — три режима. Они строго opt-in: включаются только явным кодовым словом и никогда не выводятся из «сделай поинтереснее». Variety и Madness — взаимоисключающие.
Всегда активен. Бренд HS, семантические токены, проектная типографика. Опирается на проверенные паттерны — process row, big-number hero, red CTA — и десяток hero-фонов без повторов в одной деке. Рабочая лошадка: предсказуемо и на бренде.
По явному слову. Скилл изобретает форму из контента, а не из каталога — каждый слайд новый shape, проверенные паттерны под запретом. Стилевой конверт зафиксирован: только цвета и шрифты HS. В отчёте — карта layout’ов.
Кодовое слово «madness» и обязательный warning-гейт. Снят весь стилевой конверт: любые цвета, шрифты, layout, текст можно переписывать — editorial, постер, zine. Держится только техника: валидный SSR, fullscreen, «не кринж».
Default — рабочая лошадка на каждый день. Variety — когда стандартной формы мало и хочется свежий layout под контент. Madness показывает, насколько далеко движок может зайти, если снять рамки целиком.
Ещё на лендингах я понял: люди делятся на два типа. Одним проще собрать всё текстом в голове и в MD — кинул и получил. Другим нужно видеть структуру: «вот мой контент, как он ляжет на блок». Под обе аудитории сделал свой вход.
Кидаешь MD / текст / HTML / PDF / ссылку в Claude → «собери презентацию». Скилл сам разбивает на слайды, маппит на блоки, подбирает иконки и лейауты. Быстрый путь для тех, кому важен результат, а не процесс сборки.
Унаследован от лендинг-платформы: видимые блоки, режим редактирования, превью. Для тех, кто любит контроль — видишь, как контент раскладывается, фиксируешь удачный вариант в MD и отдаёшь Claude. Он собирает по ней готовую презентацию за 5–7 минут.
Со временем мы упёрлись в ограничение: у тебя один слайд, а данных много — и приходится плодить слайды. Но зачастую простым интерактивом этого можно избежать. Я ввёл в скилл параметр «интерактивный слайд»: указываешь Claude, какой кусок контента превратить в интерактив, и он сам предлагает, как лучше это обыграть.
Это открыло вообще новый слой. У тебя готовится не презентация, а презентационный мини-лендос, в котором каждый слайд может быть отдельным приложением. Ребята сейчас творят там такое, чего я в исходную идею не закладывал.
Когда презентация готова — деплоишь. Локально всё собирается на localhost, а отдельный skill deploy гоняет линтеры и проверочные тесты, чтобы «совсем какашка не залилась», и выкатывает. Сначала в пайплайне был разработчик перед деплоем, но Claude стал работать достаточно чётко — звено убрали, и деплой пошёл автоматически после дизайнерского ревью.
Fixik сделал правки настолько простыми и быстрыми, что презентации просто взлетели — каждый автор доводит свою до идеала за час, не дёргая дизайнера.
Презентации взлетели. Все наши спикеры перешли на этот формат, и каждый день кто-то делает новую. Каждый автор получил две вещи: супергибкую генерацию по любым входным данным и не менее гибкий шаринг с трекингом. Дизайнера перестали дёргать по мелочам — система делает это сама.
Сделано на генераторе. Каждый день добавляется новая — daily use по всей компании.
Default, Variety, Madness — один и тот же контент в трёх формах: от строгого бренда до off-brand хаоса. Плюс две точки входа: «кинул текст — получил» или визуальный редактор.
Каждый слайд может быть мини-приложением — потолок презентации поднялся до уровня веб-апа.
Получилась настолько крутая штука, что мы всерьёз подумываем оформить её отдельным продуктом. Пока это только мысли — но то, что внутренний инструмент дорос до уровня «а не продать ли это», само по себе результат.
Three-tier token architecture and a shared component spec across web, iOS and Android — instant theming via Figma modes, Code Connect to React.
Сюда нужна о том, что сначала дизайн система делалась как та, что поддерживает текущий дизайн, а потом когда пришёл задача редизайна, я решил что будем унифицировать внешний вид и поэтому львинная доля всех компонентов стала жить в common components, и только нативные жили в соответствующих библиотеках
Семантический слой поверх shadCN для Aidbox и продуктовых команд. Код — источник истины, Figma собрана из кода, а перенос интерфейсов идёт через маппинг-матрицы Claude.
Меня наняли в Health Samurai как дизайнера с замашками разработчика — человека, который пишет код и шарит в технике больше, чем рисует красивые картинки. Компания — это healthcare-IT с плоской культурой: взрослые t-shape инженеры, нет PM, нет QA, нет тестировщиков. Кто хочет драйвить продукт — берёт его и собирает команду по интересам. За 15 лет так наплодилось много приложений, и все они делались без дизайнера. Нейронок, которые могли бы хоть немного помочь, тогда ещё не было — поэтому куча продуктов с точки зрения дизайна выглядела, мягко говоря, так себе.
Первым же проектом мне дали Aidbox — флагманскую FHIR-платформу. За полгода до меня наняли второго дизайнера: он провёл интервью с пользователями и командой, собрал CJM, ревью, большой документ и начал накидывать вайрфреймы. На этом этапе пришёл я.
Aidbox — платформа, на базе которой разные команды достраивают свои модули. Каждая команда разворачивала Aidbox и рисовала свой дизайн, плюс-минус похожий на остальное. Отдельного дизайн-пакета, который можно было бы подключить, не существовало.
У Aidbox не было ни закономерности, ни дизайн-системы, ни констант — просто набор утилитарных Tailwind-классов и компоненты отовсюду: какие-то самописные, какие-то взятые непонятно где. Даже внутри одного Aidbox можно было встретить несколько разных селектов и кнопок.
Кнопки ставились то px-2, то px-4, бордеры и цвета чуть отличались от места к месту. Всех это бесило — особенно CTO. Задача была сформулирована так: сделать структурный дизайн-слой, отдельный пакет, который любая команда сможет подключить и собирать свой продукт на том же, на чём работает сам Aidbox.
Дальше — собственно дизайн-система. Я взял shadCN-компоненты и перестелил их под существующий дизайн Aidbox. shadCN был выбран как основа: он даёт компоненты и свободу, не навязывая визуальный язык. Но именно из-за этой свободы при нескольких командах всё расползалось — поэтому свобода нуждалась в ограничениях.
По пути я унифицировал все микрорасхождения: где-то цвета, где-то бордеры — все незначительно различающиеся элементы смержил к одному. Вместо утилитарных классов — готовые типографические стили. Вместо разбросанных вариантов — компоненты со всеми состояниями внутри: заходишь в кнопку, а там прописаны все её вариации.
Семантическая палитра — primary / secondary / tertiary / quaternary, с border, foreground и background у каждой роли. Никаких утилитарных цветовых классов.
Единые типографические стили вместо набора Tailwind-утилит. При конвертации компонента Claude подменял типографику заодно с цветами.
Отдельный компонент иконки, который умеет включать наборы Phosphor, Lucida и другие — единая точка работы с иконографикой.
Переписывал компоненты вместе с Claude — компонент за компонентом, забирал из shadCN, конвертировал. Сделал таблицу, несколько кастомных компонентов под узкие кейсы системы, добавил состояния, которых у shadCN нет из коробки, расширил инпуты и селекты. Где нужно — добавлял паддинги и иконки.
Архитектурно: команды используют только наши компоненты с нашими токенами. shadCN остаётся фундаментом, но не точкой расширения — расширяемся только через семантический слой.
Поскольку конвертация shadCN-компонента в наш стек повторялась снова и снова, я не делал её руками каждый раз. Для всех повторяющихся работ всегда писались скиллы — тогда они назывались иначе, просто MD-файлы в памяти Claude, но суть та же.
Я описал Claude, как мы переносим shadCN-компонент: меняем все утилитарные классы, касающиеся цветов, на нашу семантическую палитру; подменяем то, что лежит в styles/css; заодно правим типографику и нужные элементы — паддинги побольше, добавить иконки через компонент Icon.
Буквально через месяц на свет появилась первая версия дизайн-системы — то, что я представил команде в Storybook. Все базовые компоненты, таблица, кастомные компоненты под узкие кейсы.
Storybook я поднял с самого начала и складывал туда всё, что делаю — он же служил документацией. Можно покликать компонент, переключить состояния, посмотреть все property.
Презентовал систему команде Aidbox. Команда заревьюила — я всё-таки дизайнер — внесла корректировки, и мы вместе дописали правила для Claude, чтобы он с этого момента делал так, как указала разработка. Нюансы были небольшие. Я получил зелёный свет продолжать.
Параллельно второму дизайнеру нужно было пересобирать интерфейсы в Figma на новых компонентах — чтобы и там, и там было одинаково. Но к этому моменту дизайн-система в коде ушла далеко вперёд: мы с Claude уже наделали десятки компонентов с кучей состояний, а в Figma было всего около десятка.
Мы покумекали, и я предложил: подожди, давай попросим Claude. Это был мой первый опыт, когда Claude из кода собирал по крупичкам дизайн-систему прямо в Figma.
Сегодня это делается просто — появились скиллы, появилась хорошая Figma-MCP с кучей методов. Но тогда задача была совсем не тривиальной.
Тогда приходилось много контролировать. Если просто отдать Claude Figma-файл и код, он начинал всё парсить и выжирал кучу токенов — было больно. Поэтому я проверял разные способы: парсил Figma JSON-ом, разными сторонними MCP, пытался через API отдавать только нужные куски, чтобы Claude разбирался быстрее. Ковырял как мог, чтобы сэкономить.
После некоторых мытарств собрали достаточно много компонентов — со всеми состояниями. Дальше допиливали руками, постоянно проверяли синхронизацию: что-то добавлялось в коде, в дизайн-системе — мы синхронизировали это в Figma.
Порядок намеренно обратный обычному: код — источник истины, Figma — представление. Особенно здорово работала синхронизация переменных — токенов между собой и со стилями. Как всё было названо в коде с точки зрения стилей и логики — точно так же переезжало в Figma.
Новый или изменённый токен в коде уезжает в переменные Figma с той же семантикой и именами — без ручного переименования.
Проверка синхронизации шла постоянно: что добавилось в коде или в дизайн-системе, то подтягивалось в Figma. Имена и логика сходились с двух сторон.
Когда разработчики начали доверять системе, я перешёл к сборке и редизайну интерфейсов на новых компонентах. Развернул Aidbox у себя и страничку за страничкой переводил всё на компоненты — снова в паре с Claude.
Мы с Claude создавали маппинги — матрицы соответствий: что он видит на странице, что видит в Figma, какой компонент использовать для какого блока. Если непонятно — Claude задавал вопросы, я навигировал, он составлял для себя карту. Так за месяц мы пересобрали интерфейсы.
Идеально получалось не всегда: код делал процентов 80, иногда меньше, и много мелочёвки приходилось доделывать руками. Но система переехала на автоматизацию — новый дизайн стали получать быстро.
Дальше написал дизайн-скилл, который переносит уже из Figma. Второй дизайнер собирал часть интерфейсов с командой, и их нужно было переносить в код: что-то один в один, а что-то имело свежий дизайн, который надо аккуратно положить на наши компоненты.
Я отдаю Claude Figma и саму страницу, которую нужно перенести. Claude сканирует реестр компонентов, видит, что на что маппится, какие состояния использовать, строит таблицу соответствий и задаёт вопросы при неопределённости. Я отлаживал и улучшал скилл итерационно по ходу.
Точность с первого запуска — 70–80%. Иногда ошибается в состоянии, паддинге или раскладке. Я итеративно улучшал инструкции — качество росло. Теперь скилл используют сами разработчики в продакшне.
Дизайн-система на shadCN с семантическим слоем работает в продакшне у всех продуктовых команд. Отдельный пакет, который подключается и используется как источник истины.
Двунаправленный мост Figma ↔ код: компоненты собираются в коде, переезжают в Figma, переменные синхронизируются с сохранением семантики.
Скилл shadCN→токены и скилл Figma→код (70–80% с первого запуска) сняли повторяющуюся работу и теперь используются разработчиками.
Опыт на раннем этапе технологии: собирал дизайн-систему в Figma из кода через Claude, когда инструментарий для этого только зарождался. Ранние стадии требовали много ручного контроля и оптимизации токенов, но доказали главное: дизайн-систему можно вести как код, а Figma держать представлением, а не источником.
Платформа, где врач описывает недостающее приложение словами, а под капотом Claude SDK и Codex SDK собирают FHIR-native приложение, которое встраивается прямо в его чарт. Систематизирую дизайн-слой и для обвязки вокруг агента, и для самого генерируемого приложения.
Проект свежий, многое ещё в работе — поэтому ниже честно: часть деталей описана, а под визуал стоят плейсхолдеры под будущие материалы.
После того как генератор лендингов и генератор презентаций показали, что подход «опиши словами → агент соберёт» реально работает в продакшене, мы замахнулись на куда более серьёзную задачу.
Большим медицинским компаниям, госпиталям и отдельным врачам постоянно не хватает каких-то приложений. Врачу нужен инструмент под его конкретный сценарий — а заказывать полноценную разработку долго и дорого. Поэтому сейчас мы пишем то, что я для себя называю Replit для healthtech: врач описывает, что ему нужно, а на выходе получает работающее приложение, которое можно интегрировать прямо в его чарт.
Врачу не хватает приложения под его конкретный сценарий. Полноценная разработка — это месяцы, согласования и бюджет. Большинство таких приложений просто никогда не появляются.
Дать врачу способ описать нужное приложение словами и получить его FHIR-native, встроенным в его чарт — без классического цикла разработки.
Это не «генератор статичных страниц», как было с лендингами. Здесь под капотом полноценная агентная система.
Основной агентный слой — понимает запрос врача и оркеструет сборку приложения.
Второй SDK в связке — на нём держится часть генерации и работы с кодом.
Набор скиллов под капотом, которые превращают описание врача в FHIR-native приложение.
Сгенерированное приложение говорит на FHIR с самого начала и встраивается в чарт конкретного врача.
Врач описывает, что ему нужно — скиллы под капотом собирают непосредственно FHIR-native приложение, которое впоследствии интегрируется в ту или иную чарту того или иного врача.
Главное отличие от прежних проектов — приложение может быть сколь угодно сложным. Это не лендинг и не презентация, это полноценный продукт со своей жизнью.
У сгенерированного приложения могут быть собственные пользователи и роли — это полноценный продукт, а не одноразовый экран.
Внутри живёт движок рабочих процессов — приложение описывает и исполняет реальный клинический workflow.
Можно гонять приложение по времени, местам и пользователям — чтобы тестировать, как ведёт себя весь workflow в разных условиях.
«Тайм-машина» — для меня одна из самых интересных частей. Мы прокручиваем приложение по времени, по местам и по разным пользователям, чтобы увидеть, как отрабатывает весь workflow целиком, а не отдельный экран. Это меняет то, как я проектирую состояния: я думаю не про один кадр, а про всю траекторию процесса.
Самое содержательное, чем я занимаюсь как дизайнер на этом проекте, — это то, что здесь два принципиально разных дизайн-слоя, и их нельзя смешивать.
Слой вокруг агента — «карта / сад». Это интерфейс, через который врач общается с агентом, видит, что собирается, и управляет процессом.
Слой внутренней части самого сгенерированного приложения — то, что в итоге попадает врачу в чарт и чем пользуются конечные пользователи.
Поначалу я отвечал за дизайн и систематизировал дизайн-слой для карты / сада — для обвязки вокруг агента. А потом отдельно систематизировал дизайн-слой для внутренней части приложения. Это два разных слоя со своими правилами, и держать их раздельно — принципиально: обвязка должна быть про управление и наблюдаемость агента, а внутренняя часть — про чистый, предсказуемый продукт для врача.
Если смешать слои, получится каша: интерфейс управления агентом начнёт протекать в само приложение, которым пользуется врач. Поэтому я веду их как две отдельные дизайн-системы — у каждой свой язык, свои паттерны, свои состояния.
Это два разных слоя — обвязка вокруг агента и внутренняя часть приложения. Я систематизирую дизайн отдельно для каждого.
На этом проекте я окончательно живу в том же репозитории, что и инженеры. Никакого «дизайнер отдал макет — команда когда-нибудь реализует».
Остаётся для проработки мелочёвки и отдельных интерфейсных кусков, где нужен точный визуальный контроль.
Основная работа — прямо в коде, в одной main-ветке с разработчиками.
Я не жду релиза, чтобы потрогать дизайн. Дождался сложной бизнес-логики от инженеров — прокрутил, увидел шероховатости, тут же поправил в коде, обсудил с командой. Дизайн здесь — это коммиты в общей ветке, а не отдельные файлы.
Это мой основной проект на данный момент. Параллельно я продолжаю поддерживать всё, что сделал до этого — генераторы лендингов и презентаций, блог, дизайн-систему — добавляю формы, куски интерфейса, новые блоки. Но фокус сейчас здесь: мы пишем агента, который пишет врачам приложения.
Проект живой и продолжает развиваться — деталей и материалов будет становиться больше. Готов пройтись по любому слою: как устроена обвязка агента, как генерируются FHIR-native приложения, как работает тайм-машина и почему я веду два дизайн-слоя раздельно.
Написать→Редизайн фирстиля компании и линейки продуктов, система иллюстраций, маскот, стиль диаграмм и управляемый пайплайн нейрогенерации графики — вплоть до генератора кудосов на нейросети, дообученной на бренд-маскоте.
Health Samurai — это 15 лет жизни компании, где 80 инженеров строили продукты вообще без дизайнера. Нейронок, которые могли бы хоть немного помочь с графикой, тогда ещё не было. В итоге накопилась куча приложений, и с точки зрения дизайна они, мягко говоря, выглядели по-разному. У каждой команды — свой продукт, свой случайный визуал, никакой системы.
У компании нет узнаваемого лица. Продукты линейки выглядят так, будто их делали разные компании. Бренд не работает на доверие в healthcare, где доверие — это всё.
Каждая команда каждый раз изобретает графику с нуля — логотип модуля, иллюстрацию, диаграмму. Долго, непредсказуемо и всегда вразнобой.
Я зашёл в проект по бренду в паре с со-дизайнером. Мы переделали фирменный стиль компании целиком: палитра, типографика, графические элементы, маркетинговые шаблоны — и собрали систему, которую можно держать единой на всех поверхностях.
Отдельная большая часть — логотипы. Продуктов в линейке много, и каждому нужен был знак, который читается как часть одной семьи, но при этом узнаётся отдельно.
Новый корпоративный визуальный язык — палитра, типографика, графические константы.
Знаки для всей продуктовой линейки — единая система, узнаваемые члены семьи.
Маркетинговые заготовки — LinkedIn, мероприятия, загрузки.
Под лендинги, статьи блога и пустые состояния нужна была не пачка случайных картинок, а система — узнаваемые сцены, единые персонажи, общая стилистика линии и цвета. Это то, что превращает набор страниц в единое лицо компании.
Отдельно мы собрали фирменного персонажа — маскота. Это не просто украшение: персонаж даёт бренду характер, его легко поставить в любую сцену, и, как выяснится дальше, именно он стал ядром одной из самых живых внутренних фич компании.
У нас работают очень серьёзные эксперты по healthtech, и блог — важная часть компании: люди постоянно делятся решениями в статьях. А в статьях про FHIR-инфраструктуру без диаграмм никуда. Проблема была та же — каждый рисовал схемы как умел.
Я сделал единый стиль диаграмм и, что важнее, перевёл его в Claude-скилл, который собирает SVG-диаграммы в нашем фирменном стиле прямо из описания. Разработчик пишет статью, скилл подтягивает брендовую схему — и не надо звать дизайнера на каждую картинку. Туда же ушла стилизация диаграмм Mermaid.
Не «нарисовать красивые диаграммы», а зашить стиль в скилл — чтобы разработчики выкатывали брендовые SVG-схемы сами, быстро и единообразно.
Самое интересное — не отдельные картинки, а то, как мы их делаем. Логотипы, иллюстрации, маскота мы генерировали в разных нейронках: Gemini, ChatGPT, Flux — в чём только не пробовали. Поначалу это было лотереей: где-то «угадал», где-то нет.
В итоге мы выработали стиль и нашли повторяемый пайплайн. Финальный рендер всей графики я гоняю через Figma Weavy — это даёт контроль над результатом, а не разовое везение модели. Главное достижение тут — не отдельная красивая картинка, а управляемый процесс: я могу предсказуемо получать графику в нашем стиле.
Gemini · ChatGPT · Flux — подбор модели под задачу.
Выработанные правила и референсы, чтобы держать бренд.
Figma Weavy как точка финального контроля над графикой.
Фирменный стиль получился симпатичный и запоминающийся, а главное — графику теперь делает управляемый пайплайн, а не разовое «повезло с генерацией».
Внутри компании есть «кудосы» — внутренняя валюта благодарностей: сотрудники дарят их друг другу за достижения. Жила эта система в Telegram-боте, но сообщения были чисто текстовыми — жест получался сухим.
Раз у нас уже был маскот и пайплайн нейрогенерации, я собрал генератор изображений на нейросети, дообученной на бренд-персонаже. Сотрудник пишет, за что благодарит, — сеть генерит картинку маскота, разыгрывающего ровно этот сценарий, и бот прикладывает её к кудосу. Благодарность стала личной и запоминающейся.
Маскот, нарисованный для бренда, в итоге каждый день ходит по компании — как валюта благодарности.
Из зоопарка случайной графики получился единый язык: фирстиль, логотипы всей линейки продуктов, система иллюстраций, маскот и стиль диаграмм. Под капотом — не ручная отрисовка каждой картинки, а управляемый пайплайн нейрогенерации и скилл для брендовых SVG-диаграмм. А вершина истории — маскот, который из статичного образа превратился в живой продукт: генератор кудосов в Telegram-боте, которым пользуются каждый день.
Мобильное веб-приложение для офлайн-конференции FHIR Camp. Участники предлагают темы для обсуждений (Birds of a Feather) и собирают вокруг них группы, организаторы модерируют, а на экранах в зале в реальном времени видно, какие темы набирают людей. Собрал вайб-кодом за неделю — отработало на реальной конференции.
FHIR Camp — большое офлайн-собрание лидеров healthcare-IT, которое проводит Health Samurai. Один из форматов там — BOF (Birds of a Feather): неформальные обсуждения в группах по темам. Сложность в том, что за ограниченное число слотов нужно быстро понять, какие темы реально интересны залу и кто их поведёт — без бумажных списков и каши в чатах.
Я собрал под это мобильное веб-приложение: участник с телефона за десять секунд предлагает тему или присоединяется к чужой, организаторы модерируют, а на экранах в зале в реальном времени видно, какие темы набирают людей. Сделал вайб-кодом за неделю — и оно отработало на настоящей конференции: 3 дня, 6 сессий, 94 участника.
Конференцию ещё только планировали. На паре митингов я случайно услышал, как её собираются организовывать — и среди прочего, что BOF-сессии хотят вести по бумаге: каждый от руки записывается в тему на распечатанном листке.
Я спросил, зачем так — и мне объяснили суть формата: за ограниченное число слотов надо быстро понять, какие темы реально заходят залу и кто готов их вести. Звучало как ровно та задача, которую телефон в кармане решает лучше бумаги. Я предложил собрать под это приложение. Сказали: ну да, вроде здорово — но без энтузиазма, скорее в духе «когда-нибудь».
Я не стал ждать тикета и согласований. Никому ничего не сказав, просто пошёл и спаял приложение — а принёс его уже работающим.
Дальше — по частям: что есть в приложении и зачем. Три интерфейса под три аудитории — участник с телефона, организатор в админке и проектор в зале.
У каждого участника на бейдже свой QR-код. Сканируешь — и сразу внутри, без паролей и регистраций. За кодом закреплён конкретный человек, поэтому система знает, кто голосует, и считает честно — без накруток с нескольких телефонов.
Открываешь — и видишь все BOF-сессии, разложенные по дням конференции, а в каждой — топ-темы, которые набирают людей прямо сейчас. Отсюда проваливаешься в нужную сессию.
Главная механика: не просто «голос», а «веду или присоединяюсь» — так, как это и работает на офлайн-BOF.
Создаёшь свою тему и становишься её ведущим. Одна тема на сессию — фокус на том, что реально хочешь обсудить.
Подсаживаешься к чужой теме. Один выбор на сессию, можно передумать и переключиться на другую.
Вес темы — это сколько людей вокруг неё собралось плюс сам ведущий. По нему темы и ранжируются. В части сессий включается режим Lightning Talks — присоединяться нельзя, можно только вести короткое выступление; интерфейс это подсказывает.
Отдельный экран показывает твою активность: какие темы ты создал и в скольких сессиях из шести поучаствовал. В профиле — данные, собранные бейджи и выход.
У организаторов — своя панель на весь цикл мероприятия:
Настройка BOF-сессий (день, номер, окна голосования, режим) и генерация QR-кодов на участников для печати на бейджи.
Массовое добавление, список со статистикой, блокировка нарушителей, печать кодов.
Скрыть/перенести тему, а в аналитике — топ-темы, топ-участники и разбивка по дням и сессиям.
На проектор выводится полноэкранный режим: сетка тем, отсортированных по числу собравшихся, индикатор LIVE и обновление в реальном времени. Зал видит, как темы перестраиваются прямо по ходу голосования — это и драйвит участие.
Это первый случай, когда мой вайб-код ушёл не во внутреннюю песочницу, а в живой продакшн с реальными пользователями — и отработал. Полноценный продукт с тремя интерфейсами, продуманной механикой и геймификацией, собранный за неделю — причём с тестами, а не на скорую руку.
FHIR Camp стал поворотным: после него поддержка code-first-подхода в компании заметно расширилась — первый крупный продакшн-пример, что вайб-код реален, а не побочный проект.
A small custom-built sticker library — chibi-style samurai mascots used across landings, social, OG-images and conference swag. Built with an image-gen pipeline tuned to the brand mascot.
// test case — assembled live to validate the build-and-ship pipeline (Roman in Telegram → main agent in terminal → MDX → astro build → link back into the chat).
Health Samurai’s brand mascot is, well, a samurai. Marketing kept asking for more illustrations — for landing pages, social posts, OG-images, conference swag. Hand-drawing each one in Figma was slow. Buying stock didn’t fit the brand.
I set up a small image-gen pipeline tuned to the mascot: same posture, palette, sticker frame, soft cute energy, transparent-friendly background. One brief in, one finished asset out, ~an hour each.
▸ One brand prompt, locked. Same color palette, sticker outline, soft pastel background, mascot proportions. ▸ Three modes: chibi (cute, social), classic (landing-hero), meditation (about / culture pages). ▸ Output: 1024×1024 PNG with a baked white outline, ready to drop into any surface. ▸ Each asset took ~30-60 minutes from brief to final, vs days through a hand-drawn process.
▸ 40+ stickers in the library after a few weeks. ▸ Used across landings, social, OG-images, and FHIR Camp conference materials. ▸ Marketing can self-serve — they brief the prompt template themselves now.
This page was assembled live as a test of the portfolio’s case-build pipeline: a request comes from a visitor’s chat into Roman’s Telegram, gets handed off to the main agent in his terminal, MDX is written here, astro build ships it, the link drops back into the visitor’s chat. End-to-end validation.