Люди, для людей: сохранение вашей системы дизайна вечно зеленой

Этот пост является третьим в серии о HubSpot Canvas, нашем новом языке дизайна. Прочитайте первое здесь, а второе здесь.

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

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

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

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

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

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

Люди - ваша система должна принадлежать всем

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

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

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

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

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

Тем не менее, дизайнеры в этой команде должны:

  • Язык дизайна Champion the HubSpot Canvas
  • Хорошо разбирайтесь в существующей документации и решениях на сегодняшний день, чтобы они могли легко отвечать на вопросы и выявлять несоответствия
  • Продолжить поиск путей улучшения процесса и документации
  • Обновляйте Sketch UI Kit еженедельно и отправляйте по электронной почте подробности обновлений дизайнерам и фронт-эндам
  • Распределение входящих вопросов и облегчение обсуждения и принятия решений на наших еженедельных обзорных встречах
  • Упреждающее взаимодействие с дизайнерами всей команды, чтобы помочь документировать варианты использования, варианты и шаблоны
  • Работайте с нашей командой Frontend-as-a-Service, чтобы отвечать на вопросы и помогать убедиться, что компоненты правильно изменены или построены.

Как законопроект становится законом

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

Это делает Github нашим единственным источником правды для Canvas. Так…

  • Если инженеру нужно знать, был ли компонент одобрен командой разработчиков? Это в Github.
  • Если дизайнер должен знать, был ли компонент построен? Это в Github.
  • Если команде нужно обсудить, должен ли компонент вообще существовать? Вы догадались - мы делаем это в Github.

Шаг 1: Нам нужен новый компонент или редактирование существующего компонента.

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

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

Затем он добавляется в нашу очередь:

Шаг 2: Проблемы решаются командой Canvas.

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

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

Шаг 3: Проблемы проходят проверку.

На высоком уровне процесс обзора отражает наш общий процесс проектирования (но в меньшем масштабе):

  1. Понять проблему
  2. Определите, на кого влияет проблема
  3. Общайтесь с другими командами
  4. Создание, изменение и оттачивание дизайна компонентов
  5. Обзор с командой Canvas

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

Шаг 4+: это зависит.

Есть несколько сценариев, которые могут выйти из обзора компонентов:

  • Дизайн для компонентов с широким использованием. Для нашей команды Frontend-as-a-Service наиболее целесообразно создавать и внедрять эти компоненты, поскольку они будут использоваться во всем продукте.
  • Дизайн для компонентов с более узким использованием. Часто, если одна команда нуждается в компоненте больше всего, они создают его многократно, а затем добавляют его в нашу библиотеку пользовательского интерфейса.
  • Дизайн для компонентов, которые не нужно многократно использовать. Иногда компоненты настолько узки по объему, что нет причин, по которым другой команде нужно было бы их использовать. В этом случае компонент проверяется на соответствие остальной части системы, а затем команда встраивает его в свое приложение. Если он должен стать компонентом многократного использования в будущем, команды могут добавить его в библиотеку пользовательского интерфейса.

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

Есть также несколько причин, по которым группа может отклонить запрос компонента:

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

Для людей - ваша система должна помочь вам

Мы хотели, чтобы Canvas был настолько прост в использовании, чтобы наши дизайнеры никогда не мечтали об использовании чего-либо еще. Так, например, вместо того, чтобы использовать только цифры для обозначения наших версий UI Kit, мы начали именовать каждую версию в алфавитном порядке после известных рэперов. Мало того, что мы получили забавные факты и отличные плейлисты, но это также сделало запоминание и обсуждение различных версий намного проще (неудивительно, что Jam Master Jay и Kris Kross намного легче запомнить, чем v1, v22 или v100). Как только мы сделали это с помощью алфавита, мы начали пробираться через «Как увидено» к телевизионным продуктам.

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

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

Видение того, что меняется.

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

Соответствующий код в библиотеке пользовательского интерфейса для разработки ресурсов в наборе Sketch UI.

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

Думать за пределами традиционных компонентов.

Иллюстрации, макеты страниц, пустые состояния, состояния ошибок - вы называете это. Если повторное использование объекта создает рычаги, стоит превратить его в компонент или дополнение. Наша команда Frontend-as-a-Service также значительно упростила для инженеров из групп разработчиков продуктов возможность самостоятельно добавлять компоненты или дополнения в систему. Мы также начали документировать шаблоны UX (не просто «какой компонент мне использовать?», А «как его использовать?»).

Но мы, конечно, не все исправили. Вот некоторые проблемы, которые мы все еще пытаемся решить и которые мы повторяем:

Эффективно назначать и отображать приоритет.

Когда мы начали перемещать наш процесс в Github, мы предоставили теги, которые позволяют пользователям выбирать приоритет своего запроса в масштабе от P1 до P3 (P1 означало «нам нужно сделать это вчера», а P3 означало «мы доберемся до этого»). когда-нибудь»). Но поскольку наша команда движется так быстро, почти все оказалось P1.

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

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

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

В нашей системе мы верим

У нас в HubSpot есть золотое правило как часть нашего Кодекса культуры: используйте здравый смысл. Это вытекает из культуры доверия и ответственности перед другими. Мы построили наши принципы, руководящие принципы и процессы на основе доверия, чтобы обеспечить долговечность нашей системы проектирования, потому что система работает только в том случае, если ей доверяют.

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

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

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

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

Кредиты:
Иллюстрации Сью Йи.

Первоначально опубликовано в блоге по продукту HubSpot.