Денис Бессонов

Тревога любит бездействие

2026-02-14T08:00:38.300Z

Осознание утра (без соплей): тревожность — это топливо. Просто большинство жжёт его вхолостую.

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

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

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

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

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

Нейронные сети, или Как перестать бояться и полюбил бомбу

2025-12-29T06:05:15.132Z

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

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

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

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

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

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

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

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

Я почитал и вам советую: Как сказать. Главная книга по развитию коммуникативных навыков

2025-12-29T06:03:20.638Z

Ненапряжное чтиво про коммуникацию во всех её проявлениях — от карьеры до личных отношений.

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

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

Действительно полезный плагин для Figma SBOL Typograph

2025-12-05T06:22:23.170Z

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

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

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

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

Главное отличие хорошего дизайнера от плохого, и как не въебаться при найме

2025-12-01T05:15:05.862Z

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дизайн в масштабе. Создание устойчивой дизайн-системы

2025-11-28T10:22:07.528Z

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

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

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

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

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

Прочитал и вам советую прочитать: «Законы UX-дизайна»

2025-08-21T12:29:24.897Z

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

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

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

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

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

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

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

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

О том, почему нельзя просто в тупую пиздить чужие дизайн-решения

2025-08-21T12:27:24.888Z

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

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

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

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

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

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

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

Мысли о редизайне Apple

2025-06-10T06:45:13.693Z

Новый взгляд.
Еще больше магии.

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

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

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

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

Пять промахов продуктового дизайнера, тормозящих команду

2025-06-08T11:15:50.245Z

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

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

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

Решение:

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

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

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

Решение:

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

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

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

Решение:

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

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

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

Решение:

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

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

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

Решение:

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