Подборка книг о практике создания модульных дизайн-систем

Составлена руководителем портальной дизайн-команды Mail.Ru Group Юрием Ветровым.

Мы строим свою дизайн-систему Paradigm с 2012 года. Но такого лютого взрыва интереса к теме с уймой новых примеров и публикаций, как в последние пару лет, ещё не было. В прошлом году наконец-то вышла книга Брэда Фроста (Brad Frost) "Atomic Design", и про дизайн-системы говорят вообще все.

Правда, большинство статей — бесконечное пережёвывание теории модульного дизайна, про практику внедрения почти никто, кроме Натана Кёртиса (Nathan Curtis), не пишет.

Кроме того, хотя заслуга Брэда в популяризации идеи модульного дизайна неоценима, но и сам подход, и метафора атомарности или молекулярности существовала до него. Кёртис пишет, что ещё Dell в середине 1990-х годов делала компонентную систему с такой же терминологией, а в современный обиход atomic design ввёл Джереми Кейт (Jeremy Keith) в районе 2011 года.

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

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

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

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

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

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

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

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

Из свежего есть ещё книга Аллы Холматовой (Alla Kholmatova) — "Design Systems" (2017) и электронные книги вроде UXPin — "Creating a Design System: The 100-Point Process Checklist" (2017).

В середине 2000-х годов вышла пачка книг про интерфейсные паттерны от Дженифер Тидвел (Jennifer Tidwell), Билла Скотта (Bill Scott), Терезы Нэйл (Theresa Neil), Эрин Мэлоун и других. Почитать любую из них полезно, но в целом они не очень актуальны — концепция современных дизайн-систем ушла далеко вперёд (кстати, Натан Кёртис описал своё понимание разницы между паттернами и компонентами).

Классическая книга Эрика Гаммы (Erich Gamma) — "Design Patterns" (1994) про паттерны в программировании интересна своим подходом к структурированию, но в остальном нужно читать только с изыскательской точки зрения.

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

На первой иллюстрации в этом материале — самая полная хронология от Эрин Мэлоун, которая занималась легендарной библиотекой паттернов Yahoo. Пока не добрался разве что до Мики Годболт (Micah Godbolt) — "Frontend Architecture for Design Systems" (2016).

Книг и статей много (есть ещё один список), но если вы не такой ботан, как я — на сегодня достаточно прочитать только "Atomic Design" от Брэда Фроста и "Design Systems Handbook" от InVision в качестве теории и подписаться на Натана Кёртиса для практики (все ждут свежую книгу от него). Ну и если вы не устали от моих отсылок на сайт styleguides.io, прошерстите всё, что там есть.

В группе «Дайджест продуктового дизайна» есть ветка со свежими ссылками и статьями на тему — тоже отличный вариант следить за свежими вещами.

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

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

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

Но тогда речь шла о физических продуктах и объектах, которые стоят на полке в магазине (или сама сеть магазинов), а мы-то с вами работаем с цифровыми продуктами, где макет ничего не гарантирует и много раз меняется перед запуском на пользователей. Так что работать надо с основным материалом этой среды ― кодом.

#дизайн #библиотека #инструменты