Преодоление разрыва между дизайнерами и разработчиками

Эта статья любезно написана нашими друзьями из UXPin, инструмента для проектирования и прототипирования пользовательского интерфейса, который дает вашим прототипам сверхспособности, которых они заслуживают: состояния, JS-выражения, переменные, условные взаимодействия, синхронизацию с Git. Эта статья, однако, никоим образом не связана с UXPin и выражает независимое мнение автора. Спасибо!

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

Давайте рассмотрим типичную дилемму:

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

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

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

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

Скрытый драгоценный камень во всем хаосе

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

Долой старый процесс

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

Что происходит, когда нам нужно обновить компонент? Появился новый вариант использования, или, возможно, мы решили изменить наши границы с закругленных на острые как бритва? Теперь нам нужно добавить варианты в библиотеку, (возможно) снова обновить документацию, опубликовать и доставить ее нашим разработчикам. Фу! Будем надеяться, что ничего не сломалось для наших дизайнеров со всей этой реорганизацией компонента.

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

В новом процессе

Итак, вам может быть интересно, как технология UXPin Merge помогает в этом чрезмерном процессе, который мы все используем сегодня? Что ж, взгляните на схему ниже. Вы можете заметить, что при создании компонента варианты не нужны (в большинстве случаев). Этот новый процесс уменьшает количество возни с инструментами автоматического макета благодаря нашим теперь синергетическим отношениям с разработчиками:

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

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

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

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

Но хватит о процессе. Давайте посмотрим, как работает UXPin Merge.

Управление библиотеками

Самое приятное то, что библиотеки можно импортировать непосредственно из вашего репозитория кода, такого как GitHub, Bitbucket, GitLab (работает только для компонентов React) или даже из Storybook. После создания библиотеки у вас будет возможность присвоить ей имя.

При импорте с помощью Storybook процесс довольно прост. Просто возьмите URL-адрес библиотеки, и UXPin сделает все остальное за вас. С компонентами React, используя интерфейс командной строки, вы можете контролировать публикуемые компоненты , указав уникальный токен библиотеки UXPin.

Контроль версий и тестирование

Одной из самых больших проблем среди дизайнеров и команд дизайн-систем является контроль версий. Большинство проблем можно решить с помощью этой функции слияния UXPin. Нарисуем краткую картину:

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

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

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

Тестирование обновлений

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

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

Проектирование с помощью кода

Итак, как члены нашей команды занимаются проектированием на земле и что для них значит эта технология? Что ж, я рад, что вы спросили! С точки зрения продуктового дизайнера — особой разницы нет. Когда дизайнер использует компонент из библиотеки разработки с помощью Merge, они будут отмечены оранжевым шестиугольником для каждого компонента. Все новое будет вести себя точно так же, как библиотека разработчика.

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

Кроме того, кнопка со значком ниже позволяет взаимодействовать. Это позволяет нам действительно уточнять и контролировать, с какими компонентами следует взаимодействовать, а с какими нет; как с точки зрения стандартов, так и доступности.

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

Передавать

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

Доступность

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

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

Макеты, шаблоны и сетки

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

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

В заключение

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