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

Продакт-менеджер DeviantArt / Wix Виталий Дворецкий рассказал на лекции об особенностях дизайна систем, а Telegraf.Design записал услышанное.

Дизайн-система — единое общее источник правды. Оно позволяет командам создавать дизайн, разрабатывать, писать тексты, в любых формах развивать продукт.

Обычно это набор стилей или компонентов, которые могут быть описаны, собранные на нескольких артбордах и выполнять базовые задачи. Иногда системы дополняются, например, UX-паттернами, брендингом, Voice & Tone. Если вы имеете дело с большим продуктом, важно заботиться о Voice & Tone. Еще можно позаботиться о том, чтобы контент был доступен и удобен для людей с физическими и ментальными нарушениями.

Дизайн-система — это:

Обычно: визуальный стиль и UI-компоненты;

Иногда: UX-паттерны, брендинг, Voice & Tone;

Редко: доступность (accessibility), локализация и визуализация данных.

Она разрабатывается с помощью:

Обычно: HTML, CSS, документов и гайдлайны;

Иногда дизайн-Асет (Sketch-файлов, библиотек и т.д.);

Редко JS-фреймворков (React, Angular т.д.).

Документируется все обычно в живых веб- (Confluence, Phabricator, Google Docs / Dropbox), очень редко в оффлайне, в PDF-файлах.

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

С чего начать:

  1. Из опроса пользователей: у вас должны быть потенциальные или реальные контрибьютор дизайн-системы. Нужно общаться с ними, узнать о проблемах и перспективах вашего продукта.
  2. Определение требований: у каждой команды есть устоявшийся подход к формулированию документации, цикла релизов и тому подобное. Радикальные изменения (а это как раз касается дизайн-систем) всегда сложно воплощать, лучше понемногу оптимизировать привычные процессы. Есть куча рекомендаций относительно того, как собирать требования, общаться с девелоперами и тому подобное. Например, Брэд Фрост сделал подборку материалов о том, как писать гайдлайны для фронтендерив.
  3. Обзор продуктов. Вас ждут радикальные изменения; чтобы подготовиться, нужно собрать максимум информации. Чем больше продуктов вы увидите, проанализируете, обсудите с командой, тем легче будет что-то решать.

концептуальное направление

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

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

Команда и коммитмент

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

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

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

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

Постепенно delivering

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

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

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

Виды командной работы

Гибридная дизайн-команда

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

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

Отдельная команда для дизайн-системы

Есть группа дизайнеров и фронтендерив, которые по запросу других команд делают определенные компоненты и документацию.

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

смешанные команды

Все работают над продуктом и помогают развивать дизайн-систему.

В дизайн-системы во контрибьюторов: маркетологи, дизайнеры, копирайтеры, фронтендеры, все потенциальные пользователи могут сделать свой вклад.

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

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

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

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

документация

Чтобы сделать документацию нужно:

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

Product map и структура

Чтобы создать структуру компонентов, воспользуйтесь методом Card sorting. Вы можете либо распечатать те компоненты, которые есть, или выделить разделы, на которые вы хотите разделить фичи. Тогда просто встречаетесь с каждым членом команды и предлагаете ему собрать компоненты в соответствии со структурой, назвать разделы и тому подобное. Лучше всего это делать индивидуально, а не коллективно.

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

Трудностей добавляет и контроль версий. В новых версиях компоненты могут быть исправлены, изменены в соответствии с новыми требованиями, иметь вариации для A / B-тестирования. Всему этому нужен менеджмент и не факт что над новой версией компонента будет работать тот же человек, что и над предыдущей. Это нормально, но к этому надо быть готовыми: поговорить с человеком, который ранее отвечал за компонент и фичи, где этот компонент используется.

Детализация и шаблоны для документов

Делится на три части: примеры, дизайн и код.

1. Примеры

По примерам можно ориентироваться на опыт Atlassian Design system. Они много документируют, компонент разбивается на кейсы, есть примечания с пояснениями, но главное — это ссылка на документацию по API. Они все разрабатывают в своем фреймоворкови и девелоперы тоже участвуют в создании документации. Указанные источники, версии, является ченджлогы каждой версии, живые примеры, инструкции и тому подобное. Для громоздких компонентов создаются отдельные поп-апы.

Можно выбрать и более простой путь, как команда WeWork Plasma, которая имеет достаточно ограниченные ресурсы. Они просто используют GoogleDocs, где описывают компоненты, структурируют их, добавляют кейсы, примеры кода.

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

Например, IBM Carbon добавляют гифкы, а Apple — скриншоты с описаниями контекста.

2. Дизайн-гайдлайны

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

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

Несколько советов, как улучшить дизайн-гайдлайны:

  • Следуйте одинаковой структуры во всей документации.
  • Используйте слова: Include …, Avoid …, Prevent …, Limit ….
  • Добавляйте ссылки.
  • Используйте списки.
  • Делайте чтения документа быстрее и проще.

Пример того, как пишет гайдлайны Apple:

3. Код

В документации позаботьтесь о:

  • живые примеры;
  • описание версий и изменений в новых релизах;
  • статус задачи — на каком этапе разработки сейчас компонент;
  • указания ответственных лиц и команд — product owners.

контроль версий

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

С контролем версий помогает софт Abstract и git . Как вариант можно использовать Zeplin + хранилище файлов + список с описанием того, что и где хранится (например, в SpreadSheet ).

Еще один полезный инструмент — Confluence , это разработка Atlassian для документации. Она базируется на технологиях git и после каждого хранения документации показывает вам ченджлог. Так вы знаете, что изменилось, добавилось или удалилось в каждой новой версии.

контроль качества

  1. Для контроля качества, прежде всего, нужна документация и гайдлайны, чтобы можно было придерживаться структуры.
  2. Также должны быть определенные критерии успешности, которым файл должен отвечать.
  3. Менеджмент качества — все изменения проходят через человека, отвечающего за дизайн-систему и принимает решение.

Например, в австралийского правительства есть свои дизайн-системы и гайдлайны. У них есть описания продуктов, процессов загрузки компонентов, дизайн-Асет в Sketch. Все начинается с общих рекомендаций, тогда — переход к дизайну и разработки компонентов. Такие вещи очень помогают новым членам команды, которые начинают работать с системой.

Как оценивать дизайн-систему

Первый критерий — то, насколько активно люди пользуются вашей дизайн-системой. Сколько компонентов девелоперы разработали с ней? Как все задокументировано? Сколько людей используют ваши инструменты для поиска?

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

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

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

Разрабатывать первую версию очень сложно. Поддерживать и развивать ее еще сложнее. 

Write A Comment