Существующие инструменты дизайна сильно отстают от развития продуктов: они не поддерживают разные этапы создания интерфейса, не ставят необходимых для целостности дизайна ограничений и не контролируют процесс. Это влияет как на пользователей приложения, так и на команды, работающие над продуктом, считает дизайнер Кольм Туит.
Редкий мой день проходит без размышлений о дизайнерских инструментах. Несколько лет назад я создал инструмент, который был приобретен Marvel. Это было два года назад, но с тех пор не изменился ни мой интерес к этому, ни сам рынок инструментов.
Недавно я запостил вот такой твит о дизайнерских инструментах:
UI design happens at the 4th level of abstraction.
1. Styles
2. Components
3. Modules
4. UIDesign tools have barely made it to level 2.
— Colm Tuite (@colmtuite) July 28, 2017
Ко мне присоединились многие другие люди:
Even the most “advanced” digital design tools are based on workflows for drawing mere pictures of interfaces.
— Daniel Eden (@_dte) July 28, 2017
It's like we have transatlantic passenger air travel but the planes are just people holding onto lots and lots of birds real tight.
— ¸„.-•~¹°”ˆ˜¨ ĴÖŅ ĠÖĻĐ ¨˜ˆ”°¹~•-.„¸ (@jongold) July 28, 2017
В этих тредах вы найдете много отличных мыслей, но я не хотел торопиться в понимании того, что именно не так в нынешних дизайнерских инструментах и в каком направлении нам нужно двигаться.
Мы все просто рисуем картинки
Почти все популярные инструменты дизайна дают результат в виде изображения. В этом есть несколько проблем:
- Вы не можете взаимодействовать с изображением. Инструменты прототипирования дают нам возможность добавлять переходы между экранами и простые взаимодействия. Однако наши продукты требуют более сложных переходов и микровзаимодействий, которые не поддерживают изображения.
- Через изображения сложно передать отзывчивый дизайн.
- Изображения не изменяют состояние. Чтобы показать разные состояния интерфейса, часто нужно много изображений.
- Bitmap-изображения зависят от разрешения. С распространением экранов Retina изображения иногда могут плохо рендериться.
- Файлы с изображениями могут быть слишком объемными для хранения и отправки.
Пока инструменты дизайна работают с изображениями, они не могут точно передавать смысл наших продуктов. Эта нехватка точности становится препятствием для общения дизайнеров и разработчиков. Пока дизайнеры продолжают использовать неподходящее средство передачи своей работы, в этой работе всегда будет место для недопонимания.
Это очень важный момент, потому что почти все дизайнерские инструменты конвертируют векторные формы в изображения. Photoshop, Illustrator, Marvel, Adobe XD, Sketch и Figma одинаковы в этом отношении. Наши продукты сейчас принимают и поддерживают сложные взаимодействия: голосовой и видеоввод, дополненная и виртуальная реальность, чувствительность к температуре и т.д. Дизайн, основанный на изображениях, снижает ценность этих взаимодействий и ведет в тупик. Наши дизайнерские инструменты должны показывать сам продукт, а не его изображение.
Наши продукты интерактивны. Наши инструменты статичны.
Я затронул эту тему в предыдущем пункте, но она настолько важна, что я решил её конкретизировать.
Подумайте о количестве простых взаимодействий, которые происходят в продуктах и не могут быть выражены при помощи существующих инструментов дизайна. Вот мой небольшой список:
- Наведение на кнопку
- Указание на поле ввода
- Проставление галочки в специальном окне
- Контент во вкладках
- Области скроллинга
- Горячие клавиши
Конечно, некоторые из этих функций можно сымитировать, но зачем? Почему дизайнеры не могут создавать реальный продукт? Они проводят месяцы работы над одноразовыми макетами, когда могли бы потратить это время на создание продукта. Я не говорю, что все дизайнеры должны уметь кодить, но нет никакой причины для того, чтобы дизайнерские инструменты не могли поддерживать работу с продуктом в действии.
В этом отношении выделяется Framer, поддерживающий детальные и сложные взаимодействия. Остальные инструменты далеко позади.
Инструменты дизайна должны поддерживать парадигму разметки
Около года назад единственным способом создания разметки в вебе было использование display: table и CSS-свойств vertical-align. Теперь у нас есть Flexbox и скоро у нас будет CSS-сетка. Эти три функции работают практически одинаково, используя DOM. Почти все сайты построены на одной из этих трех систем.
Поэтому разумно полагать, что наши дизайнерские инструменты должны поддерживать ту же самую модель создания разметки.
Почти все дизайнерские инструменты игнорируют эти системы, предпочитая размещать каждый слой в отдельной рабочей области. Это создает разрыв между функционированием сайта и инструмента, порождая следующие проблемы:
- Отзывчивый дизайн становится сложно создавать, потому что для каждого разрешения нужно вручную изменять слои. Вместо этого можно использовать систему разметки, основанную на ограничениях, но это добавляет сложности, требует обучения и мешает разработчикам переносить макет непосредственно на продукт.
- Так как каждый слой располагается отдельно, управление контентом также усложняется. Например, если вы хотите добавить пункт в список, вы должны вручную изменить положение других элементов списка. Конечно, вы можете использовать функции повторения, чтобы облегчить себе задачу, но, опять же, это добавляет сложности.
- Абсолютное позиционирование ведет к фиксированию координат пикселей. Это ведет к снижению гибкости и не соответствует функционированию веба, который построен на таких единицах, как em, rem, vh, vw и %. Наши инструменты должны поддерживать эти единицы по умолчанию.
Дизайнерские инструменты не должны напоминать веб или отражать его нюансы — они должны быть вебом.
Монолитные инструменты дизайна
Хороший дизайн идет стадиями. У хорошо структурированной системы есть несколько слоев:
- Палитра стилей: Коллекция цветов, теней, интервалов, радиусов границ, шрифтов, анимаций и других стилей, формирующих идентичность бренда. Сейчас многие инструменты поддерживают только цветовые палитры. Пока они не поддерживают другие свойства, довольно сложно создавать систему дизайна.
- Графика: Иконки, иллюстрации и изображения. Существуют феноменальные редакторы изображений и отличный векторный инструмент от Figma, но когда дело доходит до поддержки SVG, инструменты не совсем справляются.
- Библиотека компонентов: Компоненты — это коллекция стилей и графики, которая рендерит данные в единый элемент со множеством вариаций, например, кнопки, бейджи и т.д. Figma и Sketch недавно извлекли этот процесс из основного потока, заменив компоненты их изображениями.
- Модули: Модуль или композиция обрабатывает компоненты и превращает их в конкретное представление интерфейса в разных состояниях, например, вкладку меню, форму входа в систему, таблицы и др. Так как модули являются просто сложными компонентами, я думаю, что Figma и Sketch могут справляться и с ними. Но разделить эти пункты было бы неплохо.
- Экраны: Коллекции модулей, компонентов и данных формируют завершенный интерфейс, с которым может взаимодействовать пользователь.
Многие дизайнерские инструменты поддерживают эти этапы в той или иной степени. Проблема заключается в том, что они объединены в одно. Почти все дизайнерские инструменты предлагают только один режим — режим рисования. Вы создаете набор рабочих областей и начинаете рисовать. Только недавно Sketch и Figma выделили компоненты/символы из основного режима, что странно, потому что в фронтенд-разработке компоненты выделены уже много лет.
При создании палитры стилей мне не нужны рабочие области или векторные инструменты. Я хочу видеть инструменты для выбора гармоничного сочетания цветов. Я хочу предустановленные типы отступов.
Создание иконки требует совершенно другого режима, нежели создание пользовательского потока. Простой SVG-редактор, который позволил бы мне рисовать прямоугольники, круги и линии, а затем экспортировал бы оптимизированный SVG-код, был бы идеален.
При создании компонента я не должен думать об индивидуальных стилях — я должен просто выбрать стиль из предопределенной палитры. Создание стилей для одного компонента внесет непостоянство и снизит эффективность моей системы дизайна. Как только палитра стилей создана, она должна изменяться только на своем этапе. Аналогично, при создании модуля я хочу работать с ранее составленной библиотекой компонентов. Никаких векторных инструментов. Просто библиотека компонентов, которые я могу перетаскивать для создания модулей. При компоновке экрана мы просто используем компоненты и модули, чтобы создать интерфейс. Мы не думаем о стилях или формах. Мы сфокусированы на создании контента и пользовательского опыта.
Каждая стадия должна проходить в отдельных инструментах или разных режимах одного инструмента. Это не так важно, ясно то, что существующие дизайнерские инструменты не поддерживают процесс создания интерфейса.
Наши инструменты дизайна должны поощрять хороший дизайн
Дизайнеры могут добавлять бесконечное число уникальных стилей в проект без каких-либо заметных последствий. Нужен шрифт чуть больше? Не проблема. Чуть более яркий цвет? Просто выбери его. Вы можете создавать множество рабочих областей в одном проекте, создавая немного отличающиеся варианты одного стиля, и этого, скорее всего, никто не заметит.
Ваш дизайнерский инструмент никогда не запретит вам что-то сделать. Он не предупредит вас об использовании цвета, отличающегося от палитры бренда. Он не предостережет вас от использования значения отступа, не принадлежащего к текущему проекту. Он не напишет вам, что 20% населения не сможет увидеть светло-серый текст, который вы только что создали.
Дизайнерские инструменты настолько привязаны к идее безграничного творчества, что не учитывают, что значит создавать разумный, инклюзивный и систематический дизайн. Они позволяют нам создавать всё, что мы хотим. В какой-то степени этот уровень творчества полезен, особенно в фазе создания идей. Но большая часть работы UI-дизайнера не требует такой свободы. Наш рабочий процесс должен быть построен на повторном использовании и стандартизации.
Эта свобода не согласуется с реальностью веб-разработки. Так как разработчики работают с реальным продуктом, они должны работать с одним и тем же кодом. Они не могут просто добавить любой размер шрифта или значение цвета в массив кода. Во-первых, они немедленно увидят сообщение с предупреждением. Если нет, то это будет замечено при обзоре кода. Если и на этом этапе это не будет замечено, значительный спад производительности все-акти вызовет предупреждение.
Одна из главных проблем в командах по созданию продукта — разрыв между дизайнерами и разработчиками. Разработчики работают со строгими правилами и ограничениями. Пока дизайнерские инструменты не примут такие же ограничения, пробел никогда не сократится.
Мы должны создавать дизайн на основе живых данных
В какой-то степени реальные данные входят во многие инструменты. В Adobe XD есть отличные функции по генерированию фальшивых данных, отображающих реальные. Invision Craft предоставляет такие функции для Sketch.
Но эти данные не должны ограничиваться текстом. Другие элементы, например, изображения и видео, имеют огромное влияние на пользовательский опыт при увеличении времени загрузки. Если вы работаете в вебе, браузерные инструменты разработки позволят вам протестировать разные скорости интернет-соединения. Вы можете видеть, как новое содержание влияет на пользовательский опыт.
Предоставляют ли инструменты дизайна такую возможность? Нет. Чем ближе мы подходим к созданию реального продукта, тем более влиятельной может становиться наша работа.
Наши инструменты должны быть открытыми
Одна из самых прекрасных черт веба — его открытость. Веб-сайт можно просмотреть на любом браузере и с любого устройства.
Как это относится к дизайнерским инструментам? Несколько дней назад мой брат Дэвид попросил меня посмотреть на дизайн приложения, которое он создает. Он отправил мне файл Sketch. Вот что я увидел, когда попытался его открыть…
Если один дизайнер работает в Photoshop, то его коллега не сможет открыть этот проект в Sketch. При этом недостаточно использовать один и тот же инструмент, вы должны использовать одну и ту же версию инструмента.
Каково будущее дизайнерских инструментов?
С дизайнерскими инструментами сейчас происходит много нового. Для Airbnb Джон Голд и Бенджамин Уилкинс создали инструмент React-Sketchapp, который встраивает компоненты React в Sketch. Джон и Бен также работают над новым инструментом, который будет превращать эскизы с бумаги в компоненты React.
Адам Мос, Брент Джексон и Джон Отандер работают над набором инструментов Compositor, который решит все проблемы, о которых я рассказал в этой статье. Я работаю над Modulz, дизайнерским инструментом с открытым исходным кодом, который также нацелен на решение всех упомянутых проблем.
Инновации в инструментах важны, но действительно сложно обстоят дела с образованием. Дизайнерское сообщество просто не готово к системному инструменту. Многие дизайнеры не заинтересованы в создании систем. Для некоторых конечная цель — это JPG и лайки на Dribbble.
Мы должны разработать культуру ответственности, которая существует у разработчиков уже много лет. У них есть инструменты, чтобы проверять свой код. Если разработчик постоянно отклоняется от правил, эта проблема не останется незамеченной. Дизайнеры часто создают множество беспорядочных слоев, не уделяя внимания их наименованию, группировке и выстраиванию по порядку. Так как результат (растровое изображение) не зависит от входных данных (векторные слои), от дизайнеров не требует организованности. Этот недостаток часто оправдывают романтизацией искусства дизайна.
Мы должны также разработать культуру инклюзивности. Мы должны осуждать небрежность, вроде ультрасветлого текста, который не смогут прочитать некоторые люди, или слишком высококачественных шрифтов, которые приведут к долгой загрузке страницы, или неупорядоченных элементов интерфейса, непонятных для людей с нарушением восприятия цвета. Если мы создадим умный инструмент, мы сможем изменить эту культуру.