Каковы здоровые отношения с вашими веб-разработчиками? [закрыто]

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

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

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

Если дизайнеры могут свободно работать с дизайном без каких-либо творческих ограничений, всегда есть инновации через дизайн?

В ваших опытах, что сработало хорошо, и что бы вы сделали, чтобы вы никогда не делали этого?

12 голосов | спросил SidetrackedByLife 7 42013vEurope/Moscow11bEurope/MoscowThu, 07 Nov 2013 20:46:32 +0400 2013, 20:46:32

6 ответов


15
  

В ваших опытах, что сработало хорошо, и что бы вы сделали   уверен, что вы больше не делали?

Хорошо работает:

  1. Будьте дизайнером, который разрабатывает И разработчика, который разрабатывает.

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

Никогда больше не делайте:

  1. Проведите «дизайн» собрания или собеседование без разработчика присутствует.

  2. Присоединяйтесь к фирме, где пользовательский опыт не является приоритетом

Это мои $ .02 на каждый аспект.

ответил Itumac 7 42013vEurope/Moscow11bEurope/MoscowThu, 07 Nov 2013 22:10:37 +0400 2013, 22:10:37
3

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

ответил jazZRo 7 42013vEurope/Moscow11bEurope/MoscowThu, 07 Nov 2013 21:39:32 +0400 2013, 21:39:32
1

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

Итак, давайте притвориться, что вы парень UX, и я разработчик ...

Я всегда должен принимать окончательное решение во всем. Как быстро что-то построено, в значительной степени зависит от меня, и это важный фактор в любом проекте. Но разработчики не боги (хотя некоторые считают, что они есть). Каждый должен подробно рассказать разработчику спецификации и достаточно четко, чтобы он мог просто «хорошо, пришло время писать код». Чем больше времени ваш разработчик задает вопросы, тем хуже получается. Как парень UX, вы поставляете спецификации. Наряду с людьми, которые знают, что это должен делать продукт, и теми рывками в маркетинге, которые дают вам нереалистичный срок. Парень UX - парень идеи, который должен уже знать, как проектировать красивую и простую, и уже сделал это на тоннах прошлых проектов. К сожалению, разработчики любят погружаться в комплекс (это то, что мы делаем), и они обычно не могут отличить красивое от уродливого.

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

Удачи в работе с вашими разработчиками. Нам нелегко справиться.

ответил Stephen Hazel 7 42013vEurope/Moscow11bEurope/MoscowThu, 07 Nov 2013 22:14:59 +0400 2013, 22:14:59
0

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

UX и Development должны быть одним и тем же. Они должны работать вместе с первого дня.

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

ответил DA01 8 52013vEurope/Moscow11bEurope/MoscowFri, 08 Nov 2013 01:46:05 +0400 2013, 01:46:05
0

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

Сейчас уже несколько лет, и более современный томе может потребовать больше наклона Agile /Lean UX, но его, безусловно, стоит прочитать.

ответил calum_b 8 52013vEurope/Moscow11bEurope/MoscowFri, 08 Nov 2013 15:13:07 +0400 2013, 15:13:07
0

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

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

Аналогично, дизайнеры UX должны знать ограничения, с которыми сталкивается команда разработчиков - если разработчик UX разрабатывает что-то технически невыполнимое или потребует больших усилий, это необходимо принять во внимание. Мозговой штурм должен быть беспрепятственным, если придумать идеи для лучшего творчества, но тогда его нужно адаптировать для удовлетворения потребностей проекта (например, крайних сроков /бюджета /возможностей), прежде чем идея будет подписана.

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

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

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

ответил anotherdave 8 52013vEurope/Moscow11bEurope/MoscowFri, 08 Nov 2013 20:57:37 +0400 2013, 20:57:37

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132