Интернет развивается с головокружительной скоростью, и разделение между традиционным дизайном и разработкой все больше смещается. Движение “научитесь писать код” также набирает обороты среди дизайнеров, но было бы сложно найти аналогично развивающееся движение для других направлений в команде. Возможно, оно есть.
Мы все должны стремиться узнавать что-то новое, но остается все тот же вопрос, что именно мы должны изучать? Нам могут ответить простыми фразами, как “учитесь разрабатывать” или “учитесь создавать дизайн”, но на самом деле нам нужно научиться общаться и сотрудничать, уважать чужую работу – и артистизм, не пытаясь овладеть ее полностью.
Проект редактора 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. Я также знаю, какой метод общения использовать (устный, электронную почту, Skype, пистолет NERF), в зависимости от того какое время суток или в наушниках мой коллега или нет. Это кажется очевидным, но это та информация, которую мы не получим, если мы не спросим, и мне кажется это столь же ценно, как изучение кода. Обращаться к прошлому не всегда легко, и это только один пример, но какую бы технику мы не использовали, важно знать об эмпатии.
Так как индустрия все больше делится на специализации, единорогов больше не существует, и никто не должен стремиться быть им. Вместо этого, специализируйтесь на том, что вы любите, и узнайте, что вдохновляет вас на креативность и что разжигает ваше любопытство. Узнайте все, что поможет вам осуществить свои мечты или открыть целый мир возможностей. Уважайте работу друг друга и не пытайтесь узнать то, что вам не интересно. Каждый день появляется все больше ресурсов: Learnable Programming и Dynamic Pictures от Bret Victor, iulang, HackDesign и многие другие. Используйте их, чтобы узнать свою команду, чтобы сотрудничать с ними, а отражать их.
Эти личные знания вы можете перенести на другие проекты с гораздо большей пользой, чем один язык программирования или принцип дизайна. Узнайте, как ваши коллеги думают и почему они пишут код определенным образом, или почему они выбирают тот или иной шрифт. Это бесценный опыт, вид личного совершенствования, что я считаю, делает нас гораздо более опытными, чем изучение тонкостей разработки фреймворков или типографских различий, когда человек рядом с нами уже знает, как это делать. Учитесь сотрудничеству и признательности, и это поможет нам стать лучшими специалистами.
Перевод статьи
