Три вещи, которые стоит прокачать дизайнеру в продуктовой команде

Знание кода помогает дизайнерам делать продукты реалистичнее и понятнее для разработки — это факт. Но что именно прокачивать?

Вот, с чего советует начать лид-дизайнер Brele Виктор Тимофеев.

🔣 Понимание вёрстки (HTML/CSS)

Флексбоксы, гриды, медиа-запросы. Это поможет не рисовать 10 экранов, а сделать 2-3, зная, как они будут растягиваться и сжиматься.

🔣 Знание возможностей и принципов JS

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

Когда дизайнер понимает основы JS, он может заложить всю эту логику заранее — и тогда интерфейс получается не декоративным, а работающим по реальным пользовательским сценариям.

🔣 Умение давать пояснения

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

А вы что бы добавили в этот список? Какие навыки и знания, по вашему опыту, помогают дизайнерам лучше понимать разработку? Делитесь в комментариях 👇

Иногда размывать границы между ролями в команде — это хорошо!

Знаете, за что я больше всего ценю разработчиков, которые понимают UX? Они работают не просто по макету или как в ТЗ написано — они смотрят дальше и шире.

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

И что эта синергия даёт проекту?

✅ Предсказуемость

Когда разработчик понимает UX, он работает не просто с макетами, а с заложенными в них сценариями. Дизайнер показывает макет формы, а фронтендер сразу видит за ним не просто поля и кнопки, а логику: валидацию, загрузку данных для списков, прелоадер и сохранение частично заполненных форм. Он задаёт нужные вопросы, понимает объём работы и даёт адекватную оценку.

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

✅ Меньше переделок

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

✅ Меньше подвисаний

Когда разработчик понимает UX и основы дизайна, он не застревает, если в макете чего-то нет. Может сам реализовать недостающие состояния или ветки сценария — так, чтобы это соответствовало общей логике и стилю интерфейса. В итоге работа не стопорится, и продукт развивается без пауз.

✅ Нормальный диалог

Когда разработчик и дизайнер понимают базовые принципы работы друг друга, исчезают бесконечные «что вы тут нарисовали, это же полгода делать!» или «а почему тут не по макету?». Вместо споров — разговоры про сценарии и решения: как сделать проще, понятнее и быстрее в реализации.

И самое важное: чтобы этот диалог происходил на этапе проектирования, а не постфактум.

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

У нас так было на проекте «Цессионарий» — это внутренний сервис, где дизайн изначально даже не закладывали, были только прототипы. Наш фронтендер по собственной инициативе проработал визуал, сделал логотип, подобрал библиотеку компонентов и адаптировал её под систему. Клиент этого не ожидал, но был приятно удивлён: система получилась не только удобной, но и визуально приятной. А чуть позже «Цессионарий» занял третье место на Tagline Awards.

В итоге всё сводится к одному: чем лучше дизайн и разработка понимают друг друга, тем ровнее и быстрее идёт работа над продуктом. Согласны?😉

#продуктоваякоманда #продуктоваяразработка

Как разработчику начать видеть интерфейсы глазами дизайнера: рекомендации от Андрея Степанова

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

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

➕ «Психбольница в руках пациентов» Алана Купера

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

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

Прочитав книгу, вы поймете (вероятно, с некоторым сожалением), что UX-дизайнер в команде главнее разработчика. Но еще главнее — пользователи, их контекст, потребности и сценарии.

➕ «Пользовательский интерфейс» Ильи Бирмана

Это уже про конкретные принципы и законы интерфейсов. Лучший современный учебник с интерактивными примерами, который объясняет, как устроены типовые элементы интерфейса и на что важно обращать внимание при их реализации.

Хорошая альтернатива — «Интерфейс. Основы проектирования взаимодействия» того же Купера.

Что еще стоит изучить

Я бы рекомендовал всем фронтенд- и фулстек-разработчикам разобраться с основами типографики, модульными сетками и законами композиции. Это помогает лучше понимать дизайнеров и видеть интерфейсы не как набор блоков, а как целостные конструкции.

А что бы вы посоветовали разработчику, который хочет прокачать UX?

#продуктоваякоманда #продуктовыйразработчик

Дизайн VS Разработка: финальной битвы не будет ☮️

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

✅ Продуктовый дизайнер понимает, как живёт интерфейс в коде

Знание разработки помогает ему создавать решения, которые не рассыпаются при реализации: понятные для команды, предсказуемые и технически выполнимые.

✅ Сильный разработчик считывает в макете замысел и UX-логику

Понимание основных принципов UX позволяет ему видеть за макетом пользователей и их сценарии взаимодействия с интерфейсом. А значит, он не просто компилирует картинки в код, а по-настоящему оживляет макеты, превращая их в продукт.

✅ Лучшие продукты рождаются там, где дизайн и разработка не сепарируются друг от друга, а наводят мосты

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

На случай, если вы пропустили весь «разговор», вот, что происходило на нашем канале последние две недели:

➖ Лид-дизайнер Brele Виктор Тимофеев рассказал, почему дизайнеру важно и нужно разбираться в разработке хотя бы на базовом уровне, а также посоветовал, с чего стоит начать прокачку, если нужных знаний еще нет.

➖ Техдир fuse8 Андрей Степанов поделился взглядом со стороны разработки: почему разработчику нужно понимать UX и что стоит изучить, чтобы начать видеть интерфейсы глазами дизайнера.

#продуктоваяразработка #дизайн #продуктовыйразработчик #продуктоваякоманда

Встречаемся на Спорт Бизнес Конгрессе уже в эту пятницу!

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

Спорт в России стал очень технологичным, и мы хотим поделиться своим крутым опытом в работе с данными и цифровизацией для этой сферы на Спорт Бизнес Конгрессе 28 ноября. В прошлом году мероприятие собрало 1884 участника, 39 сессий и более 50 часов контента. Это одна из немногих площадок, где можно открыто обсудить цифровую трансформацию спорта с теми, кто действительно двигает его вперед через технологии, аналитику, новые сервисы и управленческие решения.

Мы выступим в рамках секции «Big Data = Big Win. Как большие данные и технологии помогают спортивному бизнесу зарабатывать». Как раз этот вектор мы прорабатываем в продуктах, включая Freedom Football Manager. Вот на примере FFM и расскажем, как цифровизация тренировочного процесса помогает юным спортсменам и тренерам развиваться быстрее и эффективнее, а аналитикам лиги — работать с данными проще и точнее. Это — наш способ внести вклад в развитие спортивной отрасли, которой мы искренне интересуемся и в которую верим.

Если будете на Конгрессе, будем рады пересечься и обменяться опытом или просто поболтать 🙂

🔣 Спорт Бизнес Конгресс 2025
🔣 Когда: 27-28 ноября
🔣 Где: БСА «Лужники», Москва

Любите ли вы демо так, как его любим мы? Сейчас посмотрим.

Что такое вообще демо? Это когда команда раз в спринт приходит к клиенту и говорит: «вот, клиент, смотри, что мы сделали». И ждет фидбек. Так?

Нуууу…нет 🫤

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

Но нельзя просто так взять и решить: «Теперь мы на демо синхронизируемся, а не просто показываем работу». Чтобы демо было продуктовым, а не формальным, важно держаться нескольких принципов.

✅ Демо — не встреча для согласования результатов.

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

✅ Главная цель — понять направление, а не показать результат.

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

✅ Демонстрируют те, кто делает.

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

✅ На демо рождаются идеи, а не формальный фидбэк. И эти идеи нужно не только фиксировать, но и валидировать.

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

А что на ваших демо важнее — показать сделанное или свериться с курсом? Делитесь в комментариях!

#продуктоваяразработка #процессы

Привет! Это Веня. Раз уж мы заговорили о демо, то хочу одну важную тему поднять: что на самом деле есть демо.

Во многих командах, особенно не очень зрелых, демо = приемка результатов, а так не должно работать. Давайте объясню, почему.

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

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

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

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

Хорошее демо проходит спокойно. На нем можно честно сказать, что сделали, что заняло больше времени и что вызывает вопросы. Клиент на таком демо – не экзаменатор, а часть команды. Он помогает скорректировать направление, расставить приоритеты и принимать стратегические решения, от которых зависит релиз.

Согласование – другой процесс. На нем мы формально сдаем результаты работ. Там уместны придирки разной степени дотошности, обсуждение нюансов и разбор деталей. На демо это только тормозит работу. Разбор пикселей и вкусовщины можно и нужно выносить в отдельные созвоны с менеджером или дизайнером, а не трясти всю команду.

Резюмируем. На демо здорового человека нам нужно:

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

Такой формат дает команде пространство работать, а не оправдываться. И каждый новый спринт начинается без ощущения, что впереди еще одна нервная пятница.

Доверим проведение демо самому разговорчивому или самому трудолюбивому❓


Что демо должно из себя представлять разобрались. Но этому всему вроде как нужен ведущий. Это менеджер? Тимлид? Разработчик, который делал фичу? Может вся команда понемногу?

Кажется, на рынке любят искать золотой стандарт, но, если честно, его нет. Порой один человек стабильно ведёт демо, и все в восторге. Видели и обратный вариант, когда весь проектный состав выходит в звонок, и это тоже работает прекрасно.

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

С одной стороны, удобно сделать проведение демо отвественностью одного конкретного человека. Например, проджекта. Но есть нюансы:

🚫 невозможно доподлинно рассказать все за всех, даже если уровень синергии в команде небывало высокий: всегда будут вещи, о которых лучше говорить из первых уст;
🚫 не презентующие участники команды остаются в позции зрителей, хотя делали основную работу.

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

Плюсы заметны сразу:
✅ рассказывать (и слушать) проще, потому что никому не надо заходить в чужую область ответственности;
✅ качество демо растёт, потому что самый классный способ описать проделанную работу – дать слово тому, кто её делал
✅ команда получает шанс показать свой вклад и целиком, и по отдельности, а клиент видит живых людей, а не абстрактный «отдел разработки».


🔣Есть и бонус: демо – это безопасная тренировка публичных выступлений🔣


Мы хоть и ратуем за то, что не должно быть сенсаций на демо, навык презентации на них все равно прокачивается. Клиент понимает, что не на премьере в театре, и реагирует куда спокойнее, чем случайная аудитория на конференции. Для разработчиков (и для начинающих в том числе) появляется хорошая возможность бустануть умение объяснять сложные вещи простым языком.

Да, бывают проекты, где вся команда на демо – не лучший вариант. Бывают и клиенты, которым удобнее выслушать один голос и пойти дальше по делам. Бывают тимлиды, которые блестяще держат структуру и тянут формат в одиночку. И это все окей.

Но если смотреть на долгую дистанцию, мы тут поняли для себя, что прозрачность и качество объяснения выше там, где демо – общая работа.

А у вас как? 🥴

Демо должно быть скучным.

Про то, почему на демо никто не должен ничего согласовывать, уже поговорили, давайте теперь про вау-эффект, которого как будто принято ждать от демо. Кратко говоря, его быть вообще не должно и стремиться к нему не нужно.

Скучное демо — лучший показатель того, что продукт развивается правильно.

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

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

Скучное демо помогает увидеть цельную картину. В спринте мы уделяем внимание частностям, а на демо как бы выныриваем и смотрим сверху: куда уходит время, что реально продвигает релиз, не застряли ли мы где-нибудь. Ну и формальная релизная приемка при условии таких демо более спокойной становится: никакой драмы и правок за два часа до дедлайна.

Для подготовки скучных демо нужно всего лишь:

🔣 оставлять место критическим обсуждениям и корректировкам внутри спринта;
🔣 показывать клиенту промежуточные версии вне демо;
🔣 выносить мелкие правки в отдельный процесс;
🔣 сделать клиента вовлеченным владельцем продукта, а не время от времени приезжающим ревизором.

Формальную приёмку и демо совмещают те, кто любит боль 😈

Это как раз тот случай, когда демо превращается в экзамен. А мы уже говорили, что от такого превращения никому лучше не станет. И продукту вашему — тоже.

Мы разделяем эти вещи принципиально. И вот в чем разница.

Демо всегда проводится раньше и чаще. Условно, релизный функциоанльный блок делается 3 месяца. За это время у нас проходит по меньшей мере 6 демо и вдвое больше других синков. Клиент уже видел промежуточные версии, общался с дизайнером, уточнял сценарии, давал мелкие фидбеки. Нет внезапных разворотов на 180 градусов, потому что всё важное корректируется последовательно в спринтах, а не в последний момент.

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

То есть мы в принципе исключаем возможность того, что очередное демо сорвет релиз из-за каких-то разногласий.

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

Как один стейкхолдер может разрушить полгода работы за пять минут

Привет, на связи Андрей! Хочу немного уделить внимания тому аспекту демо, с которым никому не нравится сталкиваться 😐

Вот вы полгода делаете сервис, демо идут ровно и скучно, команда уверена в курсе. И вдруг на встрече появляется важный стейкхолдер — условный Василий Петрович — и с порога заявляет:

— Что это все вообще такое? Всё не то и всё не так.

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

Что делать в такой момент?

➕ Спокойно поговорите отдельно.

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

➕ Если вопросы серьёзные, повысьте прозрачность.

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

➕ Настройте регулярный формат взаимодействия.

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

В итоге появление Василия Петровича должно перестать быть сюрпризом. И никакого стресса 😉

Последние пару недель получились посвященными процессу демо в продукте. Хоть эту тему, как и многие, можно бесконечно раскручивать на микро-смыслы, мы пока закончим это обсуждение.

Итак, рецепт успешного демо продукта:

🔣 определите его как точку синхронизации всех участников процесса;
🔣 запишите, для чего нужно демо здорового человека;
🔣 решите, кому доверить проведение демо;
🔣 поймите, что скука — ваш друг;
🔣 не забудьте отделить формальную приемку работ от демо-встречи;
🔣 не расстраивайтесь, если Василий Петрович испортил вам всю малину;
🔣 правильно обработайте фидбек, если он появится.

Кажется, мы случайно открыли продуктовый супермаркет и теперь не знаем, как закрыть 😳

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

А потом разговор съезжает не туда. Человек от бизнеса цепляется за решение из чужого проекта и начинает примерять его на себя.
Вместо «какую проблему мы хотим решить» идет обсуждение в духе «давайте внедрим вот это, оно же у них работает».

Есть ощущение, что рынок очень хочет купить историю успеха как готовый продукт.
А продуктовый подход работает по другому: решение формируется из запроса, из конкретной ситуации бизнеса.

Не наоборот: нет смысла запрос формулировать исходя из чужого решения.

Да и вообще под похожую потребность в другой компании может быть нужно совсем другое: проще, сложнее, гибче, полностью уникальное.
Иногда достаточно просто коробки. Бывает что и решение конкурента подойдет.
Но всё это должно опираться на живую потребность конкретной компании, а не на чужое решение.

В такие моменты ощущаю себя кассиром в супермаркете, которого просто просят что-то там с полки достать, а зачем – не рассказывают.
И пытаюсь аккуратно вернуть разговор к процессам, целям и изменениям, которые бизнес реально хочет увидеть.

Хочется понять, насколько эта боль общая.
Сталкиваетесь с таким же «витринным мышлением» на кастдевах?
Как вы возвращаете разговор с полки готовых решений обратно к реальным задачам?

Давайте попробуем собрать коллективный разум.