Лучшие статьи и кейсы стартапов
Включить уведомления
Дадим сигнал, когда появится
что-то суперстоящее.
Спасибо, не надо
Главное Свежее   Проекты
Рекомендуем
Продвинуть свой проект
786 13 В избр. Сохранено
Авторизуйтесь
Вход с паролем

​ТОП-6 трений между дизайнерами и разработчиками

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

Дизайн часто рассматривается в качестве лёгкого искусства, несущего эстетику и имеющего мало общего с жесткими, правилами логики и тем более, кода. Тем не менее, дизайнеры работают годами, совершенствуя навыки в своём ремесле, а не только развивая бурную фантазию. Однако, оказаться в состоянии объяснить и придать форму «идее, стоящей за дизайнерским безумием» получается далеко не всегда легко и быстро. Это зачастую приводит, к срыву сроков сдачи проектов и прочим неприятным казусам. К счастью, можно найти способы разрядить обстановку.

1. У меня были основания, проектировать дизайн именно таким образом

b_56cf21abd7cf9.jpg

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

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

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

2. Что важно? Всё важно!

b_56cf21b6197f1.jpg

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

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

3. Сколько это будет длиться?!?!?

b_56cf21db4e509.jpg

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

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

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

04. Что вы подразумеваете под «Я не могу этого сделать!»?

b_56cf21e504b9a.jpg

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

  1. разработка на основе сложного дизайна займёт больше времени, чем имеют разработчики;
  2. разработчик просто не знает, как это можно реализовать.

Решение: Если дизайн не может быть внедрён, значит, он не может быть внедрён. Дизайнеру придётся пересмотреть свой макет. Если речь идёт просто о необходимости большего количества времени на разработку, то команда должна решить, вернуться к упрощённому варианту или взять больше времени. Но, если разработчики просто не представляют, как заставить макет работать полностью, дизайнер должен показать примеры , где желаемый подход всё-таки может работать. Для этих целей можно воспользоваться CodePen.io.

05. Тестирование юзабилити является обязательным

b_56cf21f88736b.jpg

Проблема: В понимании многих разработчиков «юзабилити» означает то, что проект работает так, как определено в требованиях. Если дизайнер хочет поэкспериментировать над чем-то, то он должен делать этого до того, как разработчик проведёт множество часов за строительством интерфейса в соответствии со спецификациями. Тем не менее, тестирование можно провести на бумаге и с кликабельными прототипами. Чаще всего, наиболее эффективный тест юзабилити проводят во время самой разработки.

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

06. Они опять мне говорят, как разрабатывать дизайн!

b_56cf22036e721.jpg

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

Решение: Эту проблему решить непросто, она лежит в плоскости межличностных отношений в команде. Одной логикой и практической необходимостью её не решить. Лучшим путём выравнивания ситуации является, выслушивание оппонентов, без попыток защищаться и спорить. Пусть говорят, а вы слушайте и анализируйте их слова на предмет здравости идей/замечаний.

Их ли заслуга в чужих знаниях, которые они получили из модных журналов о дизайне? Зачем пытаться вешать на вас чужой подход к работе? Они что ли дизайн делают? Пусть знают, объясните, почему вы решили пойти по выбранному пути, признавая попутно своё несогласие с «эталонными» практиками «лучших дизайнеров», о которых они начитались. Иногда столь вредное поведение со стороны разработчиков вызвано простым желанием ощущать, что дизайнер прислушивается к ним. Вот и послушайте. А работайте так, как считаете необходимым. Кто из вас дизайнер, в конце концов!?

Что-нибудь ещё?

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

Перевод: http://www.creativebloq.com/web-design/frustration...

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Подбираем рекоммендации...
Комментарии
Первые Новые Популярные
Автоматизация бизнеса.
Разработка ПО на платформе 1С:Предприятие
Нагибович Константин
Я тихонько порадуюсь, что работаю с 1С - там нет места дизайнерам и проблем, которые они привносят.
Ответить
Показать предыдущие комментарии
ADZY
Ассистент для ведения рекламных компаний
Дмитрий Кубитский
хехех, да это не повод для радости. более того стоит признать что интерфейсы и подходы у 1с чертовски устарели, возможно именно потому что там нет места дизайнерам, а реальность такова, что ничего не стоит на месте все развивается, в том числе и требования к интерфейсу/дизайну, и кто им не соответствует скорее всего проиграет конкурентам.
Ответить
Автоматизация бизнеса.
Разработка ПО на платформе 1С:Предприятие
Нагибович Константин
Дмитрий, с какой версией 1С (платформы) вы знакомы?
Ответить
ADZY
Ассистент для ведения рекламных компаний
Дмитрий Кубитский
хехех за 1C со мной поговорить хотите?
я плохо с платформой знаком, потому что с ней не работаю, но я знаком, тк пересекался.
Ответить
Автоматизация бизнеса.
Разработка ПО на платформе 1С:Предприятие
Нагибович Константин
Хотелось понимать на сколько обосновано мнение об устаревших подходах и пр.
Ответить
ADZY
Ассистент для ведения рекламных компаний
Дмитрий Кубитский
я регулярно вижу это платформу, как изнутри так и снаружи, что вижу то и говорю.
Ответить
ADZY
Ассистент для ведения рекламных компаний
Дмитрий Кубитский
дизайнер обязательно должен быть хотяб немного разработчиком, разработчик хотяб немного быть дизайнером, ну и работать всем вместе над задачей, одновременно, а не по отдельности. по-другому просто никак.
Ответить
FORTES
Создаём, продвигаем и заботимся о сайтах.
Ксения FORTES
А потом приходит спец по SEO и вообще всё ломает)) Дизайн должен проектироваться при участии интернет-маркетолога, консультируясь с разработчиком. Иначе получается чушь. Дизайнер не может знать все фишек и плюшек по юзабилити, которые знает маркетолог или сеошник, а также ничего не понимает в разработке. Так же как остальные участники - не понимают в дизайне. Поэтому командой надо работать.
Мне так понравилось работать - делали интерфейс конструктора сайтов. Я проектирую, иду к дизайнеру - сидим думаем, делаем наброски макета. Дизайнер рисует - бегает к разработчику, потом ко мне. Мозговой штурм получается. И учитываются требования всех сторон. Классно было.
Ответить
Симулятор бизнес-процессов
Сервис имитационного моделирования и оптимизации бизнес-процессов
Prolis Labkk
Кроме эстетического удовольствия от введения социальных элементов в работу, ваш пример служит антипаттерном процесса разработки, поскольку:
- нет фиксации сроков, качества и ответственности за результат этапа разработки макета страницы.
- вы тратили ресурс дизайнера и разработчика, отвлекая их от плановых работ
- инструмент мозгового штурма должен был применяться на этапе планирования создания страницы, но никак не в процессе её разработки, поскольку уводит результат в непредсказуемую плоскость.
Ответить
ADZY
Ассистент для ведения рекламных компаний
Дмитрий Кубитский
соглашусь, хотя я бы не стал прямо так фиксировать какой-то точно срок для творческого процесса, а делал бы его паралельно в процессе всей разработки, регулярно пересматривая дизайн (в любом случае это всегда приходится делать, тк это часть продукта - чтоб реализовать возможность проще и удобнее им пользоваться нужно как бы уже подходить к завершающей стадии продукта, который например в самом начале может быть даже и не ясен, какой он там завершающий будет)
ну а в целом, я плохо отношусь к тому чтоб разного рода маркетологи, или не дай бог SEO специалисты как то участвовали в разработке дизайна продукта...
на пушечный выстрел бы их не подпустил.
продукт делаем для людей а не для поисковых машин - ну там проконсультироваться у SEOшника можно например, но не велика наука, а участие левых людей только будет убивать продукт, у дизайнера с разработчиком очень большая задача разбираться самому в этих деталях.
Ответить
Симулятор бизнес-процессов
Сервис имитационного моделирования и оптимизации бизнес-процессов
Prolis Labkk
Не знаю такого творчества, которым нельзя управлять. Художник если не нарисует три иллюстрации в неделю - не будет нанят в проект, поэт не напишет свои 10000 знаков в день - останется без работы. А уж сео- , маркетологов и аналитиков нормировать - сам Бог велел.
Ответить
ADZY
Ассистент для ведения рекламных компаний
Дмитрий Кубитский
всё же творчество это акт божественного рождения)
ты не можешь управлять божественным проведением.
хотя согласен, что если есть задача, её можно решить в определённые сроки, но это скорее не творчество, это скорее халтурка)
любой профессионал может халтурить, но не каждый может творить.
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать