Журнал решений: почему лучшие дизайнеры документируют решения, о которых никто не спрашивал

Сеньор и мидл могут выпустить один и тот же экран. Сеньор помнит, почему. Мидл помнит, что.

Эта разница сводится к одному артефакту. Короткая, датированная, структурированная запись каждого дизайнерского решения с приложенным обоснованием. Журнал решений. Большинство дизайнеров его не ведут: в школе этого не требовали, а в прошлой команде его не было. Сама по себе практика не распространяется.

Команды, задающие планку в 2026 году, уже так работают. У Linear есть дизайн-RFC. Vercel выпускает продуктовые спецификации рядом с инженерными. Anthropic публикует исследовательские заметки. Stripe ведёт документы дизайн-ревью. Brian Lovin держит свой журнал на публичном личном сайте. Jordan Singer выпускает небольшие продукты с публичными дизайн-дневниками. Везде один и тот же артефакт.

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

Артефакт, который большинство дизайнеров не ведут

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

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

Что такое журнал решений на самом деле

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

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

Это не протокол встречи. Журнал фиксирует, что решили и почему, даже если решение родилось в сообщении в Slack за тридцать секунд. Роадмап смотрит вперёд. Журнал смотрит назад на каждое уже принятое решение: с датой, подписью и готовностью к защите.

Почему нанимающие менеджеры ценят его выше макетов

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

Модель выдаёт отполированный лендинг за восемь минут. Менеджер, глядя на эту страницу, ничего не узнаёт о дизайнере, который её выпустил. Та же модель, тот же промпт, те же референсы с Dribbble. Журнал единственный артефакт, который переживает AI-обесценивание лоска: он не результат, а след выборов, давших именно этот результат вместо восемнадцати других.

Чтение занимает две минуты. Менеджер открывает журнал, просматривает пять записей и видит, как думает дизайнер. Конкретные альтернативы, названные ограничения, предметное обоснование, принятая ответственность за итог, готовность написать «сейчас я бы сделал иначе». Это всё собеседование, сжатое до документа.

Откуда пошла практика

Журнал решений старше софта. Christopher Alexander писал паттерн-языки, которые читаются как журналы решений в масштабе зданий: каждый паттерн датирован, назван, обоснован, с отмеченными альтернативами. Архитекторы ведут проектные книги веками.

Софт унаследовал это через культуру RFC. IETF публикует документы Request for Comments с 1969 года. ADR (записи архитектурных решений) в Spotify, Pivotal и Thoughtworks это тот же артефакт поменьше. Самое свежее наследование идёт из исследовательских лабораторий. Anthropic публикует исследовательские заметки, которые читаются как журналы решений на уровне модели.

Три линии, один артефакт. Дизайнеры опаздывают, а планка растёт так быстро, что «поздно» начинает читаться как «джуниор».

Шаблон из шести полей, копируйте

Шесть полей. Decision, Alternatives, Constraints, Reasoning, Owner, Outcome. Шаблон короткий намеренно. Дисциплина в том, чтобы его писать, а не проектировать. Скопируйте блок. Используйте завтра.

Date: 2026-04-30 Project: Acme Onboarding v3 Decision Stack email and password vertically on the signup screen, no inline social login row. Alternatives 1. Inline social login row (Google, Apple, GitHub) above the fields. 2. Two-step flow, email first then password on screen 2. 3. Magic-link only, no password field. Constraints - Mobile-first, 360px min width, single column. - Engineering will not ship social OAuth this quarter. - Support flagged 14% of tickets as password reset confusion. - [Brand voice](/paper/glossary/brand-voice) rejects "Continue with" social patterns as generic. Reasoning Vertical stack ships fastest and matches the brand register. Two-step tested cleaner in 2024 but added a screen we cannot afford given the 38% drop on screen 2. Magic-link only blocks the password manager flow 22% of paid users rely on. Owner Maya Chen, design. Reviewer: Jordan Park, eng lead. Outcome (filled 2 weeks post-ship) Conversion +6.1% vs v2. Password reset tickets dropped 9%. Re-evaluate magic-link as v3.1 when OAuth lands in Q3.

Copy

Одна запись на каждое реальное решение. От пяти до десяти записей на проект. Обложку пропустите. Блок выше и есть работа.

Как писать каждое поле без увёрток

У каждого поля есть правило. Нарушите его, и журнал превратится в театр.

Decision. Одно предложение, настоящее время, конкретика. «Поля почты и пароля идут столбцом». Не «нам показалось, что вертикально может сработать». Если решение не принято, запись пока не пишите.

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

Constraints. Маркированный список, с именами и источниками. Ресурс инженеров, правила бренда, тикеты поддержки, нижняя планка доступности, бюджет производительности. Без них журнал читается как отмывание вкуса.

Reasoning. От трёх до пяти предложений, без «нам казалось». Используйте «потому что». Используйте «по сравнению с». Назовите ограничение или данные, которые решили дело. Дайте ссылку на артефакт.

Owner. Назовите дизайнера. Назовите ревьюера. Анонимные журналы не переживают встречу с сеньорным ревьюером.

Outcome. Заполняется через две недели или два месяца после выпуска, с датой. Что сделала метрика, что пересмотрели, что изменили бы в следующий раз. Готовность написать «я ошибся с блокировкой magic-link» самый сильный сигнал доверия в журнале.

Где хранить журнал

Журнал живёт там, где команда реально его откроет. Хранилище важно меньше, чем регулярность.

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

Linear docs. Верный выбор, если инженеры и дизайнеры уже живут там. Решения лежат рядом с задачами, которые их вызвали, а переход в инженерные RFC занимает один клик.

Markdown-файл в репозитории. Верный выбор для дизайн-инженеров и владельцев дизайн-систем. decisions.md в корне репозитория или в /docs/decisions/ выглядит серьёзно, потому что версионируется вместе с кодом. Инженеры уважают этот формат с первого взгляда.

Небольшой приватный блог или личный сайт. Верный выбор для отдельного дизайнера, который строит публичный след. Так делает Brian Lovin. Статический сайт, датированные записи, публичные ссылки. Материал работает и как портфолио, и как витрина для найма.

Выберите один. Ведите квартал. Первая ошибка, которая всё губит: выбрать инструмент и больше никогда его не открывать.

Дизайн-RFC в Linear и продуктовые спецификации в Vercel

Linear ведёт дизайн-RFC как полноправные артефакты в своих документах. Каждое значимое дизайнерское решение выходит с RFC, написанным до работы, проверенным лидами дизайна и инженерии и заархивированным вместе с проектом. RFC часть работы, а не отчёт постфактум.

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

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

Исследовательские заметки Anthropic и документы дизайн-ревью Stripe

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

Stripe ведёт документы дизайн-ревью, которые переживают продуктовые циклы. Stripe Press это публичная витрина, внутренняя практика старше. Ревью пишутся, архивируются и пересматриваются, когда новый цикл упирается в похожее решение. Институциональная память копится годами, а не уходит вместе с сеньором.

Если нужна помощь, чтобы встроить это в ремесло вашей команды, наймите Brainy. BrandBrainy делает слой ремесла, который AI не подделает. ClaudeBrainy делает Skill-паки и библиотеки промптов, которые превращают журнал из дисциплины в настройку по умолчанию.

Brian Lovin и Jordan Singer ведут свои журналы публично

Brian Lovin давно ведёт личный сайт, который читается как публичный журнал решений по его собственной работе. Короткие страницы, прямой язык, дизайнерские выборы объяснены в трёх-четырёх предложениях, с датой и ссылкой на живой продукт. Годы записей. Сайт работает и как портфолио, и как витрина для найма: двойное назначение, на которое опирается плейбук анти-портфолио.

Jordan Singer выпускает небольшие продукты с публичными дизайн-дневниками. У каждого проекта есть письменная запись решений, опубликованная открыто, с готовностью сказать вслух «это не сработало». Дневник одновременно маркетинг, запись и артефакт для найма.

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

Предупреждение: постфактум-рационализация

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

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

Вторая примета это поле результата. В живых журналах есть результаты, не совпавшие с прогнозом. «Я ждал роста конверсии, тест показал ноль, вот что пошло не так». В театральных журналах только победы, заранее округлённые в лучшую сторону.

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

Как использовать журнал на собеседованиях и ревью

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

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

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

Дизайнер, который может защитить журнал, защищает работу. Дизайнер без журнала не защищает ничего.

Новая планка: сеньорная работа без журнала читается как джуниорская

Журнал решений больше не приятный бонус для сеньора. Это самый дешёвый сигнал сеньорного суждения, который может выпустить дизайнер, а цена отказа от него растёт.

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

Вкус это последний ров в 2026 году, потому что производство обесценилось, а журнал это публичный артефакт, доказывающий, что вкус в работе есть. Если вы работаете как гибрид дизайн-инженерии, журнал служит инженерным RFC на уровне дизайна. Если вы поднимаетесь по новой карьерной лестнице дизайнера, журнал это артефакт, на котором стоит лестница.

FAQ

Что такое журнал дизайнерских решений?

Короткая структурированная запись дизайнерских выборов с приложенным обоснованием. Шесть полей в каждой записи: Decision, Alternatives, Constraints, Reasoning, Owner, Outcome. С датой, конкретикой и ссылками на артефакты.

Чем он отличается от кейса?

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

Где его хранить?

Там, где команда реально его откроет. Notion для продуктовых команд, Linear docs для тех, кто уже там, markdown-файл в репозитории для дизайн-инженеров, небольшой приватный сайт для личного публичного следа.

Какой длины должна быть запись?

Короткой. Полный шаблон помещается на один экран. Пятнадцать минут на запись.

Что делать, если моя компания не примет это?

Ведите лично. Индивидуальный журнал дизайнера копится от работы к работе. Brian Lovin и Jordan Singer ведут свои публично. Практика принадлежит вам, а не работодателю, и артефакт уходит с вами.

Начните журнал на этой неделе

Три шага. Настройте хранилище. Выберите Notion, Linear, репозиторий или небольшой сайт. Поднимите его за тридцать минут. Выберите то, что откроете завтра.

Напишите три записи о уже принятых решениях. Реальные решения этого квартала. По шесть полей в каждой. Честные альтернативы, настоящие ограничения, никаких увёрток, результаты с датой и без спина. Первые три самые трудные, остальные идут быстрее.

Покажите журнал одному сеньорному ревьюеру. Попросите его надавить на обоснование. Примите давление как сигнал. Обновите записи. Именно на первом ревью журнал начинает приносить проценты.

Если нужна помощь, чтобы встроить практику журнала решений в ремесло вашей команды, наймите Brainy. BrandBrainy делает слой бренда и ремесла, который AI не подделает. ClaudeBrainy делает Skill-паки и библиотеки промптов, которые превращают журнал из дисциплины в настройку по умолчанию. Команды, которые уже так работают, отрываются. Планка растёт, а дизайнер, начавший на этой неделе, это тот, кого названные команды будут читать через квартал.