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

Отследить-посылку

отследить-посылку.рф

25
Битрикс24

Битрикс24

www.bitrix24.ru

13
WebResidentTeam

WebResidentTeam

webresident.agency

12
Логомашина

Логомашина

logomachine.ru

12
Devicerra

Devicerra

devicerra.com

11
Reader

Reader

Интернет-журнал о современных технологиях.

9
ADN Digital Studio

ADN Digital Studio

adn.agency

9
Aword

Aword

Приложение для изучения английских слов

9
GIFTD

GIFTD

giftd.tech

8
Eczo.bike

Eczo.bike

www.eczo.bike

Показать следующие
Рейтинг проектов
Подписывайтесь на Спарк в Facebook

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

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

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

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...

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