UXPUB 🇺🇦 Дизайн-спільнота

Cover image for Как Spotify организует работу в Figma для улучшения совместной работы
Редакція
Редакція

Опубліковано

Как Spotify организует работу в Figma для улучшения совместной работы

Команда дизайнеров Spotify недавно перешла на Figma. Мы рады рассказать, как приспособили этот инструмент к своим потребностям и культуре Spotify. Но в этой статье мы не обсуждаем, почему или как мы перешли на новый инструмент. Вместо этого мы разберемся с файловыми структурами.

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

Определяя нашу цель

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

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

Новый процесс, новые вызовы

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

Предыдущие попытки сохранить наши файлы дизайна помогли нам понять, как мог повлиять переход на другой инструмент. Ряд вещей, которые мы ожидали при проектировании в Figma:

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

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

Способы работы

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

Для начала группа определила набор принципов, которые отражают наши цели и будут направлять наши идеи:

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

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

Ниже представлен пример материалов такого семинара:

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

Результат

Этот процесс привел нас к следующим трем ключевым решениям:

  1. Команды будут организованы по продуктам, которые мы создаем.
  2. Проекты будут организованы по функциям или наборам функций продукта.
  3. Спецификации будут централизованы внутри одного проекта в каждой команде.

Таким образом, организация команд обеспечивает связь с обширным набором продуктов Spotify. Например, нашим мобильным приложением, Spotify Kids, Ad Studio, Spotify for Artists, Anchor и многими другими внешними и внутренними продуктами. Из обзора нашей организации вы сразу можете сказать, что дизайн-работа всей компании у вас под рукой. Эта структура помогает дизайнерам из разных бизнес-подразделений и отделов работать вместе в одном пространстве при проектировании для одного и того же продукта, и это позволяет нам четко отображать библиотеки Encore (дизайн-система) для каждой команды.

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

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

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

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

Все вместе

Наконец, рабочая группа разработала playbook и включила его в тренинг, который мы провели, обучая дизайнеров работе в Figma. Рабочей группе необходимо было регулярно проверять инструмент, чтобы писать в Slack, когда мы видим отклонения от соглашений, и скидывать демо, чтобы показать людям, как правильно настроить вещи. Мы создали канал #figma для дизайнеров, чтобы они задавали нам вопросы, и даже добавили в него людей из команды разработчиков Figma.

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

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

Хочу выразить благодарность членам рабочей группы Figma: Achal Varma, Alex Cameron, Daniel Elg, David Owen Morgan, Ed Samour, Felipe Fiuza, Hanna Brazier, Ian VanNest, Jacqueline Sibert, Juli Sombat, Kamdyn Moore, Mattias Johansson, Michael Brand, Mikael Sundström, Nicholas Atkins, Patrik Nyblad и Shamik Ray!


Перевод статьи spotify.design

Найстарші коментарі (0)