written-critique

Written Critique — узкий workflow для обратной связи по дизайну, которую можно передать асинхронно и использовать без дополнительного раунда уточняющих вопросов. Источник прямо связывает его с дизайн-ревью, portfolio case study и документированием решений. Поэтому задача навыка не в том, чтобы переписать интерфейс или составить длинный отчёт, а в том, чтобы превратить наблюдение над готовой работой в короткую диагностическую запись с понятным следующим направлением. Команда /written-critique запускает этот формат в разговоре с агентом. Структура состоит из четырёх последовательных частей. Сначала фиксируется Intent в двух-трёх предложениях: чего пытается добиться дизайн и какой опыт он должен создать. Здесь нужно описывать намерение, а не пересказывать видимые элементы экрана. Затем идут два-три конкретных решения, которые работают, и для каждого указывается принцип, объясняющий пользу решения. Такой порядок помогает отделить наблюдаемую конструкцию от общего впечатления и показывает, за счёт чего сильная часть действительно поддерживает задачу пользователя. Третья часть называется What does not work. В ней источник разрешает назвать одно-два конкретных решения, объяснить проблему и описать её влияние на пользователя. Это ограничение не даёт превратить критику в перечисление всех мелких недочётов: приоритет остаётся у тех наблюдений, на которые можно ответить действием. Финальная часть — One change — содержит одну рекомендацию с наибольшим ожидаемым эффектом. Её следует сформулировать как направление, а не как готовое предписание или детальный редизайн. Правила письма требуют быть достаточно точным, чтобы дизайнер мог действовать без новой беседы. Отдельно разделяются craft-наблюдения — например, про выравнивание и согласованность — и taste-вопросы о том, должен ли элемент вообще существовать. Основанием служат наблюдаемые решения, а не чувства рецензента. Источник рекомендует укладываться менее чем в 300 слов, потому что краткую обратную связь легче прочитать и применить. Навык также запрещает переписывать дизайн вместо постановки диагноза. Из этих ограничений следуют практические границы. Workflow не выбирает изменения за дизайнера и не превращает субъективный вкус в измеренный факт. Он не заменяет профессиональную экспертизу, исследование пользователей или согласование итогового решения с командой. Нельзя смешивать похвалу и критику в одном наблюдении, одинаково подробно разбирать каждую деталь, писать стену текста без структуры или смягчать замечания настолько, что исчезает их смысл. Результатом должен быть компактный, приоритизированный и проверяемый план обсуждения, а не новый макет.