Спецификация — это новый каркас: проектирование на основе спецификаций в 2026 году

Макет — это балласт. Спецификация — это артефакт, который теперь используется для выпуска продукта.

В течение двух десятилетий макет находился в центре продуктового дизайна. Блоки, стрелки, низкокачественные прямоугольники, текст-заполнитель. Это был первый результат, инструмент выравнивания, то, что вы перетаскивали в файл Figma, прежде чем кто-либо прикасался к реальным пикселям.

В 2026 году этот артефакт незаметно был понижен в статусе. Генераторы кода на основе ИИ лучше считывают структурированные намерения, чем макеты, а менеджеры проектов направляют спецификации прямо в Cursor.

Инженеры выпускают функции из файлов spec.md без видимой связи с Figma. Макет теперь является последним этапом, если он вообще появляется.

Это не история об инструментах. Это сдвиг в мастерстве. Дизайнеры, которые рассматривают спецификацию как основной артефакт, выпускают продукты быстрее, передают их дальше более аккуратно и в итоге владеют большей частью поверхности, чем когда-либо с файлами пикселей. Дизайнеры, которые продолжают перемещать прямоугольники по холсту Figma, наблюдают, как их влияние испаряется в реальном времени.

Почему каркасы утратили свою актуальность

Каркас заслужил свое место в мире, где для создания экрана требовалось четыре человека, три передачи проекта и спринт. Нужен был низкодетализированный артефакт, потому что высокодетализированный стоил дорого. Нужен был слой преобразования, потому что инженеры и менеджеры проектов не могли, глядя на файл Figma, прийти к согласию относительно его смысла.

Этот мир ушел в прошлое. Cursor, Claude Code, v0, Bolt и следующие четыре инструмента после них могут взять четкое письменное описание функции и создать рабочую поверхность за считанные минуты. Они не могут прочитать ваш каркас. Они могут прочитать вашу спецификацию.

Узкое место переместилось. Пиксели теперь дешевы, а намерение — дефицитный ресурс.

Каркас кодирует макет. Спецификация описывает намерения, поведение, граничные случаи и условия, при которых функция корректна. Угадайте, что именно нужно инструменту генерации кода.

Также на уровне команды происходит более тихий сдвиг. Размывание границ между дизайнером и менеджером проекта, рост роли инженера-конструктора, исчезновение выделенного исследователя в большинстве продуктовых команд. Все это указывает в одном направлении. Артефакт, который хорошо работает на стыке этих размытых ролей, — это текст, а не блоки.

Вайрфреймы также были, по сути, инструментом планирования для людей, которые еще не могли видеть объект. Инструменты искусственного интеллекта могут за считанные секунды создать приемлемую рабочую поверхность на основе описания. Цена «давайте посмотрим» рухнула.

Когда вы можете создать реальную интерактивную поверхность за меньшее время, чем потребовалось для создания низкокачественной версии, низкокачественная версия перестает быть полезной. Вы либо сразу переходите к спецификации, либо сразу к прототипу, полностью пропуская прямоугольники.

Макет объясняет что. Спецификация объясняет почему.

Макет отвечает на один вопрос: как это должно выглядеть? Спецификация отвечает на более сложные. Для чего это нужно и для кого?

Что произойдет, если данные окажутся пустыми? Что произойдет, если сеть даст сбой? Что вообще означает успех в данном случае?

Хороший дизайнер в 2026 году сначала пишет спецификацию, а визуальная составляющая вытекает из нее. Не наоборот. Визуальная составляющая является следствием принятия решения, а само решение заложено в спецификации.

Это не новая мудрость. Опытные дизайнеры годами писали структурированные обоснования. Новым является то, что спецификация теперь является активом, который инструменты ИИ используют напрямую, а это значит, что качество написания вашей спецификации теперь играет решающую роль.

Расплывчатая спецификация приводит к расплывчатому результату, и цена этой расплывчатости больше не в растерянном инженере. Это наполовину созданная функция, от которой приходится отказываться.

Анатомия отличной спецификации дизайна

Спецификации, которые выдерживают проверку как инженерами, так и ИИ, имеют стабильную форму. После анализа сотен подобных спецификаций от команд разработчиков, выпускающих продукты в кратчайшие сроки, закономерность остается неизменной.

Рабочая спецификация дизайна включает семь разделов в следующем порядке:

1. Намерение. Один абзац, объясняющий, почему это существует, какую проблему пользователя это решает и какие изменения в продукте происходят после его выпуска.

2. Область применения. Что включено, а что явно исключено, при этом список исключений выполняет больше работы, чем список включений.

3. Поведение. Пошаговое описание того, что происходит при взаимодействии пользователя с функцией, включая триггеры, состояния, переходы и результаты.

4. Критические случаи. Непривлекательный список, который никто не хочет писать, но который нужен всем: пустое состояние, состояние ошибки, состояние загрузки, отказ в доступе, отключение сети, превышение лимита запросов, устаревшие данные.

5. Критерии успеха. Как мы понимаем, что это работает, измеримые, а не субъективные показатели, «процент сохранений выше 40%», а не «пользователи довольны результатами сохранений».

6. Оценка. Что мы будем тестировать автоматически, чтобы подтвердить соответствие реализации замыслу, и именно здесь рабочие процессы ИИ действительно отличаются от старых методов проектирования.

7. Доступность и текст. Требования WCAG, пути клавиатуры, поведение программ чтения с экрана и каждая строка, которую видит пользователь, в соответствии с концепцией продукта.

Это рабочая основа. В некоторых спецификациях добавляется раздел «Ссылки», содержащий ссылки на токены системы проектирования, аналогичные функции или прецеденты. В других добавляется раздел «Риски», указывающий на моменты, на которые команда должна обратить внимание во время разработки. Семь пунктов выше являются обязательными.

Обратите внимание на то, чего там нет. Нет скриншота, нет схемы компоновки, нет схемы потока «блок-стрелка». Спецификация описывает функцию как набор ограничений и поведения, а не как картинку.

На практике: сначала каркасный подход против подхода, основанного на спецификации

Переход от каркасного подхода к подходу, основанному на спецификации, меняет не только сам артефакт. Он меняет то, кто что делает, когда и как работа перемещается внутри команды.

| Измерение | Рабочий процесс с использованием каркасного подхода | Рабочий процесс с использованием спецификации |

|---|---|---|

| Основной артефакт | Файл Figma с низкодетализированными экранами | Спецификация в формате Markdown, ~200-500 строк |

| Время до первой сборки | 3-7 дней | В тот же день, часто в тот же час |

| Время ввода данных инженером | После завершения создания макета | Во время составления спецификации |

| Использование ИИ-инструментов | Ограниченное, на поздней стадии | Основной путь сборки |

| Покрытие граничных случаев | Обнаружено в отделе контроля качества | Записано заранее в разделе 4 |

| Формат передачи | Ссылка на Figma плюс аннотации | Файл спецификации плюс токены дизайна |

| Единица итерации | Экран или поток | Раздел спецификации |

| Где находится замысел | В голове дизайнера | На странице, в письменном виде |

Столбец «сначала спецификация» — это не будущее состояние. Так работают самые быстрые продуктовые команды уже в 2026 году. Столбец «сначала каркас» — это то, что медленные команды до сих пор называют «дизайном».

Как спецификации обрабатываются с помощью инструментов ИИ

Хорошо написанная спецификация — это не результат работы, который навсегда лежит в Notion. Это входные данные.

Спецификация — это то, что вы вставляете в Cursor при создании структуры функции. Это то, что вы передаете Claude Code, когда вам нужен рабочий маршрут. Это то, что читает v0 при генерации начального пользовательского интерфейса. Это то, что Bolt использует при создании прототипа.

Один и тот же артефакт, но с разной маршрутизацией, управляет каждой частью сборки.

Инженеры используют его в процессе реализации. Команды разработчиков используют его для проверки использования токенов. QA-специалисты пишут тесты на соответствие критериям успеха и оценивают разделы. Даже маркетинговая команда может взять текст для запуска из абзаца с описанием намерений.

В этом и заключается настоящая победа перехода к спецификации как артефакту. Один источник истины, написанный один раз, используется каждым инструментом и каждой ролью. Больше никаких «BRAND9 устарел, но в тикете BRAND15 есть самая последняя версия». Больше никаких дизайнеров, которые гонятся за инженерами, чтобы те обновили моки после обнаружения ограничений бэкэнда.

Спецификация живет в репозитории. Она перемещается вместе с кодом и проверяется в запросах на слияние. Когда спецификация изменяется, изменение отслеживается, датируется и указывается авторство. Попробуйте сделать это с файлом BRAND10.

Написание спецификаций, которые выдерживают проверку инженерами и ИИ

Самый быстрый способ обнаружить плохую спецификацию — это дать ее генератору кода и прочитать, что он вернет. Если результат неверен, значит, и спецификация неверна. Модель — это жестокий, но справедливый редактор.

Плохие спецификации имеют общие черты. В них используется жаргон продуктовой команды, который никто за пределами команды не понимает, и они описывают взаимодействия с точки зрения компонентов пользовательского интерфейса («модальное окно») вместо действий пользователя («пользователь подтверждает сохранение»). Они пропускают крайние случаи, потому что автор предполагает, что читатель сам догадается. Они скрывают критерии успеха в чьей-то голове.

Хорошие спецификации конкретны. Они называют поведение, а не компоненты, и описывают пустое состояние простым языком. Они определяют успех в числах, которые система может измерить. Их скучно читать, потому что скука — это то, что выживает в условиях неопределенности.

Полезный тест: дайте свою спецификацию тому, кто никогда не видел продукт, и попросите его описать, что будет создано. Если он сможет это сделать, спецификация хороша. Если он задаст три уточняющих вопроса, в спецификации три дыры. Заделайте их и выпускайте продукт.

Вывод: Генератор кода — самый честный редактор, с которым когда-либо столкнется ваша спецификация. Если сборка неправильная, значит, и текст неправильный.

Полная аннотированная мини-спецификация

Вот как выглядит рабочая спецификация для реальной функции. Это шаблон сохранения в коллекцию для гипотетического SaaS-проекта, написанный лаконично, легко копируемый и вставляемый в репозиторий.

# Spec: Save to Collection ## Intent Users browsing content need a way to bookmark items into named groups so they can return to them later. Without this, repeat visit rate drops and high-intent users churn. ## Scope In: save action on any content card. Collection picker. Default "Saved" collection. Create new collection inline. Out: collection sharing. Collaborative collections. Collection cover images. Reordering items within a collection. ## Behavior 1. User clicks the save icon on a content card. 2. Picker opens, anchored to the card, listing user's collections plus a "+ New collection" row. 3. User selects a collection. Item is saved. Picker closes. Toast confirms with collection name and an Undo action. 4. If user selects "+ New collection", inline input appears. On submit, collection is created and item is saved to it. ## Edge cases - User not signed in: clicking save opens auth modal, resumes save action after auth. - No collections exist: picker shows "+ New collection" only, with placeholder text "Save your first item." - Network error mid-save: toast shows error, save action remains available, item is not marked saved. - Item already in target collection: picker shows checkmark, selecting it removes the item from that collection. - User hits free-tier collection limit: "+ New collection" row shows lock icon and routes to upgrade. ## Success criteria - 30%+ of weekly active users save at least one item per month. - Average user has 2.4+ collections within 30 days of first save. - 60%+ of saved items are revisited within 14 days. ## Evals - E2E: save flow completes in under 2 seconds on 4G. - Unit: collection picker renders correctly with 0, 1, 50 collections. - Visual: picker anchoring stays within viewport on all breakpoints. ## Accessibility and copy - Save button: aria-label "Save to collection". - Picker is fully keyboard navigable. Esc closes. - Focus returns to save button on close. - Toast is announced via aria-live="polite". - Copy: "Saved to [Collection]" / "Undo" / "Save your first item".

Эта спецификация состоит примерно из 40 строк и не содержит пикселей. Инструмент искусственного интеллекта может создать рабочую версию этой функции за один проход. Инженер может определить объем работ за пятнадцать минут, а руководитель отдела контроля качества может написать план тестирования прямо из раздела оценок.

Это артефакт. Не файл Figma. Не блок-схема. Вот это.

Как написать свою первую спецификацию

Если вы никогда не писали спецификацию, начните здесь. Выберите небольшую функцию, которую вы хорошо знаете, и откройте пустой файл Markdown. Используйте приведенный выше шаблон из семи разделов и установите 90-минутный таймер.

Сначала напишите абзац с описанием намерений. Если вы не можете описать это в трёх предложениях, значит, вы ещё не до конца понимаете эту функцию. Остановитесь и разберитесь с этим, прежде чем двигаться дальше.

Затем напишите описание задачи. Список «исключений» — самая важная часть. Заставьте себя написать пять вещей, которыми эта функция не является. Именно здесь большинство спецификаций находят свои реальные преимущества.

Далее — описание поведения. Напишите его в виде нумерованного списка, простым языком, как будто вы объясняете это умному другу, который никогда не пользовался продуктом. Никаких названий компонентов, никакого дизайнерского жаргона, только то, что делает пользователь и что происходит.

Самым сложным разделом на первом этапе будут граничные случаи. Прочитайте свой список поведенческих сценариев и задавайте себе вопрос: «Что если это не сработает?» на каждом шаге.

Пустые данные, неправильные разрешения, медленная сеть. Пользователь отказывается на полпути. Запишите каждый из них в виде предложения.

Критерии успеха и оценки — это то, где вы меняете расплывчатые цели на измеримые. «Пользователям это понравится» — это не критерий успеха. Критерием является «Уровень сохранения выше 30%». Выберите три числа, которые вы бы действительно защищали на обзоре.

И наконец, доступность и текст. Пишите каждую строку, определяйте пути клавиатуры и указывайте aria-labels. Этот раздел обеспечивает ясность, ничто другое этого не делает.

Сохраните файл в репозитории, а не в Notion. Назовите его spec.md в папке feature. С этого момента это исходный код.

Примечание: Спецификации, которые находятся в репозитории, перемещаются вместе с кодом. Спецификации, которые находятся в Notion, устаревают в момент начала сборки.

Где находится система дизайна

Дизайн, основанный на спецификациях, работает только в том случае, если лежащая в его основе система дизайна надежна. Спецификация описывает намерение. Система дизайна предоставляет необходимые компоненты. Если система — это беспорядок, спецификация в конечном итоге переносит этот беспорядок в каждую функцию.

Команды, которые быстро выпускают продукты в 2026 году, рассматривают свою систему дизайна как публичный API для инструментов ИИ. Токены именуются по назначению, а не по внешнему виду. Компоненты имеют документированные свойства (props), ожидаемое поведение и контракты доступности. Каждая страница компонента в системе читается как небольшая спецификация, содержащая описание назначения, поведения, граничных случаев и кода.

Когда спецификация ссылается на компонент, она указывает на стабильный контракт, а не на скриншот. Достаточно «Используйте стандартный компонент Card с уровнем детализации 2». Инструмент ИИ считывает документацию компонента, спецификация воспринимается как ограничения, и сборка остается согласованной для всех функций.

Если ваша система дизайна по-прежнему представляет собой библиотеку Figma, полную безымянных локальных стилей, вам нужно выполнить домашнее задание, прежде чем полностью переходить к использованию спецификаций в первую очередь. Документируйте компоненты простым английским языком. Называйте токены в соответствии с их значением. Рассматривайте саму систему как первую спецификацию, которую вы пишете.

Когда каркасы все еще оправдывают себя

Спецификации заменяют большинство каркасов. Не все. Все еще есть случаи, когда низкодетализированная визуализация является правильным решением, и притворяться, что это не так, — просто нетерпимость ради развлечения.

Три ситуации, когда каркас по-прежнему заслуживает своего места:

1. Действительно оригинальные макеты. Когда вы придумываете новый пространственный шаблон, который система дизайна еще не поддерживает, вам нужно его нарисовать, потому что одних слов недостаточно, а пространственная идея требует пространственного эскиза.

2. Главные разделы и моменты, определяющие бренд. Маркетинговые страницы, поверхности запуска и главные модули, где сам макет является сообщением, поскольку спецификация не может передать «выглядит дорого», а каркас, по крайней мере, намекает на это, прежде чем визуальный дизайнер возьмется за дело.

3. Согласование с руководством в организациях, не занимающихся продуктом. Если вы представляете проект команде руководителей, которая не внедрила рабочие процессы, основанные на спецификациях, каркас по-прежнему является языком межнационального общения, используемым в качестве инструмента перевода, а не основного артефакта.

Это список. Три случая. Во всём остальном спецификация — это лучший артефакт, а создание каркаса — это привычка, от которой следует отказаться.

Новое портфолио для дизайнеров

Вопрос о портфолио следует за вопросом об артефакте. Если спецификация — это работа, то как должно выглядеть портфолио?

Самые сильные дизайнерские портфолио в 2026 году начинаются с выдержек из спецификации, а не с макетов экранов. Страница с абзацем, описывающим намерения, списком крайних случаев и скриншотом реализованной функции даст менеджеру по найму больше пользы, чем десять скриншотов с Dribbble.

Она демонстрирует способность принимать решения. Она демонстрирует дисциплину в отношении объема работ. Она показывает, что кандидат может выполнять реальную работу.

Галерея макетов всё ещё существует, но это второй уровень портфолио, а не первый. Визуальные элементы показывают вкус. Спецификации показывают мышление. Менеджеры по найму в компаниях, где вы действительно хотите работать, оценивают мышление.

Дизайнерам, переходящим в 2026 год, следует перестроить свои портфолио вокруг трёх-пяти кейсов, каждый из которых основан на спецификации и заканчивается реализованным результатом. Не ссылка Figma. Продукт, который уже выпущен. Спецификация — это главная составляющая.

Как начинающим дизайнерам следует переквалифицироваться

Сейчас существуют два лагеря начинающих дизайнеров. Те, кто относится к инструментам ИИ как к шпаргалкам, которые нужно прятать, и те, кто рассматривает их как новое ремесло. Только у второго лагеря будет карьера через пять лет.

Путь к переквалификации прост. Научитесь писать, и не «научитесь писать отзывы о дизайне». Научитесь писать структурированную техническую прозу, так же, как менеджер проекта пишет PRD или инженер пишет RFC.

Читайте хорошие спецификации, имитируйте их и попросите кого-нибудь из старших разработчиков отредактировать вашу.

Проводите час в день в Cursor или Claude Code со спецификацией, которую вы написали, наблюдая за тем, что создается и где это отклоняется от вашего замысла. Каждое отклонение — это дыра в вашей спецификации. Заделайте её, запустите снова. Этот цикл, выполняемый ежедневно в течение трех месяцев, изменит ваше мышление о дизайне.

Перестаньте тратить время на обучающие материалы по плагинам Figma. Начните уделять время структурированному мышлению, которое сохраняется при каждом изменении инструмента. Спецификации сохраняются. Обработка пикселей — нет.

Вывод: Начинающие дизайнеры, которые пишут хорошие спецификации, работают на два уровня выше своих коллег, которые только обрабатывают пиксели. Разрыв увеличивается с каждой неделей.

Сочетайте это с двумя смежными навыками. Во-первых, научитесь достаточно хорошо читать код, чтобы проверять, что инструменты ИИ создают на основе ваших спецификаций. Вам не нужно писать код, соответствующий React, но вам нужно посмотреть на файл компонента и понять, соответствует ли он описанному вами поведению.

Во-вторых, изучите eval-функции. Написание теста, подтверждающего, что «пустое состояние отображает правильный текст», теперь является обязанностью дизайнера, а не только инженера. Спецификация определяет корректность, eval-функции обеспечивают её. Дизайнер, умеющий писать и то, и другое, работает на два уровня выше того, кто может только работать с пикселями.

Что это значит для дизайнеров

Работа с пикселями теперь стала второстепенной задачей, автоматизированной инструментами и коммерциализированной шаблонами. Эта работа поднялась по иерархии. Теперь это разработка концепции, дисциплина в определении объема работ, мышление в нестандартных ситуациях и написание текста настолько хорошо, чтобы инструмент искусственного интеллекта мог создать функцию на основе вашего текста.

Это не ухудшение дисциплины. Наоборот. Дизайнеры, которые пишут хорошие спецификации, теперь работают ближе к продуктовой стратегии, чем когда-либо прежде, имея больше влияния на поверхностный слой, чем позволял старый рабочий процесс.

Один дизайнер с хорошими навыками составления спецификаций может сделать то, что раньше делала команда из четырех человек. Разрыв в результатах реален и увеличивается с каждой неделей.

Работа на этой неделе небольшая и конкретная. Выберите одну функцию, над которой вы работаете, напишите спецификацию, используя семь разделов. Передайте ее инженеру и инструменту искусственного интеллекта параллельно.

Посмотрите, что получится. Сравните с тем, что вы бы создали с помощью вайрфрейма. Разница между двумя результатами — это разница между старым и новым вариантом.

Каркас был полезен долгое время. Спецификация полезна сейчас. Напишите следующий вариант.

hero: key: hero prompt: "voxel illustration. A wireframe and a spec document side by side, with the spec glowing brighter. Soft pastel palette. Editorial. The composition does not include any human figures." alt: "A wireframe and a design spec document side by side, the spec glowing brighter" width: 1600 height: 900 inline-1: key: spec-anatomy prompt: "voxel illustration showing a spec document with labeled sections: intent, scope, behavior, edge cases, success criteria, evals. Soft pastel." alt: "A spec document with labeled sections: intent, scope, behavior, edge cases, success criteria, evals" width: 1400 height: 900 inline-2: key: workflow-comparison prompt: "voxel split illustration. Left: designer pushing pixels in figma forever. Right: designer writing a clear spec, AI tools building. Soft pastel. The composition does not include any human figures." alt: "Split illustration comparing endless pixel pushing on the left to a clear spec driving AI tools on the right" width: 1400 height: 900 inline-3: key: spec-routing prompt: "voxel illustration: a single spec document at the top, branching arrows down into Cursor, Claude Code, v0, Bolt, design system docs. Soft pastel. The composition does not include any human figures." alt: "A single spec document at the top, branching arrows down into Cursor, Claude Code, v0, Bolt, design system docs" width: 1400 height: 900 inline-4: key: when-wireframes-still-work prompt: "voxel illustration: a few preserved wireframes for novel layouts and hero sections, the rest fading into mist. Soft pastel. The composition does not include any human figures." alt: "A few preserved wireframes for novel layouts and hero sections, the rest fading into mist" width: 1400 height: 900