Об эффективном взаимодействии внутри команды
В 2014 году меня взяли в маленькую компанию, где надо было создавать дизайн шаблонов для интернет-магазинов. Делать я этого, конечно же, не умела: пришлось много гуглить, читать, изучать и пробовать. Вскоре что-то начало более или менее получаться, и я стала передавать свои макеты программистам (таким же студентам-неумехам, как и я), которые там пилили и бэкенд и фронтенд. Результатами я была не слишком довольна: отступы были неправильные, картинки нарезаны криво, размеры шрифтов не те, и вообще, все не так, как я задумывала. Тогда я решила изучить верстку, чтобы самой возиться со своим пиксель-перфект, который в той компании волновал только меня. Прошло 6 лет, навыки прокачались, сейчас я занимаюсь дизайном (в основном web и mobile) и, если я работаю над сайтом, в 95% случаев я его потом сама и верстаю. Я не делаю бэкенд, админки и не умею во всякие базы данных и фреймворки. Я умею только клево верстать, чтобы все было красиво, адаптивно, четко по макету, плавно, с анимациями и всякими приколами. Этим вступлением я хочу сказать, что порой, помимо дизайнера, я выступаю в роли разработчика, и со мной общаются другие дизайнеры, а значит я могу прокомментировать ситуацию с обеих сторон.
Я много раз слышала иронию в голосах разработчиков, когда речь заходила о верстке: об HTML, CSS (про JS никто не шутит, окей). Типа, это легкотня, с которой вообще справится кто угодно. Но если это так легко, то почему 90% этих ребят на деле так отвратительно верстают? Ответ прост: их это мало волнует. Задача разработчиков — сделать так, чтобы работало. Им чаще всего вообще без разницы, какого цвета будет иконка, и соблюдены ли отступы внутри текстового блока.
В том, что дела так обстоят, никто не виноват. Просто все занимаются своим делом, и это нормально. Нормально, что дизайнер трясется за каждый пиксель, и так же ок, если разработчик не заметил, что фон на самом деле не белый, а немножко #FEFEFE.
Что же с этим делать? Как добиться максимально точного воплощения вашего макета в жизнь? Верстайте сами! (Шутка, сейчас опишу несколько других способов).
Помните, что некоторые вещи кажутся очевидными только вам. Например, что хедер зафиксирован сверху, а ссылки по наведению становятся полупрозрачными. Если проект новый, и вы первый раз выдаете дизайн тем, кто будет с ним работать, то было бы хорошо рассказать о своих макетах, объяснить, как должны вести себя некоторые элементы (если вы задумали что-то особое), а разработчики зададут вопросы, если им будет что-то непонятно. Если проект не новый, тоже периодически сверяйтесь, выдавая, например, новую партию экранов в приложении. Вдруг там добавился компонент, поведение которого стоит описать подробнее. Открытость к общению касается всех участников процесса: если разработчик не уверен в том, что делает элемент, лучше подойти (или написать) и спросить, а не догадываться и потом, возможно, переделывать.
Многие не любят показывать результат работы до того, как все будет доделано. Будь то дизайнеры или разработчики. Я и сама не люблю, причем в обеих этих ролях. Но я с собой борюсь, потому что очень часто несвоевременно продемонстрированная работа будет иметь последствия в виде кучи правок, которые можно было бы сократить, если бы ошибки отловили на более раннем этапе. Несколько раз было так, что я первый раз открывала сборку мобильного приложения со словами: «Это что за п@#%ец?!», потому что казалось, что там не так абсолютно все! Я садилась писать огромные простыни фидбэков, со скришотами и макетами для сравнения, с подробным пояснением, где и что нужно исправить. В эти фидбэки попадал почти каждый экран приложения. В таких ситуацях с кривой сборкой я и сама была отчасти виновата, потому что надо было попросить показать ее раньше и пресечь некоторые моменты «на берегу».
Всем нужно быть немного нежнее друг с другом. Каждый раз, когда я писала правки к приложению, как описано в предыдущем абзаце, я перечитывала их несколько раз, чтобы убедиться, что тон мой нейтрален и я не обосрала чью-то работу. Да, возможно, все выглядело немного криво (с моей точки зрения), но оно работало, а это значит, что люди трудились, старались, пыхтели и сделали. И вместо «ого, круто, молодцы» они не хотят слышать «У вас руки из жопы, все надо переделать» Всегда надо помнить про то, что:
Задача разработчика — сделать так, чтобы работало. Им чаще всего вообще без разницы, какого цвета будет иконка, и соблюдены ли отступы внутри текстового блока.
Сначала надо похвалить! А потом деликатно указать на недочеты. В таком случае разработчик будет доволен, спокоен, и без проблем внесет все ваши правки. Кстати, обычно там все не так страшно, как кажется на первый взгляд дизайнера: им не надо лезть в каждый экран и менять там это кривое поле ввода, им просто надо подредактировать пару переменных.
Если вы дизайнер, то и вашу работу будут постоянно обсуждать и критиковать. Мы сейчас не будем говорить о критике от всех подряд, так как речь идет только о дизайнерах и разработчиках. Так вот: разработчик тоже может вам на что-то указать. Вы тоже можете накосячить с отступами, наделать кучу разных оттенков серого, оставить в макете обрезанные картинки, в общем, допустить некоторые ошибки по невнимательности, и это окей, так бывает, человеческий фактор. Но вам могут задать резонные вопросы по этому поводу, не надо сразу думать, что к вам цепляются: разработчик, вероятно, хочет узнать, как в итоге надо сделать, чтобы потом вы же сами ему не указали на то, что серый не тот, и отступ слишком мелкий.
Если вы работаете над большим проектом (например, админкой или приложением с кучей функций и экранов), было бы прекрасно создать документацию по его основным компонентам. Кнопки, дропдауны, поля ввода, состояния всех элементов. Стили текста, меню, иконки. Эта документация будет постоянно расти вместе с вашим проектом, не забывайте ее пополнять и держать в актуальном виде. Если у вас веб проект — сделайте гайд для разных размеров экранов, покажите, как должно вести себя содержимое на примере самого сложного и навороченного экрана. Пропишите все размеры: контента, отступов внутри блоков, отступов от заголовка до текста, и так далее. Один раз выделив на это время, вы можете избежать кучи правок и потрепанных нервов. А еще, все эти гайдлайны и документации можно классно оформить, а потом даже распечатать, чтобы они были всегда под рукой у разработчика. В общем, это очень полезное и творческое дело!
Дизайнеру хорошо бы понимать базовые принципы верстки, и знать, какие вещи адекватны, а какие не очень. Я сейчас говорю о таких вещах как сетка, размеры макета (и элементов в нем). Часто проблемы бывают именно с этим: все либо огромное, либо наоборот мелкое.
P.S.: Если у вас мало опыта, заскриньте сайт или приложение (в зависимости от того, что вы делаете) и повторите все размеры (шрифт, кнопки, расстояния) с этого скрина. Сделайте это несколько раз и у вас появится понимание, где убавить, где прибавить). Здесь можно почитать о том, как поменьше косячить в дизайне.
Некоторые вещи из дизайна не могут быть воплощены в реальный проект без супер кривых и долгих костылей. Например, супер-мега-офигенная тройная тень под кнопкой не будет видна в некоторых версиях Android. А выбор времени и даты зачастую лучше сделать нативным «барабаном» в iOS, вместо того, чтобы мастерить кастомный велосипед. Не забывайте о таких важных вещах, как бюджет клиента, и время разработчика, которое оплачивается из этого бюджета. И некоторыми красивостями и приколами дизайна придётся пожертвовать почти в любом проекте (только если это не ваше детище, и вы сами все пилите, и у вас неограниченное количество времени).
Не думайте, что кто-то пренебрегает вашим дизайном и лепит что попало, иногда действительно придётся находить компромисс. Но не давайте себя надуть: вам может попасться ленивый разработчик, или тот, кто не хочет признать, что что-то не умеет. Если у вас есть ощущение, что вам вешают лапшу на уши, тихонечко спросите у других разработчиков, действительно так ли сложно внедрить эту фичу или нет.
Если вы придумали что-то грандиозное, необычное и классное, то всегда лучше заранее спросить у разработчика, сможет ли он это воплотить. Речь идёт о каких-нибудь сложных анимациях, нестандартном поведении элементов. Было бы совсем хорошо, если бы вы показали пример реального проекта, где такое (или похожее) уже сделали, тогда разработчик сможет посмотреть, как именно это было реализовано. Если не покажете и не спросите заранее – есть риск того, что вы потратите время на дизайн этой супер-классной штуки, которая в итоге пойдёт в ящик и никогда не увидит свет. Время потрачено, деньги потрачены, грусть от нереализованной фичи засела в душе. Никому это не надо, избегайте этого.
Беда многих коллективов состоит в том, что каждый пытается прикрыть свою жопу и свалить вину на другого. Типа, вы сделали свою часть работы, а там дальше, у других, что-то пошло не так. Так вот, если проект дошёл до продакшна в сыром, стремном виде – виноваты абсолютно все участники. Всем будет совершенно без разницы, что ваши макеты идеальны, там подписаны все слои и сгруппированы все блоки, если результат получился неважным. Вы должны быть настырными, и трясти всех, если нужно, хоть по 50 раз. Именно вы должны убедиться, что разработчики ничего не упустили, и все сделано как надо.
Все вышеперечисленные тезисы относятся к категории не совсем очевидных скиллов и обязанностей хорошего дизайнера. Если вам не хочется этим всем заниматься, и ваша главная цель — это выставить новую картинку на дриббл, то лучше станьте художником, потому что продуктовый (и все возможные названия этого направления) дизайн — это не про идеальные макеты, это про результат и опыт пользователя. И чтобы эти результат и опыт были максимально положительными, вам надо работать в команде. Разработчик должен стать вашим лучшим другом, вы не должны с ним спорить и ругаться. Если надо кого то обосрать, помните, что всегда есть менеджеры 🙂 (шутка) (почти).
Загрузка...
