Разработчики «владеют» кодом, так не должны ли дизайнеры «владеть» опытом?

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

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

Дальнейшее чтение на SmashingMag:

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

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

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

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

Этот случай напомнил мне о новостях, которые я видел по местному новостному каналу США несколько лет назад. На окружной ярмарке проходили соревнования на выносливость, в которых приз выигрывал последний человек, оставшийся с рукой на пикапе. Я часто думаю, что дизайн похож на массовую игру «прикоснись к грузовику» , когда команда разработчиков всегда уходит с ключами в конце конкурса. Как и последнее слово в споре, последний человек, который вступит в контакт с сайтом, обладает всей властью и может диктовать, как он работает или как он выглядит. Особенно, если они утверждают, что конкретный целевой опыт «технически невозможен», что часто является сокращением от «действительно сложно», «мне неинтересно делать это таким образом» или «я думаю, что есть лучший способ сделать это». так что я собираюсь вытащить карту разработчика».

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

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

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

Теперь давайте кое-что прямо здесь. Я не говорю, что разработчики не должны проявлять интерес к дизайну или вносить свой вклад в процесс проектирования. Я твердо верю в кросс-функциональное объединение и считаю, что некоторые из лучших решений для удобства использования исходят от технической команды . Есть также много талантливых людей, которые охватывают множество дисциплин. Однако в какой-то момент опыт должен принадлежать, и я не думаю, что им должен владеть последний человек, открывший HTML-файл и «прикоснувшийся к грузовику».

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

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

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