Раскол в дизайне или как уйти от векторной графики и полиграфии в UX/UI

Перевод материала дизайнера и разработчика веб-продуктов Колма Туита.

В дизайне есть два подхода со своими инструментами и направлениями развития.

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

Второй подход подразумевает, что все, кто участвует в разработке продукта, должны работать вместе. Здесь код важнее дизайна. Дизайнеры уважают и понимают технические характеристики платформы. Решения принимают, учитывая контекст, а инструменты подбирают, исходя из конечной цели. Назовём такой подход «объединяющим».

Подход первый: восполняющий пробел

В 2005 году, когда началась моя карьера веб-дизайнера, большинство людей использовали Adobe Illustrator и Photoshop для всех задач. Статус-кво сохранялся много лет — большинство работ требовало владения Adobe Creative Suite.

Так продолжалось до тех пор, пока в 2010 году не появился Sketch. Он оказался проще, дешевле, а его функциональность была ориентирована на веб.

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

Но пробел между дизайном и процессом разработки никуда не исчез. Что будет следующим шагом?

Как именно передавать макеты разработчикам — спорный вопрос. InVision и Abstract выпустили Inspect. Avocode, Marvel и Zeplin представили Handoff. Figma и Sketch попытались экспортировать CSS. Также появились сервисы для конвертирования статичных изображений в код: Supernova Studio, Rapid UI, PageDraw, Teleport, Sketch2React и Anima Launchpad.

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

Но давайте вернёмся к моменту, когда печать была основным средством коммуникации в маркетинге. Тогда было проще. Бесконечные споры насчёт инструментов или фреймворков были сведены к минимуму. Большинство дизайнеров использовали Adobe Illustrator, Photoshop и InDesign­.

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

К примеру, полиграфические дизайнеры знали, что различия между цветом на плотной карточке и на тонком печатном бланке 120 г/м² незначительны. Дизайнеры отвечали за трёхмиллиметровые обрезки бумаги, которые позволяли учесть неточности в выравнивании принтера.

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

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

Но дело не в самом переходе, а в том, что мы мало знали о новых носителях, для которых делали дизайн. Вместо того чтобы разобраться, как с ними работать, мы хотели их приручить. Это стало очевидно, когда многие пытались уместить всё в контейнер размером 960px, называли интерфейсы «страницами» и придумали термин «сайт-визитка».

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

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

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

Сегодня всё это делается при помощи CSS. Даже растровые изображения меньше используют для коммуникации, отдавая предпочтение более качественным или более живым СSS-анимациям, SVG-иллюстрациям и видео.

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

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

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

Подход второй: объединяющий

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

Как ни странно, происхождение обоих подходов можно проследить примерно в одно и то же время. Adobe Dreamweaver, печально известный визуальный редактор кода WYSIWYG, появился в 1997 году. Softress Freeway появился 1996 году, а Microsoft Frontpage в 1995 году, всего через пять лет после Photoshop и более чем за десять лет до Sketch.

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

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

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

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

Форматирование кода и выделение синтаксиса были одними из первых инструментов для удобства написания и чтения кода.

Препроцессоры и шаблонизаторы появились примерно в 2006 году. Инструменты вроде Haml, Sass, LESS, CoffeeScript и другие упростили работу кодом ещё больше, поощряя краткость, облегчая визуальное восприятие и автоматизируя некоторые из наиболее распространённых задач.

JSX — это синтаксическое расширение JavaScript, разработанное Facebook, которое не очень отличается от шаблонизаторов, придуманных ранее. API-интерфейс React также способствует повторному использованию кода и облегчает его визуальное восприятие, помогая сделать его более понятным и доступным.

В последнее время мы видим, что инструменты устраняют барьеры входа: исчезла необходимость настраивать среду разработки, возиться с командной строкой и так далее. Например, такие сервисы, как Compositor ISO и SEEK Style Guide Sandbox.

Modulz — это основанный на коде инструмент для визуального создания пользовательского интерфейса.

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

Polypane — это «умный» веб-браузер для отзывчивого дизайна и разработки.

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

Jason Miller
Предсказание: конечным состоянием моделей виртуальных компонентов, таких как React или Preact, станет частично визуальное программирование. Всё, кроме поставщиков данных, может быть представлено в виде редактируемого визуала.

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

Набор графических интерфейсов для визуального управления кодом внутри инструментов Google Chrome

Конечно, браузерные инструменты разработки работают на скомпилированном коде, но эти же визуальные инструменты могут применяться и к предкомпилированному коду. Compositor Lab и Modulz Editor упрощают визуальное редактирование компонентов React

Modulz Editor — это инструмент для визуального создания компонентов React

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

Lona от Airbnb предоставляет графический интерфейс для создания компонентных систем, мокапов на основе компонентов. Также в сервисе можно просматривать проекты с введенными данными и экспериментировать с разными размерами экрана.

Редакторы Maya, Unity, Cubase, Logic Pro и Final Cut предоставляют инструменты для непосредственного управления, целые команды могут работать над одним и тем же продуктом.

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

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

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

Дилемма

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

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

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

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

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

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

Я до сих пор помню слова Ребекки Кокс, одного из моих самых любимых дизайнеров, о том, что в Quora вкладывали в слова «дизайн продукта».

Пользовательский интерфейс — это продукт дизайна. Дизайн — это набор решений для конкретного продукта.
Ребекка Кокс

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

Итак, раз дизайн — набор решений, какие решения подойдут дизайну цифровых продуктов в наши дни? Вот некоторые вопросы для размышления.

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

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

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

Раньше я думал о Developer Handoff (передаче разработчика) как о довольно спорном инструменте. Что он нам даёт: сильно продвинутый рабочий процесс перехода от статичных мокапов к коду, но он практически бессмысленный, учитывая огромные различия между этими двумя носителями.

Проблема Developer Handoff совсем не в названии. И не в исполнении. Даже идея дизайнеров передавать работу кому-то другому в процессе производства звучит вполне концептуально.

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

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

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

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

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

Ребекка утверждает, что люди, в чьих руках право принимать решения, — это те, кто ближе всего к коду.

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