Какие инструменты дизайна ошибаются
Современные инструменты для дизайна, как векторные, так и основанные на коде, являются потрясающими программами, которые в последние годы преобразовали профессию дизайнера, но ни одна из них, кажется, не понимает контекста, в котором мы сейчас проектируем. Остатки фиксированных размеров все еще присутствуют везде, и эти инструменты не помогают нам учитывать соображения и компромиссы, которые дизайнеры должны делать в отношении своей работы. Вот некоторые из функций, которые бы поддерживал мой идеальный инструмент для дизайна изначально.
Дизайн-библиотеки должны быть функциональны и удобны для дизайнеров агентств
Библиотеки в приложениях, таких как Sketch, Figma и Adobe XD, хорошо работают для дизайнеров продуктов, но значительно хуже подходят для дизайнеров агентств.
Чтобы понять причину, давайте разъясним разницу между дизайнерами продуктов и дизайнерами агентств. Дизайнеры продуктов - это люди, работающие над одним или несколькими продуктами, которые создает их компания. Подумайте о дизайнерской команде Airbnb или, действительно, компаний вроде Sketch. У этих дизайнеров может быть единая система дизайна или стайл-гайд, с которым они работают, и один или несколько проектов, построенных на основе этой системы.
Дизайнеры агентств, с другой стороны, работают в веб-агентствах, где они могут одновременно заниматься проектами для полудюжины клиентов, каждый из которых имеет собственную систему дизайна (если вообще есть) или стайл-гайд с разным уровнем зрелости дизайна. Эти дизайнеры часто переключаются между проектами и даже могут передавать ресурсы новому дизайнеру в зависимости от планирования проекта.
Для дизайнеров продуктов текущая реализация дизайн-библиотек работает хорошо. У них может быть всего одна или две (например, для веба и мобильных устройств) дизайн-библиотеки, которые отражают общий стиль. Поскольку все дизайн-библиотеки доступны для всех дизайн-файлов, это хорошо справляется с задачей.
С другой стороны, у дизайнеров агентств может быть 10 или 20 различных библиотек. Некоторые из них будут актуальными для текущего проекта, а другие - для проектов, над которыми они недавно работали, но возможно, придется снова вернуться к ним в следующей версии. В связи с этим им приходится постоянно быть внимательными, чтобы использовать символы только из правильной системы дизайна, или постоянно активировать и деактивировать дизайн-библиотеки при переключении между проектами. Как можно себе представить, это не очень приятный опыт.
Многие дизайнеры агентств либо вовсе не используют дизайн-библиотеки, либо используют общие библиотеки дизайна, такие как UX Power tools, чтобы поддерживать работу над системами дизайна, что ведет к более общим дизайнам для их клиентов.
Связывание дизайн-библиотек с конкретными проектами - это первый шаг к тому, чтобы сделать дизайн-библиотеки более полезными для дизайнеров агентств.
Другая проблема заключается в создании самих дизайн-библиотек. Дизайнерам агентств было бы крайне полезно, если бы у них были доступны готовые дизайн-библиотеки, но не у всех клиентов они есть, и у агентств часто нет времени или бюджета создавать их для каждого проекта.
Как особенно мотивированный дизайнер агентства, вы можете создать дизайн-библиотеку параллельно с работой над проектом, но постоянное переключение между файлами дизайна для веба/мобильных устройств и файлами системы дизайна может быть неудобным. Возможность "отправить компонент в дизайн-библиотеку" во время работы над дизайном значительно упростит создание дизайн-библиотеки, сделав этот процесс доступным для большего числа людей и уменьшив необходимые усилия.
Дизайн-библиотеки должны стать библиотеками дизайн-токенов.
Дизайн-библиотеки ограничены в том, что они могут предоставить: только компоненты или символы. Это хорошо работает, если все ваше дизайн-работы сводится к созданию новых экранов из одних и тех же компонентов. Однако при создании чего-то нового дизайнеры постоянно должны заходить в компоненты и копировать такие вещи, как цвета, варианты шрифтов и проверять отступы, чтобы затем скопировать это в новые компоненты. При копировании элементов часто возникают ошибки (в конце концов, мы просто люди).
Если бы дизайн-библиотеки предоставляли интерфейс для выбора используемых дизайн-примитивов, а также предоставляли символы, то создание новых компонентов в вашем дизайне было бы быстрее и менее подвержено ошибкам. Что приводит меня к следующему моменту:
Ограничение вариантов до дизайн-токенов
Самая очевидная проблема с интерфейсом для этого - это выбор цвета. По умолчанию выбор цвета в вашем любимом инструменте для дизайна позволяет выбирать цвета из всего спектра RGB. То же самое касается шрифтов и интервалов (буквально бесконечное количество вариантов). Это полностью возлагает ответственность за поддержание согласованности на дизайнера. Это безумие, потому что компьютеры гораздо более способны справляться с этим.
Мой идеальный инструмент для дизайна начинается с определения этих элементов как дизайн-токены и предоставления только их в качестве возможных вариантов. Я хочу переключаться между двумя выбранными шрифтами, а не пролистывать 2000, установленных на моем компьютере. Мне нравится выбирать из 9 оттенков основного цвета, но я не хочу проверять снова и снова, правильно ли я использую #042d3d везде, а не #042d3e.
Перетаскивая компоненты или элементы по своему холсту, они будут прилипать только к значениям, которые я определил в шкале интервалов. Или, что еще лучше, давайте убедимся, что ваш инструмент для дизайна реализует модель компоновки, которая делает это за вас (более современные инструменты для дизайна на основе кода, такие как Modulz, уже это делают).
Это идет дальше, чем просто линтинг дизайна, идея, которая сама по себе является недостаточно разработанной. В то время как линтинг дизайна скажет вам, что-то не так уже после совершения ошибки, ограничение дизайна вариантами, определенными в дизайн-токенах, предотвратит появление "неправильных" вариантов с самого начала.
Символы недостаточно мощные
Символы (или кадры, или компоненты) были отличным способом создания многоразовых пакетов дизайна, и их реализация становится все лучше в отношении предположений о компоновке. Однако они по-прежнему не идеально соответствуют реалиям дизайна для веба и мобильных устройств.
Например, заголовок может существенно отличаться между мобильной и настольной версией: на мобильной версии может быть кнопка меню, которая открывает меню, тогда как на настольной версии меню полностью видимо. Поддержка обеих версий означает, что нужно иметь два символа для того, что с семантической точки зрения является одним и тем же элементом. Чтобы символы хорошо соответствовали реальности, им необходимы три вещи:
Варианты
На вашем сайте может быть несколько различных кнопок. Они могут отличаться только цветом, отступами, или одни из них могут содержать значок, а другие - нет. Все эти варианты одного и того же элемента идеально бы существовали в одном компоненте. Это упростило бы обновление общих свойств и, конечно же, уменьшило вероятность ошибок. Некоторое количество этого можно сделать с помощью переопределений или изменений экземпляров, но это не идеальное решение.
Состояния
Необходимость в этом снова проявляется в особенности кнопок. У кнопок есть несколько естественных состояний: они могут быть в покое, при наведении и фокусе, они могут быть активными (нажатыми или кликнутыми) и они могут быть отключенными. Все эти состояния - это экземпляры одного и того же символа и должны рассматриваться как таковые.
Адаптивные варианты
Я уже упоминал ситуацию с заголовком выше. Мой идеальный символ позволил бы мне устанавливать различные дизайны и стили в зависимости от доступного места. Затем, когда я использую символ, он автоматически переключается на соответствующий адаптивный вариант.
Как видите, нам нужно, чтобы символы были редактируемыми в нескольких различных измерениях. Приложения, такие как Modulz и UXPin, находятся на пути поддержки этой функциональности, и я надеюсь, что мы будем продолжать приближаться к функционалу, описанному мной выше.
Сетки бесполезны во всех инструментах для дизайна
Современный дизайн пользовательского интерфейса для мобильных устройств и веба не может полагаться на фиксированные размеры, как это может быть в печатном дизайне. Почему тогда сетки в инструментах для дизайна предполагают, что сетка от верхнего левого угла всегда будет то, что люди хотят? Или фиксированная ширина макета столбцов по центру?
Дизайн для экранов использует выравнивание от границ или от центра. Однако ни один из известных мне инструментов для дизайна не позволяет мне задавать сетки таким образом, чтобы в зависимости от позиции элемента сетка располагалась от другого угла или позиции на экране.
Например, ваш заголовок с логотипом и меню может быть полной шириной окна просмотра, и логотип будет находиться на расстоянии 10 пикселей от верхнего и левого края, а меню будет выравниваться по правому краю, также с отступом 10 пикселей. Пространство между этими двумя элементами совершенно произвольно, так как вы не знаете полной ширины вашего сайта на этапе проектирования. Это означает, что если ваша сетка работает от верхнего левого угла, навигация будет выравниваться только случайно.
Умный инструмент для дизайна позволил бы мне задать шаг сетки (например, 8 пт) и затем предоставил бы обратную связь от ближайших границ и вертикального и горизонтального центра.
Стандарты доступности должны быть встроены
Работа дизайнера - учитывать каждого пользователя. Это означает, что им нужно знать о правилах доступности и применять их. Некоторые из этих правил доступности, такие как контрастность цветов или минимальные размеры шрифтов, могут быть проверены компьютером. Инструменты для дизайна должны активно предупреждать пользователей, когда цвет текста и фоновых цветов не обеспечивают достаточную контрастность, или когда размер выбранного шрифта слишком мал для данного экрана.
Справедливости ради, эти функции постепенно реализуются в инструментах для дизайна. Это одна из причин, почему я так поклонник Modulz. Тем не менее, для таких относительно простых вещей странно, что инструменты для дизайна так долго не принимали их во внимание.
Versioning как важный аспект
На рынке существует множество различных инструментов для контроля версий, таких как Avocode, Abstract и Plan. Все они требуют некоторых ручных действий для версионирования и слияния изменений. В Figma уже есть встроенные возможности для версионирования и совместной работы, и я хотел бы, чтобы это стало стандартом. В моем идеальном мире версионирование, создание ветвей и слияние были бы такими же простыми для дизайна, как это сейчас происходит для кода.