Hi!
You're in a portfolio space. Here you can explore the last 3 years of work and chat with me and the agent.
use mouse and keys · ↑︎ ↓︎ ←︎ →︎
Большое дизайн приключение — как дизайнер-технарь жил в одной main-ветке с инженерами и строил генераторы, дизайн-систему и бренд через Claude Code.
Three platforms, multiple brands, one design language. Pre-IPO redesign of web and mobile apps, a four-layer token architecture built from scratch, and a code-first process where Figma and Claude finally talk to each other.
Three platforms, multiple brands, one design language. Pre-IPO redesign of web and mobile apps, a four-layer token architecture built from scratch, and a code-first process where Figma and Claude finally talk to each other.
In 1 year:
The key decision that changed the product — splitting the client experience into program phases. Previously, users saw the same UI at radically different stages of their journey; I designed separate interface states for each phase — and everything else grew from there.
Net Promoter Score. Business target — 70, achieved 78. +33 points from baseline after the redesign and phase system.
Customer Satisfaction on a 5-point scale. Target — 4.2, achieved 4.5. Less anxiety — more trust.
Rolled out the design system component by component together with dev teams. Covered more than half of all interfaces across three platforms.
Seven parallel workstreams. Bar color reflects intensity: primary focus, product work, background or short sprint. Much ran in parallel — which is why redesign, design system, and Community track overlap in the same periods.
Americor is a fintech company in the debt relief space. It helps people get out of debt through restructuring programs. Subsidiary brands in different states have their own visual identities — tied to differences in state legislation. The product: a web app (desktop + responsive) and mobile apps for iOS and Android.
My role — Lead Product Designer. Reported to the product manager (→ CPO). Worked with a junior designer on the team — I mentored them and gradually brought them into increasingly complex tasks.
The brief was threefold from day one: redesign the product line (company was preparing for IPO); raise NPS and CSAT; build a design system from scratch and actually embed it into the team’s workflow — not a file in Figma, but a working team tool.
There was no unified design system: reusable blocks were scattered across Figma files, and every new mockup meant assembling a screen from disconnected pieces by hand. Impossible to maintain or scale.
A previous freelance designer’s attempt at a brand identity had failed — 40–50% done in six months, then they left. Developers were spending weeks hunting for the “source of truth” for components.
Most importantly: no artifacts describing how the product worked existed — no user flows, no process maps, no documentation. Understanding lived in people’s heads.
With no documentation, I started with interviews — analysts, business stakeholders, developers. Reconstructing the product logic piece by piece.
To validate my understanding, I built a Product Flow Diagram — an end-to-end map with all flows, business-rule branches (Primary Flow for debts > $7500, Secondary for smaller), and user states at each step. This became the company’s first single source of truth.
In parallel — an audit of mockups and the live app builds (I installed test builds and walked through the flows myself). Leaning on common sense, product experience, and UX best practices. Some problems were obvious: missing information in places, confusing user paths, incorrect data display, no payment transparency. Issues accumulated fast.
Two-level structure with branching:
In parallel I reorganized the Figma structure: iterations, dev branches, clear navigation. Rolled out component by component to live apps together with dev teams — covered ~50–60% of interfaces.
About 3 months in, the business came back: the company is preparing for IPO, a full redesign is needed. A nontrivial situation — a system designed for the existing product had to start supporting a new one.
It started with the web app, then moved to mobile. The architecture (base → semantic branching into 2 products × 3 platforms) was built flexibly enough to update on the fly without breaking what was already done. This was one of those moments where the right initial architecture paid off many times over.
The key product insight — splitting the experience into program phases. Previously, clients at radically different stages saw the same UI, even though their context and needs had completely changed. I designed a phase system with distinct interface states for each phase.
The mid-level designer left before the redesign began. We worked as a pair — me and the junior designer. I led the redesign, controlled quality, and mentored.
Alongside the systems work, I tackled the graphics question — illustrations for empty states, onboarding, key screens; avatars for communications.
Started by generating dozens of variants in different styles through AI — needed to find a style that fit the brand. Over time a pipeline through a node editor emerged: ComfyUI, later Figma Weavy. This made it possible to generate illustrations consistently in a single style — not getting lucky once, but turning generation into a controlled process.
Before the redesign I needed to lean on real user problems, not guesses — so I built a couple of tools myself.
Facebook Community Analyzer. The company’s Facebook group held years of thousands of real customer messages — the most honest source of their pain. I vibe-coded an app: it exported every post and comment (~80,000 messages), ran each through a neural network tagging topic (UX, support, specific feature) and sentiment, and assembled it into a filterable UI. The result — a clear picture of what annoys people, what’s missing, which features they ask for. Those findings became the factual basis for the redesign decisions.
NSF Shortfall Simulator. A shortfall-forecasting feature for payment dates had tangled business logic. I built an interactive simulator to understand the mechanics myself, check edge cases, and design without guessing.
Both tools stayed in the team’s workflow — used beyond design.
In the final phase — one last major project, the Community section. The Facebook group was blocked, so we decided to build a Reddit/Facebook-style experience inside the app. Since this was a zero-to-one feature, I used it to try a new approach.
Built a basic scaffold in Figma, then asked Claude to assemble a React app with Storybook components in all states. Development continued in code: product hypotheses were wired directly into the prototype — a gear icon let you switch variants and compare them side by side.
When a solution was ready, I asked Claude to generate Figma components for developers and QA (they worked in their own stack) — in our tokens, typefaces, and design system. Handoff happened with zero drift.
The process flipped: instead of “design → handoff → development” it became “prototype in code → validate on a working product → hand off finished components”.
Drag the divider — left is before, right is after.
Separate product stories I’m expanding into their own cases.
How a user accepts a debt restructuring offer. +175% online acceptance, 300k users.
Process transparency, status dynamics, realistic expectations. +72% NPS, +15% retention.
Three-tier tokens, shared component spec for web / iOS / Android, Code Connect → React.
A designer with a developer mindset working alongside seasoned t-shaped engineers. Healthcare IT, FHIR infrastructure. Flat culture — everyone senior, no PM/QA. Joined as the second designer. AI-first from day one — complex tasks shipped straight to React demos.
Click any card to jump to the full sub-case — design system, content infrastructure, product redesigns, brand work, and proof artifacts.
Multi-layer DS on shadCN, semantic tokens, bidirectional sync.
Custom Claude skill, 70–80% accuracy on first run, iteratively improving.
From a 3-month chain to MD-in / brand-styled-out in 2–3 days. Block library, DOM-aware Claude chat “Fixik”, blog and docs — all on one engine.
Same engine as the landing platform, applied to presentations. Three modes, ~1 h cycle.
PostHog on every page. Zero context switching.
Collaborative UI redesign of the flagship FHIR platform.
Master Patient Index — matching, merging, audit.
Designer in production repositories, branch-and-merge model.
Logos, illustrations, mascots, diagram style.
Image generation trained on the mascot, ~200 generations, daily use.
Healthcare-IT conference in Portugal. Shipped a responsive web app in one week — voting, schedule, subscriptions. The proof that convinced C-level.
Working prototypes instead of static mockups, from day one.
Eight parallel work streams. Bar color reflects intensity: primary focus, product work, background activity, or short engagement.
System · 2024 Q3 — ongoing · 4 layers, multi-product
A multi-layer design system on top of shadCN with semantic tokens, custom states, and bidirectional Figma ↔ code sync. Used in production by all product teams.
shadCN was chosen as the foundation — it provides components and freedom without imposing a visual language. But shadCN is “loose”: one team takes a button and adds Tailwind utilities for their version, another does their own. Across multiple products and teams, that freedom needed constraints.
The solution: a semantic layer on top of shadCN:
Architecturally: teams use only our components with our tokens. shadCN stays as the foundation but not the extension point — extension happens only through the semantic layer.
Components were built in code first, then brought back into Figma. The reverse of the usual order, and intentional: code is the source of truth, Figma is the representation.
Tooling · custom Claude skill · 70–80% accuracy on first run
A custom Claude skill that takes a Figma interface as input, maps it to design system components, identifies states, builds a mapping table, and asks clarifying questions when uncertain. Used by developers in production.
Built before any comparable tooling existed. The pipeline:
First-run accuracy: 70–80%. Occasionally gets a state, padding, or layout wrong. Iteratively improved the instructions — quality increased. Developers now use the skill in their own work.
Process shift · 3 months → 2–3 days · 25+ live landings
When I joined, the other designer and I were periodically asked to help with new landing pages. We’d design new ones while old ones stayed looking old. Building a single landing meant: a call with C-level to find out what they wanted. Then a call with engineers to understand how they’d build it. Getting everyone in one meeting almost never happened. Requirements shifted mid-process. After all the calls, marketing got involved to gather content. After content was approved, the designed landing went into Webflow assembly with all that entails (technical constraints, design review…). On average, one landing took around 2–3 months.
The CTO said: “Guys, this is insane. Let’s automate it.” That’s how I started building an automatic landing generation system within the new brand style.
After v1, people complained: “We lack visual feedback, we don’t understand what blocks exist, we can’t see how the content lays out.”
So I added a separate page with all blocks visible, an edit mode, a “basket” for blocks, JSON/MD export → import into Claude. For those who want visual control instead of “drop an MD and get something.”
The entire company website now runs on this system. Presented at conferences.
Process shift · ~1 week → ~1 hour · 30+ generated presentations
Same approach as the landing platform, applied to presentations. Two entry points (drop-and-get + visual editor), three generation modes (Normal / Variety / Madness). Around 30 generated presentations, team loves it.
The problem: lots of pitches, lots of presentations. Everyone made them in different tools (Google Slides, Figma, PowerPoint, online services), in different styles. No system, no shared style constants, no reuse.
Development took about a month.
Drop MD / text / HTML / PDF into Claude → “make a presentation using the Presentation Builder Skill”. Three modes:
Slides + modules + JSON structure → Claude renders a managed solution. For those who like control: ready-made page patterns, various elements (text, icons, text-with-icon, cards, dividers), per-slide data import.
The structure is flexible: each module is a JSON node with fields, the visual representation lets you edit content right there or download the generated JSON, edit in your own editor, and return it to Claude.
Tooling · PostHog on every page · zero context switching
A “Stats” button — visible only to authenticated employees on every page in the ecosystem: landing, article, case study, documentation. Click opens a slide-out panel with PostHog data scoped to that specific page. No tool switching, no searching for the page in a global list.
The standard analytics workflow: open a separate tool → find the page in a list of all pages → load its dashboard. For a company with hundreds of articles, landings, case studies, and docs — that’s friction.
The fix: every page knows its own analytics scope. Authenticated employees see a small “Stats” button. Click — a panel slides out with PostHog data filtered to that page: traffic, sources, behavior, conversions, several breakdowns.
Cultural effect — analytics became part of daily browsing. People check performance data while reading their own articles or landings. Authors see their audience without effort.
Product · paired with co-designer · ongoing DS migration
Improving the UX and UI of Aidbox — the company’s flagship FHIR platform — originally built by engineers without a designer. Paired work with a co-designer; gradual migration to the new design system is ongoing.
Paired work model: my co-designer leads wireframes and initial UX research; I join for sessions, design system migration, and specific flows. Several hours of focused paired work daily.
Specific improvements — TBD per sub-case, but key directions: information architecture cleanup, primary navigation patterns, dense-data view UX, form UX.
Product · MDM Box / Master Patient Index
Redesign of the Master Patient Index product — working with probabilistic patient matching, merge/split workflows, and audit trails. Complex domain, dense data, real workflow constraints.
MPI Box manages patient identifier reconciliation across systems. Core workflows:
Approach: redesign existing flows, prototype new ones, validate with the engineering team and clients, migrate to the new DS.
Process shift · designer in production repositories · review-and-merge
Started with traditional design sessions — “team implements later.” Evolved into a model where I clone the team’s repository, branch, and refactor UI directly in code. Team reviews and merges. Made possible by the company’s AI-first culture.
This works because:
Brand · paired with co-designer · logos, illustrations, mascots, diagrams
Full brand redesign paired with a co-designer — logos for all products, an illustration system, mascots, diagram style, marketing templates. The visual language is now used across the entire ecosystem.
Created together with the co-designer. Deliverables:
Tooling · trained on the brand mascot · ~200 generations · daily use
The internal kudos currency for peer appreciation runs through a Telegram bot. Built an image generator on a neural network trained on the company’s brand mascot — employees describe what they’re thanking someone for, the network generates an image of the mascot acting out that scenario. Used daily.
The kudos system already worked via Telegram, but messages were text-only. Adding an image to each kudos made the gesture more memorable and personal.
The generator:
Evidence · built in 1 week · ~100 attendees · FHIR Camp 2025, October
FHIR Camp is a major healthcare-IT leadership gathering organized by Health Samurai in Portugal — Microsoft and other industry leaders attend. In previous years, all organization (roundtables, discussion topics, navigation) ran on paper. Built a responsive web app in one week. ~100 people used it. The company’s first major vibe-code story in production.
Features shipped in one week:
This was the first major proof for C-level that vibe-code can deliver production work. After FHIR Camp, support for scaling the AI pipeline work expanded.
Evidence · vibe-code as default tool · multiple prototypes
From day one, complex tasks (more than one screen or a simple flow) were built in code in React. Working demos instead of static mockups. The JSON Parser was one of the visible artifacts — a prototype of a UI hypothesis for Aidbox, used to validate the direction and present it to the team.
Vibe-code became the default method for hypothesis validation. Static mockups skip questions that only surface in interaction — performance, edge cases, real keyboard input, scroll behavior. Working prototypes catch them.
In a company where designers aren’t in the room every day, working code prototypes gave product conversations real artifacts to react to. “Look at this” beats “imagine this.”
Every sub-case goes deeper than fits on a page. Happy to walk through any of them — process, decisions, what worked, what didn’t, what I’d do differently.
Get in touch→Пришёл вторым дизайнером в команду бородатых 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.