Привет! Меня зовут Вадим, я проектирую интерфейсы в InfoWatch. Но сейчас не о том, как мы строим интерфейсы, а о том, как мы строим дизайн‑культуру. Я расскажу о нашем двухлетнем пути, полном ошибок и открытий, который привел к реальным изменениям в продуктах и работе команды.
В этой статье расскажу:
как мы за два года прошли путь от оформительства до полноценного дизайн‑процесса
какие грабли собрали
что реально изменилось в продуктах и в работе команды
как убедить коллег, что дизайн — это важно (спойлер: надо говорить на языке бизнеса)
Это не будет очередной теоретической статьей про «как надо». Только реальный опыт и — самое главное — конкретные примеры того, что сработало именно у нас.
Когда два года назад мы начали формировать основы дизайн‑культуры, были обозначены ключевые направления для развития. В частности:
продуктовые решения зачастую принимались без предварительной проверки гипотез на пользователях, что увеличивало риск неэффективных изменений
отсутствие единой дизайн‑системы приводило к визуальной и функциональной несогласованности интерфейсов
практика регулярных дизайн‑ревью не была встроена в рабочие процессы
UX‑методологии не воспринимались как значимый фактор при принятии решений.
Фокус на этих областях стал отправной точкой для построения более зрелой и устойчивой продуктовой среды.
Так вот, дизайн-культура — что это?
Под «дизайн‑культурой» часто понимают что‑то абстрактное. На практике всё проще. Дизайн‑культура начинается не тогда, когда у вас есть Figma и дизайн‑система, а когда вся команда (не только дизайнеры!) начинает думать о пользователе.
Почему это сложно внедрить? Потому что требует переключения мозга:
от «надо быстрее зарелизить» → к «надо сделать удобнее»
от «у нас особенные пользователи» → к «давайте проверим»
от «дизайнеры рисуют» → к «дизайнеры решают проблемы»
Зачем это бизнесу?
Когда мы только начинали, мне казалось, что главная цель — сделать дизайнеров «крутыми и важными». Но потом до меня дошло: дело не в наших амбициях, а в том, чтобы продукты реально стали лучше.
Для это мы:
Связали дизайн с бизнес‑целями. Каждый дизайнерский выбор должен решать конкретную задачу и приносить реальную пользу. Это не про «красивости», а про результат, который улучшает показатели продукта.
Создали прозрачность. Дизайн не должен быть тайной за семью печатями. Нужно показывать, как принимаются решения, делиться исследованиями и объяснять, почему тот или иной сценарий имеет значение.
Синхронизировались с разработкой. Понимание особенностей технологий компании — важная составляющая в проектировании. Это помогает избежать конфликтов между идеями и их реализацией, делает работу с командой разработчиков более слаженной.
Развивали доверие через коммуникацию. Важно не только делиться своими идеями, но и слушать коллег. Это создаёт общее понимание и укрепляет сотрудничество.
Построить такую культуру — это не просто задача, а необходимый фундамент для роста компании. Это основа для создания качественных продуктов и удержания лидерства на рынке.
Такие разные дизайнеры
Если бы у нас работали только «творческие» дизайнеры, все бы до сих пор считали, что мы про «перекрашивание» макетов.
Представьте, если бы мы приходили с идеями типа «Давайте сделаем неоновые кнопки!» (потому что модно). Скорее всего нас бы просто задвинули в угол «рисовать по ТЗ» или в лучшем случае — терпели как неизбежное зло.
Почему дизайнеры‑«технари» прокатывают? Потому что они:
хорошо справляются с навигацией в сложных сервисах — становятся своего рода архитекторами приложения
проектируют масштабируемые решения
предлагают решения в рамках техвозможностей
говорят не «мне кажется», а «исследования показывают» или хотя бы ориентируются на паттерны
Реальный пример из практики. Когда мы впервые пришли с предложением, что исследования макетов сэкономят компании деньги на разработке и показали, как это работает — даже самый скептичный продакт‑менеджер заинтересовался. Значительно выгоднее тестировать функционал на прототипах, чем запускать в продакшн фичу, которая, возможно, и полезна, но из‑за плохого UX будет непонятна пользователям.
В B2B дизайн выживает только когда:
решает конкретные бизнес‑задачи
не создаёт лишних проблем разработке
может доказать свою ценность в цифрах
(И да, это немного грустно для романтиков от дизайна).
Что уже сделано
Шаг 1. Создание дизайн-системы
На старте уже было какое‑то количество компонентов, но дизайн‑система все еще находилась в зачаточном состоянии и практически не использовалась. Мы начали с нуля: создали базовые принципы типографики, цветовые палитры. Пересобрали и модернизировали старые компоненты, а также добавили новые.
Важно было не просто собрать систему, но и сделать её удобной для интеграции с разработкой. Для этого дизайнеры плотно взаимодействовал с командой разработчиков, сопровождая их на каждом этапе. Разработка подключила парсер компонентов из Figma, что с одной стороны значительно упростило интеграцию, но также потребовало дополнительной проработки компонентов. Также пришлось тщательно адаптировать компоненты в Figma, чтобы их структура максимально соответствовала требованиям парсера.
Шаг 2. Организация макетов в Figma
Мы с коллегой‑дизайнером навели порядок в макетах: создали архитектуру разделов для каждого продукта, разобрали макеты на сценарии (включая граничные случаи), ну и, конечно же, теперь все собрано на автолейаутах и с использованием дизайн‑системы. Теперь у нас есть полный набор: «пустое состояние», «ошибка», «много данных», «мало данных». Это помогло команде лучше понимать, как интерфейс будет выглядеть в реальной жизни.
Шаг 3. Введение дизайн-ревью
Ранее дизайн‑ревью не проводилось вообще. Это приводило к тому, что решения оставались недоработанными, а интерфейсы выглядели неаккуратно. Мы предложили формат проведения дизайн‑ревью и внедрили его в процесс.
Шаг 4. Начало пользовательских исследований
Исследования — это то, без чего сложно делать качественные продукты. На старте мы решили не пытаться охватить сразу все восемь продуктов, а сосредоточиться на одном, чтобы протестировать гипотезы и показать пользу подхода. При этом исследования на кликабельных прототипах проводились ранее, но несистемно.
Сложности на пути
Когда я только начинал работать, то был уверен: достаточно иметь крутую идею и железную логику — и все сразу поймут мою правоту. Но, как выяснилось, этого недостаточно. В первые месяцы много времени ушло на переговоры с коллегами и самим собой.
Помню, как приходил на встречи и с горящими глазами предлагал что‑то новое. А в ответ слышал: «клиенты не жалуются», «это замедлит разработку». Я злился, спорил, пытался переубедить — но все равно получал не тот результат, какой хотел.
Тогда я решил полностью пересмотреть свой подход к общению с командой.
Первым делом я перестал давить. Вместо категоричного «Надо так!» начал говорить: «Давайте попробуем на одном модуле». Потом я нашёл союзников среди разработчиков — оказалось, многие тоже хотели изменений, но не хотели действовать в одиночку. Мы стали работать вместе, и это дало первые результаты.
Мы научились говорить на языке пользы для бизнеса. Например: «Исследования смогут сэкономить часы разработки», «Дешевле протестировать гипотезу на макетах, а потом уже переводить в продакшен». Также научились принимать компромиссы — где‑то уступать в мелочах, чтобы выиграть в главном.
Некоторые люди, которые раньше сопротивлялись любым изменениям, теперь сами подходят к дизайнерам. Они просят помочь с UX, рекомендуют нас новым сотрудникам и даже предлагают свои идеи по улучшению!
Теперь я точно знаю: чтобы добиться изменений, нужно не только иметь правильные решения, но и запастись терпением и научиться слушать. Даже самый крутой дизайн ничего не стоит, если команда в него не верит.
Результаты
Оглянувшись на два года работы, могу с уверенностью сказать: изменения произошли, и они заметны не только мне, но и многим в команде.
Изменение отношения к дизайну
Одним из самых значимых достижений стало изменение восприятия дизайна внутри компании (пока что не во всех командах, но процесс запущен). Если раньше дизайн воспринимался как «мастерская красоты», то теперь он стал полноценной частью процесса разработки. Коллеги начали больше доверять дизайнерам и понимать, что их работа напрямую влияет на успешность продуктов.
Продуктовые команды постепенно адаптировались к новым процессам, и некоторые из них стали открыто поддерживать изменения. Высшее руководство отметило, что внешний вид наших интерфейсов выгодно выделяет нас на фоне конкурентов и наши клиенты выбирают нас в том числе и по дизайну.
Влияние на бизнес-результаты
Хотя рост прибыли компании нельзя объяснить только улучшением дизайна, я уверен, что дизайн внёс свой весомый вклад. Теперь мы лучше понимаем потребности пользователей, быстрее запускаем новые функциональности и делаем интерфейсы более интуитивными.
Первые шаги в пользовательских исследованиях
Исследования пользователей с кликабельными прототипами внедряются постепенно, пока только в рамках одного продукта. Однако результаты уже показывают, насколько важны данные, основанные на реальных потребностях и поведении пользователей.
Следующим шагом будет масштабирование этой практики на другие продукты.
Системный подход в работе с макетами
Мы пересмотрели подход к созданию макетов. В Figma всё стало упорядочено: макеты организованы по сценариям, включая граничные состояния (много данных, отсутствие данных, ошибки и т. д.). Использование автолейаутов и работа с компонентами из дизайн‑системы стали стандартом. Теперь любой дизайнер может легко понять, как устроены макеты у коллеги, и внести изменения без потери времени на разбор.
Единай дизайн-система
На старте дизайн‑система была лишь на бумаге, но теперь она стала полноценным инструментом, которым пользуются все дизайнеры и разработчики. Интерфейсы всех продуктов стали унифицированными: кнопки, поля ввода, таблицы и другие компоненты теперь выглядят и работают одинаково. Это позволило сократить время на разработку на ≈25% новых интерфейсов, упростить процесс поддержки существующих продуктов и уменьшить количество багов.
Введение дизайн-ревью
Дизайн‑ревью стало обязательной частью процесса. Это помогло не только улучшить качество интерфейсов, но и повысить уровень взаимодействия внутри команды. Разработчики начали замечать, что интерфейсы стали более аккуратными, логичными и удобными.
Планы на будущее
Несмотря на значительные изменения, которые уже произошли, впереди ещё много работы. Вот ключевые направления, на которых я хотел бы сосредоточиться.
Масштабирование исследований пользователей
Сейчас пользовательские исследования проводятся по инициативе продакт‑оунера. В компании есть отдельный человек, который занимается исследованиями. Хотелось бы дизайнера включить в этот процесс, добавив к этому кликабельные прототипы. И пока только в одном из восьми продуктов появляется этот процесс, их результаты уже заметны. В планах — сделать эту практику стандартом для всех продуктов.
Для этого необходимо:
Убедить ключевых стейкхолдеров в ценности исследований.
Разработать удобный процесс для проведения интервью, анкетирования и тестирования.
Исследования помогут нам лучше понимать аудиторию и создавать интерфейсы, которые не просто эстетичны, но и эффективно решают задачи пользователей.
Развитие дизайн-культуры внутри команды
Дизайн‑культура — это не только процессы, но и отношения. Я вижу важной задачей создание атмосферы, в которой каждый дизайнер чувствует себя значимым участником процесса, а не формальным исполнителем.
Внедрение метрик для оценки дизайна
Одно из направлений — внедрение метрик, которые помогут объективно оценивать эффективность дизайна. Это могут быть различные метрики уровня удовлетворённости пользователей
Выводы
Подводя итоги работы по становлению дизайн‑культуры, я могу сказать, что это был нелёгкий, но невероятно ценный опыт. Он показал, насколько важна роль дизайна в процессе создания цифровых продуктов, и подтвердил, что изменения возможны даже в сложных условиях. Однако чтобы пройти этот путь, важно быть готовым к определённым вызовам и иметь чёткий план действий.
Слушайте людей, но оставайтесь последовательными
Изменения, особенно в крупных компаниях с устоявшимися процессами, не происходят быстро. Люди будут сопротивляться, не понимая ценности нового подхода. Моё главное открытие здесь — важно учитывать человеческий фактор. Не давите, не торопите, но оставайтесь последовательными в своих действиях.
Ищите союзников
Один в поле — не воин. Выстраивайте доверительные отношения с коллегами из других отделов: разработчиками, аналитиками, продакт‑оунерами. Постепенно они начнут видеть в вас эксперта, чьё мнение стоит учитывать.
Старайтесь смотреть вперёд
Дизайн — это не только про настоящее, но и про будущее. Всегда держите в голове, как ваши решения повлияют на продукт через год или два. Например, закладывайте масштабируемость в дизайн‑систему, проектируйте навигацию интерфейса с учётом расширения разделов, новых функций и т. д.
Берегите свои силы
Работа по трансформации процессов может быть эмоционально выматывающей. Постоянная борьба за изменения, сопротивление со стороны команды, желание сделать всё идеально — всё это требует много энергии.
В заключение
Идеальную дизайн культуру за 2 года выстроить, конечно, все еще не удалось, но уже есть крепкий фундамент и существенные позитивные подвижки в эту сторону. Возможно, вы внедряли дизайн‑культуру в своей компании или только собираетесь это сделать. Я был бы рад узнать о вашем опыте.
С какими трудностями вы столкнулись?
Какие подходы оказались наиболее эффективными?
Что в итоге удалось изменить, а что осталось без изменений?
Делитесь своими историями и советами в комментариях!
Вадим Корольков
Ведущий дизайнер интерфейсов в InfoWatch
