Спор о том, как можно реализовать дизайн в веб-разработке, — это бесконечная борьба.
Мы часто слышим, как дизайнер спрашивает: “Можно ли реализовать этот новый процесс регистрации в системе и поместить его в приложение? Это значительно улучшит наши конверсии”.
На что разработчик отвечает: “Нет. Этот процесс намного сложнее, чем вы думаете, и в нем используются элементы, которые мы никогда раньше не кодировали. Не думаю, что это возможно.”
И это всего лишь базовый пример.
Возьмем эту ситуацию и увеличим ее до команды из 20 разработчиков и 5 дизайнеров. В результате мы получим несоответствия в шаблонах проектирования, нарушенные процессы регистрации в системе, неделю потраченного впустую времени разработчика, медленные веб-страницы в мобильной версии и один вариант элемента выбора даты, который выглядит так, как будто он из 1995 года.
Где находится камень преткновения между разработчиком и дизайнером?
Мы видим недопонимания между дизайнерами и разработчиками, поскольку дизайнерам поручено наглядно представить концепцию, а разработчикам нужно ее реализовать.
Некоторые считают, что решение заключается в том, что дизайнерам следует научиться программировать. Если бы они могли писать код, то поняли бы, какие проблемы возникают при разработке продукта.
Другие говорят, что разработчики должны проектировать. Если бы они мыслили, как дизайнеры, возможно, необходимость в последних вообще бы отпала.
Как вы понимаете, обе эти точки зрения совершенно неверны.
У разработчиков и дизайнеров совершенно разные функции
Разработчики обладают определенным набором навыков. Они хорошо знают, как разрабатывать веб-сайты и приложения. Но у них нет интуитивного понимания того, как пользователь отреагирует на продукт. Опыт взаимодействия необходимо исследовать и постоянно корректировать. Это полноценная работа по изучению посетителей сайта или приложения и пониманию того, как они по нему перемещаются.
Дизайнерам необходимо наблюдать за своими пользователями, чтобы изучить то, как они ведут себя в приложении/ на сайте. Прежде чем работа над проектом будет успешно завершена, важно постоянно вносить изменения в процесс проектирования. Это нужно, чтобы удовлетворять потребности посетителей сайта, основываясь на их поведении.
UX дизайнеры обладают уникальным набором навыков для понимания психологии пользователей. Им необходимо сосредоточиться на проведении детальных исследований веб-страниц.
Но как разработчики справляются с постоянными требованиями дизайнеров и одновременно создают продукт в соответствии с ожиданиями клиента?
Нам нужен инструмент для устранения разногласий
Даже если дизайнер научится программировать, останется задача поиска оптимального решения для реализации проекта. Знание существующих компонентов всего продукта, их функционального наполнения и процесс создания бренда занимает много времени, независимо от того, кто выполняет эту работу.
Если мы стремимся разрабатывать дизайн таким образом, чтобы повторно использовать большинство уже существующих компонентов, нам все равно понадобится человек, который будет систематизировать все, что есть в приложении на сегодняшний день. Кроме того, нужно будет проводить другой анализ, чтобы убедиться, что дизайн соответствует точным параметрам.
Мы не можем поручить эту работу дизайнеру или разработчику, поскольку их обязанности уже четко определены. Результаты работы дизайнера связаны с исследованием UX, дизайном и оптимизацией показателей конверсии. Разработчик занимается написанием кода.
Нам необходимо реальное решение, которое улучшит рабочий процесс проектирования и разработки. Нужен инструмент, который в общих чертах описывает все существующие компоненты и элементы в определенной библиотеке и предусматривает возможность посмотреть их и переместить в проект простым перетаскиванием. Это позволит дизайнерам выбирать из меню существующие компоненты при работе над новым макетом.
Представляем Merge, инструмент для проектирования без кода
UXPin с технологией Merge — это инструмент дизайна, который использует средства разработки посредством объединения с Git и Storybook. Звучит здорово, но что это значит?
Во-первых, есть интеграция с Git. Merge позволяет импортировать существующие компоненты из библиотеки Git в редактор дизайна UXPin.
Во-вторых, интеграция со Storybook, инструментом разработки пользовательского интерфейса с открытым исходным кодом. UXPin функционирует совместно со Storybook, что позволяет вам применять существующие компоненты дизайна непосредственно в Storybook. Это значит, что вы можете использовать библиотеку существующих компонентов дизайна при внесении последующих изменений в пользовательский интерфейс.
Затем для создания вашего нового продукта можно просто передать дизайн разработчику и попросить его использовать код, который у него уже есть.
Давайте рассмотрим все более подробно.
Часть 1 — UXPin Merge
UXPin Merge импортирует компоненты вашего дизайна из вашей библиотеки Git в редактор UXPin. Эта интеграция в настоящее время доступна только для фреймворка React (прим. фреймворк — это набор инструментов, библиотек и готовых модулей, которые применяются при создании сайтов), что позволяет вам извлекать компоненты React и работать с ними непосредственно в UXPin.
Ваши компоненты будут храниться в ваших библиотеках дизайна UXPin, и любые новые компоненты или обновления будут автоматически синхронизироваться с вашей библиотекой.
Функции ваших компонентов и их демонстрация в действии, также напрямую видны в вашем редакторе UXPin. Это позволит вам посмотреть, как выглядит состояние при наведении курсора мыши, автозаполнение, варианты предложений в текстовых полях, анимация визуального выделения и многое другое прямо в редакторе UXPin.
Все, что вы проектируете с помощью UXPin Merge, будет прописано в коде вашими разработчиками в точном соответствии со спецификациями. Почему? Потому что весь код в вашем дизайне уже существует в библиотеке Git. Вашему разработчику не придется создавать ничего нового.
Часть 2 - Интеграция UXPin со Storybook
Интеграция UXPin и Storybook позволяет вам использовать ваши существующие компоненты дизайна, импортированные из Storybook — общедоступные или частные. Как и в случае интеграции с Git, вы можете изменять свойства и добавлять новые взаимодействия к частям готовых компонентов.
Договоренность достигнута
UXPin Merge быстро решает проблемы текущих задач, которые связаны с проектированием. Дизайнеры используют уже существующие компоненты для своего проекта. Если им нужно скорректировать элементы, они точно знают, какие компоненты нужно изменить и какая страница будет затронута после внесения этих модификаций.
В макете не будет трех версий одного и того же компонента, что упрощает его создание, внесение корректировок и поддержание единообразия.
Нужно ли дизайнерам учиться писать код?
Зачем учиться, если вы можете выполнять свою работу с помощью интерфейса без кода.
Изучение кода откроет для дизайнеров более широкую перспективу и даст больше жизненного опыта, который можно применять при разработке своего приложения. Однако нет необходимости учиться программировать, когда вы можете улучшить взаимодействие с разработчиками с помощью правильных инструментов.
Поскольку мир стремится сделать код более доступным, наш ответ на этот вопрос склоняется к отрицательному. Дизайнеры должны совершенствовать свои навыки в проектировании, а не учиться программированию.
Мы создаем команды, чтобы объединять специалистов разных квалификаций. Нам нужны люди, которые на 100% заняты вопросами UX, чтобы приложения действительно соответствовали потребностям пользователей. В то же время нам нужны люди, которые умеют быстро программировать, чтобы они могли писать код и не задумываться о проблемах UX дизайна.
С помощью UXPin Merge мы можем объединить дизайнеров и разработчиков, чтобы они могли эффективно работать вместе.
