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

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

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

Дальнейшее чтение на SmashingMag:

• Как сделать эффективное руководство по стилю
• Углубленный обзор инструментов руководства по стилю жизни
• Автоматизация разработки на основе руководства по стилю
• Бесплатный набор иконок для писателей и редакторов

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

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

Модульный дизайн заключается в разбиении проекта на мелкие части (модули), создании их независимо, а затем объединении их в более крупную систему. Если мы посмотрим вокруг себя, то обнаружим множество примеров модульной конструкции: автомобили, компьютеры и мебель — все они модульные. Благодаря своей модульности части этих систем можно заменять, добавлять, удалять и переставлять. Это очень удобно для потребителей, поскольку они могут настроить систему в соответствии со своими потребностями . Хотите люк, мотор помощнее, кожаные сиденья? Ты получил это! Модульная конструкция автомобилей позволяет выполнять такие настройки и многое другое.

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

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

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

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

Примеры модульной конструкции

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

Является ли это однородным?

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

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

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

Модульность разработки руководства по стилю

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

(Что делать, если руководства по стилю нет? Не волнуйтесь! В следующем разделе я покажу вам, как создавать модульный дизайн, даже если вы не используете руководство по стилю.)

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

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

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

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

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

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

Модульное проектирование

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

Но держите оружие! Это еще не модули. Чтобы добраться туда, нам нужно определить элементы пользовательского интерфейса, которые постоянно присутствуют в потоке, например:

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

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

• Стили:

• цвета, используемые для обозначения:

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

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

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

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

• Шаблоны взаимодействия:

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

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

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

1. Мы начинаем с атомов , которые являются самыми маленькими модулями в системе (в нашем примере это кнопки, типографика и иконография).
2. Модули усложняются, объединяясь в молекулы , которые обеспечивают больше функциональности (в нашем примере это индикаторы шагов оформления заказа и модуль сопутствующих товаров).
3. Затем есть организмы , представляющие собой молекулы, сгруппированные вместе в приложении (в нашем примере это заголовок приложения и различные формы).
4. Оставляя аналогию с химией, следующий уровень — это шаблоны , предопределенные структуры, в которые помещаются организмы.
5. Наконец, есть страницы , которые являются экземплярами шаблонов.

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

Использование руководства по стилю жизни

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

Базовый уровень для работы

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

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

Документация проектных решений

Знания, которые были приобретены для решения конкретной проблемы UI или UX, могут быть переданы для дальнейшего использования.

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

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

Простота общения

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

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

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

• «Углубленный обзор инструментов руководства по стилю жизни», Роберт Харитонов, Smashing Magazine
• «Обзор генераторов библиотек шаблонов», Дэвид Хунд, GitHub.
• «Обзор генераторов рекомендаций по стилю», Сьюзан Робертсон, A List Apart

Не доводите до крайности!

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

Руководство по стилю не заменяет дизайнерскую работу

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

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

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

Не следуйте шаблонам до крайности

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

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

Не упускайте из виду итерацию дизайна

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

Бремя обслуживания

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

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

Проектировать модульно, чтобы строить модульно

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

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