Дизайнеры и разработчики: больше никаких разделений

Posted on by riasevastopol

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

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

Проект редактора CSS 4 вышел в первых числах Февраля, и весьма легко утонуть в его богатых и захватывающих возможностях. Мы еще не совсем изучили CSS3; для новичков в мире программирования, знать, с чего начать возможно сродни поиску иголки в стоге сена. прогресс и Этот рост имеет минусы и свои плюсы, и приводит к вопросам о границах между дизайном, разработкой, логикой и творчеством, как они сочетаются между собой, и как мы приспосабливаемся к этому.

1-designers-developers-opt

код и Дизайн: не совсем различные понятия.

Сейчас, как в дизайне, так и в разработке происходит дезинтеграция на все более и более специальные дисциплины.Дизайнеры и разработчики: больше никаких разделений на данный момент практически нет для того чтобы понятия, как веб-дизайнер; имеется интерактивный дизайнер, визуальный дизайнер, UX дизайнер либо что-то совсем второе. Слово “разработчик” кроме этого прекратит существовать.

Какой разработчик? Back end, front end, full stack, iOS, Android, веб – либо что-то совсем второе? Заглавия вакансий стали более конкретными, а навыки увеличиваются.

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

Создавать дизайн чего? Любой фреймворк либо принцип дизайна имеет собственные неповторимые зависимости, совсем личный комплект управлений. Помимо этого, без использования на практике, будь то в отечественной работе либо нет, эти знания легко забудутся.

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

Cameron Moll в первых числах Января написал об этом в Twitter, что захватило внимание дизайнеров и позвало у них эмоции. Кроме этого напрашивается вопрос, из-за чего никто не ожидает аналогичного от разработчиков, команд, менеджеров, начальников проектов либо любого второй участника команды? Из-за чего выговор не делается на сотрудничестве и совместной работе, на упрочнение неспециализированного понимания, основанном не на технических знаниях, а на межличностном познании?

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

Тогда

Четыре года назад, в далеком 2010 году, Elliot Jay Stocks высказал собственный удивление в Twitter, что так же, как и прежде существуют веб-дизайнеры, каковые не смогут писать код для собственных собственных проектов. Treehouse привел данный твит в собственной статье “5 веских обстоятельств, из-за чего дизайнеры должны писать код” и в контексте того времени, это имело суть. CSS3 еще не показался.

HTML5 был еще огоньком в глазах W3C, достигнув собственного первого публичного рабочего проекта лишь в 2008 году. Термин “адаптивный веб-дизайн” будет введен лишь через четыре месяца.

Это было превосходное время, мысль дизайнера, изучающего код не была подавляющей, по крайней мере, оглядываясь назад, и это имело возможность стать нормой. Но ожидание было ясным: “Обучитесь писать код” свидетельствует “изучите HTML и CSS,” либо определите достаточно, дабы осуществить проекты. Помимо этого, “дизайн” не выходил за пределы Adobe и пределы создания плоского дизайна веб-сайтов.

Была четкая граница между разработкой и дизайном, но ее больше нет.

и по сей день

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

Речь заходит не о воплощении дизайна статической веб-страницы в судьбу. Имеется направления по iOS разработке и прототипированию, и такие компании, как Fast Company предлагают управления о том, как начать работу, в том случае, если вы растеряны. Кроме этого существует Ruby on Rails, и перемещение визуализации данных продолжает усиливаться .

Обращение сейчас идет не просто о превращении PSD в HTML, но о разработке для iOS и создании веб-приложений в Ruby либо AngularJS либо в том, что применяет ваша компания либо клиент. код и Дизайн влились приятель в приятеля при помощи таких понятий, как SVG различные библиотеки и анимация визуализации данных. Но это лишь капля в море возможности, и нам не нужно ждать, что мы можем его пересечь.

Susan Robertson пишет в A List Apart о том, что все говорит о коде, о “постоянном давлении выяснять новое и идти в ногу со всеми последними идеями”.

4-designers-developers-opt

Как выбрать предмет изучения среди стольких вариантов?

Это давление не страно, но его возможно избежать. Дабы убедиться, что то, что мы изучаем, будет полезно для нас, мы должны задать вопрос себя, из-за чего перемещение “обучитесь программировать” имеет первостепенную важность. Оно существует, дабы содействовать межведомственной связи, дабы сделать процесс создания продукта намного более ровным.

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

Отыскать неспециализированную базу

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

Как разработчики и дизайнеры мы станем лишь лучше, обучась общаться между собой.

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

И еще, Sam Hernandez, кроме этого разработчик в Happy Cog, признает неповторимые неприятности общения разработчиков в частности, но он кроме этого говорит, что ведущие разработчики не избегают их; скорее, они находят методы общаться и сотрудничать с нетехнической группой. Эти разработчики чутки не только к дизайну, вместе с тем к клиенту и продукту. Они наблюдают на вещи шире.

В это же время, мир дизайна на данный момент замечает перемещения, такие как атомарный дизайн Brad Frost – управления дизайна, каковые заимствовали концепции из объектно-ориентированного программирования. Дизайнеры смогут (и должны) применять инструменты, такие как Zeplin и Specctr, дабы лучше донести собственные проекты до разработчиков. Smashing Magazine предлагает управление по созданию технических спецификаций, каковые будут нужны для разработчика, но не отнимающие через чур много времени дизайнера.

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

Мы иногда забываем, как схожи разработка и дизайн, и они оба вычисляют креативность собственной базой. Великие разработчики и дизайнеры видят креативность как главную часть собственной работы, но их редко связывают. Термин “креативный” употребляется только (и ошибочно), подразумевая “дизайнер”.

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

2-designers-developers-opt

Специализировать и обобщать в равной мере.

Разработчики наблюдают на дизайнеров и видят живописцев, тогда как дизайнеры наблюдают на разработчиков и видят математиков либо ученых. Не смотря на то, что это возможно правдой в какой-то мере, такие мысли оказывают нехорошую услугу обеим профессиям. В ходе работы оправдание “У меня нет задатков живописца” принимается от разработчика, что не заинтересован в дизайне, тогда как “Я не кодер” не принимается от дизайнера.

Эти оправдания излишни; креативность – ответственная составляющая обеих дисциплин, и чем раньше мы это осознаем, тем лучше.

Мышление, а не технические подробности

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

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

Paul Lloyd утверждает, “Вместо того дабы разглядывать себя в дискретных ролях, мы должны вместо этого выделить отечественный спектр возможностей, и трудиться с теми, чьи навыки дополняют отечественные”. Мы должны приводить разработчиков на встречи на начальной стадии создания проекта, а дизайнеров на бэклог встречи. Brad Frost напоминает нам, “Современный процесс веб-дизайна требует интенсивного сотрудничества между дизайнерами и front-end разработчиками”, и не смотря на то, что он ратует за HTML и CSS в частности, это возможно распространено на другие языки и фреймворки.

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

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

Позволяйте идти друг другу навстречу.

Пойти навстречу и двигаться вперед

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

Кроме этого нет никаких обеспечений, что знания о программировании либо дизайне, каковые мы возьмём в одном проекте, будут нужны (либо кроме того нужны) в следующем, что не радует. Дизайнеру нет необходимости проходить полный курс Ruby, в случае если это не принесет пользу ни одному из его будущих проектов.

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

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

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

Изучение межличностных навыков кроме того не входило в повестку дня; а должно было.

3-designers-developers-opt

Как настоящ “единорог”, и должны ли мы стремиться к нему?

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

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

К примеру, в следствии ретроспективы, отечественная команда объединилась чтобы уменьшить общение. Я поведал о некоторых переживаниях по поводу технической стороны проекта, и в как следствие взял возможность определить больше о Drupal. Я кроме этого знаю, какой способ общения применять (устный, email, Skype, пистолет NERF), в зависимости от того какое время суток либо в наушниках мой сотрудник либо нет.

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

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

Уважайте работу друг друга и не пробуйте определить то, что вам не весьма интересно. Ежедневно появляется все больше ресурсов: Learnable Programming и Dynamic Pictures от Bret Victor, iulang, HackDesign и многие другие. Применяйте их, дабы определить собственную команду, дабы сотрудничать с ними, а отражать их.

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

Учитесь признательности и сотрудничеству, и это окажет помощь нам стать лучшими экспертами.

Перевод статьи

Случайные статьи:

ПОСВЯЩЕНИЕ В ДИЗАЙНЕРЫ


Подборка похожих статей:

riasevastopol

More Posts