Дизайн Ян Австрейх
7 803

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

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

В закладки

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

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

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

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

В 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 — это «умный» веб-браузер для отзывчивого дизайна и разработки.

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

🔮 Prediction: 🔮

The end-state of virtual component models like React / Preact is partially visual programming.

E… https://t.co/GJ9Y8z5F3Z
Предсказание: конечным состоянием моделей виртуальных компонентов, таких как React или Preact, станет частично визуальное программирование. Всё, кроме поставщиков данных, может быть представлено в виде редактируемого визуала.

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

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

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

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

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

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

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

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

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

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

Дилемма

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

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

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

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

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

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

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

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

Ребекка Кокс

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

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

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

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

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

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

Another day, another handoff feature.

Inspecting an illustration to extract styles, measurements and code, assumes… https://t.co/nZgg1t10Oq

Ещё один день, ещё одна характерная черта передачи (handoff). Исследование иллюстрации для извлечения стилей, измерений и кода предполагает, что иллюстрация — точное представление конечного продукта. Иллюстрации не могут точно представлять цифровые продукты.

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

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

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

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

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

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

Ребекка Кокс

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

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

#дизайн

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Ян Австрейх", "author_type": "self", "tags": ["\u0434\u0438\u0437\u0430\u0439\u043d"], "comments": 8, "likes": 28, "favorites": 59, "is_advertisement": false, "subsite_label": "design", "id": 43333, "is_wide": false, "is_ugc": true, "date": "Thu, 09 Aug 2018 10:07:46 +0300" }
{ "id": 43333, "author_id": 192524, "diff_limit": 1000, "urls": {"diff":"\/comments\/43333\/get","add":"\/comments\/43333\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/43333"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199114, "possessions": [] }

8 комментариев 8 комм.

Популярные

По порядку

Написать комментарий...
14

Ой водааа. Хрю, му, надо то, надо сё, всё неправильно, а будет правильно. Дизайн это не вот это, дизайн - это вот это! Каждый квартал какой-то гений переосмысляет дизайн, разработку, их парадигмы-хуедигмы. А что в итоге? Как рисовали, так и рисуем; как кодили, так и кодим. Пропасть между дизайном и кодом существует не потому, что полиграфия виновата. В полиграфии тоже было деление между дизайнерами и специалистами препресса и постпечатной обработки, и их война продолжается до сих пор. Пропасть между дизайнерами и кем либо еще искусственная и крайне важная: если человек помимо дизайна начинает заниматься чем-то еще, то он перестаёт заниматься дизайном и начинает заниматься какой-то хернёй. Понимать допечатку и технологии разработки дизайнер обязан, НО ТОЛЬКО ПОНИМАТЬ. Делать всё одновременно означает, что дизайн будет ограничен и не так хорош, как мог бы быть.

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

Ответить
7

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

Ответить
7

Хороший топик. Но решения не предложено.

Ответить
1

Очередная вата от Логомашины. Самое страшное что я клюю на это, очухиваюсь только к середине статьи и понимаю! Что за хрень я читаю! WTF !

Ответить

1

сайт polypane.rocks не работает

Ответить
0

Работает

Ответить
1

так а что дела-то мне как дизайнеру? код учить? ааааааааааааааааа

Ответить
0

Я невнимательно прочел, или в тексте ничего не сказано об инструментах проектирования?

Ответить
0
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Команда калифорнийского проекта
оказалась нейронной сетью
Подписаться на push-уведомления
{ "page_type": "default" }