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

Большинство дизайн-ревью это театр. Сеньор 20 минут рассуждает о цвете кнопки, джуниор кивает, работа уходит в релиз без изменений или хуже. Никто ничему не учится, работа не становится лучше, а команда начинает бояться встречи, которая должна была сделать её острее.
Эта статья это рабочая версия. Фреймворки, которые превращают критику в инструмент, правила, которые оставляют эго за дверью, и структура, которая делает обратную связь полезной для человека, чья работа сейчас на экране. Никаких банальностей про «дизайн-культуру», никаких манифестов, только операционная процедура команды, которая выпускает работу лучше, потому что умеет её ревьюить.
Что такое дизайн-критика на самом деле
Дизайн-критика это структурированное peer review работы в процессе. Цель в том, чтобы вскрыть проблемы, которые дизайнер не видит изнутри собственного черновика, и проверить работу на соответствие пользователю, брифу и системе до релиза. Критика это не утверждение, не одобрение и не голосование.
Критика также не презентация. Дизайнер здесь не для того, чтобы защищать работу. Ревьюеры здесь не для того, чтобы ею восхищаться. Обе стороны делают так, чтобы следующая итерация была лучше текущей.
Руководство по дизайн-портфолио рассказывает, как индивидуальную работу оценивают снаружи. Эта статья глубоко погружается во внутреннее командное ревью, у которого другие цели и совсем другие правила.
Почему большинство критик проваливается
Одни и те же пять провалов встречаются почти в каждой команде, которая мучается с критикой. Если встреча выматывает, а работа не улучшается, смотрите сначала сюда.
Дизайнер презентует, а не спрашивает. Работу проходят от начала до конца, ревьюеры вежливо ждут, конкретной обратной связи никто не просит. Ревьюеры скатываются к общим реакциям, потому что ничего не было очерчено.
Ревьюеры соревнуются. Каждый старается первым заметить самую умную проблему. Разговор дрейфует к тому, кто звучит солиднее. Дизайнер уходит с двенадцатью противоречивыми мнениями и без ясного пути вперёд.
Личный вкус наряжают в принцип. Ревьюеру не нравится шрифт, и он подаёт это как проблему иерархии. Ревьюер предпочитает другой паттерн вёрстки и подаёт это как доступность. Без фреймворка побеждает вкус.
Никто ничего не записывает. Разговор прошёл, встреча закончилась, дизайнер помнит процентов 30. Следующая критика проходит по тем же граблям.
Критика происходит слишком поздно. Работа уже готова на 90%. Обратную связь о крупной перестройке игнорируют, потому что нет времени. Критика сводится к полировке.
Каждое из этого чинится. Починка это остальная часть статьи.
Трёхслойная модель обратной связи
Любой полезный фидбек по дизайну укладывается в один из трёх слоёв. Ревьюеры, которые могут назвать слой, на котором говорят, остаются сфокусированными. Те, кто не могут, уплывают во вкусовщину.
Слой 1: Наблюдение
Наблюдение это то, что ревьюер буквально видит на экране. Без интерпретации, без оценки.
«CTA находится ниже сгиба на вьюпорте шириной 1440». Это наблюдение. «Кнопка маленькая». Это наблюдение. «На этой странице видны три разных гротеска без засечек». Это наблюдение.
Наблюдения не обсуждаются. Дизайнер может проверить их на экране в реальном времени. Это самый безопасный слой, потому что с ним не поспорит ни одна сторона.
Слой 2: Интерпретация
Интерпретация это то, что наблюдение может значить для пользователя, бренда или системы.
«То, что CTA ниже сгиба, значит, что мобильные пользователи, скорее всего, пролистают его, не поняв, чего от них хочет страница». Это интерпретация. «Три гротеска выглядят непоследовательно, что сигнализирует пользователю о размытом голосе бренда». Это интерпретация.
Интерпретации открыты для обсуждения. Двое могут по-разному истолковать одно и то же наблюдение. В этом и есть продуктивная часть критики. Именно в интерпретации коллективный опыт команды добавляет ценность индивидуальному черновику дизайнера.
Слой 3: Предложение
Предложение это то, что ревьюер рассмотрел бы в ответ на интерпретацию.
«Можно протестировать перенос CTA выше сгиба или добавить sticky CTA при скролле». Это предложение. «Можно свести всё к одному гротеску для текста и одному дисплейному шрифту, а затем проверить иерархию быстрым squint-тестом». Это предложение.
Предложения дизайнер берёт по желанию. Работа принадлежит дизайнеру. Ревьюер предлагает варианты, а не приказы. Критика, где предложения обязательны, не критика, а цепочка подчинения.

Фреймворки критики, которые реально работают
Фреймворк это сценарий встречи. Он снимает когнитивную нагрузку от вопроса «как дать фидбек прямо сейчас» и позволяет ревьюерам сосредоточиться на самой работе.
Фреймворк 1: Цель, обоснование, фидбек
Самый быстрый во внедрении. Три шага, десять минут на работу.
Шаг первый: дизайнер называет цель. «Я пытаюсь довести пользователя с главной страницы до платной регистрации в один клик». Максимум два предложения.
Шаг второй: дизайнер рассказывает обоснование. «Я поставил CTA в hero, потому что прошлый тест показал: 60% конверсий происходит выше сгиба. Выбрал зелёный, потому что бренд использует его для основных действий». Максимум три минуты.
Шаг третий: ревьюеры дают фидбек относительно цели. Каждый комментарий должен возвращаться к заявленной цели. «Поддерживает ли CTA цель?», а не «Тот ли это оттенок зелёного?»
Фидбек, не связанный с целью, откладывается в отдельный список на потом. Встреча остаётся сфокусированной. Дизайнер уходит с ясным путём вперёд.
Фреймворк 2: I Like, I Wish, What If
Заимствован из IDEO и адаптирован для дизайн-команд. Полезен, когда работа ранняя и исследовательская.
I like (мне нравится): что работает. Ревьюеры называют конкретные элементы, которые стоит сохранить. Заставляет делать позитивные наблюдения, которые большинство критик пропускает.
I wish (хотелось бы): что ревьюер изменил бы. Формулируется как пожелание, не команда. «Хотелось бы, чтобы контраст между заголовком и текстом был сильнее».
What if (а что если): спекулятивные альтернативы. «А что если CTA был бы sticky-элементом, а не встроенным?» Открывает направления, о которых дизайнер мог не думать.
Фреймворк работает, потому что снижает ставки. Пожелания и «а что если» звучат как сотрудничество. Прямая критика часто ощущается как противостояние, даже когда таковой не является.
Фреймворк 3: Decision Stack
Лучше всего для поздних стадий, когда команда решает, что уйдёт в релиз.
Нужное решение: по какому именно вопросу дизайнеру нужно решение? «Оставлять вторичный CTA или вырезать?», а не «посмотрите этот макет».
Варианты на столе: что рассматривал дизайнер? Покажите отвергнутые альтернативы. Ревьюеры могут спросить, почему конкретные варианты отпали.
Рекомендация: что рекомендует дизайнер и почему?
Риски: что может пойти не так с этой рекомендацией?
Работа ревьюера в том, чтобы проверить рекомендацию на рисках. Пропустил ли дизайнер риск? Правильно ли взвешены риски? Действительно ли рекомендация сильнейшая из показанных вариантов?
Этот фреймворк заставляет дизайнеров делать работу до встречи. Встреча становится проверкой мышления, а не генерацией нового мышления с нуля.

Правила, которые держат комнату в рабочем состоянии
Фреймворки структурируют встречу. Правила регулируют поведение внутри неё. Без правил даже лучший фреймворк скатывается в тот же расплывчатый разговор, который не сработал в прошлый раз.
Правило 1: дизайнер очерчивает фидбек
Перед началом критики дизайнер говорит, какой фидбек ему нужен. «Мне нужен фидбек по иерархии и CTA. Цветовая палитра зафиксирована, тексты финальные». Это бережёт время дизайнера и внимание ревьюеров.
Если ревьюер хочет прокомментировать что-то вне рамок, он записывает это на после встречи или для отдельной сессии. Критику он не сбивает.
Правило 2: один разговор за раз
Побочные разговоры убивают критику. Весь смысл в коллективном внимании на одной работе. Если двое ревьюеров начали спорить между собой, фасилитатор возвращает их в группу. Если нужно обсудить три вещи, их обсуждают по очереди, а не параллельно.
Правило 3: конкретика вместо общего
«Что-то не то» не фидбек. «CTA теряет контраст на градиентном фоне, что, вероятно, вредит видимости в светлой теме» это фидбек. Ревьюеров с общими реакциями просят уточнить или пропустить.
Правило 4: никаких предписаний без наблюдения
Ревьюер не может рекомендовать изменение, не назвав наблюдение, которое его вызвало. «Сделайте кнопку синей» это предписание без наблюдения. «Текущая красная кнопка близка к вашему состоянию ошибки, что может сбить пользователей в критичных сценариях. Можно попробовать синий или другой красный» это наблюдение, интерпретация, предложение.
Это правило самое мощное изменение, которое команда может внедрить. Оно заставляет ревьюеров думать до того, как говорить, и даёт дизайнеру рассуждение, а не просто требование.
Правило 5: фиксируйте всё
Кто-то в комнате ведёт заметки. Наблюдения, интерпретации, предложения, решения, следующие шаги. Дизайнер не должен быть записывающим, потому что он слишком загружен реакцией на фидбек.
Заметки передаются дизайнеру сразу после встречи. Дизайнер помечает каждую: принято, отклонено с причиной или отложено. Следующая критика начинается с того, что изменилось с прошлого раза.
Правило 6: ограничение по времени и определённый результат
У встречи есть жёсткое время окончания. Каждой работе отведён фиксированный слот, обычно от 15 до 30 минут. Фасилитатор это обеспечивает. Затягивание это быстрейший способ потерять энергию команды и отбить у людей желание приносить работу на встречу.
Каждый слот заканчивается заявленным результатом. «Дизайнер перенесёт CTA выше сгиба и проверит контраст на градиентном фоне. Покажет v2 на следующей критике». Нет результата, значит, встреча не принесла ценности.
Когда должна проходить критика
Критика на поздней стадии почти всегда запоздала. Максимальный рычаг у критики там, где направление ещё дёшево менять.
Три точки критики на проект
Минимальное расписание, дающее выпущенную работу, которая со временем становится лучше:
| Фаза | Цель | Фреймворк |
|---|---|---|
| Направление | Решаем ли мы правильную проблему? | I Like, I Wish, What If |
| Средняя детализация | Правильна ли структура? | Цель, обоснование, фидбек |
| Перед релизом | Готово ли это к релизу? | Decision Stack |
У каждой фазы свои цели, и ей подходит свой фреймворк. Пропуск любой даёт предсказуемые сбои.
Пропуск критики направления значит, что команда заканчивает отполированный макет неверного решения. Обнаруженная слишком поздно, это самая дорогая ошибка, которую команда может совершить.
Пропуск критики средней детализации значит, что структурные проблемы находят на высокой детализации, где их исправление стоит в пять раз дороже. Команда выпускает компромиссную работу, потому что нет времени начать заново.
Пропуск предрелизной критики значит, что предотвратимые проблемы попадают в прод. Ship doc пишется без второй пары глаз, и о сломанном состоянии команда узнаёт из пользовательских отзывов.
Разбор AI-воркфлоу в дизайне рассказывает, как встроить критику в ускоренные ИИ циклы дизайна. Быстрая генерация делает критику важнее, а не менее важной.
Роль фасилитатора
У большинства дизайн-критик нет фасилитатора, и поэтому они разваливаются. Фасилитатор это не старший дизайнер в комнате. Это тот, кто отвечает за то, чтобы встреча работала.
Что делает фасилитатор
Фасилитатор отвечает за три вещи:
- Время. Каждая работа получает свой слот. Жёсткая отсечка, когда время вышло. Отложенное уходит в список на потом.
- Фокус. Возвращает ревьюеров, когда они дрейфуют, задаёт уточняющие вопросы, когда фидбек расплывчат, называет момент, когда разговор ушёл за рамки.
- Фиксация. Либо ведёт заметки сам, либо следит, чтобы их вёл кто-то. Заметки не опция, это артефакт встречи.
Фасилитатор здесь не для того, чтобы критиковать. Критиковать он может только после того, как структура встречи отработана. Смешение фасилитации и критики дробит внимание и почти всегда даёт худший результат в обоих.
Ротируйте роль
Один и тот же человек в роли фасилитатора каждой критики становится узким местом. Ротируйте роль раз в неделю или раз в две недели по команде. Джуниорам фасилитация приносит огромную пользу, потому что заставляет думать о встрече структурно, а не только о работе.
Сеньорам тоже. Фасилитация вместо критики заставляет сеньора слушать, а не доминировать, а это навык, который большинство сеньоров недооценивает.
Как принимать критику
Вторая половина критики это быть дизайнером в кресле. Большинство дизайнерского образования это полностью пропускает. Результат: поколение дизайнеров, которые обороняются, когда их работу ревьюят, и отметают фидбек, который помог бы им больше всего.
Пять правил для дизайнера
Выслушайте полностью, прежде чем отвечать. Не перебивайте, защищая решение. Примите фидбек, запишите, затем задавайте уточняющие вопросы. Инстинкт защиты убивает ценность встречи.
Отделяйте наблюдение от предложения. Ревьюер может предложить правку, с которой вы не согласны, но лежащее в её основе наблюдение всё равно может быть верным. Берите наблюдение, оставляйте предложение, находите собственное решение.
Спрашивайте «почему», а не «ли». «Почему, как вам кажется, CTA теряет контраст?» даёт полезное продолжение. «Как вам кажется, CTA теряет контраст?» даёт «да» или «нет», которое заканчивает разговор.
Отложите реакции. Если фидбек бьёт больно, запишите и ответьте позже. Защита в реальном времени даёт плохие ответы с обеих сторон. Пауза в 24 часа почти всегда даёт ответ лучше.
Владейте решением. Работа принадлежит дизайнеру. После критики дизайнер решает, что делать. Ревьюеры предлагают варианты, а не команды. Задача дизайнера взвесить фидбек против всего остального, что он знает о проекте, и решить.

Критика в условиях 2026 года
Три сдвига изменили то, как работает дизайн-критика. Системе нужно адаптироваться ко всем трём.
Удалённая и асинхронная критика стали нормой. Общий сбор в одной комнате редкость. Критика теперь идёт в комментариях Figma, записях Loom и общих документах. Фреймворки всё ещё работают, фасилитация всё ещё важна, но меняется тайминг. У асинхронной критики должны быть чёткий запрос, чёткий дедлайн и чёткая точка решения. Без них она превращается в кладбище комментариев.
Работе, созданной ИИ, критика нужна больше, а не меньше. Инструменты, генерирующие варианты за секунды, соблазняют пропустить критику, ведь это «просто вывод ИИ». Именно тогда критика важнее всего. Работа от ИИ по умолчанию ни за что не отвечает. Человеческая критика делает её подотчётной.
Кросс-функциональная критика теперь стандарт. Инженеры, продакты и контент-дизайнеры сидят на той же критике, что и визуальные дизайнеры. Фреймворки работают для всех. Словарь нужно упрощать. «Аффорданс» и «выше сгиба» нормально, но вся встреча не может быть дизайнерским жаргоном, иначе недизайнеры отключатся.
Глоссарий по дизайн-хэндоффу объясняет, как критика связана с более широкой дисциплиной передачи. Критика, не создающая артефакта, которым можно поделиться, не переживает хэндофф.
FAQ
Что такое фреймворк дизайн-критики?
Фреймворк это структурированный сценарий проведения дизайн-ревью. Он определяет, кто и когда говорит, какой фидбек запрашивается и как заканчивается встреча. Самые распространённые фреймворки: Goal-Rationale-Feedback, I Like-I Wish-What If и Decision Stack. Каждый подходит для своей стадии работы.
Как давать хороший фидбек по дизайну?
Используйте трёхслойную модель. Начните с наблюдения (что вы видите), затем интерпретация (что это может значить), затем предложение (что бы вы рассмотрели). Пропустите любой слой, и фидбек слабеет. Пропустите наблюдение целиком, и фидбек становится предписанием, которое дизайнер может отмести.
Сколько должна длиться встреча дизайн-критики?
От 15 до 30 минут на работу, с жёстким ограничением по времени. 60-минутная критика одной работы почти всегда либо слишком широко очерчена, либо идёт на плохом фреймворке. Ограничивайте каждый слот, фиксируйте результаты и двигайтесь дальше. Большинство команд критикует от 2 до 4 работ за сессию.
Как часто дизайн-команде проводить критику?
Раз в неделю базовый вариант для небольшой команды, регулярно выпускающей работу. Раз в две недели подходит команде с более длинными циклами проектов. Расписание важно меньше, чем постоянство. Команда, которая проводит еженедельную критику целый год, улучшается быстрее, чем команда, которая критикует ad hoc, когда кто-то попросит.
Как не дать критике стать личной?
Внедрите фреймворк, внедрите правила и ротируйте фасилитатора. Фреймворки отделяют наблюдение от предписания, а именно там начинается большинство критики, которая ощущается личной. Фасилитатор ловит оговорки. Со временем команда усваивает структуру, и личная критика прекращается, потому что язык её больше не поддерживает.
Как критиковать сеньор-дизайнера?
Так же, как и любого другого. Используйте трёхслойную модель, связывайте фидбек с заявленной целью и позвольте сеньору самому принять решение. Сеньоры, не принимающие критику, проблема куда больше самой критики. Команда, которая тихо избегает ревью сеньорской работы, выпускает компромиссную сеньорскую работу.
Критика это дисциплина, а не встреча
Команда, которая хорошо проводит критику, выпускает лучшую работу, потому что ловит проблемы раньше, получает больше взглядов на каждое решение и вырабатывает общий словарь для качества дизайна. Команда, которая проводит критику плохо, выпускает либо неровную работу, либо отполированную, но неверную, и удивляется, почему еженедельная встреча не помогает.
Решение структурное. Выберите фреймворк. Внедрите правила. Назначайте критику в трёх точках проекта, а не в конце. Фиксируйте результаты. Ротируйте фасилитатора. Принимайте критику без обороны. Давайте критику без предписаний.
Цена внедрения этой дисциплины это две-три встречи лёгкого дискомфорта, пока команда подстраивается. Награда это команда, которая становится острее с каждым проектом, и корпус работ, который со временем улучшается, а не скатывается к тому, у кого самое громкое мнение.
Если вам нужна команда, которая делает эту дисциплину частью каждого проекта, наймите Brainy. Мы встраиваемся во внутренние дизайн-команды и внедряем системы критики вместе с работой над брендом и продуктом.
Читайте также
- Руководство по дизайн-системам
- Руководство по дизайн-портфолио
- AI-воркфлоу в дизайне
- Дизайн-хэндофф из Figma в разработку
Want a design team that critiques without the drama and ships better work because of it? Brainy embeds with internal teams to install critique systems and ship product with the rigor baked in.
Get Started




