{"id":13455,"url":"\/distributions\/13455\/click?bit=1&hash=8bce2c32fc522b9cfe1ab89089eff75ab558dbec8812c3dda390faecf1c743f2","title":"\u00ab\u0410 \u0442\u044b \u0442\u043e\u0447\u043d\u043e \u0440\u0438\u0435\u043b\u0442\u043e\u0440?\u00bb \u0438 \u0434\u0440\u0443\u0433\u0438\u0435 \u043d\u0435\u043b\u043e\u0432\u043a\u0438\u0435 \u0432\u043e\u043f\u0440\u043e\u0441\u044b \u0431\u0440\u043e\u043a\u0435\u0440\u0443","buttonText":"\u041f\u043e\u043a\u0430\u0436\u0438\u0442\u0435","imageUuid":"ca4cf1a1-a5ed-5aca-9f34-357accc11bb1","isPaidAndBannersEnabled":false}
Дизайн
ManyChat

Зачем нужен дизайн-менеджер и как им стать

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

Кому статья может быть полезной?

  • начинающим дизайнерам, которые рассматривают свою карьеру в IT-компаниях и в стартапах в частности и хотят иметь представление о том как устроены процессы;

  • ведущим дизайнерам, кто стоит перед выбором, стоит ли двигаться в сторону дизайн-менеджмента, и хочет узнать, какие есть нюансы;
  • действующим дизайн-менеджерам/дизайн-директорам, кому интересно взглянуть на процессы со стороны;
  • владельцам стартапов, которые активно растут и как компания, и как продукт, и хотят понимать, с чем придется столкнуться с точки зрения «подводных камней» в дизайне в скором времени.

Reason to believe

  • мне посчастливилось пройти важнейшие этапы становления компании от стартапа в 14 человек до международной компании в 160+ человек;

  • я побывал на разных ролях: продуктовый дизайнер, арт-директор, ведущий продуктовый дизайнер, персональный ментор, ментор дизайн-комьюнити, дизайн-менеджер;

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

Пару слов о компании

ManyChat — это платформа для общения компаний со своими клиентами через мессенджеры: Instagram, Facebook Messenger, WhatsApp, Telegram. Мы помогаем в решении таких задач, как маркетинг, продажи и поддержка. А наша миссия — это помогать бизнесам расти, выстраивая осмысленные отношения со своими клиентами.

Впервые я услышал о ManyChat в 2016 году, когда рисовал для ребят логотип. На тот момент я был весьма далек от IT и о стартапах было представление только по сериалу Silicon Valley, поскольку я работал арт-директором и дизайнером в рекламном агентстве. Но уже через год, в июне 2017, я присоединился к ManyChat в качестве продуктового дизайнера. На тот момент вся команда ManyChat состояла из 14 человек, ребята работали удалённо и всё делали вместе, в общем, это был самый настоящий стартап.

C того момента изменилось многое — мы как команда выросли до 160+ человек и продолжаем расти; как компания подняли раунд А в Кремниевой долине и нацелены стать компанией «единорогом»; как продукт стали платформой № 1 для мессенджер-маркетинга.

Эволюционный подход к роли

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

2017 г.

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

2018 г.

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

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

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

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

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

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

И перед нами встал выбор:

1. Нанять опытного дизайн-менеджера/дизайн-директора, который бы помог выстроить процессы.

2. Пройти этот путь самостоятельно.

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

Давайте здесь я ещё подробнее расскажу о ролях, которые у нас оформились к 2018 году:

  • продуктовый дизайнер/personal contributor — это основная роль, в которой дизайнер работал в рамках своей продуктовой команды и отвечал за командный результат по дизайну;

  • ведущий дизайнер/lead product designer — тоже находился в продуктовой команде и тоже отвечал за результат команды в первую очередь. Но есть пару отличий от основной роли: как правило ведущий дизайнер занимался стратегическими продуктовыми изменениями, которые необходимо было делать быстро и желательно качественно, плюс оказывать помощь/супервайзить дизайнеров из других продуктовых команд;

  • ментор дизайн-комьюнити/design community mentor — новая и непонятная на тот момент для нас роль, ментор комьюнити должен был консолидировать дизайнеров из разных продуктовых команд и предлагать (ключевое слово предлагать) какие-то изменения на уровне комьюнити, например, обсуждение дизайн-принципов.

К концу 2018 команде в ManyChat было 6 дизайнеров.

2019 г.

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

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

Так к середине 2019 года у дизайн-комьюнити появился первый значимый результат, который стал заметен внутри всей компании:

1. Был выстроен процесс дизайн-ревью, когда все дизайнеры стали вовлекаться в оценку дизайн-решений команд (механику опишу чуть ниже). Это позволило кардинально снизить количество комментариев от CEO и не блокировать результаты продуктовых команд.

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

К концу 2019 года успехи дизайн-комьюнити дополнились следующими результатами:

  • были формализованы UI принципы, что позволило повысить качество дизайн-решений, они стали консистентными. Часть этих дизайн-принципов мы подсмотрели у дизайн-комьюнити Intercom и дополнили UX эвристиками Якоба Нильсена. На данный момент у нас 9 таких принципов.

Вот эти принципы:

— Подсказывайте пользователю, что можно сделать дальше;

— Задавайте иерархию;

— Поддерживайте цельность, будьте консистентными;

— Интерфейс должен откликаться при взаимодействии с пользователем;

— Думайте шире. Думайте об изменениях которые вносите в продукт;

— Используйте привычные решения;

— Будьте дружелюбными;

— Будьте последовательными;

— Будьте доступными;

Каждый из этих принципов мы дополнили примерами и описанием.

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

3. Была проделана работа над дизайн-системой. Избавились от большей части legacy-стилей: цвета, шрифты, отступы. Сделали первую версию дизайн-системы: базовые компоненты, типографика, палитра и т. д. Как результат, перестали постоянно собирать макеты из скриншотов.

Это очень сильно помогло нам, поскольку к этому моменту количество дизайнеров увеличилось уже до 11 человек.

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

2020 г.

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

За 2020 год была проделана большая подготовительная работа — были проведены глубинные интервью со всеми стейкхолдерами: продукт-менеджерами, владельцами продуктов, CEO, дизайнерами, инженерами, чтобы синхронизировать и формализовать зону ответственности дизайнера. Для меня было открытием, что на вопросы «кто такой продуктовый дизайнер, что он должен делать и за что отвечать», ответы довольно сильно различались. На тот момент у нас не было точки синхронизации, но после этой работы мы уже смогли заложить и определить набор навыков дизайнеров (skillset), и выделить зоны ответственности дизайнера, которые необходимы именно нашей компании.

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

2021 г.

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

Для дизайн-комьюнити мы определили 5 ролей и прописали соответствующие им обязанности и зоны ответственности:

персональный контрибьютор (отвечает за результат продуктовой команды);

персональный ментор (помогает профессионально развиваться другому дизайнеру);

ведущий дизайнер (отвечает за результат направления, которое может состоять из нескольких продуктовых команд);

эксперт дизайн-комьюнити (предлагает и драйвит улучшения связанные с технической частью разработки продукта: работа над дизайн-системой; работа с UX долгом; улучшение процесса дизайн-ревью и т. д.);

дизайн-менеджер.

Так зачем же нужен дизайн-менеджер?

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

Зоны ответственности:

  • Найм (hiring plan, собеседования, «нанимающий менеджер», финальное решение);

  • Участие в обсуждениях при формировании команд (состав команд/направлений);
  • Performance review — запуск, сопровождение, финализация процесса ревью;
  • Финальные выводы и решения, оглашение результата. Принятие финальных решений про промоушен, увольнение, PIP (performance improvement plan), компенсации;
  • Отвечает в целом за рост и развитие дизайн-комьюнити, стратегия, финализация целей;
  • Отвечает за наличие в команде/продуктовой группе дизайн-компетенции для решения бизнес задач;
  • Отвечает за результат работы всего дизайн-комьюнити;
  • Верхнеуровневый поиск проблем связанный с пользовательским опытом;
  • Помощь в формировании вижна продукта;
  • Помощь продуктовым командам в качестве эксперта в обсуждении, декомпозиции и реализации задач.

Выводы

В качестве выводов хотелось бы рассказать о результатах, которые нам помогла достичь роль дизайн-менеджера:

  • Мы подготовились к дальнейшему росту команды как количественно, так и качественно:

— Формирование карты навыков (skillset). Определили список навыков и их уровень для каждой позиции: это позволило ребятам в командах понимать, в какой точке они сейчас находятся, и наметить вектор развития.

— Помощь в составлении профессионального плана развития (PDP), участие в проведении performance review.

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

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

Советы

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

Совет № 1 | Меняй свой образ мышления.

Любая победа — это победа команды, поражение команды — это твоя неудача.

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

Из книг могу порекомендовать почитать следующее:

1. The Making of a Manager: What to Do When Everyone Looks to You. Julie Zhuo

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

2. Principles: Life and Work. Ray Dalio

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

  • Быть искренним.

  • Принимать слабости и пробелы в знаниях.
  • Не бояться ошибаться и помогать другим осознать их ошибки.
  • Быть ответственным.

Совет № 2 | Прокачивай продуктовое мышление, мысли как Product Owner

Это про понимание того, как дизайн-решения влияют на продуктовые и бизнес-метрики. Всегда задавай себе и другим дизайнерам вопрос: какую проблему мы решаем; как мы поймем, что мы решили эту проблему. Точно ли фокус на этой задаче или проблеме будет сейчас самым важным и полезным? На что это повлияет с точки зрения продуктовых и бизнес-метрик? Глубже погружайся в мотивацию задач и проблематику.

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

  • Начни пользоваться своим продуктом. Это невероятно прокачает понимание пользовательских проблем и даст +25 очков к эмпатии.

  • Еще стоит обязательно дружить с ребятами из поддержки, они являются кладезем болей и можно получить очень много полезных инсайтов.
  • Изучи основные метрики: MAU, ARR, MRR, Churn, ARPPU, ARPPA и т.д., старайся отслеживать их. Это поможет на уровне компании сосредоточиться на том, где больше всего болит. Здесь здорово могут помочь ребята из команды аналитиков или продуктовые менеджеры.

Совет № 3 | Обратная связь — это твой инструмент

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

Книги по теме:

  • Эмоциональный интеллект. Дэниел Гоулман;

  • Трудные диалоги. Керри Патерсон, Джозеф Гренни;

  • Радикальная прямота. Ким Скотт.

Совет № 4 | Наберись терпения и научись играть «в долгую»

Качественные результаты или изменения приходят не сразу. И помимо этого будет допущено еще много ошибок, и много чего не сработает, как хотелось бы, и это абсолютно нормально. Стоит отрефлексировать, сделать выводы, пробовать снова и делать это постоянно. Так постепенно будет виден прогресс.

И еще очень важно учиться правильно распределять свои силы и уметь восстанавливаться. Если будешь стараться делать все сразу и тратить все свои силы по-максимуму, то скорее всего, силы быстро закончатся и ты просто выгоришь потому, что результат работы дизайн-менеджера как правило имеет отложенный эффект. Здесь поможет формирование как личных OKR’s, так и OKR’s дизайн-комьюнити. OKR расшифровываются как «цели и ключевые результаты». Это методология совместной постановки целей, используемая командами и отдельными людьми для постановки сложных, амбициозных целей с измеримыми результатами. OKR – это то, как вы отслеживаете прогресс, обеспечиваете согласованность и поощряете участие в достижении измеримых целей.

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

Совет № 5 | Не становись бутылочным горлышком

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

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

Что это нам дало?

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

  • дизайн-менеджеры не блокируют остальных дизайнеров, если по каким-то причинам не могут дать свои комментарии;

Как результат, прохождение дизайн-ревью и апрув от дизайн-комьюнити стало частью общего процесса разработки продукта и входит в критерии DoD (Definition of Done).

Совет № 6 | Найди ментора

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

0
22 комментария
Написать комментарий...
Вася Барна

Да, достаточно объёмный текст и объёмный путь.
Хотелось бы узнать, сколько часов/дней/времени у рядового дизайнера занимает и занимал процесс - аппрува дизайна? Дизайн ревью? Участия в дизайн коммьюнити?

Участвовали ли рядовые дизайнеры (дизайнеры в командах) в написании инструкций, чек листов и тд?
Если да, то сколько это занимало времени? Если нет - то кто это делал?
Интересуюсь исключительно для получения бенчмарков.
Спасибо!

Ответить
Развернуть ветку
Егор Красноперов

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

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

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

Ответить
Развернуть ветку
Вася Барна

Спасибо за ответы!

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

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

Думаю, это последние вопросы :)

Ответить
Развернуть ветку
Егор Красноперов

Василий, аппрувы могут происходить в любой рабочий день, единственное ограничение это то, что все должно происходить в рамках рабочего дня +-1 час, с 11:00 до 19:00. Иначе есть вероятность, что твое ревью не смогут оперативно посмотреть :)
2. Сначала были комментарии от ребят, что давать комментарии это лишняя трата времени и отвлечение от своих задач, но когда мы увидели и почувствовали ценность от таких ревью, то эти комментарии отпали. На это ушло около 3 месяцев. А ценность заключается в следующем: ревьюверы могут своими комментариями и аргументами повлиять на итоговый результат и сделать его сильнее; все дизайнеры понимают какие изменения происходят в продукте и почему.
И плюс у дизайнера, кто отправляет на ревью макеты есть отличная возможность проверить свое решение на «прочность» и получить советы.

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

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

Ответить
Развернуть ветку
Михаил Лидовский

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

Ответить
Развернуть ветку
Лапа

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

Ответить
Развернуть ветку
Егор Красноперов

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

Ответить
Развернуть ветку
Ivan Tatarov

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

Ответить
Развернуть ветку
Егор Красноперов

Иван, в этой статье как раз и хотелось показать, что конкретно в нашей компании, роль дизайн-менеджера не появилась искусственно или потому что так надо, а появилась в результате роста компании/продукта.

Ответить
Развернуть ветку
Fedor Durdin

Ни одной картинки!! Читать без визуального ряда не хочется

Ответить
Развернуть ветку
Егор Красноперов

Спасибо за обратную связь! Добавили)

Ответить
Развернуть ветку
Alex Ayer

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

Ответить
Развернуть ветку
Егор Красноперов

Alex, cпасибо за вопрос. Тут важный нюанс, в некоторых компаниях арт-директор и есть дизайн-менеджер. В нашем же случае, дизайн-менеджер отвечает за продуктовую часть и плюс у нас еще есть команда бренд/маркетингового дизайна, где есть head of brand design. Но так как у нас разные зоны ответственности, то мы очень органично сосуществуем и зачастую только синхронизируемся между собой.

Ответить
Развернуть ветку
Alex Ayer

Я правильно понимаю, что на западе данную роль, описанную в статье, называют Design Ops?

Ответить
Развернуть ветку
Егор Красноперов

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

Ответить
Развернуть ветку
Roman Solonovich

Текст действительно полезный и интересный, больше бы визуала. А так, спасибо большое ❤️ с рандомайзером крутая идея

Ответить
Развернуть ветку
Егор Красноперов

Спасибо!

Ответить
Развернуть ветку
Sergey Mikhalev

Большая работа! спасибо за статью.

Ответить
Развернуть ветку
Егор Красноперов

Спасибо!

Ответить
Развернуть ветку
Nick Maletskyi

Спасибо, действительно крутая статья.
Если не секрет, а можно взглянуть на Ваши переработанные UI принципы?

Ответить
Развернуть ветку
Егор Красноперов

Nick, спасибо! Я вставил скриншот с одним из принципов и перечислил остальные тезисно, + дополнительно вставил ссылки на источники. По сути, мы сделали компиляцию, которая именно для нас имеет смысл на данном этапе, никакого rocket science)

Ответить
Развернуть ветку
Nick Maletskyi

окей, спасибо :)

Ответить
Развернуть ветку
Читать все 22 комментария
null