x
 
↑
Февраль
3 •

5 •
4 •
10 •

5 •
↓
Андрей
4 февраля 2011

Здравствуйте!

Скажите, как отучить дизайнера лезть в код? На самом деле это очень большая проблема, когда дизайнер начинает считать себя специалистом в еще какой-то области кроме дизайна. И еще хуже, когда дизайнер начинает ощущать себя професионалом в программировании или верстке.

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

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

Спасибо!

Что за глупости?

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

Я, например, понятия не имею, как залезть на сервер разработчиков бюро.

И ещё. Сегодня пятница, и ваш вопрос хотя и не о клиентах, но о взаимоотношениях. Любые переговоры начинаются с анализа ситуации.

Так вот, дизайнер — довольно зависимый от технолога человек. Как только вы это осознаете, ситуация повернётся на сто восемьдесят градусов. Я прекрасно помню, как на предыдущем месте работы приходил на поклон к Юриклу и Личи, если эти имена вам знакомы, с просьбой подвинуть иконку на пиксель. А за пару лет до этого они по капризу дизайнера за ночь нарезали по триста гифов из текстовых надписей.
P. S.
Это был пятничный совет по взаимоотношениям с клиентом. Хотите получить совет по самой эффективной системе переговоров без оружия? Присылайте вопросы.
P. P. S.
Кстати, вопросы заканчиваются.

Поделиться
Отправить

Комментарии
Алексей Мельников
4 февраля 2011

Способ второй, изящный.

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

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

Сразите дизайнера. Никакие запреты и уговоры не действуют на человека так, как собственное мнение.
Евгений Ширин
4 февраля 2011

Андрей, первый вопрос, который у меня возник: почему дизайнер лезет в код и в какой именно код он лезет? По всей видимости, речь идёт о верстке, а не работе базы данных или исполняемых модулей. Полагаю, что дизайнера не устраивает результат использования его макетов.

На самом деле это действительно большая проблема. Я неоднократно сталкивался с ситуацией, когда после вёрстки классный макет превращается в ужас. Подчас разговоры о том, что сделать нужно иначе, наталкиваются на фразы типа: «так сделать невозможно». Хуже всего, когда ты знаешь, что это сделать возможно и проще самому всё исправить за несколько минут, чем растягивать дебаты на несколько часов.

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

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

После того, как вёрстка макета согласована с дизайнером, он больше в вёрстку не лезет.

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

Чтобы не было желаний лезть в код — ставьте пароль.

Ещё совет: введите стандарты для вёрстки, в которых будут даны основные требования и запреты.

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

Польза очевидна. Например, я как менеджер не могу физически отслеживать все тенденции и новые технологии в сфере дизайна, вёрстки, программирования и т. д. Когда сотрудники рассказывают друг другу, что появилось нового, то и можно предлагать клиентам более интересные решения. Возможно, появится какая-то идея, как применить ту или иную технологию в рамках текущих и новых проектов.
Валентин Силютин
4 февраля 2011

Как я понимаю, вашему дизайнеру не нравится, как работают технологи

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

На мой взгляд, ничего не нужно запрещать — это не решение проблемы. Решение — коммуникация и понимание того, что все здесь — профессионалы. Дизайнер не считает программистов профессионалами, которые знают что делают и делают это правильно. У дизайнера нет «уважения» к работе программистов, если хотите.

Так что технологам нужно выслушать все претензии дизайнера к их работе и, если дизайнер и правда мало понимает в программировании и вёрстке и его претензии ошибочны — объяснить ему, почему вы делаете именно так, а не иначе. Причём объяснить это не отговорками, наподобие «так надо», а подробно и предельно ясно — если ваши технологи профессионалы своего дела — они, думаю, вполне на это способны.

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

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

Считает дизайнер себя великим гуру программирования? Окей. Дайте ему написать часть проекта самому. Не хочет — заставьте. А после, в сравнении с профессионально написанным кодом, покажите ему всю ущербность его позиции.

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

На мой взгляд (применял подобный подход), вменяемым людям становится понятно практически сразу. А главное, что мне нравится, получается без шума и ругани — человек сам всё понимает на «живом» примере.

Если же и после этого человек не понял — смело увольняйте. Нервы дороже, тем более что найти талантливого дизайнера сегодня, на мой взгляд, не проблема. С программистами и технологами куда сложнее :-)

Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

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

Вот такой веб 2.0.
Собираем и наполняем сайт одному дилеру известной автомобильной марки по гайдлайнам представительства Хозяин конторы принимает все решения относительно любого дизайна и вообще 3 • Клиент хочет на сайте цветок. Железно 4 • Артём, пытаюсь не допустить настойчивого предложения сделать выключку текста по ширине в вебе 10 •




Недавно всплыло

1 • Выбранные элементы списка, как не забывать принципы из советов бюро и когда нужен логотип 1 • 1 • Какие законы для текста, который будет восприниматься только на слух? 1 •