И другие штуки, которые ты можешь не любить, но без них ничего бы не заработало

На днях подруга переслала мне переписку с джуном из её команды.
Он скинул твит от «очень весомого медийного» дизайнера в 2025 году:

— Я два дня пробую автолэйаут и компоненты в Figma.
Хотел облегчить себе жизнь — получил только головную боль. Как вы вообще так работаете? Вы все монстры.

С намеком, что наши текущие инструменты не нужны, и проще работать на хексах и группах.
Я сначала крякнула.
Потом вспомнила, как когда-то впервые открыла Sketch и пыталась выравнивать «компоненты» на 50 экранах.. И первые костыльные дизайн-системы, 127 версий одной кнопки в одном проекте..

Вот мы и дожили до момента, когда автолэйауту нужно не учить, а объяснять, зачем он вообще появился.

Так что если ты джун, и тебе кажется, что всё это лишнее, — тут короткий список вещей, которые когда-то были спорными, потом спасли всех, а теперь стали настолько привычными, что их больше не объясняют.

Автолэйаут — чтобы не держать всё в голове и не переделывать всё руками

До 2019 года в Figma не было автолэйаута.
А в Sketch всё приходилось настраивать плагинами, руками и через боль.

В начале автолэйаут казался костылём. Он «ломал» выравнивания, мешал на первых порах. Но со временем стало очевидно: автолэйаут не для удобства, а для предсказуемости. Ты не просто ставишь отступы — ты строишь правила. Задаёшь поведение элементов при масштабировании, смене текста, изменении языка, адаптации к другим экранам.

Зачем тебе это как продуктовому дизайнеру:

Хороший макет — это не тот, где «всё ровно». А тот, который не развалится через два месяца, когда продукт расширится, переведётся, или в него вольют новую фичу.

Автолэйаут — это инструмент мышления:
→ как будет вести себя интерфейс при изменении контента?
→ как он впишется в другие сценарии?
→ как будет жить при реальных данных?

Если ты отвечаешь на эти вопросы до релиза — ты уже не просто дизайнер. Ты участвуешь в устойчивости твоего продукта.

Дизайн-система — не библиотека компонентов, а инфраструктура

Дизайн-систему часто принимают за визуальный гайд.
Когда в 2015–2016 годах начали появляться первые полноценные дизайн-системы (Material от Google, Lightning от Salesforce, Polaris от Shopify), всё выглядело как методичка.

На деле — это архитектура повторяемости и совместимости.
У тебя 7 фичей? Завтра будет 70. Если у каждой кнопки своя логика, если поведение компонентов не согласовано — ты создаёшь не интерфейс, а х/ф...ю.

Зачем это джуну:

Работа с системой — это первый контакт с масштабом продукта.

Ты начинаешь задаваться вопросами:
→ это решение одноразовое или системное?
→ сломаю ли я логику где-то, если изменю этот компонент?
→ сколько времени и денег сэкономит эта унификация?

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

Отступы по 4/8 — чтобы потом не переделывать всё из-за одного бага

В мире до ретины (до iPhone 4 и Android с высоким ppi), дизайн строился буквально по пикселям. Но с появлением экранов с кратной плотностью стало понятно: всё, что не делится на 4 или 8, превращается в костыли.

Появились системные гриды, поддержка 8pt-сеток в Bootstrap, iOS и Android-гайдлайны с упором на кратность — и стало ясно: это не «рекомендация», это универсальный язык совместимости.

Зачем это тебе, даже если ты не фронт:

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

И да, не все замечают, когда ты держишься четной сетки.
Но все замечают, когда ты перестаешь это делать.

Компоненты — чтобы не рисовать одно и то же, и не чинить руками

В Sketch «символы» появились в 2014 году. В Figma — с самого начала, но нормальный компонентный подход заработал где-то в 2018–2019.
До этого всё копировали руками:
— Нужна новая карточка? Скопируй старую. Измени цену. Удали лишнее.
— Поменялась логика? Вноси правку в 20 местах.

Компоненты дали то, чего не хватало: один источник правды.

Зачем это тебе в команде:

→ Компоненты позволяют вносить изменения разом.
→ Компоненты делают поведение предсказуемым.
→ Компоненты дают разработчику понимание, как всё работает.

Если ты строишь фичу из компонентов — ты не просто рисуешь.
Ты моделируешь интерфейс, который можно поддерживать.
Это как писать быстро читаемый код, а не просто рабочий.

Исследования — чтобы не делать красиво, а делать полезно

Исторически UX возник не в стартапах, а в NASA. Там не могли позволить себе кнопку, которую «не нашли». Потом этим занялись IDEO, потом продуктовые команды. Когда пришли первые A/B-тесты, поведенческая аналитика, юзабилити-исследования —
стало ясно, что глазомер не UX.

Зачем это джуну:

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

Финал

Короче, если ты джун и где-то внутри тебя зреет мысль «а можно без всего этого сложного?», знай, можно.
Но будет как в 2015 — с четырьмя разными кнопками, ручным выравниванием и ором в чате от фронта.

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

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