Design That Scales
Creating a Sustainable Design System Practice

Dan Mall

Дизайн в масштабе
Создание устойчивой дизайн-системы

Дэн Молл

2025

Дэн Молл
Дизайн в масштабе. Создание устойчивой дизайн-системы
Серия «Для профессионалов»

ББК 32.988.02-018
УДК 004.738.5
Молл Дэн
М75

Дизайн в масштабе. Создание устойчивой дизайн-системы. — СПб.: Питер, 2025. —
272 с.: ил. — (Серия «Для профессионалов»).
ISBN 978-5-4461-4229-3

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

16+ (В соответствии с Федеральным законом от 29 декабря 2010 г. № 436-ФЗ.)
Права на издание получены по соглашению с ROSENFELD MEDIA LLC. Все права защищены. Никакая
часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного
разрешения владельцев авторских прав.
Информация, содержащаяся в данной книге, получена из источников, рассматриваемых издательством
как надежные. Тем не менее, имея в виду возможные человеческие или технические ошибки, издательство не может гарантировать абсолютную точность и полноту приводимых сведений и не несет
ответственности за возможные ошибки, связанные с использованием книги.
В книге возможны упоминания организаций, деятельность которых запрещена на территории Российской Федерации, таких как Meta Platforms Inc., Facebook, Instagram и др.
Издательство не несет ответственности за доступность материалов, ссылки на которые вы можете
найти в этой книге. На момент подготовки книги к изданию все ссылки на интернет-ресурсы были
действующими.
ISBN 978-1959029212 англ.
ISBN 978-5-4461-4229-3

© Original English language edition published by ROSENFELD MEDIA LLC
© 2023 by Dan Mall
© Перевод на русский язык ООО «Прогресс книга», 2025
© Издание на русском языке, оформление ООО «Прогресс книга», 2025
© Серия «Для профессионалов», 2025

Для меня как практикующего специалиста по дизайн-системам эта
книга станет настольным руководством по созданию и поддержке
дизайн-систем по мере их роста.
Афия Смит (Afyia Smyth),
менеджер по дизайну, Epic Games
Во время чтения этой книги мне приходилось постоянно прерываться, чтобы тут же давать указания сотрудникам: изменить курс,
чтобы обойти подводные камни, или ускорить темп. Это руководство
раскрывает тайны дизайн-систем и помогает корпоративным цифровым командам создавать ценность здесь и сейчас.
Дилан Валад (Dylan Valade),
ведущий специалист в отрасли, MACH Alliance, DAX 40 (PUMA),
Fortune 100 (Abbott)
Дэн разбирает сложные аспекты дизайн-систем и предлагает практичный подход к созданию эффективной системы работы с дизайнсистемами в вашей организации.
Кэтрин Гонсалес (Kathryn Gonzalez),
бывший руководитель отдела проектирования
инфраструктуры в DoorDash

5

Книга Дэна радикально изменила наш подход к дизайн-системам,
приведя к значительным изменениям в компании, и стала обязательным чтением для всех, кто стремится упростить и оптимизировать дизайн-системы любой сложности. Эта книга предоставляет
все необходимое, для того чтобы трансформировать вашу дизайнсистему и поднять ее на новый уровень.
Надин Саррадж (Nadine Sarraj),
дизайнер продукта, 365 Retail Markets
Магия книги «Дизайн в масштабе» — в формировании базовых привычек и процессов, гарантирующих, что дизайн-система действительно принесет организации долгосрочную пользу.
Тедди Ни (Teddy Ni),
соучредитель Mirrorful
Независимо от того, являетесь ли вы новичком в дизайн-системах или
опытным специалистом, книга «Дизайн в масштабе» предложит вам
ценные идеи не только по созданию дизайн-системы, но и по тому,
как эффективно продвигать ее среди пользователей и оценивать ее
успех. Эта книга несомненно станет для вас надежным справочником,
к которому вы будете регулярно обращаться за рекомендациями.
Адекунле Одуйе (Adekunle Oduye),
консультант по дизайн-системам, Бруклин, Нью-Йорк

6

Книга «Дизайн в масштабе» — это чрезвычайно ценный ресурс,
который предлагает дизайнерам, разработчикам и продакт-менеджерам практические шаги и методы для усовершенствования дизайн-систем. Дэн излагает простым и понятным языком даже самые
сложные концепции дизайн-систем, и очевидно, что книга является кульминацией многолетнего опыта и желания помочь другим
в этой области. Это полезное и подробное руководство, на которое
можно положиться, а Дэн — идеальный проводник, он проведет вас
через все темы и этапы.
Джоуи Бэнкс (Joey Banks),
основатель Baseline Design

В книге «Дизайн в масштабе» Дэн преобразует свой богатый опыт
в практическое руководство, которое будет полезно как новичкам,
так и опытным специалистам по дизайн-системам.
Майк Апарисио (Mike Aparicio),
главный инженер по дизайн-системам, Turquoise Health
Эта книга наполнена бесценными деталями, которые заставят вас
подвергнуть сомнению интуитивные подходы и искать новые способы осмысления процессов и оценки эффективности дизайн-систем.
Когда читаешь ее, создается ощущение, что Дэн находится рядом,
делясь своим опытом: успехами, подводными камнями и уроками,
извлеченными на этом пути. Читайте эту книгу и рассказывайте
о ней другим!
Дерек Фезерстоун (Derek Featherstone),
вице-президент по доступности
и инклюзивному дизайну, Salesforce

7

ОГЛАВЛЕНИЕ

От издательства
О научном редакторе русского издания
О книге

14
14
16

Для кого эта книга

16

Структура книги

17

Дополнительные материалы

19

Часто задаваемые вопросы

20

Что такое дизайн-система?

20

Почему дизайн-системы важны?

20

Правда ли, что дизайн-системы нужны только дизайнерам?

21

Даст ли эта книга навык создания дизайн-системы?

21

Раньше я создавал дизайн-системы всего за несколько дней.
Действительно ли эта тема заслуживает написания
целой книги?

21

Рекомендует ли эта книга инструменты для облегчения
работы над дизайн-системой?

22

Предисловие

23

Введение

25

Дизайн-системы: преимущество дизайна в масштабе
ГЛАВА 1
Зачем нужны дизайн-системы

8

25

29

Системы соединяют организации

30

Общие преимущества дизайн-систем

32

Для кого предназначены дизайн-системы

33

Вопросы для размышления

34

ГЛАВА 2
Основы дизайн-системы

41

Нерды всех стран, объединяйтесь!

43

Различные виды дизайн-систем

44

Выберите свою дизайн-систему

51

Вопросы для размышления

52

ГЛАВА 3
Составляющие дизайн-системы как продукта

53

Основные составляющие дизайн-системы

54

Дизайн-система — это совокупность всех составляющих

66

Дизайн-система — это взаимосвязь

66

Библиотеки компонентов vs дизайн-система

67

Соедините всю цифровую экосистему

72

Вопросы для размышления

73

ГЛАВА 4
Как непросто получить одобрение дизайн-системы

75

«Создай систему, используй систему» —
это фантазия

76

Получение поддержки для дизайн-системы — это как
«продажа воздуха»

77

Создание дизайн-системы на основе абстракций —
сложный процесс

78

Пытаетесь убедить других принять новый инструмент? Удачи!

78

Продуктовые команды не вносят вклад в дизайн-систему

79

Вопросы для размышления

80

9

ГЛАВА 5
Пилотные проекты — лучший способ запустить
и поддерживать дизайн-систему
Связь дизайн-системы с работой над продуктом

82

Пилотная оценочная карта дизайн-системы

84

Типы пилотных проектов дизайн-систем

86

Несколько параллельных пилотных проектов

88

Совершенствование дизайн-системы по мере
ее использования

91

Процесс выпуска пилотных версий

93

Извлечение и абстрагирование

129

Вопросы для размышления

133

ГЛАВА 6
Управление и вклад

10

81

135

Экосистема WordPress и ее связь с дизайн-системами

136

Фреймворк для управления дизайн-системой

138

Управление и вклад: шаблон

148

Дизайн-система как канон и расширенная вселенная

150

Вопросы для размышления

151

ГЛАВА 7
Роли и обязанности

153

Фронтенд-разработка важнее визуального дизайна

156

Фронтенд-разработка важнее бэкенд-разработки

158

Фронтенд-разработка: недостающий набор навыков

159

Ребрендинг «фронтенд-разработчика»

160

Психологическая безопасность

168

Инженеры экосистемы

170

Трехногая табуретка

171

Другие роли в команде дизайн-системы

172

Годовой бюджет дизайн-системы

184

Вопросы для размышления

187

ГЛАВА 8
Процесс и фреймворк

189

Фреймворки важнее процессов

194

Меньше значит больше

198

Принцип «горячей картошки»

198

Изменение инструментов требует изменения поведения

209

Подводные камни метода «горячей картошки»

213

Сопротивление новому рабочему процессу

215

Вопросы для размышления

217

11

ГЛАВА 9
Показатели успеха дизайн-системы

219

Определение индивидуальных показателей успеха

223

Фреймворк для измерения успеха

229

Успеха добиваются люди, а не системы

236

Согласование целей для объединения организации

241

Вопросы для размышления

242

ГЛАВА 10
Евангелизм никогда не прекращается

243

Оформите дизайн-систему как магазин

251

Сделайте дизайн-систему ориентированной
на пользователей

253

Вопросы для размышления

258

Заключение

259

Благодарности

261

Об авторе

266

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

ОТ ИЗДАТЕЛЬСТВА
Мы выражаем огромную благодарность клубу рецензентов ИТлитературы ReadIT Club за помощь в работе над русскоязычным
изданием книги и вклад в повышение качества переводной литературы.
Ваши замечания, предложения, вопросы отправляйте по адресу
comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

О научном редакторе русского издания
Екатерина Кучина — ведущий системный аналитик компании
Orion soft с более чем 14-летним опытом в IT. Начала свою карьеру
в сфере IT со стажировки в компании «Росгосстрах», где за значимый личный вклад в решение актуальных задач была отмечена
благодарностью.
За свою карьеру занимала ведущие позиции в крупнейших компаниях — системных интеграторах. В профессиональном портфолио —
аналитическая и проектная работа над рядом ключевых информационных систем федерального и международного уровня.
Помимо активной проектной деятельности принимает участие
в качестве эксперта в образовательных программах для студентов
и школьников.

Если бы эта книга попала мне в руки 10 лет назад, я бы сэкономил
несколько лет на создании действительно работающих дизайн-­
систем. Именно работающих — об этом подробно и с примерами
пишет Дэн Молл. Когда вам предстоит столкнуться с проблемами
и сложностями внедрения и развития дизайн-системы в ваших
продуктах, вы уже будете знать, какое решение принять, почему
именно его и как аргументировать свой выбор перед командой
дизайнеров и разработчиков. Дэн упаковал весь свой многолетний
опыт в лаконичные, практичные и «по делу» советы. Короче говоря,
это настоящий справочник по решению проблем.
Артём Кобяков,
архитектор дизайн-систем (Яндекс, «Честный ЗНАК», АТОЛ),
автор Telegram-канала Oh My Design System, консультант

С первых страниц становится ясно: фокус не на визуальных библио­
теках и UI-китах, а на людях, процессах и культуре. Молл подробно
объясняет, что дизайн-система — это не просто набор компонентов,
а полноценный продукт и одновременно внутренняя практика,
требующая командного участия, продуманного управления, поддержки со стороны руководства и постоянной евангелизации.
Особенно ценны вопросы проектирования дизайн-систем, которые
другие авторы часто обходят стороной, сосредоточиваясь на компонентах и пикселях: как создать систему, которой продуктовые
команды действительно захотят пользоваться, как организовать
вклад в нее — и как измерять ее успех.
Сергей Мухин,
лидер дизайн-команд, архитектор дизайн-систем
(Т-банк, Вкус Вилл), автор проекта UXFLOW

О КНИГЕ
Для кого эта книга
Если вы дизайнер, разработчик или продакт-менеджер в крупной
компании, где считают, что существуют более эффективные способы работы в условиях масштабирования, эта книга для вас. Если
вы тимлид или продакт-менеджер, способный инициировать изменения, но не уверены, какие именно изменения приведут к наилучшим результатам, эта книга для вас. Если вы думаете над тем,
как улучшить коллективную работу над цифровым продуктом, эта
книга для вас. Если вы считаете, что работа могла бы приносить
больше удовольствия, когда удастся каким-то образом избавиться
от рутинных задач, эта книга также для вас.
Эта книга о нестандартном подходе к созданию дизайн-системы,
который делает путь к успеху и привлечению инвестиций проще
и доступнее. О новом методе, которым дизайнеры, разработчики
и продакт-менеджеры могут пользоваться, имея в своем распоряжении дизайн-систему. О процессе, который вовлекает команды
и помогает совершенствовать дизайн-систему, делая ее лучше для
всех. В конечном счете эта книга о том, как связать вашу дизайнсистему с процессами, создающими ценность для клиентов, пользователей и всех заинтересованных лиц в вашей компании.
Дизайн-системы способны на все это, если вам известен правильный
подход. Эта книга содержит концепции и теорию, которые помогают понять контекст дизайн-систем, а также примеры того, как
можно успешно применять их на практике, и истории о том, как
это удалось другим. Эта книга поможет вам взглянуть на дизайнсистемы по-новому.
Несмотря на то что в книге есть глава «Основы дизайн-системы»,
это не пособие для начинающих. Здесь вы найдете лишь несколько
определений и основополагающих вопросов, поскольку в других
источниках эти темы уже подробно раскрыты. Также эта книга не

16

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

Структура книги
В главе 1 «Зачем нужны дизайн-системы» рассказывается о том,
почему дизайн-система является стоящим начинанием для большинства организаций, управляющих несколькими цифровыми
продуктами.
Многие команды не понимают разницы между дизайн-системами,
библиотеками компонентов и UI-китами1. В главе 2 «Основы дизайн-системы» обсуждаются эти различия и некоторые ключевые
понятия, а также объясняется, почему дать точное определение
дизайн-системам так сложно.
В главе 3 «Составляющие дизайн-системы как продукта» разбирается экосистема вокруг дизайн-системы, чтобы понять, в какой
ситуации дизайн-система будет успешной.
В главе 4 «Как непросто получить одобрение дизайн-системы» разбирается стандартный способ продвижения дизайн-системы и объясняется, почему он почти никогда не работает, а также какой
другой способ может быть более эффективным.

1

UI-киты (User Interface Kits) — это наборы предварительно разработанных компонентов и элементов пользовательского интерфейса, они помогают дизайнерам и разработчикам ускорить процесс проектирования. — Примеч. ред.

17

В главе 5 «Пилотные проекты — лучший способ запустить и поддерживать дизайн-систему» рассказывается о неочевидном подходе к созданию дизайн-системы, который позволяет легко и естественно вовлекать команды в процесс и постоянно улучшать
систему.
В главе 6 «Управление и вклад» рассматриваются ключевые вопросы — кто, что, где, когда и почему, ответы на которые помогут
создать понятный и удобный процесс управления дизайн-системой
и внесения в нее изменений.
В главе 7 «Роли и обязанности» и главе 8 «Процесс и фреймворк»
идет речь о сотрудниках, участвующих в работе над связанными
дизайн-системами, их месте в проекте и об эффективных рабочих
процессах для оптимального взаимодействия.
В главе 9 «Показатели успеха дизайн-системы» рассматриваются
как общие, так и специфические для организации показатели успеха, которых должны достичь дизайн-системы.
В главе 10 «Евангелизм никогда не прекращается» обсуждается
часто упускаемая из виду задача продвижения дизайн-системы
среди тех, кто должен ее использовать: внутренних дизайнеров,
разработчиков и продакт-менеджеров.
В заключении объясняется, почему все вопросы, связанные с дизайн-системами, имеют значение.

18

Дополнительные материалы
Сопутствующий сайт книги (rosenfeldmedia.com/books/design-that-scales)
содержит блог и дополнительные материалы. Диаграммы и другие
иллюстрации из книги доступны под лицензией Creative Commons1
(при соблюдении определенных условий) для скачивания и использования в ваших собственных презентациях. Вы можете найти их на
фотохостинге Flickr по адресу: www.flickr.com/photos/rosenfeldmedia/sets.

1

Creative Commons (СС) — особый вид лицензий, которые созданы для
защиты произведений человеческого творчества (картины, видео, фотографии, музыкальные композиции и пр.). При размещении контента по
лицензии CC авторы разрешают использовать его любому желающему
с соблюдением определенных условий. — Примеч. ред.

19

ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
Что такое дизайн-система?
Дизайн-системы могут быть разных видов: дизайн-система как
визуальный язык, как библиотека фрагментов кода, как набор артбордов1 в инструменте дизайна, как способ проектирования и т. п.
В этой книге я рассказываю о дизайн-системах в первую очередь
как об организационной практике. В главе 2 «Основы дизайн-системы» более подробно рассматривается каждый из видов дизайнсистем.

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

1

Артборды — это отдельные рабочие области, размещенные внутри одного документа в таких программах, как Adobe Illustrator, Adobe Photoshop
и др. Главное их достоинство — возможность во время работы быстро
переключаться между различными макетами, экранами или страницами. — Примеч. ред.

20

Правда ли, что дизайн-системы нужны
только дизайнерам?
Ни в коем случае! Дизайн-системы особенно интересны тем, что
они являются одним из немногих инструментов, которые в равной
степени служат пресловутым «трем китам» — дизайну, разработке
и продукту. В главе 7 «Роли и обязанности» описаны все необходимые профессиональные навыки и круг обязанностей, которые могут
иметь место в команде разработчиков дизайн-систем.

Даст ли эта книга навык создания
дизайн-системы?
И да, и нет. Если вы ищете подробные инструкции по настройке
UI-китов в таких инструментах дизайна, как графический редактор
Figma, или по настройке свойств в языках React или Angular, то
можно найти множество хороших статей и курсов на эту тему в интернете. Я решил не затрагивать подобные темы в книге, потому
что большинство дизайн-систем плохо работают не из-за этого.
Большинство дизайн-систем оказываются неудачными, потому что
они не интегрированы вовремя в структуру работы организации,
и книга в основном посвящена тому, как это правильно сделать.

Раньше я создавал дизайн-системы всего
за несколько дней. Действительно ли эта тема
заслуживает написания целой книги?
Правда в том, что опытный специалист может очень быстро создать
такие артефакты дизайн-системы, как UI-киты в Figma и библиотеки кода. Однако для внедрения настоящей практики дизайн-­

21

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

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

22

ПРЕДИСЛОВИЕ
Услышав имя Сьюзен Кэр (Susan Kare)1, вы подумаете об иконках.
При упоминании имени Джона Маэды (John Maeda)2 на ум придет
пересечение дизайна и технологий. А услышав имя Дэна Молла (Dan
Mall), вы подумаете о дизайн-системах.
Поздравляю! Если вы читаете это предисловие, значит, вы только
что приобрели книгу, которая поможет не только вам, но и окружающим вас людям. Если вы просто листаете книгу и задаетесь
вопросом: «Стоит ли мне ее покупать?», то я здесь, чтобы сказать
вам: «ДА! Совершенно точно ДА!»
Дэн Молл — безусловно, самый опытный человек на планете из тех,
кто может рассказать о дизайн-системах. Его опыт невероятно
обширен, и эта книга предоставит вам все инструменты, необходимые для создания и поддержания дизайн-системы. Не просто
дизайн-системы, которая будет работать здесь и сейчас, а устойчивой дизайн-системы, за создание которой дизайнеры, разработчики и другие специалисты будут благодарить вас еще много лет.
Эта книга изменит ваше мышление: от тревог, что дизайн-системы
мешают инновациям, вы придете к осознанию того, что именно они
дают дизайнерам и разработчикам больше свободы, чем когда-либо.
Я познакомилась с Дэном несколько лет назад на конференции по
дизайну. Мы сидели рядом за ужином и довольно долго обсуждали
1

Сьюзен Кэр — американская художница и графический дизайнер, создавшая многие из элементов интерфейса Apple Macintosh, Windows, IBM
OS/2 в 1980-х годах. Соучредитель и креативный директор NeXT
Computer — компании, основанной Стивом Джобсом в 1985 году после
его ухода из Apple Computer. — Примеч. ред.

2

Джон Маэда — американский дизайнер японского происхождения, специалист в области компьютерных технологий. Автор более десятка книг;
одна из них, бестселлер «Законы простоты», издана на русском языке
в 2008 году. — Примеч. ред.

23

роль дизайн-операций (DesignOps) и дизайн-систем в дизайн-коман­
дах. Все, о чем мы говорили, было важно. Нам так хотелось рассказать миру, как использовать эти навыки, чтобы сделать команды более счастливыми и успешными! Это ваш шанс услышать
самого маэстро.
А теперь прекратите читать мое предисловие и переходите к самой
книге.
Мередит Блэк (Meredith Black),
основатель DesignOps Assembly

24

ВВЕДЕНИЕ
Дизайн-системы: преимущество дизайна
в масштабе
Мне посчастливилось работать и консультировать людей по поводу
их дизайн-систем в сотнях организаций. Большинство из них действуют неправильно.
Обычно история выглядит следующим образом.
Потратив недели, месяцы и даже годы, заново проектируя и создавая одни и те же элементы интерфейса, небольшая группа специалистов наконец понимает, что создание набора переиспользуемых
общих решений поможет всем избавиться от необходимости каждый
раз изобретать велосипед. Они проектируют и кодируют базовые
элементы интерфейса: формы, таблицы, хедеры, футеры, кнопки —
те, что, по их мнению, используют или могли бы использовать все
остальные.
Они сами начинают пользоваться этой новой библиотекой, и она
работает! Они быстрее выполняют свои задачи и даже замечают дополнительный бонус в виде большей консистентности дизайна.
Не будучи эгоистами, они думают, что эта новая библиотека будет
полезна и другим, поэтому они делятся ею с остальными командами
внутри компании. А дальше...
Тишина.
Долгое время никакой обратной связи. А когда они все-таки получают ответ, реакция оказывается неожиданной и совсем не той,
которую ждали.
«Мы пытались ее использовать, но в ней не хватает нескольких элементов».

25

«Мы не совсем поняли, как ее использовать, потому что не было достаточного количества документации».
«Сейчас у нас нет времени на изучение новой библиотеки».
Разочарованные, они понимают, что могли бы устранить эти обоснованные претензии других команд, но это отвлекло бы их от основной работы, а они не могут себе этого позволить в данный момент. В итоге библиотека остается лежать в стороне, одинокая
и никому не нужная.
Не зная об этом, другая команда в другой части компании только
что проделала то же самое и получила аналогичный результат. Что
еще хуже: ни одна из этих двух команд не подозревает, что вторая
также работала над тем же и что еще несколько команд в компании
делали то же самое в прошлом году, а другие — годом ранее. Лишь
немногие люди, проработавшие в компании не один год, знают обо
всех этих неудачных начинаниях.
Я называю эти коллекции провалившихся попыток городами-призраками или кладбищами дизайн-систем. Они есть почти в каждой
организации. Всегда это происходит из лучших побуждений. Коман­
ды делают то, что кажется разумным и интуитивно понятным, но
редко получают желаемый результат. Почему же так происходит?
Большинство команд подходят к созданию дизайн-системы в первую очередь как к проекту. Они не готовы к тому, что внедрение
дизайн-системы зависит от изменения культуры организации,
а именно от того, чтобы все начали думать и работать иначе, чем
они привыкли. Большинство усилий по внедрению дизайн-систем
начинается с борьбы со статус-кво. В современных цифровых компаниях, как правило, принято разделять команды и задачи на изолированные блоки, поскольку это считается более эффективным
подходом. Работа над дизайн-системой быстро сталкивается с ограничениями такой структуры. Успешные дизайн-системы преодоле-

26

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

1

Паттерн MVC (model-view-controller pattern) — это архитектурный шаблон, который разделяет приложение на три логических компонента:
модель, представление и контроллер. — Примеч. ред.

27

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

ГЛАВА 1

Зачем нужны
дизайн-системы
Системы соединяют организации

30

Общие преимущества дизайн-систем

32

Для кого предназначены дизайн-системы

33

Вопросы для размышления

34

Вспомните все продукты Google, которыми вы пользовались сегодня.
Может быть, с утра вы проверяли свою электронную почту с помощью
Gmail. Возможно, вы ехали в офис или на встречу, используя Google
Maps, чтобы проложить маршрут. Вероятно, вам понадобилась дополнительная информация о чем-то, и вы искали ее в Google Search,
может быть, используя Google Chrome. Возможно, вы с коллегой совместно работали над документом в Google Docs или таблицей в Google
Sheets. Может быть, вы смотрели видео на YouTube. Не исключено,
что вы делали все это на мобильном устройстве Android.
Как пользователь, вы, вероятно, не задумывались о том, как компании Google удалось сделать такой день возможным для вас. Да
и не должны! Все, что вас должно волновать, это получаете ли вы
то, что хотите, используя эти приложения.

Системы соединяют организации
Но что потребовалось Google, чтобы все это создать? На момент написания этой книги в компании Google (точнее, в материнской компании Google, Alphabet Inc.) работает почти 140 000 человек. Кроме
того, Google сотрудничает со многими внешними партнерами и агентствами, помогая им ускорять работу и внедрять инновации в цифровые продукты, которые они создают для своих пользователей. Для
согласования действий тысяч людей с точки зрения дизайна и разработки требуется некая система, набор элементов, работающих
вместе как части единого механизма или взаимосвязанной сети. Для
организаций, создающих цифровые продукты, одной из таких систем
является дизайн-система. Вот мое определение:
Дизайн-система — это связанный, управляемый пакетами программный продукт с системой контроля версий, содержащий минимальный
набор компонентов и руководств, необходимых конкретной организации для последовательного, эффективного и успешного создания
цифровых продуктов.

Это определение может показаться громоздким! Более подробно
я рассмотрю и объясню каждое из этих слов и фраз в главе 2 «Основы дизайн-системы» и в главе 9 «Показатели успеха дизайн-системы».
Дизайн-система Google называется Material Design1. По словам самой
компании Google, Material Design — это «адаптивная система руко1

«Material Design», Google, https://m3.material.io/.

30

водств, компонентов и инструментов, которые поддерживают лучшие практики проектирования пользовательских интерфейсов».
(Видите, насколько это близко к моему определению?) Без Material
Design сотрудникам и партнерам Google пришлось бы каждый раз
проектировать и создавать каждый продукт, экран, взаимодействие
и элемент с нуля, что привело бы к огромным трудозатратам и нежелательному разнообразию. Наличие общей системы, такой как
Material Design, позволяет дизайнерам и разработчикам Google
быстро находить уже существующие решения (рис. 1.1), готовые
к использованию без доработок.

Рис. 1.1. Независимо от того, какое приложение Google вы используете,
компонент плавающей кнопки действия (FAB) всегда обеспечивает
легкий доступ к основному действию экрана в правом нижнем углу

Дизайн-системы удобны не только для дизайнеров, разработчиков,
продакт-менеджеров и остальных членов команды, создающей
цифровые продукты. Дизайн-системы также создают удобство и для
пользователей, поскольку им не приходится заново изучать правила работы в разных приложениях. Исследование Forrester 2016 года1
показало, что согласованность в работе с клиентами привела к увеличению доходов на 24%, а дизайн-системы по своей природе создают консистентность интерфейса (рис. 1.2).
1

Dylan Czarnecki and Harley Manning, «Customer Experience Drives Revenue
Growth, 2016», Forrester, 21 июня 2016 года, www.forrester.com/report/
Customer-Experience-Drives-Revenue-Growth-2016/RES125102.

31

Рис. 1.2. Если вы использовали шапку всего лишь одного продукта Google,
вы знаете, как использовать их все

Но, возможно, вы не пользуетесь продуктами Google.
Может быть, вы пользуетесь продуктами Microsoft. Microsoft применяет тот же подход в своей дизайн-системе Fluent Design System1.
Возможно, вы пользуетесь продуктами IBM. IBM применяет тот же
подход в своей дизайн-системе Carbon Design System2.
Возможно, вы пользуетесь продуктами Salesforce. Salesforce применяет тот же подход в своей дизайн-системе Lightning Design
System3.
Список можно продолжать, но суть очевидна: организации, которые
создают и поддерживают несколько цифровых продуктов, часто
обращаются к дизайн-системам, чтобы решить проблему управления
цифровыми продуктами в масштабе. Если ваша организация хочет
масштабировать цифровые продукты, тогда дизайн-системы — это
не просто хорошая идея, это неизбежность.

Общие преимущества дизайн-систем
Поклонники дизайн-систем часто говорят об их трех основных преимуществах:
zz Дизайн-система способствует поддержанию эффектив-

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

1

«Fluent Design System», Microsoft, https://fluent2.microsoft.design/.

2

«Carbon Design System», IBM, https://carbondesignsystem.com/.

3

«Lightning Design System», Salesforce, www.lightningdesignsystem.com/.

32

расходу средств на цифровые технологии. Наличие готовых
проверенных решений помогает командам быстрее решать
проблемы.
zz Дизайн-система обеспечивает консистентность. Дизайн-

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

zz Дизайн-система способствует развитию инноваций. Переход

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

Я также хотел бы добавить четвертое:
zz Дизайн-система облегчает работу. Команды, работающие над

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

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

Для кого предназначены дизайн-системы
Дизайн-система может быть полезна любому, кто работает в команде разработки цифровых продуктов. Хотя в этой книге основное
внимание сосредоточено на «трех китах»: дизайне, разработке и продукте, работа с дизайн-системой включает в себя множество других
областей, таких как контент, QA, исследование пользовательского
опыта (ресёрч), иллюстрации, бизнес-аналитика, поведенческая
наука и другие сферы, которые обычно присутствуют в команде,
работающей над цифровым продуктом.
Неудивительно, что все это пригодится при создании дизайн-системы для организации. Естественно, что дизайн-система берет свое
начало в рамках определенной области, такой как дизайн, IT или

33

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

Вопросы для размышления
•

Управляет ли ваша команда или организация несколькими
цифровыми продуктами?

•

Какие виды оптимизации инструментов и процессов могли
бы принести пользу вашей организации?

•

В вашей организации уже есть дизайн-система?

УСПЕХ В ДИЗАЙН-СИСТЕМАХ
Хейли Хьюз (Hayley Hughes) — эксперт по дизайн-системам,
работала в нескольких крупнейших и наиболее известных
корпоративных организациях. Я задал ей несколько вопросов о ее опыте работы с дизайн-системами и о том,
что нужно для достижения успеха в этой области.
Чем для вас является дизайн-система?
Для меня дизайн-системы — это сообщество практикующих специалистов, оно состоит из различных команд внутри организации. Это
практика, в рамках которой команды взаимодействуют в постоянно
развивающемся цикле обратной связи: наблюдение, создание и осмысление того, что означает качественный пользовательский опыт
и как его обеспечить. Сообщество создает общие платформы и инструменты для масштабирования идей, стандартов, активов и сервисов по всей организации в целом и управляет ими.
Вы работали над дизайн-системами огромного масштаба в нескольких крупнейших организациях мира. Какие навыки необходимы для
работы на таком уровне?
В крупных организациях дизайн-система поддерживает тысячи людей,
от внутренних команд до внешних партнеров. Она должна быть полезной для различных аудиторий в разных географических регионах
и средах, использующих различные устройства и технологии. При
таком количестве вариантов использования дизайн-система должна
обеспечивать единство, а не единообразие, то есть объединять коман­
ды для создания согласованности во взаимодействиях, но при этом
предоставлять им гибкость и широкие возможности для самовыражения.
Переход от небольших компаний к крупным — это не только изменение набора навыков, но и смена образа мышления. Вы перестаете
воспринимать дизайн-системы исключительно как работу с пикселями и кодом и начинаете видеть их как искусство управления — людьми и процессами.
Операционные навыки, такие как фасилитация, коучинг и дипломатия, помогают координировать процессы и управлять изменениями
в больших группах людей. Это означает, что вы ведете переговоры
для выработки единого подхода между десятками команд. Вы ко-

35

УСПЕХ В ДИЗАЙН-СИСТЕМАХ (продолжение)
ординируете внедрение изменений, которые каскадно распространяются на сотни продуктов. Вы создаете учебные материалы для
подготовки тренеров по дизайн-системе. Вы накапливаете знания
о жизненном цикле разработки продуктов и находите способы, с помощью которых дизайн-системы могут усилить  потенциал организации. Вы ищете закономерности и связываете людей и ресурсы.
Пиксели и код по-прежнему имеют значение, но вы не просто нанимаете людей с навыками, необходимыми для выполнения этой
работы, вы одновременно обучаете их навыкам, необходимым для
масштабирования систем.
Что общего между всеми дизайн-системами, над которыми вы работали?
Я работала над несколькими дизайн-системами в IBM, Airbnb, Nike
и Shopify. Вот одна из причин, по которой я выбрала эту работу: люди,
ведущие эти системы, имеют общие ценности. Во-первых, они понимают, что цель дизайн-систем состоит в улучшении качества принятия решений в командах, а не просто в ускорении разработки.
Во-вторых, они действительно стремятся к развитию сотрудничества
между командами и продуманному внедрению изменений. В-третьих,
они уделяют приоритетное внимание таким аспектам, как доступность,
инклюзивность, локализация и этичность.
С точки зрения размера команд большинство дизайн-систем, над
которыми я работала, имели основную группу дизайнеров и разработчиков, численность которой могла варьироваться от нескольких
человек до нескольких десятков человек в разное время. Все они
использовали общий язык проектирования, общие библиотеки компонентов, а также сайт документации и программу поддержки, предназначенную для обучения и взаимодействия с продуктовыми командами. Обычно такие дизайн-системы располагаются горизонтально
и подчиняются функциям проектирования, эксплуатации или инфраструктуры.
Какие именно различия в организациях делают каждую из их дизайнсистем уникальной по сравнению с другими?
Каждая дизайн-система, над которой я работала, находилась на разной стадии зрелости. Дизайн-система IBM создавалась с нуля, раз-

36

рабатывался стиль дизайна для всего: не только программного
и аппаратного обеспечения, но и зданий, визитных карточек, мероприятий, рекламы и т. д. У Airbnb были проблемы с привлечением
людей к использованию дизайн-системы, поэтому меня попросили
помочь с ее внедрением. Shopify хотела расшириться и сделать свою
дизайн-систему самой крупной. Это означало, что нужно было сосредоточиться на управлении и дать командам возможность создавать
локальные дизайн-системы. Дизайн-система Nike должна была стать
более гибкой, чтобы поддерживать бˆольшую дифференциацию по
брендам, географическим регионам и вариантам использования.
У каждой дизайн-системы есть похожие проблемы, но в зависимости
от того, на какой стадии зрелости она находится, можно отдать предпочтение одной системе перед другой.
Как ваш карьерный путь подготовил вас к столь эффективной работе с дизайн-системами?
Не существует какого-то одного карьерного пути, который бы гарантировал успех в работе с дизайн-системами. У меня в команде были
бывшие биологи, которые были экспертами в петлях обратной связи1,
и юристы, знающие, как работать с лицензированием открытого кода.
Люди, занимающиеся дизайн-системами, приходят из самых разных
областей и имеют разный опыт.
Общим мотивом карьерного пути в дизайн-системах является идея
разносторонности, то есть проявления интереса и способностей
в нескольких областях. Чаще всего это касается совмещения навыков
в дизайне и разработке, но не только. Чтобы стать разносторонним,
нужно попробовать выполнять разные обязанности по работе, прежде чем определить свою роль в разработке дизайн-систем. Поступая
таким образом, вы становитесь междисциплинарным специалистом,
который также лучше понимает других сотрудников.
1

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

37

УСПЕХ В ДИЗАЙН-СИСТЕМАХ (продолжение)
Я не могу назвать себя разносторонней, но большую часть своей
карьеры я работала на стыке нескольких дисциплин. Сначала я сотрудничала с некоммерческими организациями, которые стремились
влиять на политические и экологические системы. Затем я работала
в ресторанах и музеях, создавая системы гостеприимства, брендинга
и навигации. В аспирантуре я изучала системы здравоохранения
и местного питания. Сейчас я занимаюсь дизайн-системами.
Что бы вы посоветовали тем, кто хочет начать карьеру в сфере дизайн-систем?
Ищите «дыры». Если вы сможете представить эти «дыры» как реальную
проблему, тогда у вас появится возможность стать тем, кто сможет
их устранить. Проведите исследование, чтобы понять, что нужно
коман­дам. Например, если вы замечаете проблемы с пользовательской доступностью продукта, копните глубже. Это должно волновать
и бизнес, потому что он, вероятно, обязан соответствовать требованиям по соблюдению стандартов, чтобы избежать судебных разбирательств. Объедините потребности пользователей и бизнес-требования в привлекательную возможность и найдите для нее решение.
Поначалу вам даже не нужно произносить слова «дизайн-система»,
хотя, может быть, это именно то, чем вы и занимаетесь. Как только
вы решите соответствующую проблему, вам начнут доверять, и вы
сможете это использовать, чтобы попросить дополнительные ресурсы — возможно, еще одного члена команды — чтобы продолжить заделывать другие «дыры». Продолжайте отслеживать и измерять результаты, которых вы достигли, решая проблемы. В конце концов все
это будет расти как снежный ком и приведет к тому, что вы сможете
поделиться полноценными кейсами и раскрыть систему, на которой
они основаны.
Что бы вы посоветовали ветеранам дизайн-систем?
Если вы работаете в организации, которая неохотно поощряет системную работу и редко продвигает системных специалистов на
более высокие уровни, не сдавайтесь. В карьере бывают периоды,
когда, что бы вы ни говорили, люди просто «не понимают» дизайнсистем. Может быть, это происходит из-за того, что работа над дизайнсистемой является довольно сложной, и с этим нужно смириться.

38

В другие периоды у вас будут преданные сторонники, которые не
только «поймут» дизайн-системы, но и будут инвестировать в вас
и вашу команду. Можно быть спокойным, зная, что это бесконечный
цикл, поскольку стейкхолдеры и инвесторы приходят и уходят на
протяжении многих лет.
Что мы действительно можем контролировать, так это способность
применять целостный подход к решению любых проблем в организации. Не просто принимайте решения. Изучайте, как принимаются
решения. Людям, которые переходят на роль системного лидера,
необходимо понимать, как вносятся решения, как ими управляют, как
о них узнают. Наша задача — сделать так, чтобы этот рабочий процесс
принятия решений был максимально гладким, простым в исполнении
и способствовал достижению хороших результатов. Это и есть работа над жизненным циклом дизайн-системы.
И наконец, не забудьте задать себе вопрос: где вы можете оказать
наибольшее влияние внутри или даже за пределами вашей организации, используя свои навыки в области дизайн-систем? Ваш ответ
может заключаться в том, чтобы помочь людям лучше работать вместе. Возможно, речь идет об обучении людей системному мышлению.
Может быть, об объединении всей организации и сквозного пользовательского опыта (E2E UX, end-to-end user experience). Границы дизайн-систем находятся только там, где вы проводите черту для себя,
своей команды и своей организации. Продолжайте мечтать и позвольте своему воображению быть вашим проводником.

39

ГЛАВА 2

Основы дизайн-системы
Нерды всех стран, объединяйтесь!

43

Различные виды дизайн-систем

44

Выберите свою дизайн-систему

51

Вопросы для размышления

52

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

KPI

СПРАВОЧНЫЙ
САЙТ

ФОТОГРАФИЯ
КОМАНДЫ
САЙТ ДОКУМЕНТАЦИИ
ЧЕРЕЗ НАШ УДОБНЫЙ
ВНУТРЕННИЙ
URL-ЯРЛЫК

ПУСТОЙ ЭСКИЗНЫЙ
ДОКУМЕНТ

СКЕТЧ-ФАЙЛ

СИСТЕМА
АДАПТИВНОЙ
ТИПОГРАФИКИ

ЛОГОТИП

ПРОДУКТ,
СОЗДАННЫЙ
С ПОМОЩЬЮ
СИСТЕМЫ
JIRAСТОРИЗ

ПРИНЦИПЫ
ДИЗАЙНА

ОРГСТРУКТУРА
КНОПКА
EMAIL / ПРЕЗЕНТАЦИЯ /
SLACK-СООБЩЕНИЯ

МУДБОРД

РЕЗУЛЬТАТЫ
ИССЛЕДОВАНИЙ

STORYBOOK

ОДНА ИЗ МОИХ
ПРЕДВАРИТЕЛЬНЫХ
ВЕРСИЙ ПРЕЗЕНТАЦИИ,
ПРОДВИГАЮЩАЯ ВСЕ
ЧАСТИ СИСТЕМЫ

STYLEGUIDE.SCSS
БИБЛИОТЕКА
ДОСТУПНОСТИ

ДИЗАЙНТОКЕНЫ

ПРИЛОЖЕНИЕ

БИБЛИОТЕКА
КОМПОНЕНТОВ

ПРОДАКШЕНСРЕДА

BOOTSTRAP

ДОКУМЕНТАЦИЯ
TAILWIND

НЕЗАКОНЧЕННАЯ
РАБОТА

ТАЙМЛАЙН

ЦВЕТОВЫЕ
ПАЛИТРЫ

Рис. 2.1. Дизайн-система — это экосистема, состоящая из множества
различных частей

42

Из любопытства я спросил людей в Twitter, как они могли бы описать
свою дизайн-систему1, и получил десятки разных ответов (рис. 2.1).
Ни один из них не был абсолютно точным, но все вместе они создавали полную картину.

Нерды всех стран, объединяйтесь!
Несмотря на бесчисленное количество статей, книг, видеороликов,
курсов и других материалов о дизайн-системах в интернете, сложность их понимания заключается в том, что индустрия цифрового
дизайна в целом не пришла к единому определению. Вот несколько
различных взглядов на то, что такое дизайн-система.
Набор взаимосвязанных паттернов и общих практик, последовательно
организованных для обслуживания целей цифрового продукта.
Алла Холматова (Alla Kholmatova),
UX + дизайнер взаимодействия
Дизайн-система — это библиотека визуальных стилей, компонентов
и других аспектов, задокументированных и выпущенных отдельным
человеком, командой или сообществом в виде кода и инструментов
дизайна с целью сделать внедрение продуктов более эффективным
и согласованным.
Натан Кертис (Nathan Curtis),
евангелист дизайн-системы, EightShapes
Дизайн-система — это официальная история о том, как ваша организация
проектирует и создает цифровые интерфейсы.
Брэд Фрост (Brad Frost),
фронтенд-дизайнер
Дизайн-система — это любой набор решений, регулируемых в рамках
организации.
Хейли Хьюз (Hayley Hughes),
директор по дизайну, Nike
Компоненты — это деревья. Дизайн-система — это лес.
Джереми Кит (Jeremy Keith),
веб-разработчик
1

Дэн Молл [@danmall], «Если бы кто-то сказал: “Покажите мне вашу дизайн-систему”, что бы вы обозначили первым делом?» Twitter, 6 апреля
2020 года, https://twitter.com/danmall/status/1247285170396422145.

43

Все эти высказывания точны! Сложность заключается в том, что
основные слова «дизайн» и «система» имеют широкое значение.
Давайте разберемся, откуда они произошли.
Слово «дизайн» особенно сложно объяснить, потому что это и существительное, и глагол. Оно возникло как глагол в конце XIV века от
латинского слова «designare», что означает «делать опознавательный
знак». Слово также превратилось в существительное в конце XVI века
от французского слова «desseign», что означает «составление плана
с определенной целью».
Слово «система» появилось в начале XVII века на основе латинского
слова «systema», означающего «расположение», и греческого слова
«systema», означающего «организованное целое, состоящее из частей».
Если соединить все это вместе, получится нечто близкое к понятию
«организованное соглашение для определенной цели». Это можно
применить к чему угодно!

Различные виды дизайн-систем
Вместо того чтобы пытаться дать одно четкое определение дизайнсистеме, чтобы отличать, что является таковой, а что нет, давайте
посмотрим шире. Никаких ограничений! Определим несколько различных типов дизайн-систем: это будет полезным упражнением.
Применительно к работе над цифровыми продуктами вот семь
распространенных видов дизайн-систем:
1. Дизайн-системы как фирменные стили и визуальные языки.
2. Дизайн-системы как проекты.
3. Дизайн-системы как инструменты и шаблоны.
4. Дизайн-системы как цифровые продукты.
5. Дизайн-системы как процесс.
6. Дизайн-системы как услуга.
7. Дизайн-системы как практика.

Дизайн-системы как фирменные стили
и визуальные языки
Визуальные языки — один из старейших видов дизайн-систем. Люди
использовали символы для передачи смысла, начиная с наскальных
рисунков 38 000 лет до н. э., алфавита шумеров в 3000 году до н. э.,

44

подвижного шрифта в Китае VI века, современного печатного станка Гутенберга в 1400-х годах и заканчивая электронным письмом,
которое вы, возможно, отправили несколько часов назад. Бренды
разрабатывают визуально идентичные образы, которые они повторно используют, чтобы закрепиться в сознании своих потребителей. Например, определенный оттенок голубого напоминает людям
о продавце ювелирных изделий класса люкс — компании Tiffany &
Co. (рис. 2.2). Простой силуэт бутылки вызывает желание выпить
ледяной кока-колы (рис. 2.3). Люди знают, что если фраза на футболке набрана шрифтом Futura Extra Bold Condensed, то это футболка Nike, без всяких других сигналов (рис. 2.4). Визуальные языки — важный и распространенный вид дизайн-системы в нашем
насыщенном брендами мире.

Рис. 2.2. Знаменитый голубой цвет
Tiffany Blue® является важной частью
фирменного стиля Tiffany & Co

Рис. 2.3. Простой силуэт бутылки
в сочетании с определенным
оттенком красного цвета кричит
о кока-колe

Рис. 2.4. Текст, набранный
шрифтом Futura Extra Bold
Condensed, напоминает
о футболке Nike еще до того,
как вы увидите логотип

45

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

Дизайн-системы как инструменты и шаблоны
Инструменты и шаблоны особенно полезны для поставщиков услуг, таких как фрилансеры, студии и агентства, выполняющие
работу для других. Это дизайн-системы, которые предназначены
для того, чтобы в итоге их можно было отделить от своего первоисточника и использовать в другом месте. Это могут быть шаблонные контракты и соглашения, шаблоны Keynote и PowerPoint или
некоторые общие файлы кода, с которых начинается каждый
проект.
HTML5 Boilerplate1 — отличный пример дизайн-системы как инструмента. Он создан в центральном источнике и предназначен
для того, чтобы другие могли брать его и изменять для своих нужд
(рис. 2.5). Создатели называют его «дружественным к клавише
Delete», поскольку он содержит больше, чем вам, вероятно, понадобится, а процесс создания собственного шаблона включает
удаление частей, которые неприменимы к вашему варианту использования.
Быстрый способ внедрить дизайн-систему как инструмент и шаблон — воспользоваться уже готовой. Хотя дизайн-система как
проект обычно предполагает создание инструмента или шаблона,
вы вполне можете приобрести готовый инструмент или начать с бесплатного решения с открытым исходным кодом.

1

«HTML5 Boilerplate», https://html5boilerplate.com/.

46

Рис. 2.5. HTML5 Boilerplate — это простой шаблон для быстрого создания
веб-страниц, соответствующих лучшим практикам

Дизайн-системы как цифровые продукты
В цифровом дизайне продукты — это программные решения, для
которых обычно регулярно выпускаются новые версии. Как правило, их совершенствованием занимается один человек или небольшая
команда. Это часто означает, что периодически выделяются средства на техническое обслуживание и оплату труда сотрудников.
(Именно о такой дизайн-системе вы, вероятно, хотели узнать больше, когда взялись за чтение этой книги.)
Дизайн-система Polaris компании Shopify — отличный пример дизайн-системы, которая является цифровым продуктом (рис. 2.6).
В Shopify есть сотрудники, чья работа заключается в том, чтобы
заниматься Polaris на постоянной основе. В разделе «What’s new»
(«Что нового») описаны последние изменения под названием «Ver­
sion 10 typography», что подразумевает, что до этого уже было выпущено девять версий!

47

Рис. 2.6. Дизайн-система Polaris от Shopify — это цифровой продукт, который
помогает сотрудникам Shopify формировать пользовательский опыт для
своих клиентов

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

48

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

Дизайн-системы как процесс
Некоторые дизайн-системы не имеют материальной формы. Для
многих организаций дизайн-система может быть особым способом
разработки и создания продуктов, который все могут принять и применить.
Дизайн-спринты — отличный пример дизайн-системы как процесса. Популяризированный командой венчурного фонда Google GV,
дизайн-спринт — это пятидневный цикл решения критически важных для бизнеса вопросов посредством проектирования, создания
прототипов и тестирования идей с клиентами (рис. 2.8). Независимо от конкретного клиента или варианта использования, команда GV
использует систему дизайн-спринтов, чтобы помочь своим портфельным компаниям проектировать новые продукты и исследовать
новые рынки.

49

те
Начнинца
о
к
с

ка
аботие
р
е
р
е
П лучшен
иу

Карта

Решение

Прототип
Тест

Набросок

ите
Спропсертов
с
эк
Цель

сия
Дискусбор
т
ио
рд
Сторибо

Анализ

Рис. 2.8. Пятидневный спринт GV — процесс, который будет полезен
любой компании, которая возьмет его на вооружение

Существует множество различных видов процессов разработки
продуктов и дизайна, которые могут быть использованы в качестве
дизайн-систем, например двойные ромбы (double diamonds), спиральные модели (spiral models), бережливое производство (Lean)
и многие другие. Чтобы такие процессы стали полноценными дизайн-системами, нужно сделать их общим способом работы для
вашей команды или всей организации.

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

50

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

Дизайн-системы как практика
В своем блоге преподаватель йоги Джеймс Хапп (James Happe)
описывает разницу между занятиями йогой и практикой йоги1. Он
говорит о том, что заниматься йогой может каждый. Это может
быть весело и легко. Йога может быть частью еженедельного расписания, изредка или часто, как вам больше нравится.
Практика йоги, однако, «больше связана с усилиями, чем с результатом... Она требует активного вовлеченного обучения со стороны
ученика, где инструкции усваиваются только через вопросы, эксперименты, применение и размышления. Это требует искреннего
внимания».
Дизайн-системы тоже могут быть практикой. Дизайн-системы как
практика не касаются конкретного артефакта, инструмента, технологии или процесса. Вместо этого речь идет о совместных, коллективных усилиях, которые могут гармонично объединить такие
разрозненные дисциплины, как продукт, дизайн и разработка.
Какую бы дизайн-систему или их комбинацию вы ни выбрали, вам
придется следовать этой практике непрерывно, чтобы добиться
хороших результатов. Чем больше вы работаете с инструментом,
тем лучше вы его используете. Чем больше вы используете процесс,
тем более знакомым он становится. Дизайн-системы, которые не
практикуются, рискуют быстро стать нерабочими, поэтому обязательно выделяйте время для практики использования дизайн-системы, которую вы выбрали.

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

James Happe, «The Difference Between Practicing Yoga and Doing Yoga»,
22 сентября 2014 года, https://jameshappeyoga.co.za/practicing-yoga-doing-yoga/.

51

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

Вопросы для размышления
•

С какими видами дизайн-систем вы работали? Какие из
них для вас в новинку?

•

Какой вид или комбинация видов дизайн-систем имеется
в вашей организации? Есть ли другой вид или комбинация
видов дизайн-систем, которые бы работали лучше?

•

Как вы можете донести до своей команды, какого именно
вида дизайн-систему вы стремитесь создать, чтобы все
работали над одной и той же целью?

ГЛАВА 3

Составляющие
дизайн-системы
как продукта
Основные составляющие дизайн-системы

54

Дизайн-система — это совокупность всех составляющих

66

Дизайн-система — это взаимосвязь

66

Библиотеки компонентов vs дизайн-система

67

Соедините всю цифровую экосистему

72

Вопросы для размышления

73

Первым автомобилем массового производства был Ford Model T,
созданный компанией Ford Motor Company в 1908 году. В нем было
всего лишь несколько составляющих: двигатель, трансмиссия, подвеска, колеса и кузов.
Более века спустя автомобили стали намного сложнее и прогрессивнее, чем Model T. Современные авто автоматически включают
стеклоочистители при появлении влаги на стекле, автоматически
приглушают свет фар при приближении встречного авто, а некоторые и вовсе могут ездить самостоятельно.
И все же, несмотря на все эти достижения и существенные различия,
можно с уверенностью предположить, что сегодняшнему водителю
будет несложно управлять Model T. Современные автомобили имеют
ту же базовую конструкцию: двигатель, трансмиссия, подвеска, колеса и кузов. Благодаря этим стандартным компонентам даже начинающий водитель может сесть в любой из совершенно разных
автомобилей, выпущенных в течение многих десятилетий, и освоиться всего за несколько минут, потому что основные элементы у них
остаются практически неизменными.
То же самое можно сказать и о дизайн-системах. Каждая дизайнсистема уникальна, потому что уникальна каждая организация, но
один и тот же набор стандартных составных частей, как правило,
встречается от системы к системе. Это означает, что если вы научились использовать одну дизайн-систему, то сможете довольно быстро
освоить большинство других.

Основные составляющие дизайн-системы
Наиболее распространенные составляющие дизайн-системы как
продукта, как правило, естественным образом соответствуют тому,
что нужно дизайнерам и разработчикам в их повседневной работе.
Сюда входят несколько инструментов и ресурсов, несколько инструкций по их использованию и несколько способов донести все
это до широкой аудитории. Многие дизайн-системы включают в себя
следующие шесть составляющих (рис. 3.1):
zz UI-кит;
zz библиотека компонентов;
zz гайдлайны;

54

zz справочный веб-сайт;
zz дизайн-токены;
zz цифровые продукты, например веб-сайты и приложения.

ДИЗАЙН-СИСТЕМА

ДИЗАЙН-ТОКЕНЫ

ГАЙДЛАЙНЫ

СПРАВОЧНЫЙ
САЙТ

ПРИЛОЖЕНИЕ

UI-КИТ

БИБЛИОТЕКА
КОМПОНЕНТОВ

ВЕБ-САЙТ

Рис. 3.1. Здесь показаны шесть наиболее распространенных составляющих
дизайн-системы как продукта

Давайте изучим и проанализируем каждую из этих состав­ляющих.

55

UI-кит
Многие люди при упоминании дизайн-системы представляют себе
UI-кит (User Interface Kit) — файл, обычно созданный в таких инструментах дизайна, как Figma или Sketch, который отображает
все отдельные компоненты так, как если бы они были разложены
на столе (рис. 3.2).

Рис. 3.2. Tetrisly — пример популярного UI-кита

UI-киты полезны, но они являются лишь частью дизайн-системы
как продукта, а не всем его содержимым. Приоритет UI-китов над
другими частями — один из главных виновников того, что дизайнсистемы не получают широкого распространения в организации.
На самом деле UI-кит может быть наименее важной частью всей
экосистемы.
За последние несколько лет в индустрии дизайна произошло свое­
образное возрождение дизайнерских инструментов в таких приложениях, как Figma и Sketch. Однако сопутствующая этому возрождению опасность заключается в том, что инструменты
начинают применять для задач, на которые они на самом деле
не рассчитаны.

56

В своей речи на конференции компании Config Europe 20201 генеральный директор Figma Дилан Филд (Dylan Field) представил новую
функцию Variants, продемонстрировав файл, отображающий страницу настроек мобильного приложения Spotify. Он описал проблему,
с которой сталкиваются дизайнеры: «Если бы я сегодня попытался
сделать прототип этой страницы в Figma, мне пришлось бы создать
чудовище, потому что нужно было бы думать обо всех возможных
комбинациях, а это что-то около двадцати шести. Мы начали создавать прототип, чтобы посмотреть, будет ли он работать, но остановились на полпути, потому что есть более полезные занятия, на
которые можно потратить время».
Хотя новая функция Figma Variants, безусловно, упрощает создание
прототипов подобных страниц настроек, скрытая проблема заключается в том, что она создает у дизайнеров ложное ощущение, что
такую работу вообще не нужно делать. Вместо того чтобы работать
над созданием ценности для клиентов, дизайнеры тратят свои усилия на полировку наборов UI-китов и настройку экранов состояний
в графическом редакторе, а не в полноценной программной среде.
(Более подробно о работе, заслуживающей усилий, я расскажу в главе 7 «Роли и обязанности».)

Библиотека компонентов
Разработчикам нужен свой собственный эквивалент UI-кита, но
в коде, а не в качестве инструмента дизайна. Обычно это называется библиотекой компонентов, или библиотекой паттернов.
(В дальнейшем в этой книге я буду называть ее «библиотекой компонентов», но в целом эти термины взаимозаменяемы.) Компоненты — это многократно используемые фрагменты кода. Библиотека
компонентов — это, соответственно, набор фрагментов кода, где
можно найти примеры и референсы для внед­рения в кодовую базу.
Дизайн-системы, являющиеся продуктами, должны каким-то образом соединять многократно используемый код компонентов
с цифровыми продуктами, с которыми взаимодействуют конечные
потребители, и библиотеки компонентов — самый распространенный способ сделать это. Именно поэтому большинство таких дизайн-

1

«Config Europe 2020», YouTube, 17 сентября 2020 года, www.youtube.com/
watch?v=lWy4fB3G9Gc.

57

систем — это библиотеки компонентов с последующими инструкциями, прилагающимися к компонентам.
Material Design от Google — это скорее методология, чем продукт;
о ней можно прочитать на справочном сайте Material Design
(рис. 3.3). Однако на момент написания этой книги веб-библиотека
компонентов для Material представляет собой простой репозиторий
компонентов на GitHub с очень скудной документацией1, поэтому
другие сторонние компании взяли на вооружение методологию
Material Design и создали для нее свои собственные библиотеки
компонентов (рис. 3.4).

Рис. 3.3. Material Design — это не просто библиотека компонентов.
Это целая методология проектирования и создания цифровых продуктов,
которые по своей сути напоминают продукты Google

1

Material Design Team, «Material Web», GitHub, https://github.com/materialcomponents/material-web#readme.

58

Рис. 3.4. MUI (Material UI) — это сторонняя библиотека, в которой
представлены закодированные компоненты, основанные
на подходе Material Design

Поскольку индустрия продуктов дизайн-систем еще очень молода,
в ней появляется множество новых и перспективных идей. Одна
из них — использование инструментов, таких как Bit (рис. 3.5),
продвигающих микрофронтенд-подход. Концепция заключается
в отказе от создания монолитных, ориентированных на всю организацию дизайн-систем в пользу, по словам разработчиков Bit,
«компонентно-ориентированных приложений, состоящих из независимых компонентов, созданных автономными командами, работающими бок о бок».

59

Рис. 3.5. Bit — набор инструментов с открытым исходным кодом
для разработки компонентно-ориентированного
программного обеспечения

Гайдлайны
В каждой хорошей дизайн-системе есть гайдлайны, то есть рекомендации, советы или правила, которым нужно следовать, чтобы
наилучшим образом ее использовать. Хорошие гайдлайны подскажут
вам, что делать и чего не делать. Гайдлайны дизайн-системы часто
принимают форму принципов или лучших практик пользовательского опыта.
На первый взгляд может показаться, что это то же самое, что и справочный сайт, но не все гайдлайны или документация должны размещаться на справочном сайте, или, точнее сказать, вообще не
должны! Лучшие гайдлайны помогают дизайнерам и разработчикам
на том этапе работы, когда они в них нуждаются, что часто называют документацией «точно в срок» (just-in-time). Например, дизайнер Майк Уилсон (Mike Wilson) создал плагин для Figma под назва-

60

нием Gist 1 (рис. 3.6), который позволяет «просматривать
прикрепленную документацию, не покидая рабочий файл». Документация по компоненту отображается прямо перед вами, пока вы
работаете над ним в своей рабочей среде.

Рис. 3.6. Плагин Gist для Figma переносит документацию прямо
в среду проектирования

Справочный веб-сайт
UI-киты, библиотеки компонентов и гайдлайны обычно собираются
вместе на справочном сайте. Справочный сайт — это видимое проявление дизайн-системы, URL, по которому отображается как полная библиотека компонентов, так и набор гайдлайнов. Большинство
таких сайтов в основном содержат справочную документацию. (При
этом упускается большая возможность, о которой я расскажу в главе 10 «Евангелизм никогда не прекращается».) Свободный доступ
к документации, необходимой для работы с дизайн-системой, играет большую роль в том, насколько широко эта система применяется. Если система сложна в использовании или специалист не может
понять, как с ней работать, он, скорее всего, захочет найти другой
ресурс, тот, который покажется ему проще. Это, вероятно, и является причиной того, что многие рассчитывают на Bootstrap или
Material Design, вместо того чтобы создать собственную дизайнсистему или даже использовать ту, которая у них уже есть.

1

Mike Wilson, «Gist», Figma Community, www.figma.com/community/plugin/
1073059820691713754/Gist.

61

У многих популярных дизайн-систем справочный сайт для большинства людей является точкой входа в систему. Когда они говорят
о Polaris от Shopify, то часто имеют в виду то, что видят на https://
polaris.shopify.com; когда упоминают дизайн-систему Carbon Design
System от IBM — то, что есть на сайте https://carbondesignsystem.com;
а когда говорят о дизайн-системе Lightning компании Salesforce, —
вспоминают www.lightningdesignsystem.com/. Во всех этих примерах
справочные сайты полностью общедоступны (публичны), то есть
любой человек, имеющий подключение к интернету, может их просматривать.
У публичного справочного веб-сайта есть множество преимуществ.
Фронтенд-дизайнер Брэд Фрост подробно рассказывает об этом
в своей книге «Atomic Design». Подраздел о том, как сделать дизайнсистему публичной, является частью большого раздела под названием «Make It Visible» («Сделайте ее видимой») в главе «Maintaining
Design Systems» («Поддержка дизайн-систем»). И это правильно!
Когда вы делаете дизайн-систему доступной всем, это исключительно важно для понимания того, как ею управлять и как ее поддерживать. Брэд объясняет, что создание публичной дизайн-системы:
zz повышает ее заметность, что увеличивает вероятность ис-

пользования;

zz формирует ответственность, демонстрируя приверженность

продукту, ориентированному на консистентность и возможность
повторного использования;

zz помогает в подборе персонала, публично демонстрируя цен-

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

При всех преимуществах публичного справочного сайта дизайнсистемы почему же не все они являются таковыми? Теоретически
нет ничего сложного в том, чтобы сделать дизайн-систему общедоступной. В конце концов, основной навык веб-дизайнера или вебразработчика — взять HTML-файлы и разместить их на сервере,
имеющем связанный URL. (Кто-нибудь знает об FTP?)
Что мешает дизайн-системе быть общедоступной? Если коротко:
бизнес. Если вы работаете в организации, достаточно разросшейся,
чтобы оправдать наличие дизайн-системы, велика вероятность того,
что существует IT-процесс для развертывания любого сайта. Этот
процесс, скорее всего, включает в себя аутентификацию в той или

62

иной форме, а запуск чего-либо публично является одним из самых
рискованных действий, поэтому к нему предъявляются самые строгие требования. Я видел, как этот процесс занимает месяцы или
даже полностью блокируется. Все это может стать сдерживающим
фактором даже для одной только попытки создания публичной
дизайн-системы.
Старший руководитель отдела UX LinkedIn Нейт Уитсон (Nate Whitson)
говорит об этом прямо: «Публично делиться всей своей документацией — довольно нетривиальное решение». Нейт далее разъясняет
это утверждение, говоря о том, что обмен информацией за пределами компании означает необходимость дополнительного контекста
для непосвященных, а это, в свою очередь, означает дополнительные
расходы на написание, проектирование и документирование.
Но общедоступность не является решением по принципу «все или
ничего». Общепринятое определение подобной дизайн-системы, как
правило, относится к дизайн-системе, имеющей публичный справочный сайт и библиотеку с открытым исходным кодом. Руководитель отдела дизайна GitHub Диана Маунтер (Diana Mounter) описывает различные степени публичности дизайн-системы:
zz Только публичная документация: справочный сайт доступен

всем, но сам код скрыт.

zz Библиотека с открытым исходным кодом: не только код до-

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

zz Документация с открытым исходным кодом: люди могут

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

zz Доступная для скачивания: обычно представляется в виде zip-

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

zz Публичная библиотека компонентов: публикуется версия

библиотеки компонентов, доступная только для чтения (например, в Storybook, Pattern Lab, Fractal и т. д.) по публичному URL.

Разработчик Райан Де Беази (Ryan DeBeasi) делится тем, как он
в прошлом шел на компромисс: «У нас не было разрешения сделать

63

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

Дизайн-токены
Дизайн-токены не являются обязательным элементом дизайн-системы, как, например, гайдлайны или библиотека компонентов, но
КРАТКИЙ ОБЗОР ДИЗАЙН-ТОКЕНОВ
Эстер Черан (Esther Cheran) — директор по продуктам
и соучредитель компании Hyma, создающей инструменты нового поколения в области дизайн-систем
и дизайн-токенов. Она также является соавтором
популярного плагина Tokens Studio для Figma. Я задал
ей несколько вопросов о ее опыте работы с дизайнтокенами и о том, как они помогают повысить эффективность дизайн-системы.
Что такое дизайн-токен?
Дизайн-токены — это мельчайшие дизайнерские решения, которые заключают в себе элементы идентичности бренда. В качестве примера
можно привести такие дизайнерские решения, как радиус скругления
границы, толщина границы или фоновая заливка кнопки.
Каков ваш опыт работы с дизайн-токенами?
Я начала использовать дизайн-токены для создания токенизированной
дизайн-системы, которая в конечном счете превратилась в систему
Headless Design System1. В то время я активно использовала Tokens Studio,
созданную Яном Сиксом (Jan Six), и в итоге начала участвовать в разработке плагина и стала одним из его соавторов.
Я расширяла границы использования дизайн-токенов, чтобы создать
полностью «безголовую» дизайн-систему, и эта концепция получила широкое распространение среди множества команд, создающих мультибрендовые дизайн-системы.
1

64

Headless («безголовая») design system — это дизайн-система, которая
предоставляет только стилистически нейтральные, полностью настраиваемые компоненты без заранее заданного визуального оформления. — Примеч. ред.

многие команды применяют или начинают применять их, чтобы
сделать дизайн-систему более полезной и мощной. По определению
Design Tokens W3C Community Group, дизайн-токен — это «единый
источник истины (source of truth) для наименования и хранения
дизайнерского решения, доступный всем командам, чтобы они
могли использовать его в различных инструментах дизайна и языках программирования». Одним из распространенных применений
дизайн-токенов является централизация атрибутов дизайна и бренда на нескольких платформах, таких как веб, iOS, Android и других.

Как дизайн-токены помогают дизайнерам?
Сейчас токены доступны для дизайнеров непосредственно в процессе
их работы благодаря такому плагину, как Tokens Studio, а вскоре появятся и встроенные реализации этой функциональности в ­инструментах
дизайна. Таким образом у дизайнеров есть возможность предоставлять
непосредственную обратную связь, что значительно упрощает поддержку системы, а также делает ее консистентность менее подверженной
человеческим ошибкам.
Как дизайн-токены помогают разработчикам?
Дизайн-токены избавляют дизайнеров от необходимости гадать, как
интерпретировать дизайн. Любые незначительные изменения внешнего
вида компонентов могут быть выполнены ими самостоятельно, не прибегая к помощи разработчиков.
Как дизайн-токены помогают членам команды, которые не являются
дизайнерами или разработчиками?
Дизайн-токены дают всем единый источник истины. Например, команды
бренда могут визуализировать и быстро создать прототип того, как будет
выглядеть бренд, используя макеты на основе токенов.
Что бы вы посоветовали тем, кто никогда раньше не пользовался дизайн-токенами?
Дизайн-токены следует использовать в соответствии с требованиями
вашего проекта. Возможно, вам не понадобится сложная архитектура
дизайн-токенов с несколькими уровнями наборов токенов и тематик,
если вы создаете дизайн-систему одного бренда. Достаточно будет простой архитектуры. С другой стороны, мультибрендовая дизайн-система,
обслуживающая разные платформы, может потребовать более сложной
многоуровневой архитектуры.

65

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

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

Дизайн-система — это взаимосвязь
Большая часть разговоров о дизайн-системах, как правило, сосредоточена вокруг компонентов: как их проектировать, составлять,
комбинировать и т. д. В своей книге «Thinking in Systems» ученыйэколог, педагог и писательница Донелла Медоуз (Donella Meadows)
поясняет, что является системой, а что нет. Она говорит: «Конгломерат без каких-либо конкретных взаимосвязей или функций
[не является системой]… перестаньте анализировать элементы

66

и начните искать взаимосвязи, отношения, которые удерживают
эти элементы вместе»1.
То, как отдельные компоненты связаны друг с другом, важнее, чем
сами компоненты. Ищите то, что их объединяет, что является общим,
и то, как компоненты взаимодействуют друг с другом.
Настоящие дизайн-системы имеют внутреннюю связанность. Дизайн
и разработка должны быть связаны с продуктом. Как именно это
сделать? Читайте дальше!

Библиотеки компонентов vs дизайн-система
Часть путаницы вокруг дизайн-систем происходит потому, что одни
термины и понятия взаимозаменяемы, а другие — нет. Трудно понять, что к чему. «Библиотека компонентов» и «библиотека паттернов» обычно означают одно и то же. Компоненты «alert» (оповещения)
часто называются «notification» (уведомления) или «toast» (тосты).
А вот «pill» («таблетка») и «badge» (значок) — это совершенно разные
вещи, хотя внешне они могут выглядеть одинаково.
Пожалуй, самое распространенное смешение терминов происходит
в рамках различия между библиотекой компонентов и дизайн-системой. Эти термины не могут и не должны использоваться как
взаимозаменяемые, потому что это совершенно разные вещи, даже
если на первый взгляд они кажутся сопоставимыми.

Как использовать библиотеку компонентов
Изначально Bootstrap был задуман как «простой и гибкий HTML,
CSS и JavaScript для популярных компонентов пользовательского
интерфейса и взаимодействий» (рис. 3.7). Из этого описания неясно, является ли Bootstrap библиотекой компонентов или полноценной дизайн-системой.
Ясность достигается за счет предполагаемого способа использования
Bootstrap. Два основных призыва к действию (CTA) в верхней части
страницы сайта: «View Project on GitHub» («Посмотреть проект на
GitHub») и «Download Bootstrap» («Скачать Bootstrap». Последующие
версии Bootstrap упростили их еще больше, оставив только «Download
1

Donella H. Meadows, «Thinking in Systems» (White River Jct., VT: Chelsea
Green Publishing, 2008), 14.

67

Bootstrap». Нажатие этой кнопки приводит к скачиванию ZIP-папки
с файлами CSS, иконками и файлами JavaScript, которые можно
скопировать и вставить в сборку.

Рис. 3.7. Веб-сайт Bootstrap дебютировал с несколькими общими
компонентами, которые могли использовать дизайнеры и разработчики

Это первая подсказка о том, является ли Bootstrap библиотекой
компонентов или дизайн-системой. Скачивание файлов — это работа с дубликатами, это ваша собственная копия оригинального
набора файлов. Скачивание означает, что у вас есть собственная
версия, то есть версия Bootstrap в ваших файлах больше не связана с официальной версией Bootstrap. Помните: настоящие дизайнсистемы являются связанными, поэтому такое использование
Bootstrap не является использованием дизайн-системы.
Разница становится еще более заметной, когда вы начинаете использовать компоненты Bootstrap. Например, чтобы использовать
компонент Bootstrap «Breadcrumb» («хлебные крошки»), нужно перей­
ти на страницу «Breadcrumb» в раздел документации «Components»
и скопировать этот код в свою сборку:

68

<nav aria-label="breadcrumb">
<ol class="breadcrumb">
<li class="breadcrumb-item"><a href="#">Home</a></li>
<li class="breadcrumb-item active" aria-current="page">
Library
</li>
</ol>
</nav>

И снова, как только вы копируете и вставляете, вы разрываете все
связи с исходным источником. Для тех, кто знаком с Figma, это
кодовый эквивалент отделения экземпляра от исходного определения компонента. Библиотеки компонентов в основном полагаются
на копирование и вставку, в то время как дизайн-системы поддерживают связь с первоисточником.
Стоит отметить, что в использовании библиотеки компонентов нет
ничего плохого. На самом деле библиотеки компонентов невероятно
полезны для общей практики разработки программного обеспечения
и отчасти были предшественниками того, что в итоге превратилось
в практику дизайн-систем. Однако библио­тека компонентов не использует многие из преимуществ, которые может дать продуктовой
команде и организации настоящая взаимосвязанная дизайн-система.
Представьте, что команда, которая разрабатывает Bootstrap, выпускает новую версию с обновленными «хлебными крошками». Хотя
обновления могут быть полезными и желательными, они могут конфликтовать с настройками, сделанными вами в версии, которую
вы скачали и с которой работали. Вы окажетесь перед выбором:
сохранить проделанную работу или обновить ее и начать с нуля.

Как использовать дизайн-систему
Сравните это с использованием чего-то вроде Material UI, дизайнсистемы на основе React, созданной для внедрения в продукты
эстетики Material Design от Google. Нажав «Get Started» («Начать»)
или прокрутив домашнюю страницу вниз, вы узнаете, как применять Material UI в своей сборке. В отличие от Bootstrap, которая
предлагает только скачать файлы, Material UI просит вас установить
ее, то есть сначала скопировать, а затем обязательно выполнить
определенные действия с этим файлом. Это важное различие: библиотеки компонентов скачиваются, а дизайн-системы нужно
устанавливать. Давайте разберемся, как это работает, на примере
приложения React и создадим, к примеру, дашборд, позволяющий
быстро оценить состояние ваших личных финансов.

69

Откройте корневой каталог приложения React в окне терминала.
Введите npm install @material-ui/core в командной строке.
Вот и все! Дизайн-система теперь установлена в качестве зависимости в вашем финансовом дашборде в приложении на React. Проще говоря, этот финансовый дашборд создан на основе дизайнсистемы Material UI.
Вы можете сами это проверить, просто чтобы убедиться. Если вы
откроете файл package.json в корневой папке этого проекта, то
увидите следующие строки:
{

}

"name": "Example App",
"version": "5.0.0",
"private": true,
"scripts": {
// build scripts go here
},
"dependencies": {
"@material-ui/core": "^5.0.0-alpha.12",
"react": "latest"
}

Строка 9 — это то, что вы ищете. В переводе на обычный язык эта
строка говорит о том, что ваше приложение финансового дашборда зависит от Material UI версии 5.0.0, выпуска альфа 12. Как дети
зависят от своих родителей в некоторых важных вещах, так и это
приложение зависит от Material UI. Если бы Material UI не существовало, ваш дашборд был бы неполным. Это ссылка на исходную
дизайн-систему. Это та самая взаимосвязанность, о которой говорила Донелла Медоуз.
Преимущество такого соединения — обновления в режиме реального времени в обоих направлениях. Если команда Material UI
вносит изменения в «хлебные крошки», вы получаете обновления
бесплатно, как только решите, что они вам нужны. Все, что нужно
сделать, это набрать в терминале npm update @material-ui/core. Это
исправит строку в package.json, которую вы только что просмотрели, с "@material-ui/core": "A5.0.0-alpha.12" на "@material-ui/core":
"A5.0.1-alpha.13". Никакого переопределения не произойдет. Никаких стертых изменений. Никакой повторной работы. Программа
сама выполнит слияние, сохранив ваши старые наработки при
интеграции нового материала, и вы даже об этом не узнаете.

70

ЧТО ТАКОЕ REACT?
Многие популярные дизайн-системы построены на React. Что такое React
и почему это хороший выбор для дизайн-систем?
Согласно официальному сайту, React — это «библиотека JavaScript для
создания пользовательских интерфейсов» (рис. 3.8). Изначально она была
создана в 2011 году разработчиком Facebook Джорданом Уокером (Jordan
Walker), чтобы упростить создание сложных пользовательских интерфейсов,
таких как лента новостей Facebook. То, что библиотека поддерживает такую
посещаемую страницу, является отличным доказательством успеха концепции, поэтому многие разработчики стали выбирать именно React.

Рис. 3.8. React — популярная библиотека для создания
пользовательских интерфейсов

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

71

Если вы вносите изменения в «хлебные крошки» с вашей стороны
и решаете, что они пригодятся всем остальным пользователям Mate­
rial UI, вы также можете внести их в библиотеку Material UI, чтобы
другие тоже могли использовать их — при условии, что у вас есть
соответствующие разрешения на это. (Более подробно о таком вкладе я расскажу в главе 5 «Пилотные проекты — лучший способ запустить и поддерживать дизайн-систему».)

ПРИМЕЧАНИЕ  

ВЕБ И НАТИВ

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

Соедините всю цифровую экосистему
Настоящая взаимосвязанная дизайн-система поддерживает связь
между приложением финансового дашборда и самой дизайн-системой, чтобы они всегда оставались в целости и были синхронизированы. Истинная сила этого подхода заключается в том, что не
только один сайт может быть связан с дизайн-системой, но и все
цифровые продукты организации могут поддерживать связь между собой, дизайн-системой и всеми остальными продуктами в этой
экосистеме. Когда вы устанавливаете дизайн-систему в качестве
зависимости на любом веб-сайте и в любом приложении, то каждый
экземпляр подключается к системе и, следовательно, они становятся связанными друг с другом.
Одним из первых подводных камней, с которым сталкиваются
команды, работающие над дизайн-системой в организациях, является ошибочное мнение, что у них есть полноценная дизайнсистема как продукт, тогда как на самом деле у них есть лишь ее
инструменты, такие как UI-киты или библиотеки компонентов.
Люди не видят разницы; хуже того, они недоумевают, почему так
сложно масштабировать ту эффективность и консистентность,
которую обеспечивает истинная дизайн-система как продукт и как
практика.
Теперь, когда вы знаете, в чем разница, расскажите об этом и другим!

72

Вопросы для размышления
Задайте следующие вопросы своим командам дизайнеров,
разработчиков и продакт-менеджеров, чтобы выявить пробелы в дизайн-системе:
•

Есть ли в вашей организации UI-кит, библиотека компонентов, настоящая дизайн-система или что-нибудь подобное?

•

Если что-то из этого у вас есть, откуда оно взялось? (Понимание того, как что-то появилось, может помочь догадаться,
как заставить это развиваться.)

•

Какие связи или интеграции вы поддерживаете между
своими цифровыми продуктами и вашей дизайн-системой?

•

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

ГЛАВА 4

Как непросто получить
одобрение
дизайн-системы
«Создай систему, используй систему» — это фантазия

76

Получение поддержки для дизайн-системы — это как
«продажа воздуха»

77

Создание дизайн-системы на основе абстракций —
сложный процесс

78

Пытаетесь убедить других принять новый инструмент?
Удачи!

78

Продуктовые команды не вносят вклад в дизайн-систему

79

Вопросы для размышления

80

Существует распространенное представление о «правильном» способе запуска дизайн-системы, который почти всегда заканчивается неудачей. Это выглядит примерно так:
1. Презентуйте проект. Предложите инициативу по созданию
дизайн-системы руководству компании, чтобы заручиться их
поддержкой как в виде одобрения концепции, так и в виде реального финансирования для создания команды.
2. Создайте базовые элементы. Небольшая команда создает базовые компоненты — «дизайн-систему», — которые все остальные
продуктовые команды, как предполагается, будут внедрять и использовать.
3. Используйте систему. Продуктовые команды начинают применять компоненты дизайн-системы в своей работе над продуктами.
4. Вносите вклад. Все, чего еще нет в дизайн-системе, создается
командой разработки, а затем вносится в дизайн-систему, чтобы
другие команды могли этим воспользоваться.
Этот процесс почти никогда не работает, и все ломают голову почему. Да потому, что этот план выдает желаемое за действительное
и совсем не реалистичен.

«Создай систему, используй систему» —
это фантазия
Идея, лежащая в основе представления большинства людей о дизайн-системах, такова: сначала мы создаем систему, а затем используем ее. Так просто! Мои дети иногда говорят примерно так:
«Папа, ты выставляешь ненужные старые вещи на лужайку для
дворовой распродажи, а потом зарабатываешь на них кучу денег».
Все, что нам нужно сделать, — это создать действительно хорошую
дизайн-систему, и люди будут ее с радостью использовать. Ну конечно! Это напоминает наивную стратегию «Если идти к мечте, она
обязательно сбудется».
Подводные камни кроются в деталях, и они есть на каждом шагу.
Эти шаги могут не сработать, потому что каждый из них сложен
и каждый имеет высокую вероятность неудачи.

76

Получение поддержки для дизайн-системы —
это как «продажа воздуха»
Предложить руководству инициативу по созданию дизайн-системы
очень сложно, потому что система, которую вы презентуете, еще не
существует в природе — это «воздух» («vaporware»). На момент написания этой книги в Google было найдено три миллиарда результатов поиска по запросу «как получить поддержку дизайн-системы».
Результаты поиска схожи: подготовьте краткую презентацию,
определите проблему, сформулируйте предположения о ценности
дизайн-систем для бизнеса и их типичной окупаемости, представьте план перехода от нуля к полноценной работе и регулярно докладывайте стейкхолдерам о ходе процесса. Благодаря этим мудрым
советам вы непременно получите полную поддержку руководства
и финансирование для воплощения мечты о дизайн-системе в реальность.
Это привлекательная концепция, которая редко работает в реальности.
Возможно, сегодняшний мир стартапов-единорогов1, финансируемых венчурным капиталом, ввел многих в заблуждение, заставив
думать, что если только наше предложение будет достаточно сильным, люди будут вкладывать средства не глядя. Но точно так же,
как венчурный инвестор с большей вероятностью вложит деньги,
когда стартап наберет обороты, то есть критическая масса людей
уже будет использовать продукт, так и руководство организации
с гораздо большей вероятностью благословит инициативу по созданию дизайн-системы, когда люди будут стабильно ею пользоваться.
А до тех пор вам остается только надеяться на то, что команда
руководителей любит рисковать, что в наши дни большая редкость.

1

Стартап-единорог — компания-стартап с рыночной стоимостью более
1 миллиарда долларов. Термин применяется с начала 2010-х годов. Впервые его использовала основательница венчурного фонда Cowboy Ventures
Эйлин Ли в 2013 году, желая сравнением с мифическим животным подчеркнуть уникальность и редкость таких компаний. — Примеч. ред.

77

Создание дизайн-системы на основе
абстракций — сложный процесс
Создавать основные компоненты дизайн-системы непросто, поскольку этот процесс строится на абстракциях. Даже, казалось бы, простая
задача по созданию цветовой палитры сталкивается со множеством
сложных вопросов, которые приходится решать на абстрактном
уровне. В результате большинство цветовых палитр дизайн-систем
включают все возможные оттенки радуги и множество оттенков
серого, но при этом не содержат инструкций по их применению.
В результате вы получаете систему, которая скорее чисто теоретическая, чем применимая на практике. Это то же самое, как сказать
ребенку, что он должен выучить все тонкости теории музыки, прежде чем сможет сыграть знакомую мелодию. Знание теории музыки, конечно, пригодится, но оно сильно отдаляет радость от возможности сыграть песенку и произвести впечатление на друзей.
Когда работа над дизайн-системой ведется в вакууме и у коман­ды
разработки нет конкретных вариантов использования системы, их
стратегия выглядит примерно так: «Давайте предоставим все элементы, которые могут понадобиться продуктовой команде в любой
момент», что приводит к раздутым дизайн-системам. Пытаясь создать дизайн-систему, которая подойдет всем и каждому, они фактически создают систему, которая не подходит никому.

Пытаетесь убедить других принять новый
инструмент? Удачи!
«Но Дэн! — возразите вы. — Ты такой пессимист! Конечно же, можно создать что-то, что будет полезно продуктовым командам». Это
правда: существуют команды, которым удается преодолеть начальный этап и создать потенциально полезные компоненты с разумным
балансом между гибкостью и конкретикой.
И тогда приходит время попытаться уговорить другие команды использовать эту новую систему. Здесь обычно возникает следующая
большая трудность: убедить кого-то принять новый инструмент (или
вообще что-то новое) очень сложно! Вы просите продуктовые коман­
ды отказаться от их привычных инструментов и использовать вместо них ваши.

78

Откуда им знать, что вашим инструментам можно доверять? Будут
ли эти инструменты работать? Будет ли понятно, как их использовать? Насколько сложно будет этому научиться?
Типичное допущение, которое делают команды разработки дизайнсистем, заключается в том, что созданная ими система базовых
элементов объективно лучше, чем другие инструменты, и что она
обеспечит большую консистентность всех веб-сайтов и приложений
организации, поскольку в нее встроена цветовая палитра бренда
и типографика, а также многое другое.
Проблема не в том, что эта позиция неверна, а в том, что она неактуальна, по крайней мере в данный момент. Это попытка ответить
на вопросы, которых еще никто не задавал. Команда разработки
дизайн-системы пытается решить проблемы консистентности, в то
время как продуктовые команды в основном стремятся уложиться
в свои и без того жесткие сроки. Все, что может их замедлить (например, трата времени и умственных сил на изучение нового инструмента), считается нецелесообразным.
Этот этап особенно неприятен, потому что вам буквально приходится идти против законов природы. С точки зрения поведения
люди склонны следовать принципу наименьших усилий (или закону
Ципфа), который гласит, что при наличии выбора животные, люди
и даже хорошо сконструированные машины выберут путь наименьшего сопротивления, чтобы сохранить как можно больше
энергии. Обычно этот путь заключается в том, чтобы продолжать
делать то, что привычно. С прагматичной точки зрения команды
обычно склонны придерживаться своих принятых по умолчанию
практик, что является серьезным препятствием при попытке уговорить их принять вашу новую дизайн-систему.

Продуктовые команды не вносят вклад
в дизайн-систему
Одна из самых частых жалоб, которую я слышу от команд разработки дизайн-систем, заключается в том, что их продуктовые коман­
ды и кросс-функциональные команды не вносят свой вклад в дизайн-систему. ­Конечно не вносят! Достаточно сложно заставить их
принять риск использования новой системы в текущем рабочем
процессе.

79

Есть две основные причины, по которым продуктовые команды не
хотят принимать участия в развитии дизайн-систем своей организации:
zz Слишком много нового. Согласно статье, опубликованной ис-

следователем из Дьюкского университета (Duke University)
в 2006 году1, более 40% ежедневных действий человека определяются привычками. Внедрение слишком большого количества
новых инструментов и процедур в стандартный процесс разработки продуктов просто не приживется.

zz Это не их работа. Задача продуктовой команды — создавать

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

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

Вопросы для размышления

1

•

Поддерживают ли в организации вашу дизайн-систему?
Если да, то как вы этого добились? Если нет, то как вы
можете изменить ситуацию?

•

Если стандартный подход к получению поддержки дизайнсистемы не работает, что можно сделать лучше? Запишите
свой ответ сейчас и позже сравните его с более эффективным подходом, о котором вы узнаете через несколько глав.

David T. Neal, Wendy Wood, and Jeffrey Quinn, «Habits—A Repeat Per­for­
mance», Neuron, (2006), http://web.archive.org/web/20110526144503/http://
dornsife.usc.edu/wendywood/research/documents/Neal.Wood.Quinn.2006.pdf.

80

ГЛАВА 5

Пилотные проекты —
лучший способ
запустить
и поддерживать
дизайн-систему
Связь дизайн-системы с работой над продуктом

82

Пилотная оценочная карта дизайн-системы

84

Типы пилотных проектов дизайн-систем

86

Несколько параллельных пилотных проектов

88

Совершенствование дизайн-системы по мере
ее использования

91

Процесс выпуска пилотных версий

93

Извлечение и абстрагирование

129

Вопросы для размышления

133

Гораздо эффективнее выпускать пилотные версии дизайн-системы
в процессе работы над продуктом, чем надеяться на то, что сработает стратегия «создай систему, используй систему».
Для сравнения рассмотрим, как телевизионный сериал продается
телеканалу. Создатели сериала не просто просят бюджет на его создание. Сначала они что-то делают. Они снимают одну пилотную
серию для того, чтобы оценить, насколько успешными могут быть
другие серии и сезоны. В пилотной серии создаются прототипы персонажей, взаимодействий, диалогов, сцен и многого другого, чтобы
оправдать последующие серии и сезоны. Пилотная серия хитовой
драмы «Lost» («Остаться в живых») канала ABC погрузила зрителей
в действие сразу после крушения самолета на таинственном острове.
Зрители получили представление о многих персонажах и некоторые
намеки на то, что все на острове может быть не таким, как кажется.
Зрители попались на крючок! Им захотелось посмотреть больше серий!
Смысл дизайн-системы — в том, чтобы улучшить процесс и результат создания цифровых продуктов. Но прежде чем тратить значительное время и деньги на создание полноценной дизайн-системы
и соответствующей практики ее применения, стоит протестировать,
какая дизайн-система вам понадобится. Это даст уверенность, что
получится создавать больше подобных продуктов в будущем. Лучшим способом опробовать дизайн-систему является создание продукта с использованием этой дизайн-системы, даже если такой
системы еще не существует.

Связь дизайн-системы с работой
над продуктом
Один из лучших способов продвинуть дизайн-систему — привязать
ее разработку к текущей работе над цифровым продуктом. Почему?
Все дело в науке! Первый закон движения Исаака Ньютона — закон
инерции — гласит, что тело, находящееся в состоянии покоя, стремится оставаться в состоянии покоя. В переводе на язык дизайнсистем это означает, что организация, не имеющая дизайн-системы,
скорее всего, будет продолжать таковой и оставаться.
К счастью, у науки имеется решение! Закон инерции утверждает
и обратное: тело, находящееся в движении, стремится оставаться
в движении. Если вы хотите, чтобы инициатива по разработке дизайн-системы начала движение, «прикрепите» ее к чему-то, что уже

82

движется. А что уже движется в организациях, производящих
цифровые продукты? Процесс создания этих цифровых продуктов!
Новые продукты и функции всегда присутствуют на дорожных
картах. Команды уже выделены, имеют финансирование и поддержку руководства. Используйте их импульс как свой собственный!
В организациях, ориентированных на цифровые технологии, есть
несколько точек перегиба, которые являются идеальными стартовыми площадками для работы над дизайн-системой:
zz ребрендинг;
zz смена платформы;
zz реорганизация;
zz миграция;
zz слияние с другой компанией или ее поглощение.

Что общего у этих событий? То, что организация уже взяла на себя
обязательство провести большие изменения в масштабах всей компании. Прицепите свой квест по созданию дизайн-системы к этим
вагонам, ведь они уже в движении. Для выполнения этой задачи
вызовите добровольцев из своей команды. Это тот вид работы, где
часто можно услышать мнение: «Раз уж мы все равно этим занимаемся, можно попытаться сделать это максимально эффективно»,
что является прекрасным поводом для того, чтобы начать закладывать основу для практики дизайн-системы.
Совсем не обязательно произносить слова «дизайн-система». Если
честно, я бы даже рекомендовал не говорить их руководству, потому
что ему это часто кажется отвлекающим фактором. Вместо того
чтобы говорить об инструменте, который вы создаете, то есть о дизайн-системе, стоит больше рассказать о результате этой работы.
«Выполнение работ таким образом позволит нам опередить график
на шесть недель».
«Видите, насколько меньше ошибок мы получили, повторно используя код, который уже прошел QA (контроль качества)?»
«За последние несколько недель наша скорость возросла».
Вы и ваша команда будете знать, что дизайн-система была тем
средством, которое помогло этого достичь, но никто другой пока
пусть лучше об этом не знает.

83

Пилотная оценочная карта дизайн-системы
Выпуск пилотных версий дизайн-системы в правильном порядке
одновременно улучшает ваш продукт и развивает дизайн-систему.
В связи с этим возникает вопрос: как выбрать «правильную» последовательность? Хорошо продуманная оценочная карта, или
оценочный лист (scorecard), поможет определить, какие продукты
и в каком порядке лучше всего использовать в дизайн-системе.
Рассмотрите дорожную карту вашей организации для новых продуктов, которые планируется создать, а также дорожную карту
существующих продуктов, которые нужно доработать или переосмыслить. Можно оценить каждый продукт по следующим восьми
критериям по шкале от 0 (маловероятно) до 10 (очень вероятно),
чтобы определить, какие продукты лучше всего подойдут для пилотных проектов дизайн-системы:
zz Потенциал общих компонентов. Много ли в этом продукте

компонентов, которые можно повторно использовать в других
продуктах?

zz Потенциал общих паттернов1. Много ли в этом продукте паттер-

нов, которые можно повторно использовать в других продуктах?

zz Элементы с высокой ценностью. Имеется ли компонент или

паттерн с высокой бизнес-ценностью, являющийся ядром этого
проекта?

zz Техническая осуществимость. Насколько проста техническая

реализация дизайн-системы? Требуется ли масштабный рефакторинг?

zz Наличие лидера. Будет ли кто-то из команды поддерживать

проект до завершения, продвигать использование дизайн-системы и вносить в нее свой вклад?

zz Объем. Можно ли выполнить эту работу в рамках пилотного

проекта, например 3–4 недели (подставьте свои сроки)?

zz Техническая независимость. Достаточно ли эта работа изо-

лирована от наследуемого кода и дизайна, чтобы иметь четкие
начальные и конечные точки?

1

В данном случае я провожу различие между компонентами и паттернами. Компоненты — статические элементы, например кнопки или карточки. Паттерны — способы взаимодействия, например вход в систему или
оформление заказа.

84

zz Маркетинговый потенциал. Может ли эта работа вдохновить

других использовать дизайн-систему?

После того как вы оценили каждый новый продукт в вашей дорожной карте (табл. 5.1), выведите средние баллы и расположите их
в порядке от самого высокого к самому низкому. Именно такая
последовательность будет наилучшим образом способствовать развитию вашей дизайн-системы. В первую очередь работайте над
тем, что имеет самую высокую оценку, а в последнюю очередь — что
имеет самую низкую. Если вы правильно все подсчитали и сначала
выполнили пилотный проект с наивысшей оценкой, то второй пилотный проект получит пользу от работы, проделанной над первым.
Третий — от второго, и так далее. Пилотные проекты со временем
будет проще создавать, потому что вы сможете извлекать компоненты и паттерны из каждой пилотной версии, постоянно расширяя
дизайн-систему.
Таблица 5.1. Пример оценочного листа пилотной версии дизайн-системы
Веб-сайт
Flagship.com

Нативное
приложение
для iOS

Интранет для
сотрудников

Потенциал общих
компонентов

7

2

10

Потенциал общих
паттернов

7

2

10

Элементы с высокой ценностью

4

3

3

Техническая
осуществимость

2

10

5

Наличие лидера

8

6

9

Объем

1

10

1

Техническая
независимость

4

3

8

Маркетинговый
потенциал

10

10

4

Итого

43

46

50

5,38

5,75

6,25

Среднее значение

85

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

Типы пилотных проектов дизайн-систем
Так же как существуют разные виды пилотных эпизодов для сериалов — «концептуальные» пилоты (создают основу для развития
сюжета первого сезона) и вспомогательные (без привязки к основной сюжетной линии, больше сосредоточенные на жизни и характерах персонажей), — пилотные проекты дизайн-систем также
могут различаться по типу, масштабу и охвату. Главный вопрос:
«Что нужно уметь делать с помощью нашей дизайн-системы?» Чтобы ответить на него, каждый цифровой продукт, используемый
в пилотном проекте дизайн-системы, должен пытаться протестировать что-то конкретное. Создание продукта для проверки выразительности дизайн-системы очень отличается от проверки того,
как быстро можно создать продукт.
Вот несколько различных типов пилотных проектов, которые можно запустить в зависимости от того, какие результаты нужно проверить.
zz Индиана Джонс. В сцене из фильма «Индиана Джонс: В поисках

утраченного ковчега» предприимчивый профессор археологии Индиана Джонс пытается обменять золотого идола на мешок с песком
примерно такого же веса в надежде, что никто не заметит подмены.
Одним из первых видов пилотных проектов, который стоит реализовать, является рефакторинг кодовой базы, заменяющий кастомные компоненты на те, которые находятся в центральном репозитории дизайн-системы. Это способ создать связанную систему там,
где ее раньше не было. При создании пилотной версии такого вида
важно не поддаваться искушению что-нибудь «улучшить». Не вносите изменения в дизайн или пользовательский опыт. Главная идея

86

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

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

zz Скоростной забег. Цель этого вида пилотного проекта заклю-

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

zz Суррогат. Лучший вариант — когда в пилотном проекте работа

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

zz Периметр. Было бы круто рассказать о том, что на основе дизайн-

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

87

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

ПРИМЕЧАНИЕ

ПОТРЕБНОСТИ И ЖЕЛАНИЯ

Конечно, это семантическая разница, но важно, чтобы пилотную версию определял вопрос «Что нам нужно уметь создавать с помощью
нашей дизайн-системы?», а не «Что мы хотим уметь создавать с помощью нашей дизайн-системы?». Если бы вопрос звучал как второй
вариант, было бы слишком легко ответить: «Всё и сразу!» Это благое
намерение часто приводит к тому, что команды создают кладбища
дизайн-систем, и эти системы состоят из слишком большого количества компонентов, которые никому не нужны, и недостаточного количества компонентов, которые действительно необходимы.
Простой, но полезный совет: создавайте дизайн-систему, которая
нужна вашей организации, даже если это не та дизайн-система, которую хотят все. Как узнать, что нужно людям в вашей организации?
Спросите их!

Несколько параллельных пилотных проектов
Вполне обоснованным кажется, что работа над одним пилотным
проектом за раз является разумным способом развития дизайн-системы. Гоните эту мысль. Первый пилотный проект, скорее всего,
пройдет довольно хорошо. Затем (если только вам крупно не повезет)
вдруг станет понятно, что очень немногие из компонентов, созданных
в первом пилотном проекте, смогут хорошо работать и во втором,
потому что не был учтен другой сценарий использования.
Если в конечном счете нужно, чтобы дизайн-система одновременно поддерживала интерфейсы для веба и нативных мобильных
приложений и режимы lean-back (для фонового использования, как
в Smart TV), то придется одновременно заниматься выпуском ее
пилотных версий для всех этих платформ. Возможно, это будет непросто скоординировать, но такой подход отразит реальное положение дел. Если не получается поддерживать такое в пилотной
среде, то станет ясно, что в реальной жизни дизайн-система не
сможет поддерживать работу нескольких команд на всех этих платформах. Пилотные версии должны давать команде представление
о том, что ее ждет впереди, и уверенность, что получится сделать
то, что необходимо.

88

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

Продуктовая команда 1.
Продуктовая команда 2.
Продуктовая команда 3.
Команда разработки дизайн-системы.

ПРОДУКТОВАЯ
КОМАНДА 1

ПРОДУКТОВАЯ
КОМАНДА 2
КОМАНДА
РАЗРАБОТКИ
ДИЗАЙН-СИСТЕМЫ

ПРОДУКТОВАЯ
КОМАНДА 3

Рис. 5.1. Красота и сложность экосистемы дизайн-системы заключается
в управлении как минимум четырьмя параллельными рабочими потоками

89

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

ТРИ РАЗА — ЭТО ЗАКОНОМЕРНОСТЬ
Ян Флеминг (Ian Fleming) — автор серии шпионских романов о Джеймсе Бонде. В книге «Голдфингер» один из персонажей говорит ­Джеймсу
Бонду: «Один раз — это случайность. Дважды — совпадение. Третий
раз — действие врага». Другими словами, только после третьего раза
у вас появляется достаточная уверенность в том, что все происходит
целенаправленно.
Итак, когда вы вносите компонент в дизайн-систему? Когда он нужен
или используется тремя или более командами.
Дизайн-системы существуют для решения общих проблем. Менее
трех случаев — это недостаточно распространенная ситуация, чтобы
заслужить внимание команды, занимающейся дизайн-системой. Дизайн-системы — это инструмент для масштабирования. Тратить время
на единичные случаи (или даже двойные) — это не работа в масштабе,
но когда вы работаете с тремя или более случаями, вы начинаете
двигаться в нужном направлении.
Если такой подход достаточно хорош для агента 007, то, вероятно,
он достаточно хорош и для вас.

90

Совершенствование дизайн-системы по мере
ее использования
В фильме «Гарри Поттер и принц-полукровка» есть сцена, где юный
волшебник Гарри и его друг Рон приходят с опозданием на первый
урок по предмету «Продвинутое зельеварение». Гарри говорит профессору Слизнорту, что у них еще нет учебников, и Слизнорт отправляет учеников в кладовую, чтобы они взяли себе книги.
Осталось два учебника: совершенно новый и старый, потрепанный,
использованный (рис. 5.2). Рон и Гарри ссорятся из-за них, и Гарри
достается старый.

Рис. 5.2. Вопрос с подвохом: «Что бы вы выбрали: совершенно новый
учебник или старый подержанный?»

Первое задание, которое дается классу, — сварить приемлемый
вариант «Живой смерти», и тот, кто справится с заданием, получит
в качестве приза пузырек «Жидкой удачи». Слизнорт говорит, что
рецепт «Живой смерти» находится на десятой странице учебника,
но предупреждает, что лишь однажды ученику удалось сварить
зелье достаточно высокого качества, чтобы претендовать на приз.
(Это предзнаменование!)
Все ученики мучаются над заданием, но Гарри обнаруживает, что
его старый учебник, помеченный как собственность принца-полукровки, полон заметок, написанных на полях, которые показывают,
как успешно сварить это зелье (рис. 5.3). В заметках содержатся
различные советы, например «раздавить лезвием» вместо «разрезать»,
как сказано в инструкции, или использовать тринадцать бобов
вместо двенадцати.

91

Рис. 5.3. Заметки того, кто уже сделал то, что вы сейчас
пытаетесь сделать, бесценны

Благодаря учебнику с заметками Гарри единственному удается
успешно приготовить зелье и выиграть приз. Когда с целью добиться успеха используются советы того, кто уже делал это задание
раньше, это немного похоже на обман.
Многие команды подходят к созданию дизайн-системы как к написанию учебника. Они записывают идеальный (в теории) способ
создания продукта. Они пытаются угадать, какой компонент дорожной карты мог бы быть идеальным для всех.
Но это всего лишь спецификации. Они еще не были проверены. Вот
почему выпуск пилотных версий так полезен. Дизайн-система — это
не написание спецификации заранее. Дизайн-система — это успешное выполнение задачи и ее документирование по ходу дела.
Фронтенд-дизайнер Брэд Фрост говорит, что дизайн-система — это
«официальная история того, как организация проектирует и создает
цифровые интерфейсы»1. Другими словами, это собрание рассказов
о том, как команды в этой организации создали цифровые продукты,
и в этих рассказах можно заметить определенные закономерности.
1

Brad Frost, «Design Systems Are for User Interfaces», 15 ноября 2021 года,

https://bradfrost.com/blog/post/design-systems-are-for-user-interfaces/.

92

Сделайте шпаргалку для тех, кто создает цифровые продукты, только после того, как это сделали вы. Раздавите лезвием, не режьте.
Используйте тринадцать бобов, а не двенадцать. Здесь встроенные
уведомления, а не всплывающие окна. Этот оттенок бирюзового
потому, что он имеет более высокий контраст с фоном. Не потому,
что это может сработать в будущем, а потому, что это сработало
в прошлом.
Перестаньте пытаться построить дизайн-систему, создавая абстрактные компоненты. Вместо этого дайте своей команде реальный кейс.
Выберите зелье для варки, например «Живая смерть». Выберите
основной дашборд продукта. Создайте новый интранет. Поставьте
себя на место людей, которые попытаются использовать дизайнсистему, и попробуйте сделать что-то похожее на то, что они могли
бы делать. Если в будущем дизайн-системе понадобится оптимизировать процесс создания интранета, начните сначала создавать
интранет, чтобы отработать все трудности.
Попробуйте следовать учебнику и делать пометки о том, что в нем
неправильно.
Это дизайн-система. Не учебник. Дизайн-система — это заметки на
полях. Это то, где есть обратная связь: сюжеты, решения. Преимущество этого в контексте создания цифровых продуктов заключается в том, что вам не придется довольствоваться заметками на
полях. Вы можете обновить сам учебник. Каждый продукт, используемый для пилотного проекта дизайн-системы, делает учебник все
более и более точным, так что всем становится проще делать все
правильно.

Процесс выпуска пилотных версий
Процесс выпуска пилотных версий дизайн-системы является циклическим. Циклы и петли обратной связи — важные составляющие
любой системы. Эти циклы являются основными механизмами
самокоррекции системы.
В практике дизайн-систем связь между ростом системы и созданием продукта порождает эффективный цикл, положительную обратную связь, которая приводит к развитию (рис. 5.4). Но как организация запускает этот цикл? Классическая проблема курицы
и яйца. Лучше начать с этого места или с другого?

93

ДИЗАЙНСИСТЕМА

ПРОДУКТ

Рис. 5.4. Эффективный цикл для цифровых организаций
основан на создании положительной обратной связи
между дизайн-системой и продуктом

Ответ: начните с продукта. Продукт идет впереди системы. Я предпочитаю немного измененную схему, которую я называю «Цикл
мерной ложки для дизайн-систем» (рис. 5.5). (Потому что она имеет
форму мерной ложки, видите? Я знаю: над ней нужно еще поработать.) Короче говоря, это самый успешный процесс создания дизайн-системы, который я когда-либо видел. Итак:
1. Создайте функцию или продукт.
2. Извлеките и абстрагируйте компоненты из этой функции или
продукта, чтобы запустить систему.
3. Создайте другой продукт, используя компоненты, которые вы
ранее извлекли.
4. Вернитесь к шагу 2.
Повторите этот процесс. И делайте так постоянно. Все то время,
пока существует ваша компания.
Цикл «Мерная ложка» хорош тем, что он одинаково применим как
к новой команде, создающей свой первый продукт и систему, так
и к организации, которая уже много лет имеет дизайн-систему
и хочет ее усовершенствовать. Никогда не поздно запустить (или
перезапустить) этот маховик.

94

СОЗДАЙТЕ
ПРОДУКТ

ИЗВЛЕКИТЕ
И АБСТРАГИРУЙТЕ
КОМПОНЕНТЫ ИЗ
ЭТОГО ПРОДУКТА
В БИБЛИОТЕКУ

СОЗДАЙТЕ ДРУГОЙ
ПРОДУКТ, ИСПОЛЬЗУЯ
ИЗВЛЕЧЕННЫЕ РАНЕЕ
КОМПОНЕНТЫ

Рис. 5.5. Запуск эффективного цикла дизайн-системы как практики
должен начинаться с продукта

Выпуск пилотной версии дизайн-системы с нуля
Некоторым организациям приходится разрабатывать дизайн-систему «с чистого листа». Это может быть стартап, создающий свой
первый набор цифровых продуктов. А может быть зрелая организация, у которой так много интерфейсов или технического долга по
дизайну/коду, что начинать с нуля кажется более целесообразным,
чем распутывать то, что уже существует, и строить дизайн-систему
на основе этого. В любом случае вот несколько примеров того, как
можно использовать процесс выпуска пилотных версий для поиска
отправных точек своей дизайн-системы.

Пилотная версия Unity, дизайн-системы ExxonMobil
Когда в 2016 году я работал с ExxonMobil над созданием их дизайнсистемы Unity, у нас было 500 разработчиков и всего один дизайнер
(привет, Крис!). С самого начала необходимо было понять, как масштабировать дизайн внутри организации таким образом, чтобы
добиться консистентности бренда, не поручая эту задачу какомулибо одному человеку или команде. Разработчики были в основном
предоставлены сами себе в создании продуктов. Некоторые из них
обладали навыками дизайна; другие пытались использовать библио­
теки вроде Bootstrap или Material Design, где дизайн уже был заложен по умолчанию. Это означало, что все цифровые продукты,
созданные в ExxonMobil, сильно различались (рис. 5.6).
Работа команды началась с выбора нескольких приложений, которые будут использоваться в качестве пилотных версий для дизайнсистемы, и общения с дизайнерами и разработчиками, создающими эти приложения, а также с частью их пользователей. Мы начали

95

проектировать и создавать функции и возможности, которые
нужны пользователям приложений. Мы не делали ничего слишком
«дизайнерского», например не определяли глобальную цветовую
палитру, принципы написания текстов или что-то в этом роде.
Вместо этого мы начали позволять такой работе быть непредвиденной. Мы начали со Старого Доброго Процесса Проектирования
Продукта (Good Ol’ Product Design Prosess)™.

Рис. 5.6. До появления единой дизайн-системы приложения ExxonMobil
выглядели по-разному

Одним из наших пилотных проектов был продукт Agenda Creator
(рис. 5.7), необходимый организациям, которым нужно структурировать многочисленные встречи. Мы провели исследование стейкхолдеров и клиентов, как и в любом успешном процессе проектирования продукта. Узнали, какие функции нужны, а какие нет.
Придумали новый дизайн, который был немного проще и современнее предыдущего, с более четкой ориентацией на основные потребности клиентов (рис. 5.8).
Закончив проектирование и создание этого продукта, мы проанализировали его, чтобы понять, какие части можно абстрагировать
и извлечь для использования другими командами ExxonMobil.
­Хороший пример — шапка на рисунке 5.9. Если извлечь шапку из
продукта Agenda Creator, следующая команда, которая будет ее
использовать, получит преимущества всех хороших идей и проделанной тяжелой работы, вложенных в ее создание. Шапка адап-

96

тивна. В ней есть все нужные шрифты и атрибуты бренда. Она
была протестирована на доступность и производительность. Ее
поведение прошло проверку QA-команды. Шапка взята прямо из
продукта и готова к использованию другими.

Рис. 5.7. Продукт Agenda Creator компании ExxonMobil до внедрения
дизайн-системы

Рис. 5.8. Новый продукт Agenda Creator компании ExxonMobil

97

Рис. 5.9. Шапка Agenda Creator — идеальный кандидат для дизайн-системы,
потому что другие команды могут сразу же использовать ее

Эта шапка, конечно, не является идеальной, и ее не получится использовать вечно. В ней даже нет навигации! Но в этом и не было
необходимости. Той команде нужна была шапка без навигации, что
мы выяснили в ходе исследования при проектировании продукта,
поэтому велика вероятность того, что подобная шапка может понадобиться и другой команде.
Заметьте, что мы не начали с абстракции, не сказали: «Давайте
сделаем шапку, которую смогут использовать все». Если бы мы
пошли таким путем, то, вероятно, переделывали бы ее бесконечно.

98

Мы бы, наверное, попытались спланировать любой тип шапки,
который мог бы существовать, с выпадающими меню, полями поиска, глобальной навигацией, утилитарной навигацией и другими
вещами, которыми, возможно, даже не будут пользоваться, вместо
того чтобы работать, исходя из конкретного варианта использования. Но, к счастью, мы решили поступить наоборот: вначале создать
продукт и затем извлечь его шапку в дизайн-систему для всех, кому
она может пригодиться. Пилотные проекты дают компонентам
контекст, которого у вас не было бы в противном случае.
Agenda Creator был первым пилотным проектом. Вторым пилотным
проектом стал Identity & Access Management Portal (рис. 5.10).

Рис. 5.10. Продукт Identity & Access Management Portal компании ExxonMobil
до внедрения дизайн-системы

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

99

Рис. 5.11. Новый продукт Identity & Access Manager компании ExxonMobil

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

100

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

Рис. 5.12. Различные варианты шапки в Unity

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

101

стеме, можно добавить его на справочный сайт. На рис. 5.13 показана страница шапок и подвалов (Headers and footers), которые
мы получили в результате извлечения их из реальных продуктов для
Unity, дизайн-системы компании ExxonMobil.

Рис. 5.13. На этом этапе процесса выпуска пилотных версий все варианты
компонента добавляются на страницу справочного сайта

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

102

Рис. 5.14. На странице подробной информации о компоненте показана
вся информация, необходимая для того, чтобы понять, как его использовать

Пилотная версия веб-сайта Университета Сетон-Хилл
(Seton Hill University)
В 2015 году я помог создать дизайн-систему для католического
гуманитарного университета под названием Университет СетонХилл (Seton Hill University), расположенного недалеко от Питтс­бурга,
штат Пенсильвания. Как и в случае с примером ExxonMobil, создание этой дизайн-системы началось с обычного Старого Доброго
Процесса Проектирования Продукта™.
В шаблоне «Areas of Study» («Направления обучения») (рис. 5.15)
в середине страницы был компонент с меткой «From Degreed to
Careers» («От дипломов к карьере»). Идея заключалась в том, чтобы
показать, какую работу обычно получают студенты с таким дипломом после окончания учебы. Мы спроектировали его, создали и на-

103

звали компонент, соответственно, «From Degreed to Careers». Мы думали, что это будет одноразовый компонент (иногда его называют
«снежинкой»), так как не предполагали, что его можно будет использовать многократно.
Мы сделали еще несколько страниц, например «Campus Life» («Студенческая жизнь») (рис. 5.16). Наше исследование предполагало,

Рис. 5.15. Компонент «From
Degreed to Careers» — это
уникальная область страницы

104

Рис. 5.16. Компонент «Upcoming
Events» выглядит странно похожим на
компонент «From Degreed to Careers»

что календарь событий в кампусе может быть очень полезен для
студентов, поэтому наша команда обсудила, как добавить его на
страницу «Campus Life» наилучшим возможным способом. Мы поняли, что можно использовать формат, схожий с компонентом
«From Degreed to Careers», и придумали его вариант для этой страницы.
С точки зрения реализации и кода было немного нелогично использовать компонент «From Degreed to Careers» для предстоящих событий. Поэтому у нас было несколько вариантов:
1. Мы могли бы продублировать компонент «From Degreed to Careers»
и создать аналогичный компонент «Upcoming Events» («Предстоящие события»), но было странно иметь два отдельных компонента, которые по сути были одним и тем же.
2. Мы могли бы абстрагировать компонент «From Degreed to Careers»,
чтобы он обслуживал оба варианта использования.
Мы выбрали второй вариант (как, вероятно, поступили бы и вы).
Мы абстрагировали его в компонент под названием «Vertical Tabs»
(«Вертикальные вкладки») (рис. 5.17). Таким образом, получился
гибкий пользовательский интерфейс, который мог принимать множество различных видов контента и иметь несколько вариантов
оформления.

Рис. 5.17. Абстрагированный компонент «Vertical Tabs»
может работать как для контента «From Degreed to Careers»,
так и для контента «Upcoming Events»

105

Всякий раз, когда я делюсь подобными примерами, я обычно получаю два варианта реакции.
Первая: «Разве это не задом наперед? Разве вы не могли начать
с создания компонента «Vertical Tabs», а затем использовать его на
каждой из этих страниц?» Ответ: «Да, я мог бы это сделать, но я не
знал, что мне это нужно, пока не начал проектировать эти страницы». Значительно проще наполнить дизайн-систему компонентами, которые действительно нужны и будут использоваться,
когда у вас есть реальный контент и реальные варианты использования. Во многих организациях есть кладбище дизайн-систем,
полное компонентов, которые сейчас никому не нужны, но при
этом там отсутствуют компоненты, которые действительно нужны
всем прямо сейчас.
Вторая реакция, которую я получаю, часто выглядит как критика:
«Вы взяли что-то классное и сделали это скучным». Да! Спасибо, что
заметили! В этом и заключается суть дизайн-систем. Как говорит
лидер UX-дизайна Джош Кларк (Josh Clark) в своей статье «The Most
Exciting Design Systems Are Boring» («Самые захватывающие дизайнсистемы скучны»): «Дизайн-системы — это контейнеры для институциональных знаний1. Определите проблемы проектирования,
с которыми команды сталкиваются снова и снова. Чем чаще проблема встречается, тем лучше. Дизайн-системы должны отдавать
приоритет рутинным задачам»2. Если вы посмотрите на то, из чего
состоит дизайн-система, созданная в процессе выпуска пилотных
версий, то поймете, что всё это скучные вещи, те элементы, которые
вы не захотите создавать снова и снова: абзацы, чекбоксы, радиокнопки, кнопки оповещений. Речь идет не о том, чтобы заново
изобретать велосипед; речь идет о массовом производстве велосипедов, чтобы больше людей имели возможность переживать свои
собственные приключения.

1

Институциональные знания (institutional knowledge) — это коллективные
знания, которые хранятся в организации. Они включают в себя понимание процессов, систем, деталей, стандартов, культурных ценностей и общей информации. — Примеч. ред.

2

Josh Clark, «The Most Exciting Design Systems Are Boring», 3 апреля
2017 года, https://bigmedium.com/ideas/boring-design-systems.html.

106

КОМПОНЕНТЫ КОНТЕНТА И КОМПОНЕНТЫ ОТОБРАЖЕНИЯ
Если вы работаете в каком-либо виде цифрового бизнеса, то подход к разработке на основе паттернов невероятно ценен для вашей организации,
так как он помогает вам создавать более легкие, быстрые и ориентированные на будущее продукты. Один из самых важных уроков, которые я усвоил при создании модульных дизайн-систем, заключается в том, что существует разница между компонентами контента и компонентами отображения:
•

Компонент контента описывает типы элементов внутри и может быть
представлен в нескольких формах.

•

Компонент отображения описывает конкретный рендеринг и может
применяться к нескольким типам компонентов контента.

Что это означает? Давайте рассмотрим распространенный пример. При
создании страницы я часто слышу, как кто-то из команды говорит нечто
вроде: «Можно использовать здесь компонент событий». Что это означает
на самом деле? Пожалуй, самым очевидным, с чего следует начать, является ранее спроектированный компонент, который выглядит как на рис. 5.18.

Рис. 5.18. Простой компонент
события с заголовком, датой
и местоположением

Простой способ разметки может выглядеть следующим образом:
<div class="event">
<h1 class="event__title">Star Wars: The Force Awakens Premiere</h1>
<p class="event__date">Dec 20, 2015</p>
<p class="event__location">Ritz East, Philadelphia PA</p>
</div>

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

заголовок;
дата;
местоположение.

107

КОМПОНЕНТЫ КОНТЕНТА И КОМПОНЕНТЫ ОТОБРАЖЕНИЯ (продолжение)
Нет ничего, что связывало бы событие с этим конкретным отображением.
Другие типы контента, которые могут существовать на сайте, могут иметь
похожие модели контента, например, статьи имеют заголовок, дату, описание. Я мог бы легко использовать тот же компонент отображения для
рендеринга статьи (рис. 5.19).

Рис. 5.19. Простой компонент
статьи с заголовком, датой
публикации и описанием

Дизайнер взаимодействия Алла Холматова мудро заметила1: «Если вы
дадите [компоненту] презентационное название, его будущее будет
ограничено его стилем». Если компонент называется компонентом события, это означает, что я даже не буду рассматривать его как вариант
для статьи, хотя он мог бы работать так же хорошо.
Как же сделать более полезный компонент? Абстрагируйте отображение
как от события, так и от статьи в компонент, который может применяться
и к тому и к другому (рис. 5.20).

Рис. 5.20. Более абстрактный
компонент, который может
работать как для событий,
так и для статей

С помощью такого абстрактного компонента отображения вы можете
выбрать несколько видов шаблонов контента (события, статьи и т. д.) для

1

108

Alla Kholmatova, «Design Systems», Smashing Magazine AG, 2017.

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

Рис. 5.21. Описания контента без визуальных предложений позволяют
всем работать с идеальными версиями контента и элементов
пользовательского интерфейса

109

КОМПОНЕНТЫ КОНТЕНТА И КОМПОНЕНТЫ ОТОБРАЖЕНИЯ (продолжение)
Это позволило нам с разработчиком работать одновременно, собирая
все части по-своему и отталкиваясь от работы друг друга. Наблюдая за
этим процессом, я понял еще одну важную вещь: во время работы контент-стратеги в первую очередь думают о компонентах контента, дизайнеры — о компонентах отображения, а фронтенд-разработчики отвечают
за объединение этих двух компонентов. Конечно, это небольшое упрощение, но я убедился, что оно чаще справедливо, чем нет. Это становится очевидным, когда оглядываешься назад, но легко упускается из виду
при полном погружении в работу над проектом.
Посмотрите на электронную таблицу на рис. 5.21. Big Promo («Крупная
промоакция»), More Upcoming («Предстоящие акции») и Local Promo
(«Локальная промоакция») перечислены как отдельные компоненты, поскольку они выполняют разные задачи (см. столбец Features/Functions
(«Особенности/функции»)), но их компоненты контента абсолютно одинаковы. Наш архитектор позаботилась о том, чтобы мы с разработчиком
не забыли об этом контенте, и оставила за мной право решать, какие
компоненты отображения этих данных лучше всего использовать на
экранах разных размеров. Мы с разработчиком могли решать, насколько
абстрагировать их в коде, чтобы сделать максимально переиспользуемыми и понятными.
Я предположил, что мы можем создать эти компоненты контента с помощью нескольких экземпляров всего двух компонентов отображения,
поэтому я начал с их проектирования (рис. 5.22). Затем разработчик
перевел оба компонента отображения в один блок кода:
<div class="g-item">
<div class="block-thumb">
<div class="b-thumb">...</div>
<div class="b-text">
<h2 class="b-title">...</h2>
<div class="date-city">...</div>
<div class="dek">...</div>
</div>
<!-- .b-text -->
</div>
<!-- .block -->
</div>
<!-- .g-item -->

Далее он создал модификатор под названием .g-item-hero, который превращает маленький компонент отображения в большой.

110

Рис. 5.22. Абстрактные варианты компонентов отображения, которые
могут работать для всего, что имеет заголовок, описание, метаданные,
изображение и кикер

В итоге окончательная страница выглядела примерно так, как показано
на рис. 5.23.

111

КОМПОНЕНТЫ КОНТЕНТА И КОМПОНЕНТЫ ОТОБРАЖЕНИЯ (продолжение)

Рис. 5.23. Окончательный вариант

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

112

Таким образом, три раздела, работающие на основе одного компонента
отображения (который мы в итоге назвали «медиаобъект») с двумя различными видами в зависимости от размера были записаны как один блок
кода с одним модификатором.
В качестве общих рекомендаций: не позволяйте компонентам отображения описывать содержимое внутри и не позволяйте компонентам
контента предлагать что-либо, касающееся их представления. При такой
конструкции работа каждого специалиста может выглядеть следующим
образом.
•

Задача контент-стратега: определить компоненты контента.

•

Задача дизайнера: создать компоненты отображения.

•

Задача разработчика: создать разметку для компонента отображения
и хуки для надлежащего переноса контента в компоненты отображения.

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

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

Brad Frost, «Interface Inventory», 10 июля 2013 года, https://bradfrost.com/
blog/post/interface-inventory/.

113

всей организации количество непреднамеренных вариаций. Другими словами, они будто хотят сказать: «Посмотрите на всю эту
избыточность и неэффективность!»
Но при этом часто упускается возможность собрать и хорошие материалы вместе с плохими. На самом деле игнорирование этой
обязанности является одной из самых больших ошибок и заблуждений команд дизайнеров.
Многие видят свою роль в команде разработчиков дизайн-системы
как возможность создавать лучшие практики, которые затем смогут
использовать остальные сотрудники организации. «Я спроектирую
одну кнопку, чтобы управлять всеми», — думает наивный проектировщик дизайн-системы. Но создать что-то новое и убедить всех
остальных использовать это — нетривиальная задача. На самом деле
это одно из главных препятствий на пути к широкому внедрению
дизайн-системы. Вместо этого основной задачей команды дизайнсистемы является сбор лучших практик организации и подготовка
их к масштабированию. Выделите то, что уже было сделано в прошлом и что работает. В своей книге «Do Scale» 1 консультант Лес
Маккеон (Les McKeown) резюмирует: «Масштабируемость строится
на освоении рутины».
Один из способов понять, как ваша команда осваивает рутину, —
прислушаться к своей речи. Проанализируйте формулировки вакансий, доски канбан и повседневные рабочие обсуждения. Если
постоянно мелькают слова «создавать», «генерировать» или «определять», возможно, ваша команда склонна преувеличивать свой авторитет, и вам, скорее всего, предстоит нелегкий путь к тому,
чтобы вашу работу приняли. Но если чаще встречаются «собирать»,
«курировать» и «внедрять», то этот подход сослужит вам хорошую
службу, создаст благодатную почву для коллаборации и упростит
адаптацию системы другими.
Приняв образ мышления коллекционера, начните собирать лучшее,
что есть в вашей компании. И тут возникает вопрос: «Что есть
лучшее?» Вот несколько простых способов, как это определить
(табл. 5.2).
В главе 3 «Составляющие дизайн-системы как продукта» я упоминал
о взаимосвязанности как о важном критерии истинной дизайн-

1

Les McKeown, «Do Scale». (London, England: The Do Book Co., 2019).

114

Таблица 5.2. Определение «лучшего» в вашей компании
Приоритет компании

Определение «лучшего»

Производительность

Самые быстро загружаемые компоненты

Удовлетворенность
клиентов

Компоненты на страницах с наименьшим
количеством жалоб от клиентов

Технические возможности

Хорошо проработанные компоненты

Эстетика

Компоненты с красивым пользовательским интерфейсом

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

Коллекционирование как упражнение на инклюзивность
Вы также можете использовать свое определение «лучшего» для того,
чтобы обозначить важные ценности вашей дизайн-системы, в частности того, насколько инклюзивной вы хотите ее сделать.
Можно включить в свою дизайн-систему те компоненты, созданием
которых команды действительно гордятся, тем самым давая понять,
что дизайн-система — это место, где отмечаются их достижения.
Однажды я работал в организации, где был компонент, известный
всем как «Фред». У каждой фича-команды был свой экземпляр «Фреда» для работы даже до того, как была создана формальная команда по разработке дизайн-системы. Когда пришло время создавать
дизайн-систему, «Фред», естественно, стал первым официальным
компонентом. Поскольку организация уже испытывала приверженность к «Фреду», включение его в дизайн-систему привнесло в нее
часть этой приверженности. Когда популярность уже существует
на локальном уровне (то есть на уровне функции или продукта),
сбор и перенос ее на более глубокий уровень с помощью дизайнсистемы — отличный способ убедить людей использовать дизайнсистему и упростить внедрение: они узнаˆют то, к чему уже привыкли и что полюбили.

115

Вы также можете использовать упражнение по коллекционированию, чтобы завести друзей в своей организации. Возможно, есть
команда, которая стремится заниматься только своими собственными задачами. А может быть, есть команда, от которой все держатся подальше. Включение разработанного ими компонента или
паттерна в недавно созданную дизайн-систему покажет, что вы
хотите, чтобы они стали частью общего фундамента. Это способ
сказать: «Мы хотим, чтобы вы были частью этой инициативы, потому что вы уже являетесь ее частью», и этот сигнал является основной движущей силой внедрения дизайн-систем.
Эффект IKEA — это когнитивное искажение, сформулированное
в 2012 году исследователями Майклом Нортоном (Michael Norton),
Дэниелом Мокхоном (Daniel Mochon) и Дэном Ариели (Dan Ariely),
согласно которому люди придают непропорционально большую
ценность предметам, к созданию которых они приложили руку.
Это связано с психологической потребностью чувствовать себя
компетентным и уверенным в том, что ваша работа стоящая. Эффект IKEA — одна из причин того, что дизайнеры и разработчики
либо пытаются создать новую систему самостоятельно, либо предпочитают собственные модифицированные версии таких систем,
как Material Design от Google или Bootstrap от бывшего Twitter. Вы
можете обратить это когнитивное искажение на пользу вашей
дизайн-системе, сигнализируя: «Эй, вы тоже приняли в ней участие» и доказывая это, включая в нее элементы, созданные не
только командой разработки дизайн-системы, но и другими коллегами.

Выпуск пилотной версии гипотетической дизайн-системы Nike
В качестве примера рассмотрим такой бренд, как Nike, у которого
есть множество различных публичных сайтов и приложений, и продемонстрируем, как извлечь дизайн-систему из существующих
цифровых продуктов.
Первым делом инвентаризация. Может быть, у них уже есть дизайнсистема?
Начнем с флагманского сайта Nike.com (рис. 5.24). Здесь есть множество компонентов, которые вы ожидаете найти на флагманском
сайте компании: навигация, логотип, шапка, кнопки, главные (hero)
элементы, различные шрифтовые стили, карточки товаров, призывы к действию и многое другое.

116

  

Рис. 5.24. На сайте Nike.com
есть много элементов, которые
вы ожидаете найти
на флагманском сайте
электронной коммерции

117

Далее рассмотрим сайт Nike News («Новости») (рис. 5.25). Он содержит многие из тех же визуальных элементов, что и сайт Nike.com,
но есть и небольшие различия. Те из вас, кто разбирается в типографике, возможно, уже заметили, что шрифты здесь немного отличаются от тех, что мы видели на флагманском сайте. На сайте
новостей для заголовков используется рубленый шрифт Circular,
которого не было на .com.
Кроме того, хотя шапка выглядит достаточно единообразно, все
элементы навигации теперь скрыты под иконкой с тремя горизонтальными линиями, которую любовно называют «гамбургер».

Рис. 5.25. Сайт Nike News немного похож на сайт Nike, но имеет некоторые
отличия от Nike.com

118

Если перейти к сайту Nike Purpose («Цель») (рис. 5.26), то здесь можно увидеть еще больше различий. Навигация вернулась и стала
открытой, она больше не находится под «гамбургером». Но теперь
есть некоторые изменения в типографике: используется более жирный сжатый рубленый шрифт Futura в сочетании с основным рубленым шрифтом Helvetica Neue и шрифтом с засечками Palatino
для дополнительного колорита. С точки зрения и компонентов
и эстетики на этом сайте гораздо более броские главные элементы
с иллюстрациями и видео, чем на предыдущих.

Рис. 5.26. Сайт Nike Purpose немного похож на сайт Nike, но имеет отличия
от Nike.com

119

Переходя к сайту Nike Jobs («Работа») (рис. 5.27), видим еще больше
различий. Шапка похожа на предыдущие примеры, но с другой
типографикой и размерами. Взаимодействие на странице очень
насыщено анимацией и осуществляется с помощью прокрутки.

Рис. 5.27. Сайт Nike Jobs немного похож на сайт Nike, но имеет некоторые
отличия от Nike.com

На сайте Nike Investors («Инвесторы») (рис. 5.28) снова присутствует рубленый шрифт Trade Gothic, но уже в ведущей роли. Кроме
того, в шапке присутствует некоторая объемность в стиле Web 2.0,
а не плоский дизайн, как на предыдущих сайтах.

120

Рис. 5.28. Сайт Nike Investors немного похож на сайт Nike, но имеет
некоторые отличия от Nike.com

Давайте рассмотрим и некоторые нативные приложения Nike. Несмотря на визуальное сходство, приложение Nike Shopping («Покупки») (рис. 5.29) имеет гораздо больше компонентов, предназначенных для взаимодействия, таких как наборы вкладок, карусели
и аккордеоны, в отличие от мобильного сайта, который имеет гораздо больше статических призывов к действию (рис. 5.30).

121

Рис. 5.29. Нативное мобильное
приложение Nike для покупок

Рис. 5.30. Мобильный сайт Nike
для покупок

В приложении Nike SNKRS (рис. 5.31) используются те же приемы,
что и в приложении Nike Shopping, но есть небольшие различия
в таких, казалось бы, одинаковых элементах, как вкладки или
иконки.

122

Рассматривая эти сайты и приложения в совокупности (рис. 5.32),
легко заметить все эти мелкие различия. Большие различия легко
оправдать, потому что разный контент часто требует разных способов выражения, но именно мелочи
выявляют отсутствие системы.
Если посмотреть только на все шапки (рис. 5.33), то можно заметить,
как тесно они взаимосвязаны, но
не совсем одинаковы. Почему они
отличаются? Такую разницу сложно
обосновать, и зачастую она не
­имеет хорошего объяснения. Это
говорит о том, что каждый из этих
компонентов, вероятно, был спроектирован и создан индивидуально,
без учета того, что на самом деле
должна содержать система. Речь
идет о мелких несоответствиях, а не
о крупных.
Если заглянуть под капот и изучить
код, то неконсистентность станет
еще более очевидной (рис. 5.34). Во
фронтенд-коде навигации на трех
сайтах используются разные имена
классов: на одном — pre-l-nav, на Рис. 5.31. Нативное мобильное
другом — nav-main, а на третьем — приложение Nike SNKRS
main-menu, хотя их стили и поведение кажутся практически одинаковыми. Опять же, такие незначительные различия говорят о том, что, скорее всего, эта версия была
создана без учета других версий или без участия того, кто мог бы
проанализировать и проконтролировать все эти вещи. Короче говоря, поскольку эти сайты связаны между собой там, где это возможно и необходимо, можно с уверенностью предположить, что
никакая общая система не использовалась и, возможно, ее вообще
не существует.

123

Рис. 5.32. Сравнение веб-сайтов Nike для поиска общих паттернов

Рис. 5.33. Сравнение шапок выявляет несоответствия. Они сделаны
намеренно или нет?

124

Рис. 5.34. Сравнение кода, который мог бы быть одинаковым,
но не является таковым

Минимально жизнеспособная дизайн-система
Если наши предположения верны и дизайн-системы еще не существует, то самое время ее создать! Вы только что провели инвентаризацию, теперь пришло время собрать все самое лучшее. Попытка
собрать три лучших компонента и практики станет отличным началом. Главный вопрос, на который нужно попытаться ответить,
звучит так: «Какие три компонента прямо сейчас могут использовать
другие команды?» Проведя инвентаризацию и пообщавшись
с коман­дами, вы принимаете решение, что следующие три элемента являются достойными кандидатами (рис. 5.35):
zz Панель учетной записи: ее вертикальный формат и ограничен-

ное горизонтальное пространство меньше всего визуально портят
существующие сайты при внедрении.

zz Кнопка: похоже, что все в любом случае стремятся ее использо-

вать.

zz Выпадающее меню навигации: это отличный пример баланса

между брендом и функциональностью.

125

Панель
учетной
записи

Кнопка

Выпадающее
меню
навигации

Рис. 5.35. Вот три элемента,
с которых начинается
дизайн-система

Эти три элемента — начало дизайн-системы Nike! Вы можете удивиться, узнав, что всего три элемента могут стать дизайн-системой.
В конце концов, большинство популярных дизайн-систем включают в себя десятки, а то и сотни компонентов, так как же трех компонентов может быть достаточно?
Вспомните, что в определении дизайн-системы из главы 1 «Зачем
нужны дизайн-системы» говорилось, что дизайн-система — это наименьший набор компонентов, которые могут быть полезны. Многие
команды рассматривают дизайн-системы как утверждение «всё или
ничего», согласно которому приложение должно полностью состоять
из компонентов дизайн-системы, чтобы принести пользу. Это неверно. Если даже один компонент дизайн-системы экономит фичакоманде неделю, несколько дней или даже всего несколько часов
времени, дизайн-система уже доказывает свою ценность. Более
подробно о соответствующих целях и задачах по использованию,
внедрению и охвату дизайн-системы я расскажу в главе 9 «Показатели успеха дизайн-системы».

126

Дизайн-системы являются эмерджентными
В 1987 году консультант по управлению бизнесом Генри Минцберг
(Henry Mintzberg) написал для «Harvard Business Review» статью под
названием «Crafting Strategy» («Создание стратегии»)1, и она как
нельзя лучше подходит для работы над дизайн-системой. Минцберг
писал: «Стратегии, которые появляются без четких намерений или
вопреки им, [называются] эмерджентными2 стратегиями. Действия
просто сходятся в закономерности... Преднамеренная стратегия
исключает обучение после того, как стратегия сформулирована;
эмерджентная стратегия способствует этому. Люди совершают
действия одно за другим и реагируют на них, так что в итоге формируются закономерности».
Чаще всего практика дизайн-систем представляет собой одну из
стратегий эмерджентности. Создание дизайн-системы в вакууме,
а затем попытка внедрить ее в быстро развивающийся процесс
проектирования продукта в организации редко срабатывают. Выпуск пилотных версий дизайн-системы работает, потому что позволяет закономерностям органично возникать со временем, отражая реальность организации и следуя ее естественному темпу.
Если посмотреть на список основных компонентов, существующих
в дизайн-системе (рис. 5.36), легко предположить, что это список
обязательных элементов; что-то типа списка ингредиентов для выпечки пирога. Но это только потому, что у списка нет контекста.
Это неправильная метафора.
Представьте, что вы унаследовали от родственника старинный
автомобиль. Когда-то он был образцом инженерного искусства, но
годы простоя скрыли его блеск, и он просто больше не ездит.
Итак, вы решаете восстановить его. Вы аккуратно разбираете автомобиль, чтобы почистить его, привести в порядок детали, которые
еще можно починить, и заменить полностью изношенные на новые.
В какой-то момент все детали разобраны и разложены на полу
­гаража.

1

Henry Mintzberg, «Crafting Strategy», July 1987, https://hbr.org/1987/07/craftingstrategy.

2

Эмерджˆентность (от англ. emergent) — «возникающий, неожиданно появляющийся») в теории систем означает наличие у системы свойств, не
присущих ее компонентам по отдельности. — Примеч. пер.

127

ХЛЕБНЫЕ
КРОШКИ

КАРТОЧКИ

КНОПКИ

КАРУСЕЛИ

ОПОВЕЩЕНИЯ
ЗНАЧКИ
ЦИТАТЫ

АВАТАРЫ

ИТЕЛИ
РАЗДЕЛ

СЕТКА
СПИСКИ

ЧЕКБОКСЫ
ТАБЛИЦЫ
ДАННЫХ

ВЫДВИЖНЫЕ
МЕНЮ

ИКОНКИ

ПАГИНАЦИЯ

ЗАГОЛОВКИ

ТУЛТИПЫ

ПАРАГРАФЫ
ВКЛАДКИ
ТЕГИ

СЕЛЕКТБОКСЫ
ИНДИКАТОРЫ
ПРОГРЕССА

РАДИОКНОПКИ

ПЕРЕКЛЮЧАТЕЛИ

ИНТЕРВАЛЫ

ТЕКСТОВЫЕ
ПОЛЯ

Рис. 5.36. Это сосуды с ингредиентами для приготовления блюд или для
хранения готовой пищи? Невозможно определить, просто взглянув на них

128

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

Извлечение и абстрагирование
В этой главе я много писал об «извлечении и абстрагировании» компонентов, но как именно можно это сделать? Что это означает? Как
это выглядит в буквальном смысле?
Изучая многочисленные цифровые продукты своей организации,
вы наверняка столкнетесь с многочисленными вариациями одного
и того же компонента, что, скорее всего, является следствием отсутствия связи между командами дизайнеров. Например, при беглом
просмотре нескольких цифровых продуктов американской страховой компании Allstate можно обнаружить девять отдельных видов
полей ввода текста (рис. 5.37).
Как можно объединить все эти версии в одну каноническую? Большой риск здесь заключается в том, что в итоге вы создадите десятую
версию вместо канонической, что напоминает знаменитый комикс
Xkcd1 о стандартах (рис. 5.38).

1

Xkcd — это веб-комикс о романтике, сарказме, математике и языке.
Публикуется с 29 мая 2005 года, автор комикса Рэндел Манро. Комикс
нарисован в своеобразном стиле: рисунок весьма схематичен, бˆольшую
смысловую нагрузку несут тексты персонажей и/или автора. — Примеч. пер

129

Рис. 5.37. Различные варианты полей ввода текста для одного
и того же бренда

КАК РАСПРОСТРАНЯЮТСЯ СТАНДАРТЫ:

14?! ЭТО НЕЛЕПО! НАМ НЕОБХ­ ОДИМО РАЗРАБОТАТЬ ОДИН
УНИВЕРСАЛЬНЫЙ СТАНДАРТ,
СИТУАЦИЯ:
КОТОРЫЙ ОХВАТЫВАЛ БЫ ВСЕ
СУЩЕСТВУЕТ
ЮЗ-КЕЙСЫ.
ДА!
14 КОНКУРИРУЮЩИХ
СТАНДАРТОВ.

ВСКОРЕ:

СИТУАЦИЯ:
СУЩЕСТВУЕТ
15 КОНКУРИРУЮЩИХ
СТАНДАРТОВ.

XKCD. «СТАНДАРТЫ», HTTPS://XKCD.COM/927/

(СМ.: ЗАРЯДНЫЕ УСТРОЙСТВА ДЛЯ КОНДИЦИОНЕРОВ, КОДИРОВКИ СИМВОЛОВ,
МГНОВЕННЫЕ СООБЩЕНИЯ И Т. Д.)

Рис. 5.38. Работа над дизайн-системой часто балансирует
на грани создания еще одного конкурирующего стандарта

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

130

вариантов. Обратите внимание на общие черты по четырем различным критериям (табл. 5.3).
Таблица 5.3. Определение критериев для компонента
Все

Что общего у всех версий этого компонента?

Большинство

Что общего у большинства версий этого компонента?

Некоторые

Что общего у некоторых версий этого компонента?

Немногие

Что общего у немногих версий этого компонента?

В случае с компонентом поля ввода текста диаграмма выглядит
следующим образом (табл. 5.4).
Таблица 5.4. Компонент для ввода текста по критериям
Все
Большинство

Белый фон
Граница
Текст-подсказка (плейсхолдер)
Округлая форма vs прямоугольная

Некоторые

Курсивный шрифт текста-подсказки vs прямой
шрифт
Граница vs отсутствие границы

Немногие

Иконка

Когда вы начнете проектировать и создавать «новый» абстрактный
компонент, примените к каждой области диаграммы эти указания
(табл. 5.5).
Таблица 5.5. Критерии для абстрагирования компонента
Все

Все характеристики являются обязательными

Большинство

Все характеристики настоятельно рекомендуются

Некоторые

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

Немногие

Отложите включение этих характеристик

131

Все и немногие — самые простые. Если в каждом поле ввода текста
белый фон, убедитесь, что у объединенного, абстрагированного
компонента тоже белый фон. Если только у немногих полей ввода
текста есть иконки, не включайте пока их в объединенный компонент; подождите до того момента, когда это станет более распространенным.
С большинством немного сложнее, но не слишком. Если большинство
полей ввода имеют текст-подсказку, то вполне можно утверждать,
что абстрагированный компонент тоже должен иметь текстподсказку.
Некоторые — самый спорный критерий. Если некоторые поля ввода текста имеют округлую форму, а другие — прямоугольную, как
разрешить этот конфликт? Самым безотказным методом является
организация воркшопа. Соберите как можно больше представителей команд, у которых есть свои версии поля ввода текста. Добейтесь консенсуса по максимальному числу параметров. Это позволит
перевести характеристики в категорию все или большинство. Что
касается характеристик, по которым не удается достичь консенсуса, постарайтесь хотя бы договориться с участниками о том, что
выбор команды дизайн-системы будет решающим.
С учетом вышесказанного ваш абстрагированный текстовый компонент может выглядеть примерно так, как показано на рис. 5.39.

Подсказка
Подсказка

Рис. 5.39. Объединенный
текстовый компонент из девяти
отдельных источников

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

132

Вопросы для размышления
•

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

•

Какие «лучшие» части цифровых интерфейсов сейчас используются в вашей организации?

•

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

•

Какие три компонента могли бы составить вашу «минимально жизнеспособную дизайн-систему»?

ГЛАВА 6

Управление и вклад
Экосистема WordPress и ее связь с дизайн-системами

136

Фреймворк для управления дизайн-системой

138

Управление и вклад: шаблон

148

Дизайн-система как канон и расширенная вселенная

150

Вопросы для размышления

151

Бесспорно, большинство команд, с которыми я работаю, волнуют
две темы: вклад в дизайн-систему и управление ею. Обычно это
происходит потому, что в этих областях они видят наибольшее сопротивление, а именно: вклада очень мало, и даже когда вклад
происходит, он не такой, как нужно команде дизайн-системы.
В своей книге «Managing Chaos: Digital Governance by Design» бизнес-консультант Лиза Уэлчман (Lisa Welchman) подчеркивает важность цифрового управления, так как оно проясняет роли и обязанности для работающих совместно команд.
Я видел два распространенных сценария, когда управление дизайнсистемой давало сбой:
zz Команды определяют правильные роли и обязанности, но соеди-

няют их неправильно.

zz Команды понимают теорию, но часто теряются в применении

конкретных вещей.

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

Экосистема WordPress и ее связь
с дизайн-системами
WordPress — это бесплатная система управления контентом с открытым исходным кодом, которая обслуживает 43% из 10 миллионов крупнейших веб-сайтов. Конструктор WordPress был выпущен
в 2003 году и все еще продолжает активно использоваться 20 лет
спустя.
Одна из причин такой долговечности и масштабности WordPress —
его модель поддержки. Рассмотрим группы, участвующие в экосистеме WordPress:
zz Команда разработчиков WordPress Core состоит из 5–10 человек,

включая соучредителя Мэтта Мулленвега (Matt Mul­lenweg).

zz Automattic — компания, стоящая за WordPress (а также другими

проектами), в которой работает около 2000 сотрудников. Часть
из них занимается разработкой для WordPress на постоянной
основе.

136

zz По состоянию на июль 2023 года в WordPress Core было внесено

56 326 правок1.

zz Многие участники вносят свой вклад в WordPress по инициати-

ве своих компаний (не Automattic), поскольку он критически
важен для их бизнеса. По оценке сотрудника Automattic Чака
Гримметта (Chuck Grimmett), в каждую версию WordPress (с 5.0
по 6.0) внесли вклад в среднем 523 человека, не работающих
в Automattic2.

zz При этом у WordPress миллионы пользователей, которые, скорее

всего, никогда не вносили и не будут вносить в него свой вклад.
С учетом того, что WordPress используют 43% из 10 миллионов
крупнейших сайтов, даже при консервативной оценке (по одному веб-разработчику на сайт) это 4,3 миллиона пользователей.

Короче говоря, при самой широкой интерпретации полученных
данных:
zz Только 0,05% пользователей WordPress получают деньги за рабо-

ту над ним.

zz Только 0,01% пользователей вносят в него свой вклад.
zz Только 0,0002% пользователей напрямую отвечают за его созда-

ние и поддержку.

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

1

«Make WordPress Core», Automattic, 31 июля 2023 года, https://core.trac.
wordpress.org/changeset.

2

Chuck Grimmett, «Some WordPress Core Contributor Stats», 24 сентября
2022 года, https://cagrimmett.com/data-viz/2022/09/24/some-wp-core-contributorstats/.

137

zz Можно ожидать, что примерно два человека (2%) внесут свой

вклад в дизайн-систему.

zz Около шести человек (6%) должны получать зарплату за то, что

работают над ней на постоянной основе (полный или почти полный рабочий день).

zz Один человек (1%) должен нести за нее прямую ответственность

(скорее всего, владелец продукта дизайн-системы).

(Подробнее об этих ролях я расскажу в главе 7 «Роли и обязанности».)
Эти цифры помогут вам сформировать реалистичные ожидания
относительно экосистемы вашей дизайн-системы.

Фреймворк для управления
дизайн-системой
Вот список основных вопросов касательно управления дизайн-системой, на которые необходимо ответить именно в указанном ниже
порядке:
1. Какие работы по дизайн-системе необходимо выполнить?
2. Почему следует выполнить эти работы?
3. Кто должен выполнить эти работы?
4. Когда должны быть выполнены эти работы?
5. Где и как должны быть выполнены эти работы?
К счастью, многие авторы уже достаточно много писали на тему
управления дизайн-системой. Давайте подробнее рассмотрим каждый из приведенных вопросов.

Какие работы по дизайн-системе
необходимо выполнить?
В статье «Getting Vanilla ready for v1: the roadmap»1 дизайн-продюсер
Инаяили де Леон (Inayaili de León) приводит диаграмму для про1

Inayaili de León, «Getting Vanilla Ready for v1: The Roadmap», 8 июля
2016 года., https://medium.com/@yaili/getting-vanilla-ready-for-v1-the-roadmap8c0f4433f2f8.

138

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

работу сам по себе?

zz Как что-то новое попадает в дизайн-систему?

Паттерн Vanilla

Уже существует

Соответствует всем
требованиям?

Можно изменить его
в соответствии с новыми
требованиями, продолжая при
этом выполнять существующие?

Да

Да

Нет

Предложить поправку
к существующему паттерну

Нет
Еще не существует

Да

Существует ли что-либо
подобное?

Создать прототип
концепции. Можно ли
использовать это более
чем на одном сайте?

Нет

Можно сделать это
более универсальным?

Нет

Нет
Эти сайты используют
одну и ту же тему
или разные?

Разные темы

Добавить напрямую на сайт

Предложить
новый паттерн

Создать задачу
на GitHub
по предложенному
шаблону, назвать
ее «Предложение»

Да

Одна тема

Переместиться
на уровень темы

1. Альфа: принят как допустимый вариант
использования; прототип в разработке
2. Бета: устранены основные ошибки;
тестирование продолжается
3. Стабильный: развернут; улучшения
могут продолжаться
Примечание: переход от одного этапа
к другому должен быть одобрен рабочей
группой.

Рис. 6.1. Схема процессов добавления нового компонента в дизайн-систему
Vanilla в компании Canonical, составленная Инаяили де Леон

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

139

СТАРЫЙ ПРОЦЕСС
ПРОЕКТИРОВАНИЯ ПРОДУКТА

НОВЫЙ РАБОЧИЙ ПРОЦЕСС
НА ОСНОВЕ ДИЗАЙН-СИСТЕМЫ

Рис. 6.2. Новый рабочий процесс на основе дизайн-системы — идеальное
наполнение для существующего процесса

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

Кто должен выполнить работы по дизайн-системе?
В своей статье «Team Models for Scaling a Design System»1 («Модели
команд для масштабирования дизайн-системы») консультант по ди1

Nathan Curtis, «Team Models for Scaling a Design System», 17 сентября
2015 года, https://medium.com/eightshapes-llc/team-models-for-scaling-a-designsystem-2cf9d03be6a0.

140

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

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

Джина Энн (Jina Anne) — основательница конференции Clarity, посвященной дизайн-системам, — продолжает тему1. Она рассказывает о своей работе над дизайн-системой Lightning в компании
Salesforce. Джина рекомендует циклическую модель (рис. 6.4), когда
продуктовая команда и команда дизайн-системы работают вместе,
чтобы создать эффективный цикл. Я упоминал об этом в главе 5
«Пилотные проекты — лучший способ запустить и поддерживать
дизайн-систему», где рассказывал, как дизайн-система влияет на
дизайн продукта, а дизайн продукта влияет на дизайн-систему.

СОВМЕСТНАЯ
РАБОТА

1

Рис. 6.4. Джина Энн
описывает циклическую
модель распределения
ответственности между
продуктовыми командами
и командами дизайн-систем

Jina Anne, «The Salesforce Team Model for Scaling a Design System», 13 октября 2015 года, https://medium.com/salesforce-ux/the-salesforce-team-model-forscaling-a-design-system-d89c2a2d404b.

141

Неправильно выбранные люди, выполняющие неправильную работу в экосистеме дизайн-системы являются, пожалуй, самой распространенной причиной того, почему дизайн-системы не приживаются. Путаница ролей напрямую связана с неудачной стратегией
«создай систему, используй систему», которую я описал в главе 4
«Как непросто получить поддержку дизайн-системы». Возможно,
самая большая ценность рассмотрения работы дизайн-системы как
практики эмерджентной стратегии заключается в том, как это
переосмысляет саму концепцию вклада в дизайн-систему — одного
из самых важных и непростых этапов в цикле непрерывного совершенствования продукта в организации.
Почему вклад в систему дается так трудно? В организациях, где
работу над дизайн-системой не рассматривают как эмерджентный
процесс, она частно полностью отделена от цикла проектирования
продукта. В такой организационной модели команды дизайн-системы создают компоненты, а продуктовые команды работают над
функциями, и ни в чьи обязанности не входит выяснение того, как
эти две вещи сочетаются друг с другом. И при этом почему-то предполагается, что все это должно каким-то образом совмещаться.
Однако когда вы выпускаете пилотные версии, роли каждой команды становятся намного яснее. Задача продуктовых команд и фичакоманд заключается в создании ценности для своих клиентов — конечных пользователей продукта. Задачей команды дизайн-системы
является сбор созданных продуктовыми командами компонентов
и паттернов путем извлечения их из продукта и абстрагирования —
для того, чтобы другие команды могли тоже ими пользоваться.
Другими словами, именно команда разработки дизайн-системы
должна вносить вклад в дизайн-систему, поскольку это не является
работой продуктовой команды. Именно в этом ошибаются большинство организаций. Они думают, что задача команды дизайнсистемы заключается в создании лучших практик, а задача продуктовых команд — каким-то образом впитывать и использовать
эти лучшие практики, а затем волшебным образом выяснять, как
внести свой вклад в этот набор лучших практик. Я видел, как
­команды дизайн-систем создавали сложные чек-листы, которыми
должны были руководствоваться продуктовые команды, чтобы
внести свой вклад, а потом возникало недоумение, почему вклад
так низок или вообще отсутствует. Вклад затрудняется, когда за
него отвечают не те люди и когда действующие системы (планы
спринта, скорость выпуска продукта, культура «move fast and break

142

things»1) не стимулируют его. Лучшим способом является как можно дольше позволять командам делать то, что для них легко, естественно, привычно и (надеюсь) приносит удовольствие. Системщики хотят делать системную работу. Разработчики хотят создавать
продукты. В этом и есть решение.
Я люблю готовить, но делаю это нечасто, потому что во время готовки создаю гигантский беспорядок. Я за то, чтобы убирать за
собой по ходу дела, но все равно остается куча разделочных досок,
ножей, горшочков и тарелок, которые потом нужно мыть и чистить.
И чтобы избежать работы, которой я не хочу заниматься, я не делаю
то, что действительно хочу делать.
К счастью, мы нашли баланс в собственном доме. Моя жена Эмили
не любит готовить, но она совсем не против уборки. И у нее это отлично получается! Она делает это гораздо быстрее и лучше, чем я,
причем, как мне кажется, с гораздо меньшими усилиями, чем обычно приходится прилагать мне.
Так что мы договорились: я готовлю, она убирает. Мы с женой,
а также наши дети получаем вкусную еду, и каждый из нас вносит
в нее тот вклад, который ему нравится (или, по крайней мере, не
утомляет), при этом получая пользу от того, что делает другой.
Именно так должны работать вместе продуктовые команды и коман­
ды разработчиков дизайн-систем. Команды разработчиков дизайнсистем хороши в стандартизации вещей и их абстрагировании.
Продуктовые команды хороши в изобретении новых вещей и умении так использовать их в своих продуктах, чтобы уложиться в сроки и создать ценность для клиента. Инвестируйте в этот принцип,
позволяя ему управлять вашим циклом «мерной ложки».
Когда этот цикл запущен, вклад в дизайн-систему становится автоматическим просто в силу того, что каждый делает свою работу.
С точки зрения продуктовой команды они создали определенные
вещи для выполнения функций, которые необходимы для их клиентов. А через несколько недель эти вещи появляются в дизайн-системе, готовые к использованию другими командами. С точки зрения
коман­ды разработчиков дизайн-системы все, что им нужно было
1

«Двигайся быстро и ломай все подряд» — подход к работе и инновациям
с акцентом на скорость и эксперименты. Фраза стала популярной в мире
стартапов Кремниевой долины благодаря Марку Цукербергу, который
сделал ее официальным девизом Facebook. — Примеч. пер.

143

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

Когда должны быть выполнены работы
по дизайн-системе?
Если ответ на вопрос «кто» чаще всего бывает ошибочным, то ответ
на вопрос «когда» — второе по значимости заблуждение, и они тесно связаны. Ожидание того, что продуктовые команды будут заниматься абстрагированием, вносить вклад в дизайн-систему и документировать компоненты, которые могут войти в нее, часто
приводит к тому, что эта работа планируется на конец цикла разработки продукта. Ха! Как будто у продуктовых команд есть дополнительное время. И даже если бы оно у них было, они, вероятно,
спешат завершить свою основную работу и предпочли бы потратить
драгоценные часы на отложенные из-за дедлайна задачи, а не на
«благотворительность» для команды, в которой они не состоят, с результатами, которых они не увидят. Окончание проекта — худшее
время для того, чтобы просить любую команду навести порядок.
Несколько лет назад мы с командой отправились в Диснейленд
в Орландо, штат Флорида, чтобы выступить на конференции по
дизайну. Мы также находились на завершающей стадии работы
над продуктом, и единственное, что мы не закончили, была работа
над документацией. На следующий день все отправились в Диснейленд, а мы сидели в гостиничных номерах, документируя гайдлайны API и UX. Каждый раз, когда я думаю о том, не оставить ли
документацию напоследок, я вспоминаю, что лучше бы я поехал
в Диснейленд. Правдивая история.
Если абстрагирование, вклад и документирование не стоит выполнять в конце процесса, то когда же нужно их делать? Ответ: на
протяжении всего процесса.
Я уже слышу ваш смех: «Конечно! Вести документацию в течение
всего проекта! Так же, как ежедневно чистить зубы и раз в неделю
проверять свои финансы!» Справедливо, дорогой читатель! Для того
чтобы это вошло в привычку, вам придется немного над этим поработать. Если вы согласны со всем, что прочли в этой главе до сих
пор, то понимаете, что работа над дизайн-системой и работа над

144

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

ВТ

СР

ЧТ

ПТ

СДЕЛАТЬ ОБЗОР БЭКЛОГА: СОВМЕСТНОЕ ПЛАНИРОВАНИЕ,
ЧТОБЫ ВСЕ ЗАРАНЕЕ ЗНАЛИ, ЧТО ПРОИЗОЙДЕТ
РАЗДЕЛЯЙ И ВЛАСТВУЙ: КАЖДЫЙ ЧЛЕН
КОМАНДЫ БЕРЕТ НА СЕБЯ ТЕ ЗАДАЧИ,
КОТОРЫМИ ХОЧЕТ ЗАНЯТЬСЯ

ПОКАЗАТЬ И РАССКАЗАТЬ: ОБСУЖДЕНИЕ
ИДЕЙ В КОЛЛЕКТИВНОЙ ГРУППЕ, ПРЕЖДЕ
ЧЕМ ВЫ ЗАЙДЕТЕ СЛИШКОМ ДАЛЕКО

ВРЕМЯ ПОТОКА: ИНДИВИДУАЛЬНОЕ ВРЕМЯ, ЧТОБЫ
СОСРЕДОТОЧИТЬСЯ И ПОЛНОСТЬЮ ПОГРУЗИТЬСЯ
В ВЫПОЛНЕНИЕ ТЕКУЩЕЙ ЗАДАЧИ

РАССЛАБИТЬСЯ: ОТДЫХ
И ВОССТАНОВЛЕНИЕ — ВАЖНЕЙШАЯ ЧАСТЬ ЛЮБОЙ ХОРОШЕЙ
ТРЕНИРОВКИ

Рис. 6.5A. Это настоящее волшебство, когда сплоченная и надежная
команда входит в состояние потока
ПН

ВТ

СР

АУДИТ: ГРУППОВОЕ УПРАЖНЕНИЕ. ИЗУЧИТЬ,
ЧТО БЫЛО СДЕЛАНО, И ВЫБРАТЬ, ЧТО МОЖНО
ИСПОЛЬЗОВАТЬ В ДРУГИХ КОМАНДАХ

ЧТ

ПТ

ДОКУМЕНТИРОВАНИЕ: СОХРАНИТЬ
ВСЮ ИНФОРМАЦИЮ ДЛЯ ПЕРЕДАЧИ
СЛЕДУЮЩЕМУ УЧАСТНИКУ

АБСТРАГИРОВАНИЕ: СМЕНА КОНТЕКСТА
И РЕФАКТОРИНГ КОМПОНЕНТА ДЛЯ ШИРОКОГО
ИСПОЛЬЗОВАНИЯ
ВСТРАИВАНИЕ: ПОДГОТОВКА
СИСТЕМНОЙ СРЕДЫ ДЛЯ НОВЫХ
КОМПОНЕНТОВ

ИНФОРМИРОВАНИЕ: РЕШИТЬ,
КАК ЛЮДИ СМОГУТ УЗНАТЬ
О НОВЫХ ИЗМЕНЕНИЯХ

РАССЛАБИТЬСЯ

Рис. 6.5Б. Работа над продуктом наиболее важна, потому что это прямой
путь к созданию ценности для клиентов, но масштабирование хорошей
работы над продуктом для получения будущей выгоды требует времени.
Запланируйте «неделю систем»: одну неделю из четырех посвящайте тому,
чтобы извлекать и абстрагировать лучшие наработки, которые другие
команды смогут использовать

145

Вначале дайте продуктовым командам 2–3 недели на погружение
в процесс решения нужд пользователей («недели потока»). В этот
период команда разработки дизайн-системы может найти и предоставить существующие компоненты и паттерны, которые сэкономят
время для продуктовой команды. Затем каждые 3–4 недели команда разработки дизайн-системы должна проводить «неделю системы»,
в течение которой нужно проверить все вновь созданные компоненты любой из трех пилотных команд на предмет соответствия
этих компонентов требованиям дизайн-системы.
Критерии выбора просты. Для каждого компонента-кандидата
спросите: «Могут ли три другие команды в этой компании прямо
сейчас использовать этот компонент?» Если нет, не добавляйте его
в дизайн-систему.
Пусть будут стоны. «Какие строгие критерии! Разве мы не должны
мыслить более прогрессивно?» Я понимаю эти чувства. Но строгие
правила помогут избежать ловушки, в которую попадает большинство организаций. Помните, что большинство кладбищ дизайн-систем заполнены системами с большим количеством компонентов,
которые никто не использует. Нюанс в том, что они полны компонентов, которые кто-нибудь когда-нибудь может использовать.
Но это «когда-нибудь» никогда не наступает. Если критерии вклада
в дизайн-систему сфокусируются на текущих потребностях, у вас
будет гораздо больше шансов создать систему, которая будет немедленно внедрена, потому что в ней имеется насущная потребность.
(При этом, когда я работаю с командами, которые понимают этот
нюанс, мы немного расширяем критерии: «Может ли другая команда в этой компании использовать этот компонент в этом квартале?»
Да, я очень мягкотелый.)
Оставшаяся часть «недели систем» дает команде разработки дизайнсистемы время взять компоненты, которые соответствуют критериям использования в настоящее время или в течение квартала
(и, вероятно, были созданы для конкретного сценария), и абстрагировать дизайн и код, чтобы сделать их более гибкими и более широко применимыми. На этой неделе также следует написать всю
необходимую документацию для этих нескольких новых компонентов, а не ожидать окончания всего цикла продукта и засесть над
документацией для десятков или даже сотен новых компонентов.
(Запомните и повторяйте вместе со мной: «Мы хотим поехать в Диснейленд».)

146

Благодаря «неделе систем» находится время не только для абстрагирования и работы над документацией, но и для распространения
информации о новых доступных обновлениях. «Если в лесу падает
компонент и рядом никого нет…»1 Простите за неуклюжую аналогию, но, надеюсь, вы меня поняли. Расскажите людям, что у них
есть новые возможности! В каждой организации для этого есть
свои способы: рассылка по электронной почте, сообщения в канале Slack, записи в wiki, встречи «покажи и расскажи» и т. д. Главное, что для этой работы, которую часто оставляют «на потом»,
выделено время.
И возможно, вам стоит почаще чистить зубы.

Где и как должны быть выполнены работы
по дизайн-системе?
Уф! Мы основательно пересмотрели парадигмы при ответе на вопросы «кто» и «когда».
К счастью, в разделе, посвященном «где» и «как», можно сбавить
обороты. Ответы на вопросы «кто» и «когда» сложны, и команды
обычно идут по неверному пути. А вот с ответами на «где» и «как»,
как правило, все в порядке! Вероятно, в вашей организации уже
есть базовый процесс проектирования продукта, который определяет многие из «где» и «как». Например:
zz Как следует оценивать текущую работу команды?
zz Где мы создаем прототипы?
zz Как руководители могут контролировать нашу работу?
zz Куда обращаются клиенты, чтобы оставить отзыв о новых функ-

циях продукта?

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

Намек на известную философскую загадку: «Если в лесу падает дерево
и вокруг нет никого, чтобы это услышать, то производит ли оно звук?» —
Примеч. ред.

147

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

Управление и вклад: шаблон
Так много информации, которую надо переварить! Как собрать все
это воедино и систематизировать?
Выберите дату начала для первой «недели систем». Первая задача
на этой неделе: не просто документируйте, а фиксируйте все детали своего текущего рабочего процесса. Нет, правильнее сказать,
фиксируйте то, как вы в настоящее время работаете. Не поддавайтесь искушению создать новый процесс, даже если ваш текущий
процесс работы не идеален. Если все же не можете устоять перед
этим желанием, описывайте две версии процесса: текущий и новый,
идеальный. Документируйте «что», «почему», «кто», «когда», «где»
и «как» для каждого вида деятельности. В качестве шаблона можно
использовать вот эту подробную диаграмму (рис. 6.6).
Многое из этого шаблона будет неактуально или неуместно для вашей организации. Это нормально; отдайте приоритет документированию того, что вам больше подходит. Не так важно, что именно
вы делаете. Важнее, чтобы все о чем-то договорились, и именно это
стоит задокументировать. Как и в процессе выпуска пилотных
версий дизайн-системы, сделайте нечто, а потом это запишите.
После того как первая «неделя систем» закончится, постарайтесь
следовать процессу, который вы запланировали на следующую «неделю потока». На следующей «неделе систем» (или раньше) вносите
правки и дополнения по мере их обнаружения. Так нарабатываются организационные «мускулы» и привычки, для того чтобы перей­
ти от дизайн-системы как инструмента к дизайн-системам как
укоренившейся практике.

148

ПРОДУКТОВАЯ
КОМАНДА
ПОЛУЧАЕТ
БРИФ

ЗНАЕТ ЛИ
ПРОДУКТОВАЯ
КОМАНДА ПРИНЦИП
«ГОРЯЧЕЙ
КАРТОШКИ»?

ДА

ПРОДУКТОВАЯ
КОМАНДА
ИСПОЛЬЗУЕТ
ПРИНЦИП
«ГОРЯЧЕЙ
КАРТОШКИ»
ПРИ
РАЗРАБОТКЕ UI

ПРОДУКТОВАЯ
КОМАНДА
РАССКАЗЫВАЕТ
КОМАНДЕ
РАЗРАБОТКИ
ДИЗАЙН-СИСТЕМЫ
О СУЩЕСТВУЮЩИХ
КОМПОНЕНТАХ

КОМПОНЕНТ УЖЕ
СУЩЕСТВУЕТ?

ДА

ОТВЕЧАЕТ
ЛИ ОН ВСЕМ
НАШИМ
ТРЕБОВАНИЯМ?

ДА

ПРАЗДНИК!

НЕТ

ЕСТЬ ЛИ
ВРЕМЯ И ЖЕЛАНИЕ
НАУЧИТЬСЯ ИСПОЛЬЗОВАТЬ ПРИНЦИП
«ГОРЯЧЕЙ КАРТОШКИ»?

ДА

НЕТ

КОМАНДА
РАЗРАБОТКИ
ДИЗАЙН-СИСТЕМЫ ОБЪЯСНЯЕТ
ПРОДУКТОВОЙ
КОМАНДЕ
ПРИНЦИП
«ГОРЯЧЕЙ
КАРТОШКИ»

ОБСУЖДЕНИЕ
МЕЖДУ
ПРОДУКТОВОЙ
КОМАНДОЙ
И КОМАНДОЙ
РАЗРАБОТКИ
ДИЗАЙНСИСТЕМЫ

НЕТ

КОМАНДА
РАЗРАБОТКИ
ДИЗАЙН-СИСТЕМЫ УКАЗЫВАЕТ
ПРОДУКТОВОЙ
КОМАНДЕ НА
СУЩЕСТВУЮЩЕЕ
РЕШЕНИЕ

НЕТ

КАЖДЫЕ ТРИ
НЕДЕЛИ КОМАНДА
РАЗРАБОТКИ
ДИЗАЙН-СИСТЕМЫ
ПРОВЕРЯЕТ РАБОТУ
НАД ПРОДУКТОМ
НА ПРЕДМЕТ
ВОЗМОЖНЫХ
ВКЛАДОВ

ПРОДУКТОВАЯ
КОМАНДА
СОЗДАЕТ
ПОЛЬЗОВАТЕЛЬСКИЕ
КОМПОНЕНТЫ

НЕТ

МОЖЕТ
ЛИ ДРУГАЯ
КОМАНДА ПРЯМО
СЕЙЧАС ИСПОЛЬЗОВАТЬ ЭТОТ КОМПОНЕНТ?

НУЖНА ЛИ ЕЩЕ
КАКАЯ-ТО РАБОТА?

ДА

НЕТ

ДА

КОМАНДА
РАЗРАБОТКИ
ДИЗАЙНСИСТЕМЫ
РАБОТАЕТ
НАД НОВЫМ
КОМПОНЕНТОМ

КОМАНДА
РАЗРАБОТКИ
ДИЗАЙН-СИСТЕМЫ ПРОВЕРЯЕТ
НОВЫЙ
КОМПОНЕНТ
С ПРОДУКТОВОЙ
КОМАНДОЙ

ОТВЕЧАЕТ ЛИ ОН
ВСЕМ НАШИМ
ТРЕБОВАНИЯМ?

ДА

СОЗДАТЬ
РЕЛИЗНУЮ
ВЕТКУ

ТЕГИРОВАТЬ
РЕЛИЗ

СЛИТЬ
В ОСНОВНУЮ
ВЕТКУ

НЕТ
ПРАЗДНИК!

Рис. 6.6. Схема процессов совместной работы команд разработки
дизайн-систем и продуктовых команд

149

Дизайн-система как канон
и расширенная вселенная
Сага «Звездные войны» Джорджа Лукаса стала невероятно популярной с момента выхода оригинального фильма в 1977 году. С тех пор
о вселенной и персонажах «Звездных войн» было написано множество историй, одни — компанией Lucasfilm (а позже — компанией
Disney), другие — разными компаниями и широкой аудиторией
фанатов. В связи с этим возникает вопрос: какие истории являются официальными, а какие — нет?
Чтобы ответить на него, компания Lucasfilm в 1994 году ввела понятие «канон». По определению онлайн-энциклопедии Woo­kieepedia1
(«Вукипедия»), канон «Звездных войн» — это набор неизменных объектов истории «Звездных войн», персонажей и событий, с которыми
должны согласовываться все остальные истории. Канон «Звездных
войн» включает в себя шесть фильмов «Звездные войны», телесериал и фильм «Звездные войны: Войны клонов», романы (там, где они
совпадают с событиями на экране) и первую часть новеллы «Эскадрилья клинков». Короче говоря, канон — это Евангелие. Все остальное считается частью «расширенной вселенной» (позже переименованной в «Легенды»), то есть их существование разрешено
и поощряется, хотя они и не являются частью канона.
Общая осведомленность о «Звездных войнах» также в целом отражает канон (рис. 6.7). Большинство людей знают канонических
персонажей Дарта Вейдера и принцессу Лею, Люка Скайуокера
и Йоду, но персонажи «расширенной вселенной» Синдель Товани,
ДРН-38 или Надя Грелль гораздо менее известны, хотя они играют
важную роль в своих сюжетных линиях.
Модель того, что является и не является каноном, хорошо подходит
и для дизайн-систем. На каждом этапе развития ваша дизайн-система должна содержать то, что является каноном: официальные
компоненты, паттерны и процессы, которым все остальное должно
соответствовать.

1

«Вукипедия» (Wookieepedia, the Star Wars Wiki) — это онлайн-энциклопедия о фильмах и расширенной вселенной «Звездных войн». Структура
и принцип работы схожи с «Википедией», но тематика узкоспециализированная. — Примеч. ред.

150

Рис. 6.7. Канонические и неканонические персонажи «Звездных войн».
По часовой стрелке, начиная сверху слева: Надя Грелль, Дарт Вейдер,
BЗ-9Д, Йода, Дэш Рендар, принцесса Лея

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

Вопросы для размышления
•

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

•

Среди вопросов «кто», «что», «где», «когда» и «почему» в управлении что для вас и вашей команды было или будет самым
простым? Что было или будет самым сложным?

ГЛАВА 7

Роли и обязанности
Фронтенд-разработка важнее визуального дизайна

156

Фронтенд-разработка важнее бэкенд-разработки

158

Фронтенд-разработка: недостающий набор навыков

159

Ребрендинг «фронтенд-разработчика»

160

Психологическая безопасность

168

Инженеры экосистемы

170

Трехногая табуретка

171

Другие роли в команде дизайн-системы

172

Годовой бюджет дизайн-системы

184

Вопросы для размышления

187

В начале 2001 года 17 разработчиков встретились, чтобы обсудить,
как можно и нужно работать. Результатом явился «Manifesto for Agile
Software Development» («Манифест гибкой разработки программного обеспечения»), который часто сокращенно называют «Agileманифест». Он представляет собой ряд принципов и рекомендаций
по руководству программными проектами.
«Agile-манифест» начинался с четырех основных принципов:
zz Люди и взаимодействия важнее процессов и инструментов.
zz Работающее программное обеспечение важнее исчерпывающей

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

zz Сотрудничество с заказчиком важнее переговоров по контракту.
zz Готовность к изменениям важнее следования первоначальному

плану.

Многие организации массово внедрили «Agile-манифест» в качестве
стандарта поставки программного обеспечения, поэтому практика
дизайн-систем должна эффективно вписываться в его контекст.
Когда речь заходит о дизайн-системах, моим любимым принципом
«Agile-манифеста», тем, на котором я больше всего фокусируюсь,
является второй. О нем забывает большинство команд, а ведь именно этот принцип открывает наибольшие преимущества, если его
правильно реализовать. В манифесте подчеркивается: «Хотя есть
ценность в элементах, упомянутых в правой части фразы, мы больше ценим элементы, упомянутые в левой части». Но большинство
команд разработки дизайн-систем и продуктовых команд, похоже,
считают, что документация важнее, чем работающее программное
обеспечение.
Не верите мне? Посмотрите на результаты, за которые отвечают
члены команды. Информационные архитекторы рисуют диаграммы.
Технические писатели создают документы. Продакт-менеджеры
пишут требования. Стратеги составляют брифы. Дизайнеры создают макеты. Разработчики пишут код.
Кто в команде действительно создает работающее программное
обеспечение? Только разработчики. Все остальные специальности
в основном связаны с документированием (рис. 7.1). Что такое
вайрфрейм? Документация о том, как должен функционировать
сайт или приложение. Что такое макет? Документация о том, как
должна выглядеть часть программного обеспечения.

154

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

ПРОДАКТМЕНЕДЖЕРЫ
ТРЕБОВАНИЯ
ДОКУМЕНТАЦИЯ
ИНФОРМАЦИОННЫЕ
СТРАТЕГИ
АРХИТЕКТОРЫ
БРИФЫ
ДИАГРАММЫ
ДОКУМЕНТАЦИЯ
ДОКУМЕНТАЦИЯ
ТЕХНИЧЕСКИЕ
ПИСАТЕЛИ
ДОКУМЕНТЫ
ДОКУМЕНТАЦИЯ

ДИЗАЙНЕРЫ

РАЗРАБОТЧИКИ

МАКЕТЫ
ДОКУМЕНТАЦИЯ

КОД
ПРОГРАММНОЕ
ОБЕСПЕЧЕНИЕ

Рис. 7.1. Большинство членов цифровой команды составляют документацию,
но только разработчики создают код — реальную вещь, с которой
взаимодействуют пользователи

155

Приоритет работающего программного обеспечения — это прио­
ритет, отданный тому, чем могут пользоваться клиенты вашей организации. Чем больше времени команда тратит на написание
документации (особенно той, что создается до работы над программным обеспечением), тем дольше пользователи остаются без
доступа к вашему продукту. Вот почему выпуск пилотных версий,
о котором мы говорили в главе 5 «Пилотные проекты — лучший
способ запустить и поддерживать дизайн-систему», так важен: он
отдает приоритет быстрому внедрению и использованию. Если
в культуре вашей организации документирование преобладает над
разработкой ПО, вы можете стать примером для подражания
в противоположном подходе, то есть продвигать культуру постоянного внимания к выпуску работающего ПО, начав с вашей команды разработки дизайн-системы.
Ирония постоянно расширяющихся ролей в нашей индустрии в том,
что на самом деле нужна единственная роль в команде: люди, которые пишут HTML.

Фронтенд-разработка важнее
визуального дизайна
В 2005 году разработчик Ной Стоукс (Noah Stokes) создал удивительный личный сайт (рис. 7.2).
Сайт Ноя был написан просто на HTML. К нему не прилагался файл
CSS. На странице присутствовала анимация: линия, которая двигалась от левого до правого края экрана, но она не была реализована с помощью современных CSS или JavaScript-анимаций... Это
был старый добрый элемент <marquee>.
Веб-сайт Ноя — это законченный продукт. Был ли ему нужен дизайнерский макет? Нет. Мог ли дизайнер сделать этот сайт лучше?
Возможно. (Хотя есть веский аргумент в пользу того, что это, вероятно, лучшая версия сайта.) Мог бы информационный архитектор
сделать его лучше? Вероятно. Могло бы больше логики в бэкенде
сделать его лучше? Возможно. Но все эти вещи, о которых я говорю,
нужны для того, чтобы сделать сайт лучше, а не для того, чтобы
просто сделать его. Дизайн, архитектура, стратегия — все это является оптимизацией программного обеспечения. И как знает каждый хороший разработчик, вначале нужно сделать, а потом оптимизировать.

156

Рис. 7.2. Веб-сайт Ноя Стоукса 2005 года представляет собой
полноценный продукт

Вы не начинаете с оптимизации, когда нечего оптимизировать. Как
выглядит настоящий минимально жизнеспособный веб-продукт?
Это обычный старый добрый HTML-документ.
Когда речь идет о создании веб-продуктов, фронтенд-разработка
важнее визуального дизайна.
«Но Дэн... неужели можно сделать такой вывод на основании личного сайта, созданного в 2005 году?» — скажете вы. Справедливое
замечание, дорогой читатель. Позвольте мне привести вам еще несколько доказательств.
Широкая общественность часто забывает, что предприниматель
и инвестор Джефф Безос (Jeff Bezos) начинал как инженер-программист. Первый веб-сайт Amazon, запущенный в 1995 году, представлял собой HTML с горсткой атрибутов стиля, основанных на HTML
(рис. 7.3). В первоначальных объявлениях Безоса на Usenet о вакансиях ему требовались «разработчики C/C++/Unix», которые «знакомы
с веб-серверами и HTML». Никаких упоминаний о дизайне, стратегии

157

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

Рис. 7.3. Оригинальный
сайт Amazon.com 1995 года

(Что действительно сломает вам мозг, так это тот факт, что многие
из самых популярных в мире программных продуктов: eBay, Craigs­
list, Wikipedia — до сих пор остаются во многом верны своим первоначальным «недизайнерским» формам. Может быть, есть какая-то
связь между теми, кто лучше всего понимает идею приоритета
работающего программного обеспечения, и теми, кто добился продолжительного успеха?)

Фронтенд-разработка важнее
бэкенд-разработки
Разработчик Мэнди Майкл (Mandy Michael) написала в 2017 году
превосходную статью под названием «Is There Any Value in People
Who Cannot Write JavaScript?» («Имеют ли хоть какую-то ценность
специалисты, не владеющие JavaScript?»), в которой она сетовала
на то, что большинство современных вакансий требуют знания
JavaScript1. Я думаю, что отчасти подтекст у Мэнди таков: а HTML
и CSS так же важны, как JavaScript?
1

Mandy Michael, «Is There Any Value in People Who Cannot Write JavaScript?»,
13 сентября 2017 года, https://medium.com/@mandy.michael/is-there-any-value-inpeople-who-cannot-write-javascript-d0a66b16de06.

158

Я говорю: «Да, черт возьми!»
Серверные языки (на данный момент я добавил туда JavaScript)
являются невероятно мощными, но неслучайно у каждого из них
есть хотя бы один метод вывода HTML. Пока вы не выведете
HTML (будь то функция Echo в PHP или метод Return в React либо
любой другой способ в языке, который вы используете), продукт
не будет настоящим веб-продуктом. Только когда на экране появляется нечто, с чем люди могут взаимодействовать, продукт
оживает. И что это за «нечто»? HTML. Независимо от того, генерируется ли он сервером или клиентом, вам нужен HTML. Без
HTML в вебе не работает ничего. Когда я общаюсь с новичками
в отрасли и меня спрашивают, с чего начать обучение, я всегда
отвечаю: «С HTML». Если вы хотите создавать веб-продукты, все
дороги ведут к HTML.
Когда дело доходит до создания веб-продуктов, языки фронтенда
важнее, чем языки бэкенда.

Фронтенд-разработка: недостающий
набор навыков
Если ваша команда состоит из дизайнеров, работающих в таких
инструментах, как Figma или Sketch, и разработчиков, которые
настраивают сборки Webpack и пишут на .net или Java, то вам не
хватает основного набора навыков, который позволит использовать
все преимущества дизайн-системы.
Чтобы максимально эффективно использовать дизайн-систему, необходимо отдать приоритет фронтенд-разработке.
Это может означать расширение обязанностей дизайнеров за счет
включения в них кодинга на HTML и CSS, или убеждение всех, что
фронтенд — это «настоящее программирование», или наем фронтенд-разработчиков, которые уже имеют такую специализацию.
В любом случае вам придется инвестировать во фронтенд-дизайн
и фронтенд-разработку. Это связующее звено, которое соединяет
дизайн, разработку и клиентов (рис. 7.4). Без этих инвестиций вы
упустите самую важную часть того, как цифровые продукты, созданные с помощью дизайн-систем, могут формировать ценность
для клиентов.

159

ДИЗАЙНЕРЫ

ФРОНТЕНДРАЗРАБОТЧИКИ

РАЗРАБОТЧИКИ

Рис. 7.4. Фронтенд — это место, где дизайн и разработка сходятся воедино

Ребрендинг «фронтенд-разработчика»
11 мая 1996 года самолет ValuJet Flight 592 должен был лететь из
Майами в Атланту. Вместо этого он потерпел крушение в Эверглейдс
во Флориде, среди 110 пассажиров и членов экипажа никто не выжил. После катастрофы, несмотря на то что первоначально авиакомпания была признана безопасной, FAA (Федеральное управление
гражданской авиации США) приостановило полеты ValuJet на три
месяца. В ходе дальнейшего расследования FAA обнаружило, что
ValuJet систематически применяла опасные методы сокращения
расходов. Они плохо обучали сотрудников и полагались на самую
дешевую рабочую силу, которую могли найти для технического
обслуживания. Компания быстро приобрела репутацию ненадежного перевозчика с сомнительными стандартами безопасности.
Когда люди думали о ValuJet, они ассоциировали ее с ненадежно-

160

стью. Это было эмоциональное восприятие; ненадежность стала
брендом компании.
В 1997 году — год спустя — ValuJet приобрела компанию AirTran
Airways и взяла название приобретенной, меньшей авиакомпании.
Оригинальное название было слишком токсичным, чтобы его сохранять. Бренд ValuJet стал синонимом опасности. Им пришлось
провести ребрендинг, потому что они должны были изменить мнение людей о себе.
К сожалению, есть название, которое начинает становиться токсичным в нашей индустрии. Оно создано с благими намерениями
и на самом деле означает то, что должно означать, но — вопреки
всем намерениям — начинает вызывать неправильные ассоциации.
Думаю, пришло время провести ребрендинг «фронтенд-разработчика». Это название начинает приобретать коннотацию, что навыки работы с фронтендом не особо полезны. Не проходит и нескольких дней без споров в Twitter о том, является ли написание
HTML и CSS «настоящим программированием». Уф. (На самом деле
является.)
Нам нужно название, подчеркивающее важность навыков, которыми обладает этот специалист. Можно даже признать, что это не
то же самое, что другие виды программирования, но не менее (если
не более) ценно или даже самое ценное, как я уже утверждал в начале этой главы. Нужно дать понять, что этот специалист участвует в разработке вˆидения продукта, а также интерфейса, с которым
будут взаимодействовать пользователи.
Если задуматься, во многих компаниях уже есть подходящее слово
для этого. И это слово...
Дизайнер.
Когда я работаю с командами, которые хотят добиться большего
успеха в совместной работе над веб-продуктами, одним из первых
моих предложений становится перевод всех фронтенд-разработчиков в команду дизайнеров и изменение названия их должности на
«дизайнер». Потребуется некоторое время, чтобы проникнуться этой
идеей, и еще некоторое время, чтобы воплотить ее в жизнь, но удивительно видеть, насколько увереннее становятся фронтенд-разработчики, когда люди думают о них как о дизайнерах и когда они
сами так думают о себе.
Кроме того, это легко обосновать.

161

Фронтенд-разработчики как дизайнеры
Посмотрите на свою нынешнюю команду дизайнеров. Возможно,
один из ваших дизайнеров, Кейт, использует Sketch. Допустим,
другой дизайнер, Майлз, использует Photoshop (да-да, я знаю, знаю).
Еще один дизайнер, Камала, использует Figma.
Легко объяснить, почему фронтенд-разработчик Джейн, которая в основном использует HTML5 в качестве инструмента проектирования,
может присоединиться к этой команде в качестве дизайнера. Все эти
люди проектируют интерфейсы для пользователей. Все они применяют разные инструменты. Но именно потому, что они все такие разные,
они все в равной степени являются дизайнерами (рис. 7.5).

КЕЙТ

МАЙЛЗ

КАМАЛА

ДЖЕЙН

Рис. 7.5. Разнородные команды позволяют людям проявлять
свою индивидуальность, и это придает работе особую изюминку

162

Что это вы говорите? Все в вашей команде дизайнеров используют
Sketch, потому что работа более эффективна, когда все одинаковые?
Вы правы: в таком случае Джейн будет сложно присоединиться
к команде, потому что она отличается от всех остальных. Вот как
легко устранить разнообразие в команде. Когда вы заставляете или,
что еще хуже, поощряете людей думать и действовать одинаково
и объединяться в группы по этим признакам, это явно исключает
тех, кто не такой, как все (рис. 7.6). Это создает изгоев. Это порождает жесткое и рутинное мышление.
Но если вы сможете сформировать группу с разными навыками,
разным опытом и разными подходами, у вас получится нечто особенное. Это действительно эффективный способ создания команды.

КЕЙТ

МАЙЛЗ

КАМАЛА

ДЖЕЙН

Рис. 7.6. Если заставлять людей ассимилироваться и становиться
одинаковыми, можно легко создать изгоев

163

Сравните это с тем, как мы обычно создаем команды. Мы стараемся, чтобы категории были очень конкретными, а навыки в них —
очень широкими. Например, если вы визуальный дизайнер, вы
должны быть в полной мере визуальным дизайнером, владеющим
всем, что относится к визуальному дизайну.
Это редко срабатывает, потому что люди не вписываются в узкие
рамки. Скотт Бельски (Scott Belsky), основатель онлайн-платформы Behance для демонстрации работ художников и главный директор по продуктам Adobe, описывает это следующим образом:
«Волшебство, которое я наблюдал в командах в течение многих
лет, случается большей частью тогда, когда стек навыков и компетенций расширяется: дизайнер пишет код, разработчик обладает навыками гроус-хакинга1, а продакт-менеджер имеет талант
копирайтера. К сожалению (sic), традиционные оргструктуры
склонны подавлять такое пересечение ролей, вместо того чтобы
использовать его. Но лучшие современные организации адаптируют структуру каждой продуктовой команды под реальных людей
и их перекрывающиеся навыки, которыми им посчастливилось
обладать».
Наверняка у вас будет визуальный дизайнер, который также немного разбирается в UX, но пока не может быть отличным артдиректором. Или фронтенд-разработчик, который не знает
JavaScript, но очень интересуется инструментами деплоя (рис. 7.7).
Вместо того чтобы делать рамки ролей узкими и пытаться заполнять
их широким спектром навыков, поступайте с точностью до наоборот: определите роли широко, а затем наполняйте их конкретными
компетенциями.
Одна из конфигураций, которую я уже рекомендовал, заключается
в том, что каждый сотрудник в команде, который что-то создает,
является либо дизайнером, либо разработчиком.

1

Гроус-хакинг (англ. growth hacking), или «взлом роста», — это методология
в маркетинге, направленная на быстрое и экономичное развитие компаний или стартапов через нестандартные подходы и решения. — Примеч.
ред.

164

ПРОДАКТМЕНЕДЖЕР

КОНТЕНТСТРАТЕГ

ДИЗАЙНЕР
КОПИРАЙТЕР ВЗАИМОДЕЙСТВИЯ

UXДИЗАЙНЕР

БЭКЕНДВИЗУАЛЬНЫЙ ФРОНТЕНДДИЗАЙНЕР РАЗРАБОТЧИК РАЗРАБОТЧИК

АРХИТЕКТОР
БАЗЫ
ДАННЫХ

DEVOPSСПЕЦИАЛИСТ

ПРОДАКТМЕНЕДЖЕР

КОНТЕНТСТРАТЕГ

ДИЗАЙНЕР
КОПИРАЙТЕР ВЗАИМОДЕЙСТВИЯ

UXДИЗАЙНЕР

БЭКЕНДВИЗУАЛЬНЫЙ ФРОНТЕНДДИЗАЙНЕР РАЗРАБОТЧИК РАЗРАБОТЧИК

АРХИТЕКТОР
БАЗЫ
ДАННЫХ

DEVOPSСПЕЦИАЛИСТ

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

Думайте об этом скорее как о диапазоне, чем как о двоичной системе. Сосредоточьтесь на людях, а не на должностях. Представьте
это в виде тепловой карты (рис. 7.8).
zz Кейт — сильный дизайнер пользовательского интерфейса и может

многое продумать самостоятельно в UX. Она даже может немного подправить CSS, чтобы сделать детали более правильными,
если кто-то другой до этого написал код.

165

ДИЗАЙН

РАЗРАБОТКА

КЕЙТ

МАЙЛЗ

ДЖЕЙН

Рис. 7.8. Когда роли достаточно широки, люди могут найти в них свое
собственное место
zz Майлз — своего рода арт-директор старой школы: он любит сам

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

zz Джейн делает бˆольшую часть своего дизайна в браузере и CodePen

с помощью HTML и CSS. Она знает не очень много о написании
JavaScript с нуля, но довольно умело редактирует его и находит
сниппеты в интернете, которые можно вставить и изменить.

Джейн размывает границы между дизайном и разработкой, но поскольку ее навыки больше относятся к дизайну, чем к разработке,
она может называть себя дизайнером. Это ее выбор.
Это гораздо более реалистичная визуализация сильных и слабых
сторон вашей команды.
Это также лишь одна из версий всего спектра. Вместо того чтобы
строить тепловую карту «от проектирования к разработке», вы можете визуализировать процесс выпуска продукта (рис. 7.9), включив
туда, например, планирование, скетчинг, создание, развертывание.
Тогда станет понятно, что это скорее совокупность, чем конкретные
разделы. Планирование плавно переходит в скетчинг, который
переходит в создание.
Возможно, перепрофилирование фронтенд-разработчиков в дизайнеров — это больше, чем ваша организация может вынести в данный момент. Это справедливо! Вот несколько альтернативных

166

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

ПЛАНИРОВАНИЕ

СКЕТЧИНГ

СОЗДАНИЕ

РАЗВЕРТЫВАНИЕ

КЕЙТ

МАЙЛЗ

ДЖЕЙН

Рис. 7.9. Помимо должностных инструкций, существует множество других
способов для определения места сотрудника в команде

Фронтальная часть фронтенда
Фронтенд-дизайнер Брэд Фрост как-то пошутил в эфире подкаста
«ShopTalk Show», посвященного веб-разработке, сказав, что фронтенд-разработку следует разделить на «фронт-часть фронтенда»
и «бэк-часть фронтенда»1, и эти термины, похоже, стали популярны!
Затем он дал им определение, как в совокупности, так и по отдельности:
zz Разработчик «фронт-части фронтенда» определяет внешний вид

и стиль кнопки, а разработчик «бэк-части фронтенда» определяет, что происходит при нажатии этой кнопки.

zz Разработчик «фронт-части фронтенда» — это веб-разработчик,

который сосредоточен на создании структуры, стилей и динамических эффектов с использованием HTML, CSS и JavaScript.

zz Разработчик «бэк-части фронтенда» — это веб-разработчик, ко-

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

1

«334: How to Think like a Front-End Developer with Brad Frost», ShopTalk
Show, October 22, 2018, https://shoptalkshow.com/334/.

167

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

Молоток и долото
Sparkbox — это агентство в Дейтоне, штат Огайо, которое делает
отличные веб-проекты и дизайн-системы. У них есть концепции,
которые называются «молоток» и «долото»1. Заметьте, это не названия должностей, у них все еще есть такие обязанности, как «фронтенд-дизайнер» и «разработчик», но «молоток» и «долото» описывают
то, что они думают о своей работе.
Вот как это объясняют фронтенд-дизайнеры Филипп Застроу (Philip
Zastrow) и Эндрю Спенсер (Andrew Spencer): «“Молоток” создает
общую структуру HTML и CSS, формируя основу макета и внешний
вид компонентов. “Долото” берет работу “молотка”, дорабатывает
ее, полирует и делает более соответствующей первоначальному дизайнерскому замыслу. Это дает возможность заказчику более ясно
видеть прогресс в разработке сайта и его совершенствование на
протяжении всего процесса работы. Он может наблюдать, как его
мечта воплощается в жизнь».

Психологическая безопасность
В 2013 году группа сотрудников отдела Google’s People Operations
(так в Google называют отдел управления персоналом) задалась целью
определить, из чего складывается эффективность команды в Google.
Их гипотеза заключалась в том, что это должно быть что-то вроде
удачного сочетания стажа, навыков, энтузиазма и мотивации.
Но все оказалось совсем не так. Что же действительно было самой
большой предпосылкой успеха лучших команд? Психологическая
безопасность. Команды, в которых люди чувствовали себя в безо­
пасности (то есть знали, что их не уволят, не высмеют и не подвергнут
травле за их идеи, работу и характер), были самыми эффективными.
Изменение рабочего процесса и динамики команды нужно не только для того, чтобы сделать дизайн и разработку лучше и быстрее.
1

Philip Zastrow, «The Hammer and the Chisel», 30 мая 2017 года, https://
sparkbox.com/foundry/the_hammer_and_the_chisel.

168

Работа должна быть более интересной, инновационной и, в конечном счете, приносящей удовлетворение. Это начинается с безопасности, с осознания того, что вы все вместе и поддерживаете друг
друга.
Чтобы начать повышать уровень безопасности в своих командах,
будьте первыми, кто распространит эту безопасность на других.
Многие команды используют agile-ритуал «ежедневных стендапов»,
используя формат обмена информацией о том, что было сделано
вчера, что планируется сделать сегодня и какие препятствия стоят
на пути. Добавьте еще кое-что: на какой риск я пошел вчера? Это
одновременно нормализует тот факт, что принятие рисков является частью работы каждого, а также дает всем равную возможность
поделиться своими успехами и неудачами. Не каждый риск стоит
того, чтобы на него идти, и не каждый риск приводит к успеху. Это
нормально. Покажите всем, что это нормально.
Я редко встречал людей, несогласных с общей идеей поддержки
большей психологической безопасности в своих командах. Но имеет
смысл поговорить о конкретных ситуациях, когда возникают препятствия в работе дизайн-системы. Одна из таких ситуаций, на
которые стоит обратить внимание, — когда люди пытаются освоить
новый навык. Возможно, дизайнер впервые написал несколько строк
кода. Если вы разработчик, вашим первым побуждением может быть
критика этого кода, чтобы показать, как его можно улучшить. Однако будьте осторожны: даже если ваши намерения чисты, критика
на столь раннем этапе может скорее обескуражить дизайнера, чем
воодушевить его, и дать понять, что ему не стоило пробовать что-то
новое. Вместо того чтобы критиковать код, похвалите человека.
Укрепите его уверенность в том, что он способен пробовать что-то
новое, чтобы ему захотелось делать это снова и снова.
То же самое можно сказать и о разработчике, который принял дизайнерское решение, когда раньше не делал ничего подобного.
Вместо того чтобы говорить, что все выглядит еще довольно плохо
(что, скорее всего, так и будет при первой попытке), поддержите
эту попытку. Такого рода поддержка закладывает основу психологической безопасности для ваших коллег, и это сделает ваше сотрудничество для создания работающего программного обеспечения
гораздо более продуктивным.
Если вы менеджер, подавайте пример. Если вы не менеджер, также
подавайте пример. Просто начните это делать. Через несколько недель
вы увидите, как все начнут брать с вас пример и поступать так же.

169

Инженеры экосистемы
Бобры — удивительные существа, не так ли? Они строят плотины,
в основном для защиты, а также для того, чтобы у них была еда
в холодное время года.
Даже если это не входит в их планы, многие другие виды получают
выгоду от строительной деятельности бобров. Дятлы селятся в деревьях, которые бобры подтачивают. Утки и гуси занимают их
старые домики. Созданные ими водно-болотные угодья становятся
домом для цапель, зимородков, лягушек, ящериц, стрекоз, моллюсков, жуков и многих других видов животных.
Доктор Клайв Джонс (Clive Jones) из Cary Institute of Ecosystem
Studies (Института изучения экосистем Кэри) придумал название
для существ, подобных бобрам, которые создают среду обитания
для процветания других видов. Он называет их «инженерами экосистемы».
Разве это не отличное название для людей, которые намеренно или
ненамеренно создают среду обитания для процветания других
людей? Я знаю многих дизайнеров, которые променяли бы изобретение чего-то нового на создание такой среды. Помню, во время собеседования в Facebook много лет назад я спросил одного
очень талантливого дизайнера, чем интересна для него работа
в этой компании. Он ответил: «Возможность выпустить функцию
для ста миллионов пользователей. Нет ничего более захватывающего!»
Инженеры экосистемы заинтересованы в создании платформы —
в буквальном смысле «приподнятой поверхности, на которой могут
стоять люди или предметы». Тридцать лет назад сэр Тим Бернерс-Ли
(Sir Tim Berners-Lee) использовал существующую технологию HTTP
и недавно преобразованную версию SGML под названием HTML,
объединив их в платформу для создания World Wide Web (Всемирной
паутины). Пятнадцать лет назад потребовалось всего шесть месяцев,
чтобы создать начальную версию YouTube, потому что она основывалась на уже существующей веб-платформе.
Если вам нравится создавать платформы, помогающие другим добиваться успеха, тогда команда разработки дизайн-систем может
стать для вас подходящим местом.

170

Трехногая табуретка
В своей статье «Defining Product Design» бывший вице-президент
по дизайну Airbnb Алекс Шляйфер (Alex Schleifer) так описывает
создание хорошего продукта1:
Три элемента определяют продукт: бизнес, код и пиксели.
Дайте каждому из них право голоса при принятии продуктовых решений. С самого начала объедините разработку, продукт
и дизайн.
Команда должна напоминать трехногую табуретку, где каждая
«нога» — это одна из трех ключевых областей, помогающих
создавать продукт. Если это будет сделано изначально, все
направления будут развиваться синхронно и будет сохраняться правильная пропорция по мере масштабирования всей
организации.
Если не применять эти стратегии с самого начала, то в итоге
получится «шаткая табуретка», то есть ненадежный продукт.
Например, это может произойти, если роль дизайнера не была
предусмотрена с самого начала либо была добавлена после
того, как продукт, а также команды разработчиков и продактменеджеров уже успели сформироваться и вырасти. Лучший
способ избежать появления шаткой табуретки (продукта) —
с самого начала строить его на трех ногах.
Дизайн-системы намеренно сочетают дизайн, разработку и продукт
для достижения успеха. Лучшие команды дизайн-систем балансируют между развитием команды и наблюдением за тем, как дизайн,
разработка и продукт работают в организации, чтобы команда
разработки дизайн-системы могла идти в ногу с ними... не отставая,
но и не опережая.
Создавать или даже использовать дизайн-систему поэтапно — это
как собирать табуретку по одной ножке за раз: устойчивой она
становится только в самом конце. Вместо этого совместный рабочий

1

Alex Schleifer, «Defining Product Design: A Dispatch from Airbnb’s Design
Chief», https://review.firstround.com/defining-product-design-a-dispatch-from-airbnbsdesign-chief.

171

процесс всегда позволяет поддерживать баланс «табуретки» на всех
этапах и обеспечивать равномерный рост всех «ножек».

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

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

ВЛАДЕЛЕЦ ПРОДУКТА
ДИЗАЙН-СИСТЕМЫ

СТАРШИЙ
ДИЗАЙНЕР

172

СТАРШИЙ
РАЗРАБОТЧИК

Рис. 7.10. Владелец продукта —
это, как правило, первая роль,
необходимая в команде дизайнсистемы помимо основных ролей
дизайнера и разработчика

Владелец продукта может прийти из разных мест по разным причинам:
zz Первоначальный дизайнер или разработчик в команде может

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

zz Внешний продакт-менеджер может присоединиться к команде

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

zz Внешний продакт-менеджер, имеющий опыт работы в области

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

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

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

«Триада продукта» — это концепция, которая подразумевает взаимодействие и сотрудничество между тремя ключевыми ролями в процессе разработки продукта: продакт-менеджером, дизайнером и разработчиком. — Примеч. ред.

173

ВЛАДЕЛЕЦ ПРОДУКТА
ДИЗАЙН-СИСТЕМЫ

СТАРШИЙ
ДИЗАЙНЕР

СТАРШИЙ
РАЗРАБОТЧИК

МЛАДШИЙ
РАЗРАБОТЧИК

Рис. 7.11. По мере роста
дизайн-системы часто требуются
дополнительные ресурсы

Продюсеры / Менеджеры проектов
На следующем этапе, как правило, возникает потребность в более
оперативном управлении. Эта роль отличается от роли владельца
продукта дизайн-системы, чье внимание сосредоточено на взаимодействии с другими командами и продвижении системы в целом.
По мере роста командам нужен кто-то, кто поможет управлять
работой на детальном уровне. В этой роли обычно выступает продюсер или менеджер проекта (рис. 7.12), который связывает все
отдельные нити воедино, чтобы обеспечить движение в соответствии
с вˆидением владельца продукта. В командах, работающих по agile-

174

методологии, продюсер или менеджер проекта часто является скраммастером, то есть человеком, который организует процессы и ритуалы, такие как планирование спринтов и ежедневные стендапы.
Этот человек также может быть специалистом в области DesignOps.
По словам руководителя DesignOps компании Atlassian Доминика
Уорда (Dominique Ward), DesignOps — это структура, которая обычно
отвечает за то, как устроен сам процесс и как работают дизайнеры.
DesignOps регулирует такие области, как процесс проектирования,
структура и культура команды, наём сотрудников и инструменты
дизайна, которые, помимо прочего, могут включать в себя дизайнсистемы. (См. врезку: «Беседа с Мишель Чин о DesignOps».)

ВЛАДЕЛЕЦ ПРОДУКТА
ДИЗАЙН-СИСТЕМЫ

СТАРШИЙ
ДИЗАЙНЕР

СТАРШИЙ
РАЗРАБОТЧИК

СТАРШИЙ
ПРОДЮСЕР

МЛАДШИЙ
РАЗРАБОТЧИК

Рис. 7.12. По мере роста команды ей понадобится помощь в координации
и организации процессов

175

БЕСЕДА С МИШЕЛЬ ЧИН О DESIGNOPS
Мишель Чин — дизайн-адвокат в Zeroheight, платформе
для документирования дизайн-систем. Она была дизайнером продукта, дизайн-менеджером, DesignOpsменеджером, стратегом и т. п. Я задал ей несколько
вопросов о ее опыте работы с DesignOps и о том, почему это так важно.
Что такое DesignOps?
DesignOps — это специализированные сервисы поддержки, которые помогают команде дизайнеров добиваться наилучших результатов. Если
рассматривать индивидуальных контрибьюторов команды дизайна (например, дизайнеров, исследователей, специалистов по контенту и т. д.)
как профессиональных спортсменов, то DesignOps-специалисты — это
спортивные тренеры, диетологи и т. д. Они обладают специальными навыками, благодаря которым помогают участникам команды сосредоточиться на своем деле и настраивают их на успех.
Каков ваш опыт работы с DesignOps?
Есть DesignOps как роль и DesignOps как работа. Даже когда у меня не
было официальной роли DesignOps, я обычно выполняла какую-то
оперативную работу, чтобы улучшить процессы в команде. В Citrix некоторые побочные проекты DesignOps включали в себя создание чеклистов для обеспечения доступности дизайна, онбординга новых сотрудников или фасилитации воркшопов по формированию культуры
критики в команде.
Когда я начала работать дизайн-менеджером в Citrix, DesignOps как
работа стала более официальной частью моих обязанностей. Однако,
будучи дизайн-менеджерами, мы так много внимания уделяли стратегии
дизайна и управлению людьми, что часто пренебрегали DesignOpsпроектами. Мы пытались как-то внедрить эти инициативы, но всегда
чувствовали, что не уделяем им должного внимания. Как менеджер, вы
хотите поступать правильно по отношению к своей команде, и осознавать,
что вы этого не делаете, не очень приятно.
Я несколько раз посещала саммит DesignOps и всегда задавалась вопросом, могу ли я этим заниматься. Мне нравилось руководить людьми
и направлять их карьерный рост, но я рассматривала DesignOps как
способ помочь еще больше расширить возможности индивидуальных
контрибьюторов. Вместе со своим руководителем я проработала вопрос
о развитии моей карьеры в направлении DesignOps.

176

Мы придумали, как сделать эту систему практикой в нашей команде. Наша
идея заключалась в том, чтобы обязанности по DesignOps, которые обычно возлагались на дизайн-менеджеров, переложить исключительно на
меня. Это дало им больше времени, чтобы заниматься стратегией дизайна и управлением людьми. А я сосредоточилась исключительно на
DesignOps, и мы смогли реализовать несколько инициатив по организации
дизайна с тем вниманием и качеством, которых заслуживала команда.
Мне очень понравился этот переход, и я получала огромное удовольствие
от своей роли. В некотором смысле это было похоже на обретение своего «истинного призвания». В отличие от моей работы по проектированию
корпоративного программного обеспечения, я видела своих «пользователей» (команду дизайнеров) ежедневно. Таким образом, я имела возможность увидеть собственными глазами, какое непосредственное
влияние я оказываю, и понять, когда нам нужно перестроиться. Мне было
приятно осознавать, что я помогаю членам команды добиваться успеха
и делать отличную дизайнерскую работу.
Хотя, конечно, были и трудности. Я была в команде DesignOps одна, а для
многих концепция этой системы была новой. Поэтому, помимо запуска
инициатив и работы над проектами, я много занималась обу­чением, продвижением идей и управлением ожиданиями не только в дизайнерском
подразделении, но и в других отделах. Помимо всего прочего, непросто
быть в команде единственным сотрудником. Поскольку я одна руководила этой инициативой в масштабах всей организации, люди часто думали, что это был мой личный проект. Поэтому некоторые считали это
менее приоритетным, хотя на самом деле проект должен был принести
пользу всем. Но мне все равно даже в одиночку нравилось этим заниматься, и я нашла друзей в Slack-сообществе DesignOps Assembly.
В итоге я отошла от DesignOps, когда присоединилась к Zeroheight. Я больше
сосредоточена на консалтинге, разработке рекомендаций по написанию
текстов и построении сообщества. Но моя роль дизайн-адвоката в значительной степени опирается на мой опыт в DesignOps и дизайн-системах.
Сложно бросить дело, когда уже хорошо получается организовывать работу.
Я постоянно пытаюсь найти способы улучшить процессы в нашей команде.
Как связаны между собой DesignOps и дизайн-системы?
В некоторых отношениях DesignOps связан с дизайн-системами, а в других — нет. С философской точки зрения люди могут рассматривать дизайнсистему как решение, которое помогает индивидуальным контрибьюторам и командам работать более эффективно и сосредоточиться на
решении сложных задач. В этом отношении это похоже на DesignOps.

177

БЕСЕДА С МИШЕЛЬ ЧИН О DESIGNOPS (продолжение)
Но в общем-то, в основе дизайн-системы лежит значительный объем
дизайнерской работы. Если специалист по DesignOps ранее не был дизайнером, ему будет сложно участвовать в создании конкретных частей
дизайн-системы. Но дизайн-системы могут создаваться и без предшествующего опыта в дизайне, кодинге или написании контента.
Это не значит, что дизайн-системы не нуждаются в DesignOps. Совсем
наоборот. Специалисты по DesignOps могут внести свой вклад в дизайнсистемы многими другими способами. Они играют важнейшую роль при
масштабировании самой дизайн-системы и команды разработки дизайнсистемы. Например, их опыт может помочь определить и создать процессы управления, руководить рабочей нагрузкой и бэк­логом команды,
координировать работу с партнерами из других отделов организации
и повышать уровень принятия и внедрения системы.
Чем DesignOps отличается от дизайна или проектирования продукта?
DesignOps больше похож на сервис-дизайн; и то и другое примыкает
к дизайну и проектированию продукта. Поэтому вы часто применяете те
же принципы дизайн-мышления: понимание пользователей, проведение
мозгового штурма при принятии решений, тестирование идей и т. д. Вместо того чтобы работать над функциями или приложениями, вы будете
создавать решения в виде шаблонов, процессов или руководств. Многие
специалисты по DesignOps ранее были дизайнерами. Поэтому я думаю,
что это как быть дизайнером с другими инструментами и задачами.
Какими областями занимается DesignOps?
Когда команда небольшая, это может показаться запутанным, и люди,
занимающиеся DesignOps, чувствуют, что они делают всего поне­многу.
Но есть две основные области DesignOps: TeamOps (операции, связанные
с командой) и ProductOps (операции, связанные с продуктом).
В TeamOps специалисты фокусируются на общеорганизационных инициативах, которые приносят пользу организации дизайна «по горизонтали».
Например, это может быть наём персонала, онбординг новых сотрудников, закупка инструментов, культура команды, обучение и развитие,
стандартизация процессов, дизайн-системы, бюджетирование или согласование визуальных стилей. Они могут помочь во всем, что требует
согласования в масштабах всей организации.
В ProductOps специалисты работают в тесном сотрудничестве с дизайнерами над конкретным продуктом. Поэтому главная задача таких специа­
листов — помочь дизайнерам сосредоточиться на выполнении своей

178

работы, устраняя все помехи и взаимодействуя с представителями других подразделений организации. В некоторых компаниях они могут
также выполнять задачи по управлению проектами.
Какие качества, навыки или опыт делают специалиста по DesignOps
успешным?
Как можно догадаться, DesignOps — это роль, сильно ориентированная
на людей. Можно быть интровертом (как я) и добиваться успеха, но важнейшим необходимым навыком является содействие управлению изменениями. Успех — это не просто создание процесса; это привлечение
людей и их адаптация к этому процессу.
Если говорить о чертах характера, то здесь хорошо себя чувствуют люди,
которые не боятся хаоса. DesignOps-специалисты любят вникать в сложную ситуацию и придумывать, как можно помочь всем прийти к согласию.
Гибкость и легкий характер тоже помогают. Внедрение изменений — это
процесс, и реакция команд на изменения может отличаться от проекта
к проекту. DesignOps-специалистам нужно быть гибкими, терпеливыми
и готовыми к переменам.
Что касается опыта, то наличие знаний в области дизайна полезно для
восприятия контекста, достижения понимания или создания атмосферы
доверия. Но это точно не обязательно! Я встречала фантастических специалистов по DesignOps, которые пришли из других дисциплин, не связанных с дизайном.
Почему DesignOps важен?
В целом DesignOps помогает поддерживать работу дизайн-команды на
высоком уровне. Даже если в компании нет официальной роли DesignOpsспециалиста, кто-то выполняет задачи, связанные с DesignOps, чтобы
­помогать команде добиваться успеха. Даже если менеджеры и индивидуальные контрибьюторы вполне способны самостоятельно закупать программное обеспечение и выполнять другие операционные задачи, эти
задачи отнимают время, вызывают частое переключение контекста и отвлекают их от основных обязанностей. Наличие DesignOps-специалистов
снимает лишнюю нагрузку с менеджеров и индивидуальных контрибьюторов, так что они могут сосредоточиться на своей основной работе.
DesignOps также очень важен для того, чтобы помочь команде расти или
поддерживать консистентность при масштабировании. Когда этим занимается специальная команда, можно быть уверенным в том, что организация сможет эффективно и плавно адаптироваться к изменениям
(например, переходу на новый инструмент).

179

БЕСЕДА С МИШЕЛЬ ЧИН О DESIGNOPS (продолжение)
Что просто в DesignOps?
Самое простое в DesignOps — это доступ к вашим «пользователям». Как
дизайнеру продукта, мне пришлось бы привлекать пользователей для
получения обратной связи, что требует времени и усилий. Но в DesignOps,
если у меня есть вопрос, мне нужна обратная связь или я хочу что-то
опробовать, мне достаточно написать кому-нибудь в Slack или зайти на
собрание команды. Я также могу видеть, как все работает в режиме
реального времени, чтобы определить, что идет хорошо, а что, возможно, нужно подправить.
Что сложно в DesignOps?
Самое сложное — это управление изменениями. Перемены могут быть
тяжелы для людей, даже если они знают, что это к лучшему. При любых
непростых изменениях я стараюсь сделать делать так, чтобы это было
интересно, и находить время, чтобы отпраздновать любые победы на
этом пути. В предыдущей компании мы переходили на несколько различных облачных инструментов. Когда мы впервые мигрировали с одного инструмента на другой, люди были настроены скептически. Я понимаю,
было много работы, людям пришлось изучить совершенно новый инструмент, и даже если это было нужно, никогда не хочется менять привычный
рабочий процесс и образ мышления. Но чтобы сделать все более приятным, мы проводили рабочие сессии, создали доски Miro для добавления GIF-файлов и рецептов коктейлей в зависимости от настроения,
а также доски достижений, где отмечали освоение новых навыков.
В конце мы даже устроили праздничную вечеринку и раздали призы.
При переходе на следующий инструмент все было гораздо проще. К тому
времени DesignOps-команда завоевала доверие, и люди знали, что мы
стараемся сделать все как можно более безболезненным.
Что бы вы посоветовали команде или организации, где еще нет
DesignOps?
Размер организации, занимающейся дизайном, подсказывает, нужен ли
ей специалист или команда по DesignOps. Если ваша команда быстро
растет, я бы настоятельно рекомендовала рассмотреть возможность добавления такой системы. Для начала хорошим соотношением может быть
один DesignOps-специалист на каждого или каждых двух дизайн-менед-

180

жеров. Поскольку не все знают, что такое DesignOps и какую пользу это
приносит, может потребоваться какое-то время, чтобы получить необходимую поддержку. Полезно посеять это семя заранее, чтобы, когда придет время увеличения численности персонала, вопрос не стал ни для
кого неожиданностью.
Я бы также проверила, как обстоят дела у вашей команды менеджеров.
Если они не могут заняться DesignOps-проектами, но хотели бы, это
верный признак того, что пришло время кого-то привлечь. Если вы знаете сотрудника внутри организации, заинтересованного в переходе на
эту роль, то, возможно, будет сложно это обосновать. И дело не в том,
что стейкхолдеры не согласны с необходимостью DesignOps. Их больше
волнует брешь, которая образуется в текущей работе этого сотрудника,
при переходе его на другую роль. Поэтому будьте готовы разработать
соответствующий план.
Что бы вы посоветовали организации, у которой есть DesignOps-команда,
но которая не знает, как ее развивать?
Если у вас большая, зрелая команда DesignOps, то есть много возможностей для ее развития. Когда UX только зарождался, большинство из
нас были специалистами широкого профиля. Но по мере того как все
больше команд осознавали важность UX-дизайна, люди могли специализироваться на каком-то конкретном аспекте, например на информационной архитектуре, дизайне взаимодействия или исследованиях
пользователей. Точно так же люди, работающие в DesignOps, могут
начать специализироваться в ProductOps или TeamOps. Я даже встречала людей, которые были сосредоточены на одном конкретном аспекте TeamOps, например на закупке инструментов, обучении и развитии
или планировании мероприятий.
Когда команда DesignOps становится более зрелой и в ней больше
нет постоянного хаоса, который нужно регулировать, я думаю, что
у DesignOps появляется больше возможностей стать стратегическим
партнером в развитии дизайнерской организации в целом, а также
в обучении и взаимодействии с другими подразделениями. Благодаря
своему опыту в управлении изменениями она может предлагать идеи
и участвовать в разработке стратегий, связанных с масштабными изменениями.

181

Иерархия дизайна и разработки
С ростом спроса на дизайн-систему и внедрением процессов помощь
в разработке становится самой большой потребностью команды.
Появление еще нескольких дизайнеров и разработчиков поможет
распределить нагрузку более равномерно (рис. 7.13). Кроме того,
именно в этот момент обычно появляется большее разнообразие
задач дизайна и разработки. Привлечение в команду разработки
дизайн-системы дизайнеров и разработчиков младшего и среднего
звена для решения простых задач, связанных с компонентами, позволяет высвободить старших дизайнеров и разработчиков для
решения более сложных задач.
ВЛАДЕЛЕЦ ПРОДУКТА
ДИЗАЙН-СИСТЕМЫ

ДИЗАЙНМЕНЕДЖЕР

ТЕХНИЧЕСКИЙ
ДИРЕКТОР

СТАРШИЙ
ДИЗАЙНЕР

СТАРШИЙ
РАЗРАБОТЧИК

МЛАДШИЙ
ДИЗАЙНЕР

МЛАДШИЙ
РАЗРАБОТЧИК

СТАРШИЙ
ПРОДЮСЕР

Рис. 7.13. По мере роста потребности в компонентах потребуется больше
персонала, который поможет удовлетворить спрос, а также иерархия
для его поддержки

182

Больше чем просто дизайн, разработка и продукт
На этом этапе рабочий процесс взаимодействия между командой
разработки дизайн-системы и фича-командами обычно уже налажен,
или, по крайней мере, устанавливается устойчивый ритм. Проектирование и создание компонентов, реализация, применение, внедрение... все это проходит гладко. Команда разработки дизайн-системы
перестает чувствовать, что отстает от потребностей фича-команд,
и впервые видит, что продвигается вперед. Можно выдохнуть. Именно в это время начинают появляться дополнительные активности:
офисные часы, информационные рассылки по дизайн-системам,
Slack-каналы, публичные дорожные карты дизайн-системы и т. д.
Становится все более очевидным, что помимо основной функции по
проектированию и созданию компонентов важны и другие роли: бизнес-анализ, написание контента, контроль качества и т. д. (рис. 7.14).
ВЛАДЕЛЕЦ ПРОДУКТА
ДИЗАЙН-СИСТЕМЫ

ДИЗАЙНМЕНЕДЖЕР

ТЕХНИЧЕСКИЙ
ДИРЕКТОР

СТАРШИЙ
ДИЗАЙНЕР

СТАРШИЙ
РАЗРАБОТЧИК

СТАРШИЙ
АНАЛИТИК

СТАРШИЙ
ПРОДЮСЕР
КОНТЕНТСТРАТЕГ/
РАЙТЕР

МЛАДШИЙ
ДИЗАЙНЕР

QA-СПЕЦИА­ЛИСТ

МЛАДШИЙ
РАЗРАБОТЧИК

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

183

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

Годовой бюджет дизайн-системы
У любого цифрового продукта, которым вы пользуетесь, есть команда из нескольких человек, следящих за тем, чтобы в нем не было
ошибок, а в идеале даже со временем добавляющих полезные функции и возможности. Для того чтобы это происходило, организация,
которая занимается выпуском и поддержкой цифрового продукта,
должна выделять средства на содержание его в рабочем состоянии.
Дизайн-системы — это тоже продукты, и к ним это относится в той
же мере.
Многие команды, начинающие свой путь в области разработки
дизайн-систем, задаются вопросом: какой объем финансирования
им необходимо выделить для поддержания дизайн-системы как
практики? Тем, кто ищет простой ответ, скажу: для поддержания
практики зрелой дизайн-системы требуется от 1 до 1,5 миллиона
долларов в год (рис. 7.15).
Давайте разберемся в нюансах этого вопроса.
Зарплата сотрудников команды — самая большая статья расходов
в дизайн-системе. Поскольку зарплаты сильно варьируются в зависимости от компании и от опыта, на рисунке показаны очень
приблизительные диапазоны. Однако хорошая новость в том, что
у вас в организации, скорее всего (надеюсь), существуют вилки
зарплат в зависимости от уровня, поэтому можно их использовать
для получения цифры, реалистичной для вашей компании.

184

КОМАНДА
ВЛАДЕЛЕЦ ПРОДУКТА

150 000 – 175 000 долл.

ДИЗАЙН-МЕНЕДЖЕР

120 000 – 150 000 долл.

ТЕХНИЧЕСКИЙ ДИРЕКТОР

120 000 – 150 000 долл.

СТАРШИЙ ДИЗАЙНЕР

100 000 – 120 000 долл.

СТАРШИЙ РАЗРАБОТЧИК

100 000 – 120 000 долл.

СТАРШИЙ АНАЛИТИК

100 000 – 120 000 долл.

СТАРШИЙ ПРОДЮСЕР

100 000 – 120 000 долл.

КОНТЕНТ-СТРАТЕГ

750 000 – 100 000 долл.

МЛАДШИЙ ДИЗАЙНЕР

70 000 – 90 000 долл.

МЛАДШИЙ РАЗРАБОТЧИК

70 000 – 90 000 долл.

QA-СПЕЦИАЛИСТ

70 000 – 90 000 долл.

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ И ЛИЦЕНЗИИ

70 000 – 90 000 долл.

ОБУЧЕНИЕ И ПРОФЕССИОНАЛЬНОЕ
РАЗВИТИЕ

30 000 – 50 000 долл.

ИТОГО

1 000 000 – 1 500 000 долл.
(ЕЖЕГОДНО)

Рис. 7.15. Пример годового бюджета для зрелой многопрофильной
команды разработки дизайн-системы

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

185

ства в то, чтобы члены команды обладали высокой квалификацией
и развивались. Сюда входит отправка их на конференции, привлечение коучей и наличие сотен экземпляров этой книги под рукой
(это намек).
Последняя крупная часть бюджета для команды разработки дизайн-системы — лицензии на программное обеспечение. Дизайнсистема — это инвестиция в инструмент, облегчающий работу ­д ругих команд, а команде дизайн-системы нужны свои
собственные инструменты. Сюда входят лицензии на ПО, плагины и другое корпоративное ПО, например программы для проектирования или инструменты отслеживания в области управления проектами.
Это достаточно большие суммы. Как уже говорилось в предыдущей
главе, это одна из причин, по которой попытки получить поддержку дизайн-системы до того, как вы добились каких-то результатов, часто заканчиваются неудачей. Трудно просить миллион долларов, не имея ничего, что можно было бы показать. Но
если вы сможете удачно завершить несколько первых пилотных
проектов и даже измерить экономию времени, вы сможете экстраполировать эти данные и получить относительно реалистичный
прогноз выгод от внедрения дизайн-системы в вашей организации. (В следующей главе я приведу множество примеров того, что
можно отслеживать, и тогда ваши аргументы станут еще более
весомыми.)
Один из моих недавних клиентов провел несколько пилотных проектов и на основе полученных данных спрогнозировал экономию
в 40 миллионов долларов при первоначальных инвестициях в 4 миллиона долларов. Если мои расчеты верны, то это 1000% возврата
инвестиций. Если этого недостаточно, чтобы подогреть ваш энтузиазм, тогда, может быть, вам стоит отложить эту книгу и взять
вместо нее книгу о внутридневной торговле1?

1

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

186

Вопросы для размышления
•

Недооценивают ли в вашей организации фронтенд-разработку? Как можно изменить восприятие ценности фронтенд-разработки?

•

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

ГЛАВА 8

Процесс и фреймворк
Фреймворки важнее процессов

194

Меньше значит больше

198

Принцип «горячей картошки»

198

Изменение инструментов требует изменения поведения

209

Подводные камни метода «горячей картошки»

213

Сопротивление новому рабочему процессу

215

Вопросы для размышления

217

Рекламные объявления 1920-х годов были довольно простыми. Проверенная формула заключалась в описании характеристик продукта, чтобы привлечь внимание потенциального покупателя. Например, в рекламе полностью электрического радио Randolph Radio
Corporation слоган гласил: «Никаких батарей, зарядных устройств,
блоков питания, кислот или жидкостей» (рис. 8.1). В остальной части
рекламы говорилось о «великолепном усилителе», «корпусе из натурального орехового дерева» и «семиламповом радиоприемнике».
Никаких излишеств... и никаких чувств.

Рис. 8.1. Реклама
Randolph Radio
Corporation 1920-х годов

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

190

рые поддерживают эту идею. Все изменилось, когда копирайтер
Билл Бернбах (Bill Bernbach) познакомился с арт-директором Полом
Рэндом (Paul Rand). В их работе иногда оказывалось, что визуал
может быть идеей либо что сам текст может служить визуалом. Рэнд
однажды сказал о работе с Бернбахом: «Я впервые встретил копирайтера, который понимал визуальные идеи и не приходил с желтым
блокнотом и предвзятым представлением о том, как должен выглядеть макет». Вопреки существовавшей в то время разобщенности
в работе, они во время перерывов на обед вместе посещали художественные музеи и галереи и стали хорошими друзьями.
Это товарищество привело к появлению нового подхода к рекламе.
Возьмем, к примеру, рекламу, которую они создали для Lee Hats1
(рис. 8.2). Вместо того чтобы рассказывать о свойствах шляп2,

Рис. 8.2. Новый вид рекламы Lee Hats от Бернбаха и Рэнда

1

«Шляпы от Ли». — Примеч. ред.

2

Надпись «How about this inflation?» — игра слов. Inflation означает «инфляция», а также «надувание» (воздушного шарика). How about this… —
«Как насчет такой (такого)…». — Примеч. ред.

191

реклама прославляла компанию за то, что она нанимает больше
работников и создает новые рабочие места в качестве способа
борьбы с инфляцией. Что касается визуального ряда, то вместо
очевидного изображения шляпы в рекламе был показан воздушный
шар — символ концепции рекламы, который должен был найти отклик у читателя.
Такое мышление навсегда изменило облик рекламы. Возможно, вы
раньше не видели рекламу Lee Hats, но вы, скорее всего, сталкивались со знаменитой рекламой «Lemon» для Volkswagen (рис. 8.3),
созданной много лет спустя в том же агентстве DDB профессиональными последователями и протеже Бернбаха и Рэнда: копирайтером Джулианом Кенигом (Julian Koenig) и арт-директором Хельмутом Кроне (Helmut Krone).

Рис. 8.3. Знаменитая
реклама Volkswagen
1960-х годов

192

Стиль совместной работы Бернбаха и Рэнда привел к рождению
идеи «творческой команды», то есть взаимного уважения и парт­
нерства между арт-директором и копирайтером, что, как правило,
приносило уникальные результаты. Боб Гейдж (Bob Gage), артдиректор, работавший в агентстве DDB, одним из основателей
которого был Бернбах, описал это так:
«Два уважающих друг друга человека сидят в одной комнате
в течение длительного времени и приходят в состояние... свободных ассоциаций, когда упоминание одной идеи приводит
к другой, затем следующей... Арт-директор может предложить
заголовок, а копирайтер — визуальный ряд. Вся реклама задумывается как единое целое в своеобразном пинг-понге
между дисциплинами».
Разве не к этому мы все стремимся в своей работе? Настоящему
сотрудничеству с равными и партнерами? Идеям, которые опираются на другие? Почему для некоторых из нас это кажется таким
далеким? К сожалению, то, как развивалась цифровая индустрия
за последние несколько десятилетий, привело нас к убеждению, что
возросшее разделение обязанностей в наших дисциплинах — это
путь к успеху, хотя на самом деле это очень далеко от истины. Одна
из причин, по которой я с таким энтузиазмом отношусь к дизайнсистемам, заключается в том, что они являются одинаково мощным
и полезным инструментом как для дизайнеров, так и для разработчиков.
Дизайн-системы требуют тесного взаимодействия нескольких дисциплин для выполнения работы, меняющей организацию и отрасль.
Дизайн-системам нужны такие люди, как мы, которые думают
о своем деле иначе, чем многие другие. Нам нужно изменить динамику нашей работы и стать ближе друг к другу, стать партнерами.
Если мы сможем изменить наше мышление и принять другой взгляд
на роли дизайнеров и разработчиков, команда дизайн-системы
может оказаться прототипом и питательной средой для лучшей
Agile-команды в организации.
Давайте начнем с оценки существующего рабочего процесса взаимодействия между дизайнерами и разработчиками и найдем возможности для более тесного сотрудничества.

193

Фреймворки важнее процессов
Процессы, то есть ряд шагов, которые можно повторить для достижения определенной цели, дают ощущение комфорта. Неудивительно, что мы ищем процессы везде, где только можно. К сожалению,
не существует единственно верного процесса создания дизайн-системы. Здесь требуется некоторая доля удачи: везение в отношении
доступности и возможностей членов команды, совпадение сроков
дорожной карты с дедлайнами пилотных команд, наличие нужных
руководителей, которые поддержат проект, и многое другое. Именно это делает работу над дизайн-системой эмерджентной, и именно
это усложняет выстраивание четкого процесса.
Однако там, где процессы оказываются неэффективными, поскольку дело решает удача, фреймворки становятся удобным инструментом, который дает опору для достижения успеха.
В качестве примера можно привести колыбель Ньютона (рис. 8.4).
В этой конструкции шарик на одном конце поднимается и ударяется о соседний, который передает импульс далее следующему.
Когда импульс дойдет до последнего шара, он возвращается и передает импульс обратно, после чего цикл начинается снова. Это процедура, повторяющаяся система, оптимизированная для эффективности, а не для инноваций. Каждый раз она действует одинаково.
Здесь никогда не происходит ничего неожиданного.

Рис. 8.4. Колыбель Ньютона — предсказуемый процесс

А вот футбольное поле (рис. 8.5) — это структура. Каждая игра проводится на одном и том же поле одинаковой длины. Правила всег-

194

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

Рис. 8.5. Футбольное поле — это набор ограничений,
которые создают инновации

Несмотря на логические доводы в пользу обратного, цифровая работа все еще во многом опирается на процессы, поэтому мы должны разобрать этот процесс на составляющие, чтобы перей­ти к более
гибкому фреймворку, который вдохновит всех. Простой поиск
в Google по запросу «digital design process» («процесс цифрового
дизайна») показывает, какие этапы команды и организации используют для достижения успеха (рис. 8.6).
Откуда берутся такого рода картинки? Из двух источников.
Во-первых, от агентств. Поверьте мне, человеку, который руководил
агентством в течение десяти лет и работал с другими агентствами
в течение десяти лет до этого. Агентства заинтересованы в том,
чтобы их процессы выглядели официальными и сложными, чтобы
клиенты думали, что самостоятельно они не смогут выполнить эти
задачи, и платили агентствам за это большие деньги. Доброжелательные клиенты советовали мне (да я и сам регулярно боролся
с этим желанием) сделать график процесса как можно более красивым и официальным, чтобы мы могли обосновать более высокую
цену за наши услуги.

195

Исследование

Прототипирование

Оценка

Тестирование

Дизайн

Дизайн-стратегия

UX / Дизайн взаимодействия

ИССЛЕДОВАТЬ

ОПРЕДЕЛИТЬ

Визуальный дизайн

СПРОЕКТИРОВАТЬ

ПРОАНАЛИЗИРОВАТЬ

РЕАЛИЗОВАТЬ

Итерация
Начать с начала

PREFACE
STUDIOS

ПРОЦЕСС СОЗДАНИЯ ВЕБ-САЙТА

КЛИЕНТ

СТУДИЯ
PREFACE

Первая
встреча

UI дизайн
Фронтендтиповых страниц
Создание UX-дизайн +
и бэкенд-разработка
Отрисовка
первичного вайрфреймы
Вычитка
внутренних
Спецификация контента
страниц Финальная Кликабель- Тестирование
сайта
Вайрфрейм-контента
и валидация
Карта сайта
прототипиродоработка ный прототип
вание
контента
Контентбрифинг

Исследование

Оценка
потребностей

Обратная связь
по оценке
потребностей

Первая
встреча

Схема
контента

Согласование
спецификации сайта

Согласование
UX-дизайна +
вайрфреймов
Согласование UI
Дизайна типовых
страниц

Утверждение
прототипа
Согласование
отрисовок
внутренних
страниц

Проверка
сборки

УЧАСТИЕ
КОНТЕНТ

Миграция
контента +
наполнение
контентом

UI/UXДИЗАЙН

РАЗРАБОТКА

ЗАПУСК

СОПРОВОЖДЕНИЕ

SEOИнструменты
оптимизация аналитики
и CRM
Обучение
WordPress

Проверка перед
релизом

Договор на текущее
обслуживание /
поддержку контента

Исправления
мелких ошибок

Бесплатное
отслеживание
ошибок

Постоянная поддержка
в обучении и консультации

ВАЖНОСТЬ

МЕНЬШЕ

СРЕДНЯЯ
БОЛЬШЕ

БОЛЬШАЯ

Объяснение процедуры разработки веб-сайта

Рис. 8.6. Типичные результаты для «процесса дизайна»

196

Регистрация сайта
в поисковых системах

Запуск

Обучение
WordPress
Согласование
карты сайта

ФАЗА
ЗНАКОМ- ИССЛЕДОСТВО
ВАНИЕ

Кросс-платформенное +
кросс-браузерное
тестирование

© Preface Studios Limited 2020

Второй источник не столь сомнительного качества. В 1970-х годах
директор инженерного отдела TRW Center д-р Уинстон Ройс
(Dr. Winston Royce) описал свой идеальный процесс работы над
системами космических полетов. Его задача, как он заявил в своей
статье, заключалась в том, чтобы стараться довести проекты «до
рабочего состояния, в срок и в пределах запланированных затрат»1.
В своей статье он описал процесс, который со временем стал известен как «водопад» (waterfall) (рис. 8.7).Завершил он статью словами: «Я верю в эту концепцию, но описанная реализация рискованна и чревата неудачей». Какой облом!
СИСТЕМНЫЕ
ТРЕБОВАНИЯ
ТРЕБОВАНИЯ
К ПО
АНАЛИЗ
ПРОЕКТИРОВАНИЕ ПО
КОДИНГ

ТЕСТИРОВАНИЕ

ЭКСПЛУАТАЦИЯ

Рис. 8.7. Оригинальный водопадный процесс от Уинстона Ройса

При реализации таких сложных и эмерджентных инициатив, как
работа над дизайн-системой, трудно рассчитывать на процесс,
который будет работать всегда и при любых условиях. Какой фреймворк можно использовать вместо него?
Мой любимый ответ дан разработчиком Джонатаном Расмуссоном
(Jonathan Rasmusson) в его книге «The Agile Samurai». Первое пред-

1

W. W. Royce, «Managing the Development of Large Software Systems», Труды
IEEE WESCON 26 (1970): 328–388.

197

ложение первой главы книги гласит: «Что нужно сделать, чтобы
каждую неделю поставлять что-то ценное [для клиентов]?»
Вот и всё. Это и есть фреймворк. Каждый раз, когда ваша команда
садится за работу, задавайте этот вопрос. И что бы ни было ответом — делайте это.

Меньше значит больше
Чтобы больше совместно работать над продуктом, всем стоит меньше работать по-старому. Разработчикам нужно тратить меньше
времени на ожидание окончания «дизайн-фазы», прежде чем приступить к разработке. Дизайнерам нужно создавать меньше статичных макетов. Ограничение этих малоэффективных действий
высвобождает время для по-настоящему ценных задач.
Каких именно? Я рад, что вы спросили.

Принцип «горячей картошки»
Я хотел бы предложить новый — и одновременно старый — способ
совместной работы дизайнеров и разработчиков.
Представьте, что вы создаете веб-приложение для каталогизации
мероприятий и путешествий. Вы провели исследование, и у вас
есть гипотезы, которые нужно протестировать с помощью минимально жизнеспособного продукта (MVP — minimum viable product).
Что вам следует сделать дальше, чтобы воплотить этот продукт
в жизнь?
Для тех из вас, кто подумал о Figma, Sketch, Photoshop или какомлибо другом инструменте дизайна: остановитесь и подумайте еще
раз! Теперь вы в новом мире, где ваша основная задача — создавать
в первую очередь работающее программное обеспечение, а не документацию.
Там, где раньше визуальный дизайнер начал бы с создания экрана
в графическом редакторе, теперь появляется возможность для
фронтенд-разработчика приступить к работе.
Разработчик открывает редактор кода и начинает писать код, начиная с версии домашней страницы для авторизованных пользо-

198

вателей. Первое, что нужно сделать, — список задач, которые
должна выполнять эта страница. Разработчик пишет простой текст
в HTML-документе и открывает его в веб-браузере, чтобы посмотреть, что получилось (рис. 8.8).

Рис. 8.8. Обычный текст, отображаемый в браузере, является отличной
первой версией веб-продукта

Первая версия готова! Помните: единственное, что нужно для создания веб-продукта, — это немного HTML. Все остальное — оптимизация. Пора оптимизировать!
Следующие шаги связаны с возведением строительных лесов. Это
причудливый способ сказать, что на эту страницу добавится некоторая структура, как визуальная, так и программная, и это гораздо проще и быстрее сделать в коде, чем в графическом редакторе. Вот как выглядит процесс проектирования и принятия
решений непосредственно в браузере. Каждая задача представлена
отдельным четко различимым блоком (рис. 8.9). Решение о том, где
это будет написано, принимает разработчик: это может быть пустой
файл в локальном редакторе кода, CodePen, инструмент для создания библиотек вроде Fractal или Pattern Lab или что-то еще. Главное — двигаться быстро и итеративно.

199

Рис. 8.9. Добавьте немного простого HTML, чтобы структурировать контент

Один из профессиональных советов: уменьшите окно браузера до
минимальной ширины, обычно около 320 пикселей. Работа на минимально возможном экране является большим преимуществом,
поскольку иерархия страницы выстраивается линейно; пока не
нужно беспокоиться о колонках. Кроме того, вы получаете все
остальные преимущества подхода mobile-first: легко тестировать
с пользователями, среда предпросмотра по умолчанию адаптивна,
а маленький экран помогает сосредоточиться на контенте.
OK, вторая версия готова!
Теперь преобразуйте некоторые из задач, которые должна выполнять
эта страница, в функции и контент, которые фактически выполняют эти задачи. В первом блоке вы увидите: «Orient me so I know
where I am and let me move around if I want to» («Сориентируйте меня,
чтобы я знал, где нахожусь, и позволяйте мне передвигаться, если
я захочу»). Подходящим элементом для выполнения всех этих действий является компонент-шапка, поэтому замените фразу о задаче на одно или два слова, которые описывают фактическое содержимое, которое будет на странице (рис. 8.10).
Третья версия готова!
До сих пор фронтенд-разработчик вел процесс, но дизайнер все это
время внимательно наблюдал. В любой момент они могут проверить

200

работу друг друга. Дизайнер может понять, что «For Your
Consideration» («На рассмотрение») и «Blast from the Past» («Хорошо
забытое старое» ) имеют одинаковый приоритет, поэтому они всегда должны находиться рядом.

Рис. 8.10. Замените описательное содержимое названием компонента,
который выполняет эту работу

Разработчик может быстро внести изменения, добавив немного flexверстки, или grid-верстки, или другой техники верстки, чтобы расположить этот контент рядом друг с другом и таким образом обозначить его равнозначность. И вот четвертая версия готова (рис. 8.11)!
Все это время дизайнер не просто наблюдал. Прелесть метода «горячей картошки» (Hot Potato)1 в том, что можно работать параллельно. Пока разработчик формирует структуру, дизайнер может
начать экспериментировать с общей художественной концепцией.
Это не UI-кит, не библиотека компонентов и не что-то законченное
или официальное. Это то, что мне нравится называть коллажем
элементов (рис. 8.12). Представьте, что вы взяли готовый веб-сайт,
1

Принцип, или метод, «горячей картошки» (Hot Potato) — это цикл чередующихся этапов совместной синхронизации и самостоятельной работы.
Главная идея в том, что задачи не застревают у отдельных людей, а быстро передаются между участниками, как в игре с мячом «горячая картошка». — Примеч. ред.

201

Рис. 8.11. Структурные изменения могут происходить на ранних этапах
работы над программным обеспечением

распечатали все страницы, разрезали их, а затем разложили на
столе. Коллаж элементов — это то же самое, только в обратном
порядке. Он должен быть достаточно проработанным, чтобы все
понимали, к чему клонит дизайнер. Это всего лишь несколько
элементов, но давайте перечислим все, что разработчик мог бы
сказать об этом, основываясь только на этом кратком визуальном
исследовании:
zz Название приложения — Trippin'.
zz Похоже, что для основных частей контента используется стиль

карточки с закругленными углами.

zz Типографская палитра — жирный рубленый шрифт для заголов-

ков и курсив с засечками для некоторых подзаголовков.

zz Цветовая палитра содержит как минимум четыре основных

цвета.

На основе даже того немногого, что сейчас присутствует в этом
коллаже элементов, разработчик может начать настраивать некоторые дизайн-токены, связанные с такими вещами, как типографика и цвета (рис. 8.13). Эти токены могут быть представлены
в виде переменных Sass, JSON-файла, YAML или в любом другом
удобном для него формате.

202

Рис. 8.12. Коллаж
элементов для
   приложения Trippin'

Рис. 8.13. Файл
конфигурации
проектных решений
в коде, за который
может отвечать
дизайнер

Важно то, что этот файл теперь становится зоной ответственности
дизайнера. Да-да, дизайнер: тебе придется хотя бы немного изучить
код или по крайней мере концепции, похожие на код. Ты действительно думал, что мы просто перевернем мир фронтенд-разработчиков с ног на голову, заставив их возглавить работу над дизайном,
а ты сможешь продолжать делать всё по-старому? Подумай еще
раз! Тебе придется освоить кое-что новое, например синтаксис
Sass, и, возможно, даже научиться запускать локальную сборку.
Но это пойдет тебе на пользу. Добро пожаловать в команду! И не
волнуйся: твой коллега-разработчик поможет тебе во всем этом
разобраться.

203

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

Что вам сейчас нужно?
Это моя любимая часть метода «горячей картошки», потому что
именно здесь все начинается. Помните, фронтенд-разработчик возглавляет работу, создавая программное обеспечение. Это означает,
что все служат разработчику. И вот тот вопрос, которым должен
задаваться каждый:
«Дорогой разработчик, что тебе сейчас нужно?»
Это волшебные слова.
Как дизайнер, я постоянно спрашиваю у своих разработчиков, что
им нужно. Моя задача — помогать им. И это задача остальных членов команды тоже. Мы здесь исключительно для того, чтобы помогать разработчикам, потому что именно они ближе всего к работающему программному обеспечению.
На этом этапе разработчик может сказать, что ему нужен текст для
футера. Копирайтер, не могли бы вы подготовить текст для футера?
Если копирайтер занят, продакт-менеджер, не могли бы вы заняться этим вместо него? Если продакт-менеджер занят, тогда кто сейчас свободен и сможет это сделать?

Все на помощь!
В этот момент все силы брошены на помощь. Давайте сделаем паузу и поговорим об этом. Когда в проекте требуется помощь всей
команды? Обычно в конце, в самый ответственный момент. Все
работают вместе, но также испытывают стресс. Если вы сможете
перенести динамику «все на помощь!» на более ранние этапы проекта, например в начало, то вы получите такой же объем сотрудничества и помощи, но без стресса.

Что-то вроде этого
«Разработчик, что еще тебе нужно?» Он может сказать: «Я бы хотел
знать, как будет выглядеть раздел “Coming up” (“Скоро”)».

204

Дизайнер отвечает: «Я подумал, что это может быть набор карточек,
которые можно пролистывать по горизонтали». И он мог бы достать
свой телефон из кармана и открыть App Store: «Вот, что-то вроде
этого» (рис. 8.14). И этого будет достаточно для разработчика, чтобы перейти к созданию прототипа. Вместо того чтобы тратить несколько часов на создание макета, они решили эту проблему за
несколько секунд.

Рис. 8.14. Apple App Store служит идеальным референсом дизайна
и взаимодействия, которые хотелось бы видеть в приложении Trippin'

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

Точечные макеты
— Разработчик, что еще тебе сейчас нужно?
— Я бы хотел узнать, как выглядит шапка, — отвечает он.
На самом деле дизайнер может придумать что-то особенное для
меню «гамбургер», и у него может не быть подходящего референса,

205

потому что его идея уникальна. Тогда «что-то вроде этого» здесь не
сработает. Когда все остальные варианты исчерпаны, наступает
время для макета! Но не для полного, а для такого, который я люблю
называть «точечным макетом», то есть для визуального скетча только одной области на экране, а не всего экрана.
Дизайнер описывает то, что может, словами: «Я думаю, нужно сделать логотип слева и гамбургер справа», чтобы разработчик мог
создать структуру, а затем дизайнер уходит проектировать этот
конкретный элемент в течение следующих 5–10 минут, пока разработчик создает структуру.
На рис. 8.15 показано, как выглядит точечный макет. Это всего
лишь одна область экрана.
Пока дизайнер тратил свои 5–10 минут на создание точечного макета шапки, разработчик погрузился в паттерн прокручиваемых
карточек, которые можно пролистывать (рис. 8.16).

Рис. 8.15. Не делайте макет
целиком, если разработчику
пока это не нужно

Рис. 8.16. На страницу теперь
добавлены паттерны прокрутки

Дизайнер передает точечный макет шапки. Пока разработчик создает шапку, дизайнер может открыть дизайн-токены и начать оттачивать детали карточек, например придать карточке нужную
форму с помощью соответствующей падающей тени (рис. 8.17) или
добавить в нее правильный типографский стиль (рис. 8.18).

206

Рис. 8.17. К прокручиваемым
карточкам добавлены цвета
и закругленные углы

Рис. 8.18. Добавлена правильная
типографика

Пока дизайнер работал над этими деталями, разработчик уже собрал шапку (рис. 8.19).
Пока разработчик вставлял шапку, дизайнер начал настраивать
добавление различных цветов для разных вариантов карточек
(рис. 8.20).

Рис. 8.19. Шапка полностью
собрана

Рис. 8.20. Добавлены карточки
разных цветов

207

Я не буду углубляться в эту тему, но думаю, вы поняли суть. Надеюсь, после нескольких часов такой работы вы увидите, как команда может совместно создать целый экран. И это займет меньше
времени, чем потребовалось бы дизайнеру, чтобы сделать кучу
полных статичных макетов в каком-то дизайнерском инструменте,
а затем все начать с нуля, когда вы перейдете к разработке. При
использовании метода «горячей картошки» вы как можно раньше
переносите всё в браузер — и вдобавок получаете адаптивную рабочую среду, значительно приближаясь к работающему программному продукту, с участием всей команды в одном и том же процессе. Метод «горячей картошки» особенно хорош, когда все
работают над одной и той же задачей одновременно.
Один из лучших способов визуализировать метод «горячей картошки» — совместить синусоиду и перевернутую синусоиду (рис. 8.21).
«Горячая картошка» — это постоянное объединение для синхронизации и разделение для самостоятельной работы. Ключ к этому
процессу — как можно меньше времени проводить врозь. Многие
команды позволяют дизайнерам работать самостоятельно одну или
несколько недель, прежде чем снова собраться вместе для запланированных традиционных дел, таких как дизайн-критика. Хотя это
и полезно, это не сотрудничество, а самостоятельная ответственность дизайнеров, не позволяющая максимально использовать помощь, которую члены команды могут оказать друг другу.
РАБОТАЕТ
САМОСТОЯТЕЛЬНО

РАБОТАЕТ
САМОСТОЯТЕЛЬНО

СОТРУДНИК 1

РАБОТАЮТ
ВМЕСТЕ
РАБОТАЮТ
ВМЕСТЕ

ВРЕМЯ

СОТРУДНИК 2
РАБОТАЕТ
РАБОТАЕТ
САМОСТОЯТЕЛЬНО САМОСТОЯТЕЛЬНО

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

208

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

Изменение инструментов требует
изменения поведения
Каждое живое существо на земле ограничено своим энергетическим
бюджетом.
В своей статье для «Smithsonian Magazine» редактор Джерри Адлер
(Jerry Adler) предполагает, что большинство калорий человек сжигает незаметно для себя, обеспечивая работу сердца, пищеварительной системы и особенно мозга, который перемещает молекулы
внутри и между 100 миллиардами своих клеток1. Человеческое тело
в состоянии покоя отдает примерно пятую часть своей энергии
мозгу, независимо от того, думает ли он о чем-то полезном и думает ли вообще.
В 2009 году профессор биологической антропологии Гарвардского
университета Ричард Рэнгхэм (Richard Wrangham) предложил «The
Cooking Hypothesis» («гипотезу приготовления пищи») — теорию,
согласно которой наш мозг стал значительно больше, чем у наших
предков, благодаря приготовлению пищи. Стало возможным тратить
меньше времени на такие энергозатратные виды деятельности, как
добывание пищи, ее пережевывание и переваривание, поскольку
при приготовлении пищи из нее извлекались дополнительные питательные вещества, и они давали больше энергии, которую можно
было потратить. Более крупный мозг позволил нам обрабатывать
больше информации, создавать более динамичные социальные
группы и приспосаб­ливаться к незнакомой среде обитания.

1

Jerry Adler, «Why Fire Makes Us Human», Smithsonian Magazine, июнь
2013 года, www.smithsonianmag.com/science-nature/why-fire-makes-us-human72989884/?all.

209

И что же сделало это возможным? Огонь. Легенда гласит, что Прометей, сын Титана, взобрался на гору Олимп, чтобы украсть огонь
из мастерской Гефеста (бога огня и обработки металлов) и Афины
(богини мудрости и войны). Прометей подарил огонь людям, что
дало им возможность использовать природу в своих интересах
и в итоге господствовать над природным порядком. С помощью
огня люди могли заботиться о себе, обеспечивая себя пищей и теплом, а также ковать оружие и вести войны. Дар огня Прометея
послужил катализатором быстрого развития цивилизации.
Когда общество получает новые мощные инструменты, жизнь людей
может кардинально измениться к лучшему, если, конечно, они смогут в полной мере встроить эти новые инструменты в свой образ
жизни. Подаренный Прометеем огонь навсегда изменил жизнь
человечества, потому что люди стали его использовать. Они готовили пищу. Они мигрировали с одного места на другое. Когда человек получает новый мощный инструмент, ему нужно что-то изменить в своем поведении, чтобы извлечь из инструмента
максимальную пользу.
Самый большой подводный камень, который я вижу в дизайн-системах, заключается в том, что дизайнеры и разработчики все еще
пытаются работать так, как они работали без дизайн-системы, даже
если теперь она у них есть. Например, если я говорю паре «дизайнер — разработчик»: «Поработайте вместе над главной страницей»,
вот что они делают: дизайнер возвращается к своему столу, чтобы
нарисовать макет главной страницы, а разработчик ждет, пока
дизайнер сделает макет, чтобы затем он мог его собрать. И они искренне верят, что это и есть совместная работа. Но это не так.
Давайте рассмотрим два примера, которые, надеюсь, прояснят,
насколько разнообразной и вдохновляющей может быть совместная
работа.

Будущее совместной работы
В 2017 году несколько дизайнеров и разработчиков из Airbnb провели эксперимент, в ходе которого они классифицировали 150 компонентов в своей дизайн-системе и научили машину распознавать
их1. Они создали прототип, где можно было нарисовать примитив1

Benjamin Wilkins, «Sketching Interfaces», Airbnb, https://airbnb.design/
sketching-interfaces/.

210

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

Рис. 8.22. Эксперимент Airbnb по автоматизацииUI-дизайна с помощью
эскизов на бумаге

В 2020 году дизайнер Джордан Сингер (Jordan Singer) написал
плагин для Figma, который разбирал обычный текст и преобразовывал его в интерфейс. Дизайнер вводил описание в текстовое поле,
например: «Приложение, в котором есть панель навигации с иконкой камеры, заголовком “Фото” и иконкой сообщения. Лента фотографий, где у каждой фотографии есть иконка пользователя, фото,
иконка лайка в виде сердечка и иконка комментария в виде бабла».
И плагин генерировал из этого текста интерфейс, максимально соответствующий описанию (рис. 8.23).
В этих примерах я не могу описать конкретный алгоритм работы.
Там присутствуют такие понятия, как «нейронная сеть» и «машинное обучение», которые пока выше моего понимания, но я предполагаю, что они, вероятно, используют некоторую обработку естественного языка, чтобы как-то связать распознанные слова
и фразы с компонентами в системе.
Самое забавное в этом то, что мы как индустрия гораздо охотнее
способны писать программы, использующие обработку естественного языка или машинное обучение для сборки интерфейсов, чем
использовать те же самые слова в разговоре с дизайнером или раз-

211

работчиком. В обоих примерах предполагается, что система или
хотя бы библиотека компонентов уже существует.

Рис. 8.23. Плагин «Designer» («Дизайнер») Джордана Сингера для Figma
создавал интерфейсы по текстовому промту

Вот как нужно использовать дизайн-систему, если она у вас уже
есть. Дизайнер и разработчик могут встретиться, и дизайнер, вероятно, скажет: «Думаю, что это может быть приложение, которое
имеет панель навигации с иконкой камеры, заголовком “Фото”
и иконкой сообщения. И лента фотографий, на каждой из которых
есть иконка пользователя, фото, иконка лайка в виде сердечка
и иконка комментария в виде бабла».
В предыдущих двух примерах дизайнер «говорит» компьютеру чтото сделать. Когда делаешь работу вместе с другим человеком, а не
с искусственным интеллектом, самое большое преимущество состоит в том, что разработчик может ответить: «О, у меня есть идея
получше!» Именно с таких разговоров начинается отличная совместная работа, потому что в ней участвуют все и все идеи представлены с самого начала.

212

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

Начните работать методом «горячей картошки»,
сидя рядом
Многие команды не против попробовать метод «горячей картошки»,
но не знают, с чего начать. Лучший способ для дизайнеров и разработчиков — сесть рядом и начать работать вместе, как бы банально это ни казалось. Я видел, как многие пары дизайнеров
и разработчиков, которые сотрудничали годами, действительно
начинали понимать, как работает второй партнер, только несколько минут посидев рядом.
Если физически сесть рядом в офисе не получается, попробуйте
видеозвонок, цель которого — понаблюдать за работой друг друга.
Преодолейте первоначальную неловкость от того, что кто-то наблюдает за вашей работой. Постарайтесь рассказать о том, что вы делаете, и ответить на все вопросы вашего партнера, какими бы
простыми они ни казались. Вы можете быть удивлены, насколько
мало знаете о том, как ваши коллеги выполняют свою работу, и как
мало они знают о том, как работаете вы. Но это путь к более тесному и плодотворному сотрудничеству.

«Горячая картошка» для распределенных
и географически разделенных команд
При несовпадении графиков работы или часовых поясов используйте видео. Запишите видео своей работы и отправьте его коллеге.
Затем ваш коллега может заниматься своими задачами, просматривая вашу запись и одновременно делая свою собственную. После
этого продолжайте передавать записи туда и обратно. Такие инструменты, как Loom, Voxer, Marco Polo и другие приложения
с функциями «рации» и внутренней связи, помогают сделать асинхронную совместную работу немного ближе к синхронной.

213

«Горячая картошка» для больших команд
Бытует мнение, что принцип «горячей картошки» подходит для небольшой команды из четырех-шести человек, но он не сработает,
если команда дизайнеров или разработчиков насчитывает сто человек.
И это абсолютно верно: ничего не получится. Математика работает
против вас. Если ваша команда состоит из трех человек, то, для
того чтобы вся команда оставалась на связи, между ними необходимо всего три точки связи. Добавление всего лишь одного человека в команду удваивает количество линий связи между сотрудниками: например, команде из четырех человек, для того чтобы
оставаться на связи, нужно шесть точек связи (рис. 8.24).
Видите, как быстро возрастает сложность? Для команды из 12 человек потребуется 66 линий связи (рис. 8.25).
12 ЧЕЛОВЕК

3 ЧЕЛОВЕКА

4 ЧЕЛОВЕКА

3 ЛИНИИ

6 ЛИНИЙ

Рис. 8.24. Добавление еще одного
человека в команду требует трех
дополнительных соединений

66 ЛИНИЙ
Рис. 8.25. Для поддержания связи
в команде из 12 человек требуется
66 линий связи

Пытаться поддерживать такую ситуацию — неправильное решение
проблемы. Вместо того чтобы думать, как справиться со сложностью
66 линий связи для команды из 12 человек, нужно разделиться на
две команды по шесть человек, которым потребуется всего 30 связей (рис. 8.26). Это то же самое количество людей, но масштаб
работает против вас, если команда больше. Поэтому, вместо того

214

чтобы придумывать, как масштабировать этот процесс, попробуйте уменьшить масштаб, чтобы извлечь максимальную выгоду.
12 ЧЕЛОВЕК
6 ЧЕЛОВЕК

15 ЛИНИЙ

6 ЧЕЛОВЕК

15 ЛИНИЙ

66 ЛИНИЙ
Рис. 8.26. Разделение команды из 12 человек на две команды по шесть
человек упрощает коммуникацию, необходимую для поддержания связи

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

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

215

Потеря идентичности
Вторая причина, по которой я встречаю сопротивление, гораздо
более понятна, хотя многие люди даже не осознают, что это происходит. Обычно я получаю от дизайнеров четыре типа ответов, которые намекают на эту вторую причину:
zz «Такая процедура здесь не сработает».
zz «Зачем нам вообще что-то менять?!»
zz «Что, если мы попробуем этот новый метод только на тех про-

ектах, где у нас есть дополнительное время?»

zz «Даже если это сработает, не похоже, что это что-то улучшит».

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

О чем это говорит? Это признаки потери. Почему у людей возникает это чувство? Потому что они потеряли свою идентичность.
Очень многие дизайнеры связывают свою ценность как профессионалов с результатами, которые они создают, а именно со своими
макетами. И не зря: для дизайнера один из самых приятных моментов — быстро сделать что-то и услышать, как окружающие
говорят, что это потрясающе. Умножьте это на количество лет работы дизайнером, и это станет еще более укоренившимся. И вдруг
я говорю, что нужно поменьше создавать макеты и доверить эту
работу кому-то другому. А чем им теперь заниматься? Кто они? Кем
они могут стать?
Если дизайнеры теряют свою прежнюю идентичность из-за этого
нового подхода, давайте дадим им новую. Одно из моих любимых
упражнений при внедрении нового стиля работы заключается в том,
1

Пять известных из психологии типичных стадий проживания горя, потери, а также значительных жизненных изменений: 1) отрицание,
2) гнев, 3) поиск компромисса (торг), 4) депрессия, 5) принятие. — Примеч. ред.

216

что я прошу дизайнеров подумать о парочке своих последних проектов. Я прошу их перечислить все вещи, которые они хотели бы
сделать в этих проектах, но на которые у них не хватило времени.
Хотя разговор может начаться не сразу, в конце концов я слышу
такие ответы как, например:
zz анимация;
zz изучение нового приложения (Figma, Framer и т. д.);
zz создание кастомных иллюстраций;
zz изучение кода;
zz создание собственного набора иконок;
zz написание более качественной документации;
zz повышение пользовательской доступности.

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

Вопросы для размышления
•

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

•

Как современные технологии, такие как искусственный
интеллект или автоматизация, могут изменить дизайн-систему как процесс в лучшую сторону? А в худшую?

217

ГЛАВА 9

Показатели успеха
дизайн-системы
Определение индивидуальных показателей успеха

223

Фреймворк для измерения успеха

229

Успеха добиваются люди, а не системы

236

Согласование целей для объединения организации

241

Вопросы для размышления

242

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

работки новых функций.

Консистентность измерить немного сложнее, но если вы сможете
это сделать, то скорее всего, станет понятно, что эффект от нее
больше. Например, уменьшение избыточности в CSS, который пишут дизайнеры или разработчики, может свидетельствовать о том,
что ваши цифровые интерфейсы становятся более согласованными.
Вы можете использовать такие инструменты, как CSS Stats1, чтобы
создать контрольный показатель количественных данных о ваших
CSS и отслеживать его с течением времени, по мере того как все
больше команд будут использовать дизайн-систему.
Также можно отслеживать такие вещи, как уменьшение количества жалоб клиентов или сокращение времени выполнения задач
клиентами. Конечно, здесь столько же корреляции, сколько и причинно-следственной связи, но это может быть возможным сиг­налом
того, что клиенты вашей организации получают более качественный пользовательский опыт благодаря более согласованному интерфейсу.
В итоге все эти показатели эффективности и консистентности указывают на одну вещь, святой Грааль успеха дизайн-системы, —
внедрение. Оно происходит, когда фича-команды решают использовать компоненты дизайн-системы для создания интерфейса
своей функции или продукта. Чем больше команд внедряют вашу
дизайн-систему, тем лучше становится опыт ваших клиентов, что,
в свою очередь, лучше для организации.
К сожалению, внедрение сложно отследить. На момент написания
этой книги единственным жизнеспособным инструментом для ана1

«CSS Stats», https://cssstats.com/.

220

лиза дизайн-системы, с которым я имел дело, является Omlet1. Это
инструмент для разработчиков, который измеряет использование
компонентов, анализируя кодовую базу. Большинство прочих инструментов для отслеживания внедрения были созданы индивидуально командами, у которых имелись ресурсы и экспертность для
их создания. Команда Segment (теперь часть Twilio) создала собственный дашборд внедрения2, который точно отслеживает использование компонентов в файлах (рис. 9.1).

Рис. 9.1. Инструмент внедрения дизайн-системы, разработанный
командой Segment

Графический редактор Figma имеет собственную функцию Library
Analytics3 (ранее называвшуюся Design System Analytics4), которая
1

«Omlet», https://omlet.dev/.

2

Jeroen Ransijn, «How We Drove Adoption of Our Design System», Segment
(blog), 16 октября 2018 года, https://segment.com/blog/driving-adoption-of-adesign-system/.

3

«View and Explore Library Analytics», Figma, https://help.figma.com/hc/en-us/
articles/360039238353-View-and-explore-library-analytics.

4

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

221

предназначена исключительно для изучения того, как дизайнеры
используют подключенные компоненты в среде Figma (рис. 9.2).

Рис. 9.2. Инструмент Library Analytics компании Figma показывает, насколько
связаны UI-киты

В своей статье «Measuring Design System Success» («Измерение успеш­
ности дизайн-системы») консультант по дизайн-системам Натан
Кертис описывает четыре тематические области, которые большинство команд разработки дизайн-систем могут использовать для
измерения успешности своей работы1:
zz внедрение продукта;
zz эффективность работы команды разработки дизайн-системы;
1

Nathan Curtis, «Measuring Design System Success», 9 июня 2017 года,
https://medium.com/eightshapes-llc/measuring-design-system-success-d0513a93dd96.

222

zz развитие сообщества;
zz мониторинг улучшения продукта.

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

Определение индивидуальных
показателей успеха
В своей книге «Change by Design»1 директор по дизайну компании
IDEO Тим Браун (Tim Brown) рассуждает о том, как помочь людям
сформулировать свои потребности. Он пишет: «Самое удобное
в поиске ценной информации... это то, что она есть повсюду и бесплатна».
Существует множество различных методик, которые помогут определить индивидуальные показатели успеха.
В книге «How to Make Sense of Any Mess»2 информационный архитектор Эбби Коверт (Abby Covert) предлагает несколько ключевых
вопросов, которые можно задать себе:
zz Почему эту работу нужно выполнить?
zz Почему необходимы изменения?
zz Почему эти изменения важны?
zz Почему это должно волновать других людей?
zz Почему этот вопрос не был решен правильно?
zz Почему в следующий раз все будет иначе?
1

Браун Т., «Дизайн-мышление».

2

Abby Covert, «How to Make Sense of Any Mess» (самостоятельное издание,
2014).

223

ПОКРЫТИЕ ДИЗАЙН-СИСТЕМОЙ
Какую долю любой страницы веб-сайта должны занимать компоненты дизайн-системы?
На рис. 9.3 показана текущая (на момент написания этой книги) версия домашней страницы United Airlines.
Дизайн-система United Airlines называется
Atmos. На рис. 9.4 вы видите ту же домашнюю
страницу United Airlines, где компоненты
дизайн-системы Atmos (выделены салатовым
цветом) отделены от остальных элементов
(выделены розовым цветом).
Эта система не основывается на каком-либо
инсайдерском знании кода или логики бэк­
енда. Она представляет собой исключительно анализ фронтенда HTML. Вы можете провести такую же оценку самостоятельно,
просмотрев HTML этой страницы и отыскав
любой класс, начинающийся с atm- (это «пространство имен» дизайн-системы для всех
компонентов Atmos).
Вот различные виды компонентов, которые
могут находиться вместе на одной странице:
•

компоненты, взятые непосредственно из
дизайн-системы;

•

компоненты, созданные специально для
этой страницы или конкретной функции
на ней;

•

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

•

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

•

компоненты из дизайн-системы, стили
которых были дополнены или переопределены;

224

Рис. 9.3. Домашняя
страница United Airlines,
состоящая из множества
различных компонентов

•

компоненты дизайн-системы, размещенные в контейнерах, не являющихся частью дизайн-системы;

•

кастомные компоненты, вложенные
в контейнеры дизайн-системы.

Какое разнообразие! И это нормально.
Такова реальность дизайна корпоративных продуктов в масштабе. Все это — результат параллельных дорожных карт,
бизнес-приоритетов, ограниченных ресурсов команды разработки дизайн-системы и множества других факторов.
Ряд организаций, похоже, стремятся
к идеалу, согласно которому если дизайнсистема существует, то все в интерфейсе
может и должно быть построено с ее
помощью. Это не только нереалистичная
цель для большинства компаний, но и зачастую токсичный образ мышления, когда все, что меньше чем на 100% охвачено дизайн-системой, в лучшем случае
является ее неправильным использованием, а в худшем — полным провалом.
Используйте принцип Парето, иначе называемый «правило 80/20», чтобы по­
ставить перед командами выполнимую
задачу. Стремитесь к тому, чтобы до
80% любой страницы состояло из компонентов дизайн-системы, и оставьте около
20% страницы для индивидуальной работы. Эти оставшиеся 20% являются тем
местом, где могут случаться изобретения
и инновации. Недавно я услышал историю
от одной команды разработки дизайнсистемы. Они рассказали, что потратили
всего 20% времени спринта на создание
80% страниц с помощью дизайн-системы,
и это позволило высвободить 80% вре-

Рис. 9.4. Домашняя
страница United Airlines,
где показаны компоненты
Atmos и элементы,
не входящие в дизайн-­
систему

225

ПОКРЫТИЕ ДИЗАЙН-СИСТЕМОЙ (продолжение)
мени спринта для работы над 20% кастомной функциональности. Это
было очень вдохновляющим. Это именно тот вид инноваций, который
должны обеспечивать дизайн-системы!
Один нюанс, который следует добавить к правилу 80/20 для верстки
страниц: 80% — это максимальная цель, а не отправная точка. Итак, какой
же должна быть хорошая начальная цель для покрытия дизайн-системой1?
Используйте 10% в качестве отправной точки, планируя со временем
довести их до 80% примерно в течение года или двух. Кстати, главная
страница United Airlines демонстрирует это в действии. Из восьми основных разделов страницы, которые, конечно, несколько упрощены для
целей данного примера, лишь один раздел (12,5%) работает на основе
дизайн-системы.
Но даже 10% иногда слишком амбициозны. В качестве более достижимой цели попробуйте внедрить один компонент одновременно в нескольких фича-командах. Это может показаться незначительным успехом,
но внедрение одного компонента, особенно первого, в кодовую базу,
которая в итоге станет частью рабочей версии продукта, является
огромной работой. Наибольшие усилия требуются для внедрения с нуля
первого компонента, а дальше затрат требуется все меньше и меньше
(рис. 9.5).
Для команд, где тяжело внедрить даже один компонент, хорошим первым
шагом будет внедрение чего угодно. Я часто предлагаю простой блок
салатового цвета, например <div> с шириной, высотой и цветом фона.
Вы можете подумать, что я шучу, но это не так! Как только вы преодолеете препятствие, связанное с импортом чего-то из одной кодовой базы
в другую, вам будет проще создавать новые, более качественные компоненты. Это легче, чем пытаться создать идеальный вариант с первого
раза.

1

226

Design system coverage. Калька с английского, но уже входит в употреб­
ление, по аналогии с покрытием тестами, например. — Примеч. ред.

УСИЛИЯ ПО ВНЕДРЕНИЮ В КОДОВУЮ БАЗУ
0

1

2

3

4

5

6

7+

КОЛИЧЕСТВО КОМПОНЕНТОВ

Рис. 9.5. Сложнее всего внедрить первый компонент

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

227

В книге «Interviewing Users»1 исследователь пользователей Стив
Портигал (Steve Portigal) приводит темы для углубленного изучения:
zz Последовательность действий.
zz Количество (объемы, частотность).
zz Исключения из правил.
zz Полный перечень элементов.
zz Взаимосвязи.
zz Организационная структура.
zz Уточнение деталей.
zz Естественный язык.
zz Эмоциональные сигналы.
zz Процессы.
zz Фактор времени.

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

Метод KJ для расстановки приоритетов
Этнограф Дзиро Кавакита (Jiro Kawakita) стал первооткрывателем
методики составления карт сходства (аффинити-маппинга, или
аффинити-группировки), которая заключается в группировке похожих данных для выявления наиболее важных вещей. Этот метод
назван в честь своего основателя: «метод KJ». Сделайте эту технику
регулярной для выявления организационно значимых показателей
успеха для вашей дизайн-системы:
1. Опросите 30 человек и запишите их мнение о том, что важно для
работы над дизайн-системой. (В качестве альтернативы можно
собрать эти данные, попросив людей дать ответы с помощью
онлайн-опроса.)
1

Steve Portigal, «Interviewing Users», 2-е изд. (Нью-Йорк: Rosenfeld Media,
2023).

228

2. Сгруппируйте идеи, которые кажутся вам связанными, и дайте
каждой группе название.
3. Соберите всех людей, с которыми вы первоначально разговаривали, и представьте им полученные группы приоритетов.
4. Дайте каждому участнику три голоса и попросите выбрать три
главных приоритета.
Если все сделано правильно, вы можете легко понять, как, по мнению каждого, выглядит успех. Общее представление об успехе —
важнейший компонент устойчивой практики работы с дизайн-системой.

Фреймворк для измерения успеха
Существует множество различных фреймворков измерения, с помощью которых можно отслеживать ход работы:
zz определить соглашения об уровне обслуживания (SLA), чтобы

зафиксировать договоренности о приоритетах и зонах ответственности;

zz использовать ключевые показатели эффективности (KPI) и опе-

рационные показатели эффективности (OPI), чтобы сосредоточиться на ключевых целях, которые оказывают наибольшее
влияние на реализацию стратегии организации на высшем
уровне;

zz использовать фреймворк Jobs-to-Be-Done, чтобы определить по-

требности своих клиентов и неустанно фокусироваться на них;

zz с помощью метода Top Tasks Management сделать сложный вы-

бор и сосредоточиться на пяти или менее задачах, которые наиболее важны для ваших клиентов;

zz определить цели и ключевые результаты (OKR) для точного по-

падания в «яблочко».

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

229

Определение успеха с помощью фреймворка OKR
(цели и ключевые результаты)
Венчурный капиталист Джон Доэрр (John Doerr) представил идею
OKR руководству Google в 1999 году, когда компании был всего
один год, и с тех пор они пользуются этой методикой. Впервые
фреймворк OKR был внедрен в Intel в 1970-х годах. Сейчас
OKR применяется для управления бизнесом в таких компаниях,
как Google, LinkedIn, Zynga, Sears, Oracle, Twitter, и множестве
других.
OKR расшифровывается как цели и ключевые результаты (objectives
and key results), и обе эти составляющие необходимы, чтобы команда работала в нужном русле и оставалась в фокусе.
zz Цель — это несколько расплывчатое, амбициозное и при этом

комфортное заявление. Формулировка цели обычно начинается
с глагола.

zz Ключевой результат — это измеряемый показатель, который

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

Цели найти относительно легко. На самом деле все названия групп
приоритетов, созданные по методу KJ (о котором мы говорили ранее), являются идеальными целями, поскольку все они, вероятно,
расплывчаты, амбициозны и в некоторой степени комфортны.
Следующий вопрос, на который необходимо ответить: «Как мы узна­
ем, что движемся вперед?» Шкала оценки прогресса — главная
причина, по которой я предпочитаю фреймворк OKR другим. OKR —
это не просто цели или задачи. Эта методика не о достижении цели,
а о прогрессе. Вы не измеряете свои результаты, вместо этого вы
оцениваете свой прогресс. Ключевые результаты оцениваются по
шкале от 0 до 10 (или от 0 до 100, если вам так больше нравится, —
как и мне). Для любого ключевого результата надо стремиться
к оценке примерно от 60 до 80. Почему не 100? Представьте, что
вы набрали 100. Возникнут вопросы о том, не занижали ли вы намеренно этот ключевой результат, то есть не установили вы тот
уровень результата, который гарантированно должны были достичь.
В связи с этим возникает следующий вопрос: «Может быть, вы недостаточно амбициозны?» Целевой результат в 60–80 баллов озна-

230

чает, что вы, вероятно, делаете что-то достаточно амбициозное
и намерены добиться хороших результатов в этом деле. Это отличный настрой для команды разработки дизайн-системы, да и для
любой другой команды.
Конечно, это палка о двух концах. Если вы получили 0 баллов по
ключевому результату, то скорее всего, вы были чересчур амбициозны, до такой степени, что задача была нереалистичной. Будьте
снисходительны к себе. Фреймворк OKR предоставляет широкое
поле для достижения успеха в работе, что может подтолкнуть вас
к нахождению правильного баланса.
Первые вопросы, которые я часто получаю от команд при создании
ключевых результатов, звучат так: «Откуда берутся цифры? Как
узнать, пытаемся ли мы улучшить или уменьшить показатель на
1%, 42% или 75%?» Признаться, когда вы будете впервые использовать фреймворк OKR, то, скорее всего, будете сильно ошибаться.
И это нормально! Вы делаете это в первый раз! Вы не обязаны быть
идеальными. Помните: самое замечательное во фреймворке OKR
то, что он не о достижении цели, а об измерении прогресса. Подумайте об этом в таком ключе: первое применение фреймворка OKR
будет самым сложным и, возможно, с наихудшими итогами, так
как вы устанавливаете ориентир. В следующий раз (в следующем
квартале) это будет уже не так сложно и не так плохо. Однажды,
через несколько кварталов, применение фреймворка OKR начнет
казаться нормальным и, возможно, даже легким. Другими словами,
смысл ОКR этого квартала в том, чтобы у вас появилась лучшая
отправная точка для ОКR следующего квартала.
Теперь вы поняли, что не обязаны сразу быть идеальными при применении фреймворка OKR. Но ведь нужно с чего-то начинать,
верно? Так что, может быть, стоит просто выбрать случайное число?
Существует раздел психологии, называемый психофизикой, он изу­
чает связь между физическими стимулами и ощущениями и восприятиями, которые они вызывают. В психофизике много говорят
о минимально заметном различии (JND) 1, согласно которому
1

«Минимально заметное различие», или «разностный порог» (Just noticeable
difference (JND)), в психофизике — это минимальное изменение интенсивности стимула (например, яркости света, громкости звука, веса предмета), которое человек способен достоверно обнаружить по сравнению
с исходным стимулом. — Примеч. пер.

231

временнˆые интервалы должны составлять в среднем от 7 до 18%
для периодов длительностью менее 30 секунд. Это означает, что для
того, чтобы кто-то понял, что нечто было быстрее/лучше/медленнее/
хуже, разница должна составлять не менее 7–18%. Учитывая минимально заметное различие, мои первоначальные ключевые результаты обычно ориентированы на изменение (увеличение или
уменьшение) некоторого параметра на 15–20%.

Сделайте фреймворк OKR значимым, запланировав
время для отслеживания результатов
Недостаточно просто сформулировать хорошие показатели OKR.
После того как вы их определили, необходимо сделать их значимыми, выстроив вокруг них практику.
Добавьте три события в свой календарь:
zz Каждую пятницу выделите час на просмотр данных по всем

ключевым результатам и зафиксируйте изменения.

zz Каждый понедельник выделите час на написание отчета для

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

zz В последнюю пятницу каждого месяца напишите сообщение

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

Существует несколько инструментов, позволяющих автоматизировать отслеживание ключевых результатов, но я бы посоветовал вам
первые 2–4 квартала после внедрения фреймворка OKR делать это
вручную. Чем лучше вы будете знакомы с данными, с тем, как они
собираются и как на них можно повлиять, тем лучше сможете рассказать о том, как ваша дизайн-система способствует достижению
общих целей компании.

232

ПОКАЗАТЕЛИ УСПЕХА ДЛЯ ГЕНЕРАЛЬНОЙ КОНФЕРЕНЦИИ ЦЕРКВИ
АДВЕНТИСТОВ СЕДЬМОГО ДНЯ: РЕАЛЬНЫЙ ПРИМЕР
Несколько лет назад мы с командой SuperFriendly работали над проектом
по созданию дизайн-системы для Генеральной конференции Церкви
адвентистов седьмого дня. Церковь адвентистов седьмого дня (АСД) —
это централизованная всемирная организация. У них много подразделений: более 70 000 церквей по всему миру, объединенных в 13 всемирных
подразделений; 63 издательства, предлагающие публикации на более
чем 350 языках; более 7500 начальных школ; 15 медиацентров; помощь
при стихийных бедствиях в 130 странах.
Чтобы лучше понять, что требуется от новой дизайн-системы, мы побеседовали со множеством людей. Мы поговорили с теми, кто создает
веб-сайты для любого из подразделений, от веб-профес­сио­налов, отвечающих за несколько сайтов, до церковных секретарей, впервые осваивающих WordPress, чтобы публиковать еженедельный информационный бюллетень. Мы поговорили с теми, кто посещает сайты АСД как
регулярно, так и нерегулярно. Мы поговорили с людьми, работающими
в Генеральной конференции, о том, что нужно этой организации от новой
дизайн-системы.
Сценарий этих бесед был прост. В общем-то, мы расспрашивали людей
о них самих. Что они делают в рамках своей обычной жизни? Что им
в этом нравится? Что им хотелось бы изменить? Подобные простые вопросы приводили к 30–60 минутам интересных бесед, и эти беседы послужили отличным материалом для определения потребностей, которые
должна была удовлетворить дизайн-система.
Для АСД мы упорядочили все идеи по общим темам и целям. После
применения метода KJ было легко определить, где находится консенсус:
в местах наибольшего скопления стикеров (рис. 9.6).
Три главных приоритета стали нашими целями (objectives):
•

Создать фундаментальную, глубоко укорененную дизайн-систему.

•

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

•

Привлечь сообщество к созданию и внедрению дизайн-системы.

Ниже представлены формулировки первого квартала работы по OKR для
новой дизайн-системы Adventist Living Pattern System (ALPS).

233

ПОКАЗАТЕЛИ УСПЕХА ДЛЯ ГЕНЕРАЛЬНОЙ КОНФЕРЕНЦИИ ЦЕРКВИ
АДВЕНТИСТОВ СЕДЬМОГО ДНЯ: РЕАЛЬНЫЙ ПРИМЕР (продолжение)

Рис. 9.6. В ходе голосования были быстро определены темы,
наиболее и наименее важные для всех

Цель: создать фундаментальную, глубоко укорененную дизайн-систему.
Ключевые результаты:
1. 1800 адвентистских веб-сайтов (15% из 12 000 сайтов в сети адвентистов седьмого дня) явно используют ALPS.
2. 57 веб-сайтов, созданных Генеральной конференцией (50% из 114 вебсайтов, созданных непосредственно Генеральной конференцией), явно
используют ALPS.
3. Первые веб-сайты, созданные на следующих языках с помощью ALPS,
сообщают о нуле проблем при создании:
1) китайский (мандарин);
2) испанский;
3) английский;
4) хинди/урду;
5) арабский;
6) португальский;
7) бенгальский;
8) русский;
9) японский;
10) пенджабский;
11) немецкий;
12) французский.
Цель: обеспечить возможность индивидуального подхода и настройки
под конкретные нужды.

234

Ключевые результаты:
1. Обученный сотрудник может создать сайт с помощью ALPS за два дня
или меньше.
2. 2400 адвентистских сайтов (20% из 12 000 веб-сайтов в сети) используют один из предустановленных вариантов цвета по умолчанию
(рис. 9.7).
Цель: привлечь сообщество к созданию и внедрению дизайн-системы.
Ключевые результаты:
1. Восемнадцать профсоюзов (30% организации) зарегистрировались
в нашей программе обратной связи.
2. Были приняты три идеи, возникшие в сообществе и не включенные
в первоначальный запуск ALPS.
3. ALPS внедрена у трех клиентов, которые не участвовали в первоначальном опросе и в программе обратной связи.

Рис. 9.7. ALPS содержала множество различных цветовых тем,
которые можно было выбирать по желанию

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

235

Успеха добиваются люди, а не системы
Настоящее прозрение в создании значимых показателей успеха
для дизайн-системы наступает тогда, когда вы начинаете думать
о том, как добиваются успеха люди, создающие и использующие
дизайн-систему, а не сама система. Большинство команд разработки дизайн-систем объявляют такие ключевые результаты, как
«15%-ный рост внедрения компонентов форм». А лучше было бы
сформулировать иначе: «Команды, работающие над лендингами
(команды, использующие формы), завершают свою работу на одну
неделю быстрее». Конечно, это две стороны одной медали, но вторая формулировка открывает бесчисленные возможности для
стратегии дизайн-системы, поскольку фокусируется на том, как
люди, ее использующие, добиваются успеха.
Давайте рассмотрим несколько областей, где люди могут пре­успеть.

Поддерживайте мотивацию команды с помощью
автономии, мастерства и цели
В начале своего существования интернет представлял собой смесь
экспериментов: новостные сайты, форумы, комиксы, личное самовыражение и т. д. и т. п. По мере развития интернета все больше
людей и компаний начали вести там свой бизнес. The Interactive
Advertising Bureau (Бюро интерактивной рекламы) сообщило, что
в 2020 году вклад интернета в ВВП США составил 2,45 триллиона
долларов (более 11%)1.Теперь интернет — это Серьезный Бизнес™.
В результате потребность в отслеживании и предоставлении полезных количественных данных, которые помогают бизнесу развиваться, очень высока. Но мне кажется, что маятник качнулся
слишком далеко. Я думаю, что как отрасль мы сейчас склонны
переоценивать количественные показатели. Нам нужны дашборды,
инструменты аналитики и жесткие показатели. Это хорошо. Это
поправка к эпохе, когда мы просто полагались на чутье. Но я думаю,
что эта поправка может быть чрезмерной.

1

«Исследование показало, что интернет-экономика росла в семь раз быстрее, чем вся экономика США, и создала более 7 миллионов рабочих
мест за последние четыре года», 18 октября 2021 года, www.iab.com/news/
study-finds-internet-economy-grew-seven-times-faster/.

236

В своей книге «Drive» Дэниел Пинк (Daniel Pink) описал структуру
того, что движет людьми и что их мотивирует:
zz автономность: желание самостоятельно управлять своей

­жизнью;

zz мастерство: стремление стать лучше в чем-то значимом;
zz цель: желание внести свой вклад и стать частью дела, более ве-

ликого и долговечного, чем мы сами.

Какое отношение это имеет к дизайн-системам? Ну, в общем, не
большое. Но также... огромное! Задача дизайн-системы в том, чтобы позаботиться о повседневном, чтобы каждый в команде мог
иметь определенную автономность, мастерство и цель. Иногда дизайнеры (в особенности дизайнеры) воспринимают саму дизайнсистему как прямую угрозу своей самостоятельности, потому что
система переиспользуемых элементов устраняет момент, который
раньше давал дизайнерам наибольшую автономию, а именно процесс творчества.
Чтобы бороться с этим, составьте список всего, что ваша команда
обещает сделать «если в конце у нее будет дополнительное время».
Ну, вы знаете: это список того, что никогда не делается. Обычно
в него попадают дела, в которых присутствуют слова «индивидуальный», «больше» или «опробовать»: постановка индивидуальной
фотосессии, больше анимации, опробование новых инструментов
и т. д. Убедите свою команду, что их постоянные инвестиции
в успешную дизайн-систему означают, что они смогут выполнить
больше задач из этого списка.

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

США. — Примеч. ред.

237

продуктов, связанных с жизнью и смертью, — низкий поклон.) Всем
остальным стоит быть снисходительнее к себе и своим командам
и уменьшить это давление.
Эффективность — это хорошо, но она не всегда нужна для того,
чтобы сделать больше работы. Иногда эффективность должна позволять больше отдыхать. Вместо того чтобы «делать больше за то
же время», как насчет «делать то же самое за меньшее время и чаще
делать перерывы»?
Измерить облегчение работы еще сложнее, чем эффективность
и консистентность, но его влияние имеет большее значение. Вот
некоторые области, на которые следует обратить внимание, чтобы
понять, действительно ли ваша дизайн-система приносит облегчение в работе:
zz Текучесть кадров. Ниже ли текучесть кадров среди тех, кто

работает над дизайн-системой или использует ее, чем среди тех,
кто не работает и не использует?

zz Удовлетворенность работой. Получают ли люди, работающие

над дизайн-системой или использующие ее, больше удовольствия от своей работы, чем те, кто этого не делает? Анализируя
результаты своего недавнего опроса «Как мы ведем документацию», команда разработчиков инструмента для документирования дизайн-системы zeroheight обнаружила взаимосвязь
между работой с дизайн-системой и удовлетворенностью сотрудников1.

zz Креативность и инновации. Используя стандарты инноваций

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

zz Вовлеченность в работу команды и психологическая безопас­

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

1

Luke Murphy, «What Makes a Happy Design System Team?», zeroheight
(блог), 10 мая 2022 года, https://zeroheight.com/blog/what-makes-a-happy-designsystem-team/.

238

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

блюдается наибольшая текучесть кадров] на 15%.

zz Получить 5 предложений новых функций от команд, которые

использовали дизайн-систему.

zz Увеличить на 15% количество позитивных и одобрительных вы-

сказываний в процессе дизайн-критики.

Инвестируйте как в стабильность,
так и в волатильность
Майкл Лопп (Michael Lopp) был техническим менеджером в Apple,
затем перешел на должность руководителя команды разработки
в Pinterest, а сейчас работает в Slack. За последнее десятилетие
я не нашел ни одной статьи, которая лучше описывала бы процесс
создания продукта, чем его статья «Stables and Volatiles» («Стабильность и волатильность»)1. В ней он размышляет о том, как команды разработчиков могут дойти до первой версии программного
обеспечения и что происходит вскоре после этого. Он говорит:
«Рождение версии 1.0 инициирует разделение команды разработчиков на две группы: стабильные и волатильные». В статье подробно рассказывается о специфических характеристиках обеих
групп. Вкратце:
zz Стабильные, как правило, полагаются на процедуры, чтобы обе-

спечить предсказуемость и измеримость, и известны своей надежностью и спокойствием.

zz Волатильные нечасто создают красивые или стабильные вещи,

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

В завершение статьи Лопп сказал: «Я считаю, что здоровая компания, которая хочет продолжать расти и изобретать, должна в равной
степени инвестировать как в “стабильность”, так и в “волатильность”».
1

Michael Lopp, «Stables and Volatiles», 14 ноября 2012 года, https://randsinrepose.com/archives/stables-and-volatiles/.

239

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

Лучше поощрять, чем наказывать
Чарли Мангер (Charlie Munger) — вице-председатель совета директоров Berkshire Hathaway, финансового конгломерата, контролируемого Уорреном Баффетом. Выступая в университете, он однажды сказал: «Наказания хороши для предотвращения действий,
а стимулы — для их поощрения».
Людей часто просят делать что-то новое под страхом наказания.
Это не имеет смысла. Да, иногда такой подход срабатывает, но
он только запутывает. Командам говорят: «У вас есть год, чтобы
перейти на новый технологический стек». А подтекст таков: «Иначе будут последствия». Верно? Согласно приведенной выше цитате Мангера, угроза наказания скорее заставит людей перестать
что-то делать, чем побудит их начать что-то делать, например
изучать новую технологию или внедрять новый инструмент (дизайн-систему).
Общая мантра для команд дизайн-систем звучит так: «Делай так,
чтобы самое простое решение было самым правильным». В 2016 году
командам дизайнеров и разработчиков United Airlines был дан год
на то, чтобы отказаться от старого технологического стека .NET,
а также привести пользовательский интерфейс в соответствие с ребрендингом. При внедрении новой дизайн-системы Atmos они использовали упомянутый принцип в качестве основного ценностного предложения. Настолько, что первая строка текста на главной
странице справочного сайта гласила (рис. 9.8): «Atmos — самый
простой способ внедрить в ваше приложение новый визуальный
язык United Airlines и технологический стек React».

240

Рис. 9.8. Первая строка справочного сайта Atmos напоминает,
что это самый простой способ сделать все правильно

Согласование целей для объединения
организации
Цель команды разработки дизайн-системы часто не совпадает с целью команды разработчиков продукта. Целью команды дизайн-системы обычно является внедрение дизайн-системы. Цели продуктовой команды представляют собой некую форму ценности для
клиентов.
Когда возникает противоречие между целями команды разработки
дизайн-системы и целями команды разработчиков продукта, кому
из них отдать предпочтение? Есть простой ответ: команде разработчиков продукта. Команда дизайн-системы — это команда по
обслуживанию. Она должна связать свои цели с целями команды
разработчиков продукта. Таким образом, когда продуктовая коман­
да добивается успеха, команда разработки дизайн-системы в результате тоже выигрывает.
В главе 1 «Зачем нужны дизайн-системы» я определил дизайн-­
системы как механизм объединения организации. До сих пор

241

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

Вопросы для размышления
•

Как вы можете сформулировать или переформулировать
OKR вашей команды с четким фокусом и привязкой
к созданию ценности для клиентов в рамках вашей организации?

•

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

•

Кто в вашей команде относится к «стабильным», а кто —
к «волатильным»? Все ли работают над задачами, которые
соответствуют их типу личности?

•

Используете ли вы или ваши руководители стимулы (поощрения) или страх наказания для управления командой?
Пытаетесь ли вы заставить команду перестать работать над
тем, что уже есть, и переключиться на новые вещи?

ГЛАВА 10

Евангелизм никогда
не прекращается
Оформите дизайн-систему как магазин

251

Сделайте дизайн-систему ориентированной
на пользователей

253

Вопросы для размышления

258

В пригороде Филадельфии есть магазин под названием Andy's Brick
Shop. Это магазин, где продаются конструкторы лего, и он является прекрасной аналогией того, каким должен быть идеальный опыт
взаимодействия с дизайн-системой.
На входе в магазин представлена витрина с самыми крутыми и самыми дорогими вещами, которые люди сделали из лего. Они продаются уже в собранном виде. Первыми вы видите истребитель
Y-wing из «Звездных войн» за 360 долларов (рис. 10.1), снегоход из
«Звездных войн» за 368 долларов (рис. 10.2), орбитальный корабль
«Космический шаттл» за 100 долларов (рис. 10.3) и «Тысячелетний
сокол» из «Звездных войн» за 80 долларов (рис. 10.4).

Рис. 10.1. Истребитель Y-wing из
«Звездных войн» за 360 долларов

Рис. 10.2. Снегоход из «Звездных
войн» за 368 долларов

Пройдя самые дорогие конструкторы, вы видите более дешевые,
такие как дома и витрины магазинов за 8 долларов (рис. 10.5).

244

Рис. 10.3. Орбитальный корабль
«Космический шаттл» за 100 долларов

Рис 10.4. Собранный «Тысячелетний
сокол» за 80 долларов

В центре магазина вдоль стен расположены различные «вселенные»,
демонстрирующие собранные наборы, от «Звездных войн» (рис. 10.6)
и «Средиземья» Толкина (рис. 10.7) до комиксов DC и Marvel
(рис. 10.8) и т. д.

Рис. 10.5. Дома и витрины магазинов за 8 долларов

245

Рис. 10.6. Лего-вселенная «Звездные войны»

Рис. 10.7. Лего-вселенная
«Средиземье»

Рис. 10.8. Лего-вселенные DC
и Marvel

По мере продвижения мимо различных «вселенных» становятся
видны коллекции по типам, а не по темам. Здесь вы найдете множество Чубакк (рис. 10.9), Бэтменов (рис. 10.10), C-3PO (рис. 10.11),
Суперменов (рис. 10.12) и многих других героев.

246

Рис. 10.9. Лего-Чубакки

Рис. 10.10. Лего-Бэтмены

Рис. 10.11. Лего-C-3PO

Рис. 10.12. Лего-Супермены

247

В глубине магазина организация пространства становится более
упорядоченной, детали сортируются по типам: шестеренки, соединители, звездочки, детали в форме пламени, кастрюли, колеса
и многое другое (рис. 10.13).
Есть даже целая секция голов (рис. 10.14). Много-много голов
(рис. 10.15).

Рис. 10.13. Лего, упорядоченные по типу

Еще дальше, пройдя через категории деталей, вы обнаружите детали, не объединенные в категории (рис. 10.16). Здесь есть большие
контейнеры со случайными наборами. Некоторые из этих деталей
когда-нибудь будут распределены по категориям, а другие — нет.
И наконец, в самом конце магазина есть мусорная корзина для
поддельных лего (рис. 10.17). Они существуют. Магазин Andy's Brick
Shop признает это и выделяет для них место, в то же время давая
понять, что они отличаются от всего остального, что вы найдете
в магазине.

248

Рис. 10.14. Головы

Рис. 10.15. Множество голов лего

Рис. 10.16. Детали конструктора лего, не объединенные в категории

249

Рис. 10.17. Мусорная корзина для поддельных конструкторов лего

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

Рис. 10.18. Магазин Andy's Brick Shop во всей своей красе

250

Оформите дизайн-систему как магазин
Большинство дизайн-систем могли бы многому поучиться на примере того, как магазин Andy's Brick Shop взаимодействует со своими клиентами и сообществом любителей лего. А на самом деле
многие команды разработки дизайн-систем поступают совершенно
противоположным образом, что идет им во вред.
Большинство популярных и общедоступных справочных сайтов
дизайн-систем в первую очередь рассказывают о наименее привлекательных частях — компонентах. Дело не в том, что компоненты не важны, они имеют решающее значение для дизайн-системы.
Но фокусируясь в первую очередь на компонентах, вы упускаете
возможность презентовать то, что еще более привлекательно для
аудитории дизайнеров, разработчиков и продакт-менеджеров, которые могут использовать эту дизайн-систему. Это та же идея, что
и в маркетинговом лозунге: «Никому не нужно сверло диаметром
полсантиметра. Всем нужно отверстие диаметром полсантиметра».
Самая большая ошибка, которую допускают большинство справочных сайтов общедоступных дизайн-систем, заключается в том, что
они не рассказывают о результатах, которые можно получить при
использовании дизайн-системы (рис. 10.19)1.
Выделение в первую очередь компонентов аналогично ситуации,
как если бы в магазине Andy's Brick Shop поставили у входа контейнер с головами. Это было бы неверным сигналом для покупателей. Они могли бы подумать, что это просто магазин, где покупают
детали, а не такой, где можно погрузиться в любимые вселенные
и расширить возможности игры, дав волю воображению. Конечно,
в этом магазине можно найти детали, но ведь его контекст и возможности гораздо шире.
Первое, что должны увидеть люди, пришедшие на справочный
сайт, — примеры того, что можно сделать с помощью данной дизайн-системы. Это может показаться странным, если вы думаете
о справочном сайте как о сайте технической документации. Так
оно и есть, но лишь отчасти. Не забывайте, что справочный сайт
является еще и маркетинговым.
Сайт Material Design был бы намного мощнее, если бы на нем рассказывалось о том, как согласованные интерфейсы между такими
1

«Atlassian Design System», https://atlassian.design/.

251

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

продуктами, как Gmail, Search и Maps, делают пользователей Google
более продуктивными. Atlassian могла бы заявить о себе, показав
свою дизайн-систему, реализованную в таких инструментах, как
Trello, Jira и Bitbucket, как основную движущую силу, которая помогает командам выполнять свою работу. Если поставить эквивалент
«Тысячелетнего сокола» вашей организации у входа в магазин, туда
будет заходить больше людей (рис. 10.20)1.

1

«UI Introduction», Audi, www.audi.com/ci/en/guides/user-interface/introduction.html.

252

Рис. 10.20. Руководство по пользовательскому интерфейсу Audi — одно
из немногих, где наглядно показаны виды продукции, которые можно
изготовить с его помощью

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

253

Ориентация на конечные результаты также открывает двери для
множества дополнительных возможностей. Astro — это дизайн-система для United States Space Force (Космических сил США), и есть
несколько примеров того, какие продукты могут быть (и уже были)
созданы с помощью этой системы (рис. 10.21).

Рис. 10.21. Дашборд GRM (GRM Dashboard) является одним из примеров
реального продукта, созданного с помощью дизайн-системы Astro

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

254

Рис. 10.22. Разбор продукта GRM Dashboard

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

255

Рис. 10.23. Реальный продукт GRM

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

256

Рис. 10.24. Репозиторий Bitbucket для продукта GRM, где можно увидеть
исходный код.

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

257

Вопросы для размышления
•

Какова ваша версия «Тысячелетнего сокола» в дизайн-­
системе? Как сделать так, чтобы, когда кто-то соприкасается с вашей дизайн-системой, это было продемонстрировано
в первую очередь?

•

Какие части документации, написанной в формате инструкции, вы можете заменить историями, примерами
и шаблонами?

ЗАКЛЮЧЕНИЕ
Однажды я работал с компанией, которая проводила ребрендинг.
Ребрендинг был прост: заменить все желтые кнопки на фиолетовые.
По их оценкам, работа должна была занять около 11 месяцев и обойтись примерно в 10 миллионов долларов.
Эта компания управляла сотнями веб-сайтов и приложений на различных платформах, и каждый из них был создан с нуля отдельной
командой с использованием разных подходов.
Такой ребрендинг должен был бы занять максимум четыре недели:
день на смену цвета в единственном месте и четыре недели на
тестирование и проверку того, что ничего важного не сломалось.
Но у них не было системы, которая связала бы все кнопки с одним
каноническим источником. Вместо этого они потратили столько
времени и денег, сколько требуется для постановки бродвейского шоу.
Прочитав эту книгу, вы получили знания, которые помогут избежать
подобной ситуации в вашей команде или компании. Вот четыре
главных урока, которые, я надеюсь, вы усвоили:
zz Истинная ценность для организации заключается в действитель-

но взаимосвязанных дизайн-системах.

zz Пилотные проекты — это самый простой способ создать дизайн-

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

zz Настоящая совместная работа раскрывает весь потенциал воз-

можностей, которые дает продуманная дизайн-система.

zz Вы сможете хорошо служить людям, если поймете, что ими

движет.

Французский писатель Антуан де Сент-Экзюпери однажды написал
о человеке, который хотел построить судно для путешествий по

259

морю. Этот человек смог собрать группу друзей, чтобы выполнить
все задачи, необходимые для постройки судна. Как? Считается, что
его популярная мотивационная цитата возникла из этой истории:
Если хочешь построить корабль, не собирай людей, чтобы заготовлять лес, распределять работу и отдавать приказы, а научи их тосковать по бескрайнему морю. Тогда они сами построят корабль.
Положение дел в мире становится все тревожнее. Пандемии, экономические спады и массовые сокращения персонала заставляют
людей беспокоиться о своих средствах к существованию, поэтому
самое меньшее, что мы можем сделать для некоторых людей, — это
сделать работу максимально простой и незаметной. Для тех, кто
работает в сфере высоких технологий, создание и поддержание
практики дизайн-систем — отличный способ этого достичь.
Дизайнерам, разработчикам и специалистам по продуктам, а особенно менеджерам и руководителям стоит помнить, что ваша главная задача не в том, чтобы повышать эффективность и добиваться
инновационных результатов, а в том, чтобы заботиться о людях,
с которыми вы работаете. Помогать им. Защищать их. Сделать их
работу легкой. Вдохновлять их. Увлекать их. Бросать им вызов.
Создать для них на работе атмосферу спокойствия.
Я написал эту книгу, чтобы помочь вам глубже понять дизайн-системы, и очень надеюсь, что это получилось. Но какой в этом смысл?
Ведь дизайн-системы — это не «огромное и бесконечное море». Дело
в том, что дизайн-системы — это корабль. Огромное и бесконечное
море — это мир, в котором наша работа может стать интереснее,
безопаснее, веселее и вообще счастливее. Потому что именно это
может сделать мир немного лучше для всех.

БЛАГОДАРНОСТИ
Спасибо тебе, Господи, за все пережитые моменты и испытания,
которые подарили мне мудрость и возможность написать эту книгу.
Спасибо моей жене Эмили и дочерям Сидде и Чарли за всю вашу
поддержку в то время, пока я занимался таким глупым, захватывающим, изматывающим, заряжающим энергией, смелым, дерзким
и унизительным делом, как написание книги.
Спасибо всей команде Rosenfeld Media. Лу Розенфельду (Lou
Rosenfeld): без вас эта книга не состоялась бы. Спасибо, что верили в меня настолько, что позволили мне поднять флаг Розенфельда над моими словами. Я ценю наши схватки, которые сделали
нашу совместную работу и наши отношения еще крепче. Марте
Юстак (Marta Justak): мы легко нашли общий язык во время первой же беседы благодаря нашей общей любви к серийным запятым1. Спасибо, что подтолкнули меня к написанию книги, которую
я хотел написать, и помогли мне избежать слишком большого количества герундиев. Кевину Хоффману (Kevin Hoffman): спасибо,
что познакомил меня с Лу. Без этой связи книга могла не состояться.
Моим критикам, Джесси Гарднеру (Jesse Gardner) и Алексу Райсу
(Alex Rice), спасибо за вдумчивые и превосходные комментарии
к моим черновикам. Многие разделы этой книги существуют благодаря вам, и читатели были избавлены от многих проблем также
благодаря вам. Моему иллюстратору Пудже Джадав (Pooja Jadav):
спасибо, что заставила концепции этой книги зазвучать благодаря
твоим восхитительным иллюстрациям и визуализациям.

1

Серийная запятая (serial comma), также известная как оксфордская, —
запятая, используемая в английском языке перед союзом (обычно and
или or) перед последним пунктом в списке из трех или более элементов. —
Примеч. ред.

261

Спасибо Карлосу Андухару (Carlos Andujar), Энтони Армендарису
(Anthony Armendariz), Натали Армендарис (Natalie Armendariz), Класонде Армстронг-Грэндисон (Clasonda Armstrong-Grandison), Саре
Аспейтиа (Sarah Azpeitia), Эрнестине Уоллс Бенедикт (Ernestine Walls
Benedict), Элизабет Бенкер (Elizabeth Benker), Донте Бенн (Dontae
Benn), Саре Брэй (Sara Bray), Марго Блумштейн (Margot Bloomstein),
Кэти Бойд (Katie Boyd), Джошуа Бланкеншипу (Joshua Blankenship),
Брайану Бломеру (Brian Blomer), Клаудии Бонитатибус (Claudia
Bonitatibus), Дженнифер Брук (Jennifer Brook), Аманде Бак (Amanda
Buck), Трэвису Буркстранду (Travis Burkstrand), Лине Калин (Lina
Calin), Лесли Камачо (Leslie Camacho), Майку Карбоне (Mike Carbone),
Трэвису Кастильо (Travis Castillo), Тому Чензани (Tom Censani),
Джине Хараламбидес (Gina Charalambides), Стефани Чой (Stephanie
Choi), Мэтту Кристиансу (Matt Christians), Джанкарло Чианелли
(Giancarlo Cianelli), Джошу Кларку (Josh Clark), Нику Кохре (Nick
Cochra), Энтони Коланджело (Anthony Colangelo), Мэтту Куку (Matt
Cook), Скотту Куку (Scott Cook), Крису Койеру (Chris Coyier), Джефу
Кроулу (Geof Crowl), Джо Дагандану (Joe Dagandan), Джесси Доусону (Jesse Dawson), Кевину Дилу (Kevin Deal), Лорен Дил (Lauren Deal),
Терезе Дидерих (Theresa Diederich), Марку Дорисону (Mark Dorison),
Оливеру Дюмулену (Oliver Dumoulin), Патрису Эмбри (Patrice Embry),
Гарольду Эмшаймеру (Harold Emsheimer), Джейкобу Эспарзе (Jacob
Esparza), Кэролайн Фэй (Caroline Fay), Хилари Фентон (Hilary Fenton),
Эбби Фретц (Abby Fretz), Виталию Фридману (Vitaly Friedman), Брэду Фросту (Brad Frost), Яну Фросту (Ian Frost), Кэти Фурстосс (Katie
Furstoss), Афине Гарднер (Athena Gardner), Маккенне Грин (McKenna
Green), Кори Гринелтч (Corey Greeneltch), Мелу Гроссу (Mel Gross),
Робу Хэдли (Rob Hadley), Эрике Холл (Erika Hall), Джеймсу Холлу
(James Hall), Джесси Холл (Jessi Hall), Кейт Халворсен (Kate Halvorsen),
Трише Хан (Tricia Han), Бренту Хардингу (Brent Hardinge), Джейсону Хэду (Jason Head), Гейле Хилтон (Gayla Hilton), Нам Хо (Nam Ho),
Винсу Холлерану (Vince Holleran), Дэйву Хоме (Dave Homa), Хейли
Хьюз (Hayley Hughes), Марку Хуоту (Mark Huot), Джону Джексону
(Jon Jackson), Джине Виллависенсио Джоэлсон (Gina Villavicencio
Joelson), Тиму Кадлеку (Tim Kadlec), Джо Карасеку (Joe Karasek),
Бет Кеттелькамп (Beth Kettelkamp), Билли Кили (Billy Kiely), Хантеру Кивету (Hunter Kievet), Джонни Клемеру (Jonny Klemmer), Вольфу Клинкеру (Wolf Klinker), Джейми Косои (Jamie Kosoy), Джорджу
Куртасу (George Kurtas), Джону Лараме (Jon Larama), Эйдану Легаспи (Aidan Legaspi), Ахаве Лейбтаг (Ahava Leibtag), Веронике Лин
(Veronica Lin), Эйприл Лусеро (April Lucero), Джошу Лучано (Josh

262

Luciano), Лизе Марии Мартин (Lisa Maria Martin), Адаму Макклину
(Adam McClean), Нине Мехта (Nina Mehta), Райану Миллеру (Ryan
Miller), Мэри Малви (Mary Mulvey), Робу Нашеду (Rob Nashed), Октавиусу A. Ньюману (Octavius A. Newman), Тедди Ни (Teddy Ni), Эрин
Николл (Erin Nicolle), Крису О'Брайену (Chris O’Brien), Робу Паризи
(Rob Parisi), Джареду Пейну (Jared Payne), Энтони Пино (Anthony
Pino), Ти Джей Питре (TJ Pitre), Кэти Поточни (Katie Potochney),
Азизу Рамосу (Aziz Ramos), Хетал Ратход (Hethal Rathod), Джен Рейер (Jen Reiher), Джо Ринальди (Joe Rinaldi), Ларии Роджерс (LaRia
Rogers), Дариан Роузбрук (Darian Rosebrook), Исааку Руису (Isaac
Ruiz), Дэйву Руперту (Dave Rupert), Грегу Сараульту (Greg Sarault),
Мадлен Сава (Madeleine Sava), Каролине Шейнфельд (Caroline
Scheinfeld), Уоррену Шульхайсу (Warren Schultheis), Тони Сциантарелли (Tony Sciantarelli), Хайме Сене (Jaime Sena), Надин Серрадж
(Nadine Serraj), Тиму Шелбурну (Tim Shelburne), Яну Сиксу (Jan Six),
Афие Смит (Afyia Smith), Ву Сонг (Woo Song), Саре Суэйдан (Sara
Soueidan), Изабель Соуза (Isabel Sousa), Кену Спарксу (Ken Sparks),
Джонатану Старку (Jonathan Stark), Антону Стену (Anton Sten), Ною
Стоуксу (Noah Stokes), Эрику Томпсону (Eric Thompson), Бену Терк
Толубу (Ben Turk Tolub), Эрику Улькену (Eric Ulken), Дилану Валаду
(Dylan Valade), Мэри ван Огтроп (Mary van Ogtrop), Кристал Вителли (Crystal Vitelli), Нилу Фогелю (Neil Vogel), Мэтту Уокеру (Matt
Walker), Мэри Уоррингтон (Mary Warrington), Микайле Уивер (Mikaila
Weaver), Кристоферу Видхолму (Kristopher Widholm), Джереми Вону
(Jeremy Won) и Аманде Вандерли (Amanda Wunderley). Выводы, изложенные в этой книге, являются результатом моей работы с вами.
Я высоко это ценю.

Спасибо великанам дизайн-систем, у которых я многому научился,
и чьи достижения легли в основу моей работы: Джине Энн (Jina
Anne), Майку Апарисио (Mike Aparicio), Матье Бадимону (Mathieu
Badimon), Дэнни Бэнксу (Danny Banks), Джоуи Бэнксу (Joey Banks),
Энди Белл (Andy Bell), Майе Бенари (Maya Benari), Линзи Берри
(Linzi Berry), Демиану Борбе (Demian Borba), Гарту Брейтвейту (Garth
Braithwaite), Бену Каллахану (Ben Callahan), Мэй Капоцци (Mae
Capozzi), Эндрю Коулдвеллу (Andrew Couldwell), Натану Кертису
(Nathan Curtis), Анне Дебенхэм (Anna Debenham), Каэлиг ДелумоПриджент (Kaelig Deloumeau-Prigent), Натали Даун (Natalie Downe),
Саре Драснер (Sarah Drasner), Дэну Идену (Dan Eden), Ясмин Эвджен
(Yasmine Evjen), Дереку Фезерстоуну (Derek Featherstone), Саре Фе-

263

дерман (Sarah Federman), Джулс Форрест (Jules Forrest), Жаки Фрей
(Jacqui Frey), Кэтрин Гонсалес (Kathryn Gonzalez), Майе Хэмптон
(Maya Hampton), Келли Харроп (Kelly Harrop), Анри Гельветике (Henri
Helvetica), Эми Юп (Amy Hupe), Кайлу Хайамсу (Kyle Hyams), Ааюш
Айер (Aayush Iyer), Шарлотте Джексон (Charlotte Jackson), Ише
Касливал (Isha Kasliwal), Джоанне Киртли (Joanna Kirtley), Алле
Холматовой (Alla Kholmatova), Дэрилу Куперсмиту (Daryl Koopersmith),
Инайли де Леон (Inayaili de León), Лорен Лопрет (Lauren LoPrete),
Эдди Лу (Eddie Lou), Татьяне Мак (Tatiana Mac), Руне Мадсен (Rune
Madsen), Майклу Мангаларди (Michael Mangialardi), Итану Маркотте (Ethan Marcotte), Айлин Мари (Aylin Marie), Джоно Малланику
(Jono Mallanyk), Мине Маркхэм (Mina Markham), Шону Макинтайру
(Sean McIntyre), Карен Макгрейн (Karen McGrane), Донелле Медоуз
(Donella Meadows), Диане Маунтер (Diana Mounter), Адекунле Одуйе
(Adekunle Oduye), Хизер Палмер (Heather Palmer), Есении Перес-Круз
(Yesenia Perez-Cruz), Хейдону Пикерингу (Heydon Pickering), Стефани Рьюис (Stephanie Rewis), Майклу Риддерингу (Michael Riddering),
Наталье Шелбурн (Natalya Shelburne), Алекс Скугаревской (Alex
Skougarevskaya), Мэтту Д. Смиту (Matt D. Smith), Стефани Стимак
(Stephanie Stimac), Рою Стэнфилду (Roy Stanfield), Марко Суарезу
(Marco Suarez), Мириам Сюзанн (Miriam Suzanne), Кэти СайлорМиллер (Katie Sylor-Miller), Донне Витан (Donna Vitan), Тренту Уолтону (Trent Walton), Киму Уильямсу (Kim Williams), Дженни Йип
(Jennie Yip) и многим другим.

Дорогой читатель,
большое спасибо за покупку этой книги. За ней и за каждым продуктом,
который мы создаем в Rosenfeld Media, стоит своя история.
С начала 1990-х годов я являюсь консультантом по пользовательскому
опыту, ведущим конференций, преподавателем семинаров и автором.
(Вероятно, я наиболее известен как автор книги «Information Architecture
for the Web and Beyond».) Во всех этих сферах меня постоянно разочаровывают упущенные возможности применения принципов и практик UX.
Я основал компанию Rosenfeld Media в 2005 году с целью выпуска книг,
дизайн и разработка которых показывали бы, что издательство может
практиковать то, что проповедует. С тех пор мы расширились и стали
проводить ведущие в отрасли конференции и семинары. Во всех случаях UX помогал нам создавать более качественные и успешные продукты,
как и следовало ожидать. Мы каждый день практикуем то, что проповедуем: от анализа результатов исследований пользователей для разработки дизайна наших книг и программ конференций до тесного сотрудничества с нашими докладчиками на конференциях и глубокой
заботы об обслуживании клиентов.
Вы можете посетить сайт rosenfeldmedia.com, чтобы узнать больше о наших конференциях, семинарах, бесплатных сообществах и других замечательных ресурсах, которые мы создали для вас. И присылайте свои
идеи, предложения и пожелания мне на почту: louis@rosenfeldmedia.com.
Я буду рад узнать ваше мнение и надеюсь, что книга вам понравится!

Лу Розенфельд,
издатель

ОБ АВТОРЕ
Дэн Молл — муж, отец, учитель, креативный директор, дизайнер, основатель
компаний и предприниматель из Филадельфии. Он является руководителем
Design System University (Университет
дизайн-систем), где создает, собирает
и курирует учебную программу, контент
и сообщество, чтобы помочь корпоративным командам разрабатывать дизайн
в масштабе. Ранее Дэн более десяти лет
руководил консалтинговой компанией
SuperFriendly, специализирующейся на дизайн-системах. Дэн пишет о дизайн-системах, процессах, лидерстве и других вопросах
на своем сайте danmall.com и в своей еженедельной рассылке. Когда
он не проводит время с семьей и друзьями или не занимается дизайном, Дэн фотографирует пейзажи, коллекционирует кроссовки
и два-три раза в неделю неумело играет в баскетбол.

Дэн Молл
Дизайн в масштабе. Создание устойчивой дизайн-системы
Серия «Для профессионалов»

Перевел с английского А. Ларин
Руководитель дивизиона
Ю. Сергиенко
Руководитель проекта
Н. Михеева
Ведущий редактор
Е. Строганова
Научный редактор
Е. Кучина
Литературный редактор
Н. Егорова
Художественный редактор
В. Мостипан
Корректоры
Н. Викторова, М. Котова
Верстка
Л. Егорова
Изготовлено в России. Изготовитель: ООО «Прогресс книга».
Место нахождения и фактический адрес: 194044, Россия, г. Санкт-Петербург,
Б. Сампсониевский пр., д. 29А, пом. 52. Тел.: +78127037373.
Дата изготовления: 08.2025. Наименование: книжная продукция.
Срок годности: не ограничен.
Налоговая льгота — общероссийский классификатор продукции ОК 034-2014,
58.11.12 — Книги печатные профессиональные, технические и научные.
Импортер в Беларусь: ООО «ПИТЕР М», 220020, РБ, г. Минск,
ул. Тимирязева, д. 121/3, к. 214, тел./факс: 208 80 01.
Подписано в печать 30.07.25. Формат 70х100/16. Бумага офсетная.
Усл. п. л. 21,930. Тираж 700. Заказ 0000.

Комьюнити рецензентов
и переводчиков ИТ-литературы

Миссия участников клуба — обеспечить
высокое качество профессиональной
переводной литературы в России.
«Книжные дебагеры» проверяют
корректность терминологии и подписей
на схемах и иллюстрациях, чтобы сделать
книги более понятными русскоязычному
читателю. Стать участником Read IT Club
может любой ИТ-специалист, готовый
поделиться опытом с сообществом.

присоединиться к нам

Майкл Дж. Меттс, Энди Уэлфл
ЗДЕСЬ ДОЛЖЕН БЫТЬ ТЕКСТ.
ПРОФЕССИОНАЛЬНЫЙ
UX-РАЙТИНГ

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

КУПИТЬ

Пол Макфедрис
ВЕБ-ДИЗАЙН С НУЛЯ:
HTML + CSS НА ПРАКТИКЕ

2-е издание

Если вы умеете пользоваться браузером, то сможете создать и сайт! Второе издание книги «Веб-дизайн с нуля» представляет собой наглядное
пошаговое руководство с описанием простых и увлекательных проектов.
Благодаря ему вы освоите HTML, CSS и другие важные веб-технологии.
С помощью уникальной онлайн-песочницы, созданной специально
для книги, вы с нуля создадите лендинг, фотогалерею, сайт-портфолио
и многое другое, даже если у вас совсем нет опыта веб-дизайна.
В книге используется творческий, визуальный подход и понятно объясняются компоненты, концепции и действия, необходимые для создания
веб-страниц. Оттачивая каждый новый навык в онлайн-песочнице, вы
станете уверенным веб-дизайнером. Проработав множество небольших
проектов, вы на практике изучите все возможные темы веб-дизайна,
начиная с основ верстки веб-страниц и заканчивая новыми тегами
и функциями, такими как Flexbox и CSS Grid, — и все это с уверенной
поддержкой автора книги Пола Макфедриса.

КУПИТЬ

Сьюзан Уэйншенк
100 ГЛАВНЫХ ПРИНЦИПОВ
ДИЗАЙНА

2-е издание

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

КУПИТЬ

Федор Шкляров
ПОРТФОЛИО ПРОДУКТОВОГО
ДИЗАЙНЕРА. FINAL FINAL

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

КУПИТЬ