Дилемма инструмента проектирования

1656581792 dilemma instrumenta proektirovaniya

автор Колм Туйт

Подробный обзор двух противоположных нарративов, появляющихся в пространстве инструментов дизайна.

Mh4jZ86dool1TsiEQQGUUPpjU6SQ72pIrBjo
Диаграмма, иллюстрирующая два противоположных нарратива, возникающих в пространстве инструментов дизайна.

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

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

Назовем это «преодоление разрыва” рассказ.

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

Мы будем называть это «общая” рассказ.

Так откуда взялись эти рассказы? Насколько имеет смысл каждый из них? Давайте рассмотрим поближе.

Рассказ №1: преодоление разрыва

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

Приблизительно в 2005 году, когда началась моя карьера цифрового дизайна, большинство из нас использовали Illustrator или Photoshop для создания векторных иллюстраций любого разрабатываемого нами продукта. Это оставалось статус-кво на протяжении многих лет – большинство объявлений о вакансиях для дизайнеров требовали свободного владения программой Adobe Creative Suite.

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

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

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

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

Конечно, противоречива «Передача разработчиков». InVision и Abstract запустили «Инспект». Avocode, Marvel и Zeplin выпустили «Handoff». Figma и Sketch попробовали экспортировать CSS. Идея состоит в том, что когда дизайнеры имеют что-то, чем следует поделиться, они могут передать свою работу разработчикам в формате, понятном разработчикам.

Последним вырезом на этой временной шкале был новый тип инструментов, обещающий превратить статические изображения в производственный код. Supernova Studio, Rapid UI, PageDraw, Teleport, Sketch2React и Anima Launchpad – это лишь несколько стартапов, ведущих эту атаку.

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

Но вернитесь немного дальше, и вы что-нибудь заметите очень своеобразный.

Давайте на миг вернемся назад в то время, когда печать являлась основной формой маркетинговой коммуникации. Это было более простое время. Бесконечные дебаты об инструментах или рамках были сведены к минимуму. Иногда какой-то выскочка вспоминал QuarkXPress, но восстание не продолжалось долго. Большинство профессионалов-дизайнеров использовали Illustrator, Photoshop и InDesign. Adobe управлял местом и все.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассказ №2: Сотрудничество

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

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

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

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

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

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

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

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

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

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

Ev0t3TfC8YQOoDlzbPjbk5mdmwG0HAT6A7Dd
n9xq3W-cBeAavWG-0xPHFprR3MXQ8a0bGmSb
Compositor ISO и SEEK Style Guide Sandbox, где можно создать прототип с помощью JSX без необходимости настройки сборки.

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

RisINJWLfOC0nAIZDTa6pn6uaxQEUA1Z-yZ7
Modulz – инструмент дизайна на основе кода для визуальной сборки UI.

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

bzf4etJ84-4GUDSHBjH7udomDz8uz2RPqVmM
Polypane – умный веб-браузер для адаптивного дизайна и разработки.

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

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

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

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

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

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

Lona от Airbnb – один из самых перспективных редакторов визуального кода, которые я видел. Lona Studio предоставляет графический интерфейс для создания компонентных систем, моделирования новых экранов из существующих компонентов, предварительного просмотра проектов с реальными данными, экспериментов с разными размерами экрана и много больше.

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

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

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

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

Дилемма

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

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

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

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

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

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

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

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

Итак, если дизайн – это набор решений, какие решения касаются разработки современных цифровых продуктов? Вот небольшой образец в моей голове:

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

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

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

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

Проблема с «передачей разработчика» не в названии. Проблема тоже не в реализации. Даже представление о том, что дизайнеры передают свою работу по производственной линии, концептуально обоснованно.

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

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

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

«Производственный код – это суррогат полномочий принимать решения. Производственный код является источником истины. Это всеобщая сумма всех разговоров, всех решений, всей политики… это все. Продвигающий код в производство запускает продукт. Все остальные оказывают только влияние». — Ребекка Кокс

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

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

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

Спасибо Дэйву Фельдману, Адаму Морсу, Скотту Реймонду, Патрику Смиту, Майклу Ли, Килиану Валкхофу, Дэвиду Туйту и другим за помощь с редактированием.

Добавить комментарий

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