Как предотвратить конфликт UI редизайна и разработки 8  Как предотвратить конфликт UI редизайна и разработки 9  Как предотвратить конфликт UI редизайна и разработки 10

Как нужно делать UI редизайн, чтобы не создавать проблем разработке

#UI/UX дизайн

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

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

Какие проблемы UI дизайнер чаще всего создает разработчику

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

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

Проблема 1: несвязанные между собой экраны

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

несвязанные между собой экраны

Верстальщик трудолюбиво их верстает, тоже тратит время, пока back-end или front-end разработчик не задает вопрос: “Это, конечно, хорошо, но КАК Я СЮДА ПОПАДУ-то?”. И тут выясняется что, например, экраны для регистрации пользователя есть, а вот кнопка “Регистрация” в дизайне не предусмотрена. Или форма восстановления пароля отрисована, а кнопки “Я забыл пароль” в дизайне нет.

Как решается: мы используем компонентный подход в дизайне, тестируем дизайн и прототип на use cases.

Проблема 2: тысячеликие кнопки

Стандартная ситуация: дизайнер нарисовал кнопку, она ему очень понравилась, но вот беда – синяя кнопка  плохо смотрится на зеленом фоне. “Это не беда”, – решил дизайнер и нарисовал белую кнопку.

Многоликие кнопки в дизайне

Казалось бы, проблема решена, но на следующем экране белая кнопка смотрится слишком блекло, а синяя слишком ярко, и обе они были слишком большие. Чтобы исправить ситуацию, дизайнер рисует маленькую желтую кнопку с тенью. А на другой странице кнопку средней величины с черной обводкой и иконкой. И так ещё 5 раз. В итоге верстальщик проклинает дизайнера и говорит: “Сам верстай свои 10 кнопок”.

Вам смешно? Мы бы и сами посмеялись, если бы не верстали по чужим (сделанным не нашими дизайнерами) макетам интерфейсы, где было 3-4 разных стиля чекбокса.

Как решается: необходима унификация компонентов и компонентный подход к дизайну.

Проблема 3: очень много компонентов

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

очень много компонентов

В итоге у него что-то даже получилось, и даже красиво. Но потом дизайнер пришел к фронтендеру, показал ему это всё, а фронтендер сказал: “Зашибись – красиво. Только оно не так работает”. И показал дизайнеру Bootstrap. А дизайнер расстроился и напился с горя. А напившись, решил: “Ну его, этот компонентный дизайн. Буду дизайнить как раньше: рисовать все элементы на листе. А как их там на компоненты бить, пусть фротендеры сами решают раз такие умные”.

Как решается: желательно, чтобы front-end и дизайнер договорились о методологии разделения на компоненты еще до начала работ по дизайну. А в идеале, чтобы взяли готовый UI Kit и просто сделали редизайн.

Проблема 4: не хватает состояний

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

И тут фронтендер сказал: “Дизайнер, твою ж мать!” Потому что оказалось что select прорисован только свернутый, checkbox только выбранный (с галочкой), а меню учитывает только 5 пунктов из 20-ти, которые надо в него поместить, к тому же только для ПК и планшета, а как оно будет на телефоне работать “сами думайте, это ж очевидно”.

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

Проблема 5: “Где лежит последняя версия стиля этого компонента?”

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

Где фронтер должен найти это меню? В каком исходнике? Ну конечно, не “Table_final.ai”, а в “Материалы на встречу/21.05/к обсуждению.ai”. Это же очевидно. И пока у фронтера нервно дергается веко, дизайнер недоумевает: “Ты что, не пересматриваешь каждый день все файлы на моем компе? Вот ты странный”.

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

Проблема 6: дизайн, основанный на плохо изученных данных

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

Тогда он рисует “идеализированную картину”, которая не выдерживает столкновения с реальностью. Когда в такой дизайн попадают реальные данные, они его мгновенно “рвут”. Если фронтендер попался опытный и заложил везде ограничения, то верстка справится, но информативность потеряется.

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

Проблема 7: “Почему ты решил, что это вообще может работать?”

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

Таким образом обычно появляются формы без обязательных полей (аргумент: “Много полей – это не модно”. И неважно, что на те поля была завязана логика валидации пользователя).  Или, например, появляются очень красивые графики в dashboard, а данных, чтобы построить такие графики в системе (в БД) просто нет. Сюда же относится непонимание к чему можно привязать стрелки, подсказки и т.п. на экране, а к чему нет.

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

Как работать с дизайнером, чтобы вам не плевали в кофе. Стандартные ошибки разработчиков и фронтеров

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

Ситуация 1: “Сделай ВСЕ шрифты и отступы согласно макета”

Стандартная ситуация: дизайнер рисует макет, отправляет его верстальщику, а тот верстает, совершенно не придерживаясь отступов и шрифтов, указанных в макете. Наверное, это какой-то стандартный баг в голове у любого верстальщика, когда отступы и шрифты кажутся ему незначительными. Возможно, он даже не понимает, что Times New Roman и, например, Noto Serif – это разные шрифты.

И на справедливое возмущение дизайнера верстальщик только разводит руками и говорит: “Ну они же похожи”. Дизайнер натягивает улыбку (хотя где-то в мыслях уже сорок раз пырнул верстальщика ножом) и говорит: “В общем-то неплохо, но сделай шрифты и отступы согласно макету”. И вот на этой точке можно сидеть неделями. Фронтендеры обычно не понимают, что согласно макету надо сделать ВСЕ отступы . А не один, который они решили проверить.

Как решается: в идеале дизайнер 1 раз показывает что он имеет ввиду, фронтендер понимает и делает. Если не понимает или упрямо делает не то – снимите бедолагу с проекта. И все останутся живы.

Ситуация 2: “Давай сделаем анимации плавнее”.

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

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

Ситуация 3: “Мы этот элемент по аналогии сделали”

Обычно этой фразой отвечают на вопрос “Откуда здесь взялось ЭТО? В дизайне такого не было”. Собственно, корень проблемы кроется там же, где и у ситуации со шрифтами. У разработчиков очень специфические представления об аналогиях вообще и прекрасном в частности. Им ничего не стоит смешать несколько стилей с разных состояний элементов и влепить на один экран – и даже глазом не моргнут.

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

Ситуация 4: “В дизайне всё неправильно, мы решили, что так удобнее”

А вот за эту фразу любой дизайнер уже пойдет подливать смолы в котел для разработчиков. К сожалению, довольно часто бывает, что сверстав энное количество сайтов, разработчики решают: они уже хорошо смыслят в UI/UX и вполне могут сделать “шоб удобно”. И делают, по ходу ломая и сетку, и всю визуальную картину.

Так в тщательно спроектированном дизайнером UI появляются плохо стилизованные элементы из любого другого UI фреймворка. По принципу “компонент удобный, вот мы его и взяли”.

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

Ситуация 5: “Накидай мне как это должно выглядеть, но я не скажу как это работает”

Обычно такой подход встречается у РМов. Они ставят дизайнеру задачи типа “Нам нужен дизайн новой карточки участка”. И потом не могут или не хотят ответить на уточняющие вопросы: “А что эта карточка должна делать? Как она должна работать?” Предполагается, что ответ: “Ты ж дизайнер, ты мне скажи” решит задачу, но, увы, это не так.

Дизайнер в большинстве случаев не может придумать бизнес-логику. Если он её всё-таки придумал без подсказки снаружи, тут есть два варианта:

а) он её просто знал (например, с другого проекта);

б) вам очень повезло.

При адекватном подходе бизнес-логику придумывает PO (product owner) или BA (бизнес-аналитик). Задача дизайнера: помочь её воплотить, придумать визуальное представление, протестировать насколько реализация удобна, сравнить эффективность 2-3-х разных вариантов. Но дизайнер не должен знать и обычно не может сказать “как должно работать закрытие нарядов на большегрузы”. Это не его сфера.

Как решается: необходимо наладить коммуникацию между всеми ключевыми участниками разработки UI/UX и обеспечить дизайнеру доступ до нужной в его работе информации.

Вывод: создание UI редизайна – процесс непростой. На любом этапе всё может полететь в тартарары, если в команде не будет единства. И чтобы вернуть процесс в нормальную колею, понадобится много дополнительных часов работы.  Поэтому дизайнер должен понимать разработку и уметь с ней общаться. Помимо разработки дизайнер должен понимать данные и процессы, с которыми он работает. Он должен понимать бизнес и его задачи. И в первую очередь людей, которые будут потом пользоваться результатами его работы.

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

18.06.2019
Используемые в статье картинки взяты из открытых источников и используются как иллюстрации.
Хотите обсудить ваш проект или заказать разработку?
Отправить
Цей сайт є українською мовою. Ви можете переключити мову у меню, або зробити це зараз.