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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#дизайн