Storybook: почему инструмент разработчиков стал незаменим для дизайнеров
Основной чат
Чат для вайбкодеров: новости, гайды, поиск исполнителей, маркетплейс и разбор реальных кейсов.
Storybook создавался для разработчиков — среда для изолированной разработки компонентов без запуска всего приложения. Дизайнеры которые начали его использовать говорят одно: «не понимаю как работал без него».
Это происходит потому что Storybook решает проблемы которые Figma не решает. Не вместо Figma — рядом с ней.
Четыре проблемы которые решает Storybook
Проблема 1: Figma показывает как должно быть, а не как есть
Нарисовал Button. Разработчик реализовал. Через три месяца кто-то поправил padding «чтобы лучше смотрелось». Figma по-прежнему показывает исходный дизайн.
Storybook показывает реальные компоненты из продакшена — в браузере, живые. Button в Storybook — это тот Button который увидит пользователь. Расхождение между Figma и Storybook — это расхождение между дизайном и реальностью. Лучше обнаружить здесь, не когда клиент спросил «почему оно выглядит иначе».
Проблема 2: В Figma не видно реального поведения
В Figma — три нарисованных состояния. В Storybook — открываешь Button и нажимаешь. Видишь реальный transition при нажатии, реальную анимацию loading-спиннера, реальное поведение dropdown когда не хватает места внизу экрана.
В Controls меняешь loading: true — видишь тот спиннер который увидит пользователь. Это не прототип — это код который идёт в продакшен.
Проблема 3: Разный язык дизайна и кода
Figma: «highlighted вариант». Код: variant="featured". Это одно и то же — но дизайнер и разработчик говорят о нём по-разному.
Storybook показывает все варианты с их реальными именами. Открываешь ProductCard — видишь default, featured, compact. Понимаешь что разработчик назвал featured то что ты называл highlighted. Лучше выяснить до хендоффа.
Проблема 4: Расхождения которые накапливаются незаметно
Со временем Figma и код расходятся — это неизбежно. Обновили компонент в коде, забыли обновить в Figma. Или наоборот. Без регулярного сравнения это обнаруживается на продакшене или на показе клиенту.
Как использовать без написания кода
Для Storybook не нужно уметь писать stories или знать React. Нужно уметь открыть URL и читать.
Найди URL. Спроси разработчика. Обычно есть задеплоенная версия по внутренней ссылке — не нужно запускать проект локально. Добавь в закладки рядом с Figma.
Найди компонент в дереве. Левая панель — дерево компонентов. Если компонента который ты нарисовал там нет — либо не реализован, либо реализован под другим именем. Уточни до хендоффа, не после.
Проверь все состояния. Каждая story — одно состояние. Button/Default, Button/Loading, Button/Disabled — разные stories. Если состояния которое нарисовал нет — разработчик его не сделал.
Поиграй с Controls. Нижняя панель — живые пропсы. Меняешь variant: "danger" — кнопка меняется в браузере прямо сейчас. Проверяешь все комбинации без написания кода.
Сравни с Figma рядом. Открой Storybook и Figma на одном экране. Border-radius, padding, цвет, типографика — должны совпадать. Расхождения — разговор с разработчиком до релиза.
Как убедить команду писать stories
Дизайнер не пишет stories — но может обосновать почему разработчикам это нужно.
Аргумент для разработчика: компонент разработанный через stories лучше спроектирован архитектурно. Когда нужно показать компонент в изоляции — думаешь о его API. Это снижает связность и упрощает переиспользование.
Аргумент для менеджера: Storybook — документация которая не устаревает (если обновляется вместе с кодом). Экономит время новых членов команды — не нужно спрашивать «как использовать этот компонент?».
Аргумент про индустрию: Shopify Polaris, Atlassian Design System, GitHub Primer, IBM Carbon — все публикуют Storybook. Это не дополнительная нагрузка, это индустриальный стандарт.
Практический договор: добавить в Definition of Done: «Новый компонент задокументирован в Storybook — Default + все состояния из Figma». Без этого PR не мёрджится.
Хендофф со Storybook: улучшенный процесс
До начала разработки. Открываешь Storybook и проверяешь: все ли компоненты нового экрана уже реализованы? Если нет — это отдельная задача. Лучше знать при планировании спринта, не когда разработчик уже начал.
При хендоффе. Называешь Storybook-компоненты по имени: «Шапка — Header/Default, карточки — ProductCard/Default, кнопка — Button/Primary». Разработчик сразу знает что брать без вопросов.
После реализации. Новый компонент появился в Storybook со всеми состояниями? Это часть Definition of Done — не «желательно», а обязательно.
Storybook MCP в 2026
Storybook MCP Server (early access 2026): Storybook генерирует component manifest — JSON со всеми метаданными всех компонентов. AI-агент читает manifest и знает реальную систему в продакшене.
Autonomous correction loop: агент создаёт компонент → запускает interaction tests → видит что не прошло → исправляет. Разработчик вмешивается когда тесты зелёные.
Дашборд расхождений через MCP:
Через Storybook MCP: список компонентов с их stories.
Через Figma MCP: список компонентов из библиотеки.
Таблица:
| Компонент | Figma | Storybook | Stories полные? |
|-----------------|-------|-----------|------------------------|
| Button/Primary | ✅ | ✅ | ✅ Default/Loading/Disabled|
| Card/Featured | ✅ | ❌ | — |
Для "нет в Storybook": приоритет по частоте использования в Figma.
Для "неполные stories": какие состояния из Figma не покрыты?Что делать сегодня
Практический первый шаг который занимает 20 минут: попроси разработчика дать ссылку на Storybook и открой его. Просто посмотри что там есть — как называются компоненты, как выглядят состояния, есть ли расхождения с Figma.
После этого: перед следующим хендоффом открой Storybook рядом с Figma. Проверь что компоненты которые хочешь использовать там есть. Если есть — назови их в хендоффе по Storybook-именам.
Это не требует дополнительных инструментов или изменений процессов. Просто начни смотреть на Storybook как на часть своего воркфлоу.
Промпт для аудита через MCP
Через Storybook MCP: список всех компонентов и их stories.
Через Figma MCP: список компонентов из библиотеки [файл].
Создай сравнительную таблицу:
| Компонент | В Figma | В Storybook | Stories покрывают все состояния? |
|-----------------|---------|-------------|--------------------------------|
Для каждого компонента в Storybook: перечисли stories
и сравни со состояниями в Figma (Default/Hover/Disabled/Loading/Error).
Результат: что нужно добавить в Storybook (приоритет 1–3)
и что нужно добавить в Figma.Storybook и дизайн-токены: как они работают вместе
Storybook особенно мощен когда работает в паре с токенами синхронизированными через Tokens Studio.
Когда дизайнер меняет токен в Figma Variables → Tokens Studio пушит обновление в git → CI обновляет CSS Custom Properties → Storybook при следующем запуске показывает компоненты с новым значением. Дизайнер может сразу увидеть как изменение токена выглядит на всех компонентах — без пересборки приложения.
Это делает Storybook живым инструментом для проверки дизайн-решений, а не только документацией «как было».
История которая объясняет ценность лучше абстрактных доводов
Команда добавляла тёмную тему. Дизайнер потратил два дня на переключение всех компонентов в Figma. Разработчик взял Figma как основу и начал реализацию.
На ревью обнаружилось что 6 компонентов в тёмной теме выглядят неправильно — у них были захардкоженные значения цвета которые в Figma незаметны, а в Storybook с реальным CSS бросаются в глаза.
Пришлось переделывать. Если бы Storybook смотрели с самого начала — проблема была бы очевидна на первый день. Вместо этого — два дня потерянных на обнаружение проблемы которая уже была видна в другом инструменте.
После этого команда ввела правило: каждый новый компонент проверяется в Storybook до хендоффа. Не «желательно» — обязательно. Это сэкономило следующий инцидент.
☐ URL Storybook сохранён в закладках
☐ Перед хендоффом: все компоненты экрана есть в Storybook?
☐ При хендоффе: называю компоненты по Storybook-именам
☐ Сравниваю Default state в Storybook и Figma для ключевых компонентов
☐ Definition of Done включает stories для новых компонентов
☐ Ежемесячный аудит: дашборд расхождений Figma vs Storybook
☐ Если есть MCP: тест что AI использует компоненты из Storybook
