С чего начать разработку дизайн-системы и зачем она нужна

Руководство дизайн-студии EightShapes — от формирования стратегии до запуска первой версии.

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

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

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

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

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

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

Исследовательская деятельность может включать в себя:

• Беседы с ключевыми (потенциальными) спонсорами, влиятельными лицами и лидерами области с целью оценить перспективы, отношение, культуру и установившиеся практики.
• Исследование позиции акционеров в отношении системы, приоритетов, потребностей, источников вдохновения и угроз.
• Сбор требований через анализ рабочих задач, технологическое планирование и принятие процедур (с помощью таких инструментов, как Front End Questionnaire, автором которого является Брэд Фрост).
• Туры по продукту, к которому будет применяться система. Необходимо делать скриншоты и заметки.
• Обзор систем, оценивающий проектные ресурсы, библиотеку кода, качество типовой документации, модели управления.

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

• Рассказывать об открытиях, результатах опросов и озвучивать рекомендации.
• Определять границы системы и продуктов с помощью таких упражнений, как Parts, Products & People и Component Cut Up, цель которых — оценивать существующие продукты.
• Обсуждать модели и кандидатов на участие в команде по дизайн-системе, её возможных руководителей, долю участия сообщества, возможный вклад в дизайн-систему.
• Собирать инженеров и руководителей техотделов, чтобы подтвердить наши предположения, выбрать концептуальные схемы и определить проектную среду и потребности.
• Разрабатывать сценарий функционирования будущей системы, включая концепты типового дизайна, процессы первого рабочего цикла и то, по каким критериям мы будем оценивать успех.

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

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

Больше на тему подготовки и презентации концептов можно прочитать здесь.

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

Обычно наша презентация стратегии охватывает следующие темы:

• Что такое дизайн-система и почему она важна.
• Истории, демонстрирующие ценность, например: объединение распространённой проблемы кнопок на сайте с другими проблемами, которые актуальны для этой конкретной организации.
• Предлагаемые границы, сроки, продукты и процессы для выхода версии 1.0, последующее внедрение продукта и его поддержка, развитие и обслуживание системы в будущем (ответ на вопрос, как и когда).
• Рекомендуемый мультидисциплинарный состав команды по дизайн-системе, процедура вовлечения в работу спонсоров и людей, принимающих окончательные решения (ответ на вопрос, кто).

Не стесняйтесь. Вам предстоит запустить новый продукт, у вас неизбежно появятся требования. Что нужно требовать?

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

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

Однако вербальное одобрение совсем не значит, что можно начинать завтра. Иногда всё стопорится.

Существует множество факторов, способных отложить момент принятия решения. Может быть, ваша первая презентация запустила последующие презентации по оперативным вопросам, или отдел HR решил поменять состав команды. А может, вам придётся ждать следующего квартала, когда компания будет пересматривать операционный бюджет.

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

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

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

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

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

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

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

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

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

• поступательно внедряет свою часть работы от спринта к спринту;
• внедряет всё больше процессов за один спринт по мере роста продуктивности.

В чём все должны быть уверены? Что команда, разрабатывающая систему, предоставит начальную библиотеку — осмелюсь сказать, «минимально жизнеспособный продукт», — который будет принят к определённому ожидаемому сроку. Поэтому я буду неоднократно подчёркивать, что мы на пути к запуску версии 1.0, которая обеспечит сильную визуальную основу и от 12 до 16 компонентов UI.

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

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

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

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

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

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

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

Каждый квартал вы можете добавлять определённые компоненты:

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

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

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

#дизайн