Всё зависит от того, в чём именно проблема. Можно ведь представить ситуацию, когда незнание дизайнером нюансов разработки не вызывает проблем. Дизайнер делает макеты как умеет, разработчик по ним реализует как умеет, все довольны.
Если дизайнер недоволен
Но допустим, дизайнеру не нравится, как разработчик реализует. В голове дизайнера всё должно вести себя не так, как получилось. Как объяснить это разработчику, если не владеешь техническим языком? Можно попробовать на примерах:
— Иван, а оно как‑то не так работает, как я хочу, но я не могу точно объяснить, в чём дело. Посмотри, пожалуйста, вот на этот сайт: ссылка. Попробуй его поскроллить, видишь как там происходит то‑то и то‑то? Я хочу так же, а у нас я вижу такие‑то отличия. Я ещё вот скринкаст снял, посмотри на такой‑то секунде: видео. Чего нам не хватает, чтобы так же было?
Обращаясь к разработчику, важно включить режим максимальной скромности и готовности помочь. Представьте, что вы написали как‑то в духе «Вот ссылка, нужно сделать как там». Может ведь быть, что у вашего разработчика и так реализовано «как там», но там — текстовая страница, а у вас — тяжёлое видео, и поэтому всё то же самое уже тормозит. Ваш пример не помогает, а форма обращения вызывает раздражение. Или может быть, что там фоновая картинка нарисована с запасом по размеру, а у вас запаса не хватает, и поэтому по вашим макетам просто не сделать такое. Вам самому нужно сделать «как там», прежде чем требовать чего‑то от разработчика. В той же формулировке, которую предложил я, у разработчика сразу будет ощущение, что обратиться к вам легко за другим примером или изменениями в макете. А на этом ощущении он и со своей стороны внесёт нужные изменения охотнее.
Если разработчик недоволен
Другой вариант — разработчик недоволен дизайнером: считает, что макеты подготовлены не так, как надо; важные ситуации не рассмотрены; ассеты не выгружены в нужном формате; в описании желаемого поведения — дыры и логические противоречия. Мы исходим из того, что проблема не в том, что дизайнер ленится, а в том, что он просто пока не понимает, что и как правильно делать. Что ж, тогда снова нужно помочь разработчику:
— Иван, прости, что у меня бардак в макетах и сообщениях, я пока только учусь нормально передавать дизайн в разработку. Помоги мне сделать всё как надо. Чего недостаёт в макетах, чтобы их было удобнее разрабатывать? Какие ситуации нужно ещё нарисовать? Какие противоречия в описании? Если хочешь, можешь мне войсом записать все свои вопросы или давай созвонимся, как тебе лучше. Или если есть какой‑то пример, который мне стоит изучить, дай ссылку, пожалуйста.
Здесь снова важно, чтобы разработчик чувствовал, что дизайнер хочет сделать всё нормально, а не просто расслабленно делает кое‑как, оправдываясь тем, что не разбирается в разработке. Вообще в обязанности разработчика не входит обучение дизайнера, но тут уж что поделаешь: он сам дизайнером недоволен, а дизайнер старается «въехать» изо всех сил. Чтобы у разработчика не возникало ощущения, что объяснять бесполезно, придётся всё внимательно изучить и начать применять, а если что‑то непонятно, то задать следующие вопросы, причём из которых будет ясно, что всё, что могли, вы уже поняли.
Может возникнуть вопрос: почему в моей модели именно дизайнер всегда должен как‑то заботиться об удобстве разработчика, а не наоборот. А это просто потому, что вопрос был именно со стороны дизайнера. Спросил бы разработчик, как общаться с дизайнером, когда не разбираешься в дизайне — ответы бы перевернулись.
Приглашаю уважаемых советчиков поделиться своими примерами и возражениями.