Вы когда-нибудь всерьез задумывались о странностях отношений между разработчиком и дизайнером? Почему специалисты, которые работают вместе над созданием одного продукта, в действительности работают порознь. Безусловно, у каждого свои тараканы и виденье проектов: если дизайнер представляет все с творческой и эстетической стороны, то программисты мыслят технически.
О том, почему разработчики и дизайнеры должны работать вместе, мы писали несколько месяцев назад. Однако один вопрос так и остался нерешенным – как должен вести себя веб-дизайнер, чтобы совместная работа получилась действительно конструктивной и слаженной?
Теорий на этот счет существует множество, но лишь человек, имеющий многолетний опыт такого сотрудничества может в полной мере описать, что нужно, а чего не стоит делать при работе с кодером.
Покопавшись на дизайнерских форумах, в зарубежных журналах и блогах, мы нашли наиболее расширенный ответ на наш вопрос. И, хотя, оригинальный пост был написан еще в 2012 году, он актуален по сей день.
Автором статьи является Дженна Байлотт – дизайнер, проработавшая не один год в крупных компаниях, которая решила поделиться своим бесценным опытом выстраивания отношений с программистами. Более того, она доходчиво объяснила, как, в свою очередь, должны себя вести и сами разработчики, чтобы работа была слаженной и не вызывала дискомфорт.
Итак, как следует себя вести обеим сторонам, чтобы сформировать по-настоящему крепкий творческий альянс, рождающий поистине качественный и хороший продукт.
1. Пользуйтесь теми же инструментами, что и программисты
Начиная работать с программистом, первый шаг, который необходимо сделать, это поинтересоваться, как ему нравится работать. Многие дизайнеры совершают непростительную ошибку, используя в работе методы или инструменты, к которым сами привыкли либо уже были успешно использованы с прежними кодерами. Однако не стоит забывать, каждый специалист уникален: то, что подходит одному, может в корне не нравиться другому.
Разногласий можно избежать уже в самом начале проекта, лишь поинтересовавшись предпочтениями разработчика. Некоторые специалисты любят создать совместный документ для отслеживания ошибок или использовать специальное программное обеспечение. Другим достаточно общения через емайл или использование быстрого способа вроде Pivotal Tracker.
Действительно хороший дизайнер в состоянии адаптироваться к любому предложенному инструменту, который необходим для эффективного взаимодействия двух сторон. И даже если его изучение может отнять некоторое время, это с лихвой окупится, сократив трения и недомолвки в процессе разработки продукта.
2. Участвуйте в разработке проекта с начала до конца
Дизайнер может легко подпортить свои отношения с разработчиком в том случае, когда он просто не участвует в процессе разработки продукта. Нередко программист оказывается в неприятном положении, когда ближе к запуску проекта на него словно коршун налетает дизайнер и требует детальные изменения, которые можно было устранить намного раньше.
Как ни странно, но кодеру необходимо присутствие дизайнера на протяжении всего цикла проекта, а не только для того, чтобы последний разработал внешний вид продукта. Дизайнер должен быть вовлечен в работу и быть в курсе тяжелых задач разработчика. Более того, он должен помогать на любом этапе проекта и праздновать завершение каждого из них, как одна сплоченная команда, даже если это был кривой и сделанный наполовину прототип будущего продута.
Очень часто можно наблюдать, как дизайнеры вмешиваются в техническую эстетику или взаимодействие дизайна начального варианта. Столь ранняя критика и замечания касательно деталей, о которые кодер еще даже не успел подумать, приводит к тому, что программист просто не будет ему давать последующие отчеты. В итоге все заканчивается тем, что дизайнер начинает требовать какие-либо значимые изменения буквально перед самым запуском, но в большинстве случаев, не получает их.
3. Будьте конкретны в своих требованиях
Некоторые дизайнеры уверены, что их работа закончена после того, как готовый макет передан разработчику, а когда проект почти готов к запуску, начинают нервничать и придираться, если внешний вид продукта не соответствует их задумке. Однако вместо того чтобы брызгать слюной и вопить «Это не соответствует моей задумке, посмотрите еще раз макет!» — объясните конкретно, что сделано не так.
Дизайнер – человек творческий. Он и только он может подметить самые мелкие детали, недоступные для взора других. И если программист упустил одну из таких, то сделал это не нарочно. Для него приоритетом является функциональность сайта и написание грамотного кода без багов. Помните, программист не был обучен подмечать все малейшие детали, поэтому ответственность за их нахождение и конкретное разъяснение лежит полностью на дизайнере.
Получив очередную порцию скриншотов от разработчика, не поленитесь детально прокомментировать каждый из них, объяснив максимально конкретно, какие изменения требуется сделать. При этом укажите и выделите все моменты и на самих скриншотах для большего понимания. Научитесь делать грамотный маркированный список всех улучшений – это значительно облегчит работу, как самому программисту, так и вам. Вполне возможно, что подобный метод отнимет у дизайнера некоторое время и добавит работы, зато сбережет нервы и уменьшит беготню перед самым запуском.
4. Общение должно отслеживаться
Нередко дизайнеры предпочитают живое общение с разработчиком, если это позволяет географическое положение обеих сторон либо разговор посредству скайпа и других приложений. Однако, как бы удобно ни выглядело такое обсуждение дел, существует один значительный недостаток – такое общение не оставляет «след». Особенно ощутимые неудобства это может доставить, когда вы работаете с командой.
При разработке любого продукта всегда нужно вести протокол записей или историю общения. Это поможет лишний раз избежать повторных обсуждений одного и того же, а также позволит работать, не дергая друг друга по каждому вопросу.
5. Подружитесь с разработчиком
Частенько люди недооценивают мощь социализации. А между тем более близкое знакомство и дружеское общение на сторонние темы помогут наладить хорошие отношения с программистом и всей командой. Проявите интерес к людям, с которыми сотрудничаете и позвольте им так же узнать себя. Пусть ваш разработчик чувствует, что вы цените его не только как специалист с нужным вам набором навыков, но и как личность.
________________________________________________________
Наверняка программисты довольно потирают ладошки в предвкушении того, как дизайнеры будут идти им на уступки. Однако не стоит радоваться, что вам удастся отделаться от взаимных «жертв». В конце концов, сотрудничество двух сторон предполагает компромиссы, а, значит, и разработчикам предстоит кое-что сделать, дабы наладить отношения с дизайнерами.
1. Не спешите говорить «Нет!»
Для дизайнера нет ничего хуже, чем вдохновиться какой-либо идеей, начать ее обсуждать с разработчиком и получить категоричный отказ в реализации, даже не успев толком объяснить ее потенциал.
Разработчики очень часто негативно реагируют на любые дизайнерские идеи и инновации, и все лишь потому, что они потребуют затраты времени и работы для чего-то не столь важного (по мнению программиста). Но поверьте, каждый дизайнер знает, как тяжело приходится работать кодерам, чтобы сделать жизнеспособный продукт, который не будет постоянно слетать.
Цель совместной работы заключается в том, чтобы создать весёлый, интуитивно понятный и инновационный продукт, который подарит пользователям незабываемый опыт взаимодействия и заставит их вернуться. Иначе, вся та тяжелая работа, что была проделана разработчиком, окажется бесполезной.
Прежде чем в очередной раз сказать «Нет», потратьте немного своего времени, чтобы понять, почему дизайнера так вдохновила эта идея. Обсудите ее с коллегами и попросите совета, как можно получить тот же результат, затратив меньше времени. Будучи открытым человеком готовым к новым идеям, вы сможете вывести ваши с дизайнером отношения на новый уровень и даже приобретете некоторую выгоду.
2. Отладка продукта – это не бесполезная работа
Согласитесь, каждая специализация имеет свои приоритеты в работе. Для хорошего дизайнера внимание к мельчайшим деталям и создание поистине чистого вышколенного UX является первостепенной задачей. Эти, казалось бы, банальные детали играют важную роль. И хотя, их трудно четко объяснить и сформулировать, они влияют на подсознание пользователя, заставляя его реагировать каким-либо образом на продукт. Скопление таких небольших и на первый взгляд незначимых ошибок, может в итоге пробудить у пользователя недоверие к продукту и создать ощущение, что перед ним результат непрофессиональной работы. Опять же хорошо отлаженное приложение может подарить глубокие эмоции и дать понять, что оно спроектировано идеально, но при этом иметь абсолютно «корявый» интерфейс, отдающий небрежностью.
Если дизайнер просит вас чуть подвинуть иконку или слега выправить текст – это вовсе не попытка потратить ваше время впустую. В действительности такие незначительные детали могут создать ощутимую разницу.
3. Устройте совместный «разбор полетов»
Дизайнер, как и разработчик, переживает за успех продукта, поэтому не стоит делать какие-то даже самые малые изменения, не оповестив его об этом. Не нужно ставить его перед фактом, представляя это как данность. Устройте совместный «разбор полетов» перед запуском и еще раз обсудите все детали. Дайте ему возможность обработать полученную информацию и, возможно, предложить свои изменения.
Помните, показывать окончательный проект дизайнеру, просто доводя до его сведения, так же плохо, как запускать его, вообще не показывая.
Надеемся, что опыт Дженны Байлотт поможет построить эффективные рабочие отношения между дизайнером и разработчиком, в результате которых мы сможем получать качественные продукты, приносящие ни с чем не сравнимый пользовательский опыт.
0 комментариев