UXPUB

UXPUB - сообщество из 2,963 дизайнеров и творческих людей

Место, где дизайнеры делятся опытом

Создать аккаунт Войти
Cover image for Как Abstract улучшил совместную работу над дизайном в Microsoft
Редакция
Редакция

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

Как Abstract улучшил совместную работу над дизайном в Microsoft

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

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

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

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

Разработка файловой структуры проекта

Наши проекты разделены по платформам-Android, iOS, Mac, Web и Universal (Почта и Календарь в Windows 10). Внутри этих проектов наши файлы разделены на различные разделы нашего приложения. Ниже приведен пример нашей файловой структуры iOS внутри Abstract, где мы распределяем наши файлы на такие разделы, как «iOS UI-Kit», «Mail» и «Calendar», чтобы файлы работали быстро.

Во-первых, Start Here-это файл для новых дизайнеров и внешних партнеров. Он содержит информацию о наших принципах проектирования, о том, как использовать Abstract, об экспорте ресурсов, а также несколько советов и рекомендаций по использованию плагинов Sketch.

Файл Start Here

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

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

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

Поэтапно изучаем процесс проектирования

Первым шагом является создание ветви, которая собирает все файлы Sketch в мастере и создает реплику. Думайте об этом как о дублировании папки. Чтобы идентифицировать ветвь, мы даем наименование ярлыку для части, над которой мы работаем, добавляя соответствующий заголовок после ярлыка. Для описания проекта мы обычно используем такие ярлыки, как «Feature», «Kit» или «Exploration». В Outlook все способствует тому, чтобы мы пробовали новые идеи и изменяли все, что по нашему мнению, можно улучшить-вот когда мы используем тег типа “Exploration.” Эти ярлыки дают другим членам команды некоторый контекст и помогают им найти и понять, над чем мы работаем. Создание ветки является огромным преимуществом, потому что это означает, что несколько дизайнеров могут работать над одними и теми же файлами, а затем объединять их обратно в мастер.

Пример маркировки ветки

В новой ветке я создаю новый файл из Abstract. Я называю этот файл как-то вроде «Working», что помогает другим узнать, где находятся последние разработки. Затем я могу скопировать артборды из других файлов в этот - это помогает визуализировать общую картинку или изменить существующий экран.

Создание "рабочего" файла

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

Ежедневный Commit

Как только дизайн завершен, пора привести в порядок слои и объединить дизайн с мастер-файлами. Убедитесь, что имена слоев точны, и порядок соответствует тому, что вы видите на экране (сверху вниз). Это должно быть повторено для каждого экрана. Я могу либо создать еще одну новую ветку с надписью [Kit] и скопировать с новых экранов в соответствующий файл, либо заново создать эти экраны с нуля, используя новейшие компоненты библиотеки. Причина, по которой я создаю новый файл, состоит в том, чтобы вводить только главные экраны для мастера. Позже я всегда могу вернуться к старой ветке в абстрактном архиве. Это занимает немного времени и предотвращает слияния функций. Мы хотели бы услышать любого, у кого есть какие-либо предложения по улучшению процесса слияния.

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

Создание экранов Outlook с использованием наших компонентов пользовательского интерфейса.

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

Лучшие практики для обслуживания

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

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

Наш процесс и UI-kit использовались командами разработчиков из Microsoft, так как мы проектируем с более открытым и совместным подходом. По мере развития Fluent Design на мобильных устройствах мы увидим общие элементы в продуктах Microsoft.

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

Не стесняйтесь делиться своими идеями в комментариях ?.

Чтобы оставаться в курсе событий Microsoft Design, or join our, подпишитесь на нас в Dribbble, Twitter и Facebook или присоединитесь к Windows Insider program. И если вы заинтересованы в присоединении к нашей команде, зайдите на сайт careers.microsoft.com

Написано с ? и с помощью Miles Fitzgerald и команды Outlook.


Перевод статьи Joe Woodward

Обсуждение (0)