Процессы в продуктовой дизайн-команде с нуля

Полгода назад я пришла в Instories— это стартап с миллионной аудиторией на платформах iOS и Android. Медиа-редактор для фото и видео обработки и создания контента для соцсетей.

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

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

Дизайнерам

От уровня junior до уровня senior. Вы сможете понять какие процессы существуют в продуктовой команде и как можно их выстроить с нуля. Также вам полезно будет узнать с какими кейсами сталкивается дизайн-менеджер в своей работе.

Начинающим дизайн-менеджерам

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

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

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

Договорённости с менеджером

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

Чек-лист для продакт менеджера

Разработали вместе с менеджером документ и внедрили в 2х командах:

Встречи

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

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

Дизайнер

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

На этом этапе появилось видение, что дизайнер не рад перестройке процессов. Далее это привело к изменениям состава дизайн-команды.

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

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

Дизайн-система

В команде Instories запустилась дизайн-система. Первые несколько месяцев были подготовительными: команда дизайна описывала стили и базовые компоненты. И всё это только на iOS. Когда критическая масса набралась, был выделен отдельны разработчик, который половину времени тратил на развитие ДС на iOS. Платформа Android только запланировала процесс, к сожалению тут мы отстаем по многим пунктам, включая ДС.

Из личных заметок. Оказывается не все разработчики понимали преимущества ДС, такие как чистый код, переиспользуемость элементов, прозначность связки дизайн + код. Поэтому один из разработчиков провел презентацию, и рассказал про пользу системы и собственные лайфхаки.

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

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

Дизайн ревью

Договорились, что дизайнер тратит час каждый день на ДР, если на доске есть задача на ревью. В неделю дизайнер может спокойно ревьюить около 5-7 задач, но с таким объемом мы не столкнулись ещё. В реальности максимум 4 сборки получает дизайнер. Я как лид смотрю все, но про загрузку лидов нужно говорить отдельно.

Так мы решили сразу 2 проблемы: сборка не висит несколько дней на ревью, а дизайнер тратит на рутину не больше часа в день.

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

Бот

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

Документ

Мы по обычаю составили док и презентовали команде разработки наше видение процесса. Это помогло развести ДР фичи и компонентов, так эти задачи можно было разделить по разработчикам и тестировать отдельно.

Договоренность с разработкой

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

Сборки

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

Состав дизайн-команды за последние полгода сменился и я наняла 2х новых дизайнеров для 2х разных продуктовых команд.

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

Встречи для проектирования

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

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

Подготовка к презентациям

Дизайнеры стали готовиться к презентация со стейкхолдерами полноценно. Было сложно донести всем, что теперь задача приходит на встречу после технических и продуктовых груммингов, и, условно, готова на 97%. 3% мы закладываем на возможные неучтённые кейсы, это стандартная погрешность.

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

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

Продуктовые спецификации

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

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

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

Оценка времени на задачу и правильная декомпозиция

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

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

Проведение ux тестирований

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

Хранение артефактов экспериментов

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

Запустили эксперимент -> получили результаты -> не зафиксировали -> запустили новый эксперимент -> забыли про первые результаты.

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

Хакатоны

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

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

Пока этот формат тестовый, хочется проверить на команде и подстроить.

Резюме после встреч

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

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

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

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

За время моей работы в компании, она выросла с 30 человек до 48. В рамках небольшой компании это рост на 60% и это ощутимо.Для меня это означает то, что если процесс работает сейчас, то не факт, что он будет работать через месяц. В развивающейся компании нужно периодически оценивать эффективность тех или иных процессов и вносить корректировки.

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

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

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