Будущее дизайна пользовательского интерфейса: инструменты пользовательского интерфейса следующего поколения

Инструменты дизайна пользовательского интерфейса прошли долгий путь со времен первого поколения Adobe Photoshop, программы, предназначенной для редактирования фотографий, а не для создания динамических пользовательских интерфейсов. Текущее поколение инструментов, таких как Adobe XD, Figma и Sketch, упростило и ускорило нашу работу.

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

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

Интеграция дизайна и кода

Будущие инструменты пользовательского интерфейса объединят дизайн и код, чтобы обеспечить более удобный интерфейс для дизайнеров и разработчиков. Наши текущие инструменты не помогают нам разрабатывать веб-интерфейсы; они помогают нам разрабатывать абстрактные представления веб-интерфейсов. Мокапы, сделанные в Figma и Sketch, не связаны с исходным кодом.

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

У разработчиков программного обеспечения есть Visual Studio Code, инструмент, который объединяет редактирование и разработку кода и позволяет инженерам создавать, тестировать и отлаживать код в одной среде. Точно так же дизайнерам нужна среда визуальной разработки, которая предоставляет все возможности проектирования, а также генерирует готовый к работе код.

Вот что ждет нас в будущем.

Параллельное создание заменит передачу дизайнера/разработчика

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

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

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

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

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

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

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

Нам нужны наши инструменты для вывода веб-представлений, а не статических артбордов или мокапов. Нам не нужны симуляторы HTML и CSS. Нам нужны HTML и CSS.

Мокапы устареют

Вместо одноразовых макетов давайте выбрасывать макеты за дверь.

Макеты оставляют слишком много вопросов без ответа. Невозможно разработать один для каждой цифровой среды. Сегодня дизайнеры создают макеты для экранов шириной 320, 834 и 1440 пикселей; но что произойдет, если часть макета сломается на окне просмотра 1220 пикселей? И почему бы не оптимизировать для 375 пикселей, обычного размера для современных больших телефонов?

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

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

Будут учтены все состояния системы

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

Необходимо учитывать каждое состояние, но современные инструменты пользовательского интерфейса оставляют эту задачу дизайнерам, заставляя их создавать множество вариантов одного компонента. Инструменты разработки React и Vue.js позволяют разработчикам легко настраивать все возможные состояния компонента. Инструменты проектирования должны следовать этому примеру и поощрять дизайнеров — даже придираться — к тому, чтобы гарантировать, что все состояния компонентов предназначены для них.

Реальные данные заменят плейсхолдеры

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

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

Пограничное тестирование станет проще

Когда инструменты пользовательского интерфейса, наконец, будут учитывать все состояния и позволят тестировать реальные данные, дизайнеры смогут лучше предвидеть крайние случаи. После того, как компонент создан, дизайнеры проводят стресс-тестирование его различных состояний, подвергая его воздействию различных данных, чтобы увидеть, как он работает в различных сценариях. Таким образом, пользовательский интерфейс станет областью дизайнера, что позволит разработчикам сосредоточиться на таких задачах, как исправление кода JavaScript или тестирование API.

Откроется мир инструментов разработчика и сторонних расширений для браузера

Как только наша работа будет реализована в HTML и CSS, на этапе проектирования станет доступна целая экосистема расширений, например незаменимый Lighthouse для аудита производительности, SEO и доступности, или различные инструменты разработчика браузера, которые имитируют точки останова устройства и низкие скорости сети. Набор инструментов браузера гораздо более ценен для создания и тестирования готовых к производству пользовательских интерфейсов, чем любой из плагинов в Figma, Sketch или Adobe XD.

Дизайнеры и разработчики будут работать параллельно

Текущее состояние разработки продукта я сравниваю с кухней, на которой один повар пытается приготовить блюдо, диктуя другому повару, что делать: это может сработать, но это займет значительно больше времени и будет гораздо менее эффективным. Есть компании, разрабатывающие инструменты проектирования на основе кода — продукты Hadron, Modulz и Relate находятся в стадии бета-тестирования. Широкое внедрение этих инструментов станет началом революции в создании цифровых продуктов.

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