Понимание систем дизайна и шаблонов

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

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

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

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

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

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

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

Языки дизайна целостны

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

Чтобы понять сложную систему, важно думать о языке дизайна целостно :

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

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

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

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

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

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

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

Общие вопросы для «дизайна» системного мышления

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

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

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

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

О чем я должен думать при проектировании в дизайн-системе?

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

Если предварительно задан цвет #1f9efc , а дизайнер делает его #1b3e9b, не посоветовавшись предварительно с другими дизайнерами, использующими ту же библиотеку шаблонов, это может вызвать системную ошибку.

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

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

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

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

Нажмите, чтобы увидеть полноразмерное изображение.

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

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

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

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

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

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

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

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

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

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

Вот несколько шагов, которые следует учитывать при размышлении о том, как сломать или изменить шаблон проектирования:

1. Обеспечение контроля качества и непрерывности

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

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

   Спроси себя:

   • Является ли нарушение шаблона единственным способом решить мою проблему?
   • Как повлияют на другие команды, если я нарушу этот шаблон?
   • Что произойдет с библиотекой шаблонов, если я сломаю этот шаблон?

2. Общайтесь с соавторами

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

   Спроси себя:

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

3. Понимание возможностей внешнего интерфейса

   Узнайте, что возможно для интерфейсной реализации. Если изменение представляет собой просто обновление свойств HTML/CSS/JavaScript, оно обычно не требует нарушения шаблона или создания чего-то совершенно нового.

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

   Спроси себя:

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

4. Подтвердить решение

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

   Если внешние компоненты привязаны к метрикам, быстрое A/B-тестирование поможет с проверкой. Если нет, отлично сработает проведение юзабилити-тестов.

   Спроси себя:

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

Та же работа, другое мышление

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

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

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

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

• • •

Дальнейшее чтение в блоге Toptal Design:

• Как создать руководство по стилю эскиза, библиотеку и набор пользовательского интерфейса
• Формулировки задач проектирования — что это такое и как их формулировать
• Используйте свое вдохновение — руководство по мудбордам
• Совместное проектирование — руководство по успешному проектированию корпоративных продуктов
• Дизайн будущего: инструменты и продукты, которые нас ждут