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

Как инвестировать тревожность:

• Поймал нервяк → не обсуждаешь его с собой 40 минут.
• Открываешь курс/книгу/урок → 20 минут тупо учишься.
• Фиксируешь микроцель на сегодня (1 конспект, 1 задача, 1 маленький результат). Микроцели возвращают ощущение контроля, а контроль снижает шум.​

Тревога в голове — это сериал про «всё пропало».
Тревога в учебе — это план прокачки.

И да: поначалу будет криво. Но это лучше, чем идеально переживать.​

Если откатиться лет на 15 назад, было уже похожее кино: моментальная фотография, Polaroid, «фото для дураков», «нормальные снимают на плёнку». А потом выяснялось простое: плёночный фотограф тоже делал тонну плохих кадров, просто показывал миру один удачный — отобранный, проявленный, любимый.

Polaroid (а потом и смартфоны) сняли барьер: люди начали фотографировать всё подряд. Из этого родилась и эстетика, и мусор. Потом пришёл Instagram: сначала «вау, какие красивые ленты», потом — океан снимков всего на свете, включая странные ноги на фоне ковра. И снова: те, кому было интересно, прокачались, нашли стиль, построили аккаунты с эстетикой — а остальное растворилось в шуме.

С нейросетями сейчас ровно тот же цикл, только быстрее и громче. У инструмента нет вкуса, нет контекста и нет ответственности — они появляются у человека, который этим пользуется. Поэтому сначала будет много трэша (он уже есть), много дешёвых решений «на отвали», и много поводов сказать: «Вот видите, это всё обман и деградация».

Но история технологий обычно не про «запретить», а про «переболеть». Вспомни ранний YouTube: заливали вообще всё, качество было местами болезненным, а потом аудитория проголосовала вниманием — и выжили те, кто научился делать хорошо. Вспомни переход игр из 2D в раннее 3D: легендами стали единицы, а кладбище проектов — огромное. Это не потому что 3D “плохой”, а потому что сначала им не умели пользоваться.

Вывод простой и слегка неприятный: чтобы из новой технологии всплыло качество, миру придётся какое-то время тонуть в количестве. Если постоянно бить по рукам за любую попытку «сделано нейросетью», мы не остановим неизбежное — мы просто отодвинем момент, когда появятся грамотные практики, нормы и вкус.

Технология сама по себе никого не спасает и не портит — всё решает то, как она встраивается в жизнь и работу.
​

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

Ненапряжное чтиво про коммуникацию во всех её проявлениях — от карьеры до личных отношений.
​
Авторы разбирают от базовых приёмов (активное слушание, чёткое донесение мыслей) до продвинутых — чтение языка тела, выявление скрытых мотивов, управление конфликтами и влияние на людей. Особо выделяются главы про невербальные сигналы: как читать между строк в словах и жестах собеседника. Практика показывает — это сложный скилл, которым владеет мало кто, а потом удивляются: вроде услышали, но не поняли, что имел в виду другой.

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

Я редко пользуюсь плагинами — дефолтной Figma в большинстве случаев хватает. Но есть несколько штук, которые живут у меня в проектах годами, и один из них — SBOL Typograph.​

SBOL Typograph — это плагин, который разбирает кириллический текст по правилам типографики: чинит «е/ё», расставляет нормальные кавычки, приводит телефонные номера и числа к адекватному виду, добавляет неразрывные пробелы и ещё кучу мелочей, про которые вспоминаешь только когда их нет. По сути, он делает вид, что ты заботишься о русском языке сильнее, чем о дедлайне.​

Когда пригодится:

• У тебя серия макетов с простынями текста, а вручную проверять каждую запятую хочется меньше, чем верстать лендинг для Internet Explorer. Запускаешь плагин — и большая часть типографического ада испаряется.​
• Копирайтер присылает текст, уверяет, что закончил филфак, но в письме прямые кавычки, минусы вместо тире и ни одного неразрывного пробела. Ты запускаешь SBOL Typograph, смотришь на результат и такой: «Ну ладно, филфак засчитываем плагину».​

Медийность против ремесла

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

Можно сколько угодно собирать лайки за красивые кейсы и лекции, но если каждые 1–2 года ты меняешь компанию и нигде не доводишь продукт до внятного состояния — это звоночек. Делать классный продукт и одновременно быть публичной звездой почти нереально хотя бы первые 10–15 лет карьеры.

Почему ваше красивое портфолио — мусор

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

• Контент всегда грязный, разной длины и часто некрасивый.
• Продуктовый менеджер сам до конца не понимает бизнес‑требования.
• У бэка половины данных просто нет, а фронт не знает, как сверстать вашу «божественную тень и размытие».
• Никто не даёт вам полгода, чтобы полировать один экран до состояния дриббла.

Сделать кейсы «как на Dribbble» с нулевого уровня обучения можно научиться делать за 6–18 месяцев. А вот сделать удобный, рабочий интерфейс под реальные ограничения, реальные данные и реальную команду — это совсем другой уровень.

Откуда берётся нормальный дизайнер

Для этого нужны не «курсы за три месяца», а 6–8 лет плотной работы в командах. Нормальный боевой опыт — это:

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

Рисовать можно научить обезьяну. Делать продукт в реальных ограничениях — нет.

Чек-лист: как не въебаться при поиске дизайнера

Портфолио только с Dribbble/Behance

Увидели набор идеальных концептов без реальных продуктов, метрик и объяснений задач — сразу минус. Такой человек с очень маленькой вероятностью сделает из вашего говно‑контента что-то рабочее. Картинку — да. Продукт — вряд ли.

Портфолио только на английском, без кириллицы и реальных данных

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

«Сеньор» через 3 года карьеры

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

Не говорит про ресурсы и деньги

Если в презентации себя и на собеседовании человек вообще не затрагивает тему сроков, стоимости решений и цены итераций — это красный флаг. Такой дизайнер легко может рисовать концепты по 3–4 месяца, пока вы тратите миллионы на то, что должно было решиться за пару часов sanity‑чека.

Не может объяснить, как работал с реальными ограничениями

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

Не задаёт вам вопросов

Хороший дизайнер на интервью сам лезет в суть: спрашивает про продукт, метрики, процессы, стейкхолдеров, стек разработки. Если ему вообще ничего не интересно, кроме «удалёнка есть?» и «какой стек у дизайнера», — вы для него просто ещё один строчка в резюме.

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

Недавно прочитал книгу:
«Дизайн в масштабе. Создание устойчивой дизайн-системы».

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

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

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

И тут я подхожу к главному. На Хабре видел статейку, где отзывы об этой книге оставила пара моих знакомых — ну прям восторженные отзывы.
У меня к вам вопрос: вы вообще её читали?

Давно что-то я не писал про прочитанные мной книги — много всего произошло за последнее время: смена работы (даже парочка смен), в личной жизни перемены и т.д. Поэтому тут были только мемасы — мемасы бесплатные для ментального ресурса.

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

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

Но выяснилось, что Джон не просто там собирал эти законы, а по итогу выпустил книгу, в которую собрал самые часто встречающиеся нарушения UX-законов среди цифровых продуктов. А я люблю кейсы, в которых описывают проблемы и частые ошибки — тем и живу. Книга в оригинале называется Laws of UX, как ни странно, да.

И вот оказалось, Джон не отказал ребятам из России в переводе книги и даже официально разместил ссылку на неё у себя на сайте. Мы такое уважаем — и покупаем.
Фух, предыстория закончилась. Теперь о книге.

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

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

В общем, лёгкое и приятное чтиво. Советую к прочтению.

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

А на деле получается ебаный Франкенштейн. В 99% случаев такой дизайн мёртв на старте: элементы не дружат, всё рассыпается, работать с этим невозможно.

Как жить по принципу «воруй как художник»? Всё просто: когда что-то хочется позаимствовать, разберись как и зачем это работает. Почему сделали именно так. В процессе разборки качается не только насмотренность, но и понимание сути решений. А это уже другой уровень. Не забывайте: дизайн-системы наследуются не только визуально, но и функционально.

А если не получается — признайте свой уровень и сделайте дизайн так херово, как у вас выйдет. Это честнее. Читерство, знаете ли, не помогает расти.

Тут есть интересная аналогия с «бизнесменами из 90-х». В нулевых многие пытались легализоваться, но почти все прогорели. Отсюда и эти уродливые бизнес-центры, заборы-крепости и «дворцы» странной архитектуры. Почему? Потому что люди считерили, но знаний и культуры для нового уровня у них не было.

В общем: воровать можно, но не картинки. Воруйте механики. А лучше — развивайтесь своим темпом. Медленно, но честно.

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

Однако по законам развития невозможно всё время быть первым. И теперь, в 2025 году, мы видим, что уровень дизайна у разных компаний приблизился: кто-то делает лучше, кто-то — хуже, но в целом срез уже не так разительно отличается.

Что касается нового визуального языка — скорее всего, он действительно будет удобным. Но работать он будет только в рамках самой экосистемы Apple, потому что требует тесной интеграции железа и софта. Попытки воспроизвести такой подход со стороны других производителей, скорее всего, приведут к вторичности и потере качества.

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

Ошибка 1 – Предполагать, что разработчик всё знает

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

Решение:

• Разработчики не могут читать ваши мысли; чётко указывайте все детали.
• Избегайте недопонимания и будьте конкретны.

Ошибка 2 – Вести разговоры о дизайн-проекте в разных местах

Это классика любой команды. У вас ведь есть Jira? И, наверное, рабочий чат? А ещё в столовой что-то обсудили или на созвоне решили выпилить функционал? Такое бывает у всех. Теперь представьте, что это было в пятницу. В понедельник вы приходите выполнять задачу, а артефакты находятся везде, и какая-то часть потерялась. В итоге либо идёте по второму кругу, либо упускаете важные моменты при выполнении задачи.

Решение:

• Обсуждения должны вестись в контексте инструмента для дизайна или разработки. Всё, что написано в чатике или сказано в столовой, должно быть сразу перенесено в Jira (или аналогичный инструмент).
• Фиксируйте все решения в Figma или спецификациях, чтобы информация была доступна всем участникам.

Ошибка 3 – Не обновлять технические требования после изменений в дизайне

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

Решение:

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

Ошибка 4 – Не привлекать разработчиков на ранних этапах проектирования

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

Решение:

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

Ошибка 5 – Отсутствие организованного файла с дизайном

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

Решение:

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