Как объяснить проект-менеджеру где заканчивается его работа и начинается работа проектировщика интерфейсов?
=============================================================================================================

 Существует такой конфликт на работе. Я занимаюсь проектировкой интерфейсов, к нам привели девочку, которая ведет проекты и совершенно не представляет, кто за что должен отвечать на работе.   

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

Начальство занято своими делами и в разногласии не участвует. Мне это очень мешает работать.   

Вопрос заключается в том, как объяснить проект-менеджеру, что в этом заключается моя работа. Есть ли какая-то статья, в которой описано, что делает проектировщик и зачем это нужно? 

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

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

Создание интерфейса — это задача дизайнера. Менеджер должен предъявлять вопросы и озвучивать реальные или возможные проблемы перед дизайнером. Но правки и переделки должен делать сам дизайенр, своими руками. Важно еще понимать, в какой форме менеджер должен ставить задачи перед дизайнером. Он не должен просить дизайнера «сделать кнопку красной, а не зелёной». Он должен сформулировать проблему в целом — например, «нам нужно увеличить число кликов по кнопке в два раза» — чтобы дизайнер сам подумал, как её лучше решить и предложил свой вариант.  
  

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

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

 ИМХО. Дизайн нужно показывать и обсуждать, но конечное решение по внесению изменений в дизайн должен принимать один человек, который что-то понимает в интерфейсах (**адекватный** руководитель проекта на эту позицию подходит больше чем дизайнер : ) )  
  

У дизайнеров (не у всех) есть такая черта характера: "я нарисовал все смотрится круто, а вы поганите дизайн". При этом многие не думаю о бизнес задачах, которые должен решать этот дизайн.   
  

Ну а если дизайн пошел по рукам и дошел до топ-менеджмента, то жди беды :) 

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

2. Вы с PM должны согласовывать прототип, доказывайте целесообразность своих решений. Если не можете, значит вы плохой проектировщик. Я когда получаю комментарии по своих прототипам, выслушиваю замечания, с чем-то соглашаюсь, что-то отстаиваю, что-то отдаю на усмотрения PM.   

Главное не закрываться. 

 А спросить ее не пробовали? Дизайнер должен уметь обосновать свою работу, иначе получается что вы делаете проект основываясь только на "своем виденье" и получается что тоже вроде как не совсем правы. К примеру: каким образом опрос сотрудников может улучшить интерфейс если они не являются целевой аудиторией? На чем она основывает свои правки? Готова ли она презентовать клиенту проект и обосновать свои правки ему? И самое главное, согласна ли она что за время потраченное на правку ее правок платит она сама? Поскольку за клиентские правки платит клиент или компания. 

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

Поэтому, мой процесс проектирования интерфейсов следующий:  

1. Зарисовать идею  

2. Выцепить какого то мидла в теме по проекту, показать и переделать 20%  

3. Показать фронтенд разработчику, передвинуть по другому  

4. Показать клиенту  
  

Если менеджер делает 2,3,4 пункт то она делает всё правильно. Если же процесс идет от 1 к 4 проходя 2,3 то это ошибка. А кто там спрашивает, это уже вопрос договорённости в коллективе. И как раз менеджер должен инициировать обсуждения о договорённости о фидбеке внутри команды. Все важные процессы должны иметь фидбек заинтерисованным лицам внутри или за пределами команды. Коммуникации на плечах менеджера. 

 "Режим психолога":  
  

Дело ведь не в том, чтобы объяснить менеджеру, где кончается его работа, а начинается работа проектировщика,  

а в том, что вы [sallivana](http://toster.ru/user/sallivana) недовольны тем, что девочка вторгается в ваше личное пространство и может даже забирает часть вашей славы. Ведь, когда её не было, то вся слава за удобные интерфейсы доставалась вам, а тут приходит новичок и учит жить "бывалого", что будто бы дискриминирует вас как профессионала. И у вас появляется страх, что у коллектива или даже клиента может возникнуть мысль о том, что вы не очень-то и нужны, ведь интерфейс "коллектив делал", а вы так только "рисовали" (но мы то с вами знаем, что это не так).  
  

Ваш менеджер девочка тоже не права. Она мешает работать всей команде и не только вам. Задача любого юзабилити теста - это выявление проблем. Участники не должны сами придумывать решения, т.к. всю картину знаете только вы, а они нет и их решения могут "родить" проблемы в других местах.  
  

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

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

Также добавлю, ещё то, что полезно было бы видеть как интерфейсом пользуются разные и незнакомые вам люди, а не одни и те же, т.к. постоянные тестировщики, могут привыкнуть к вашим "фишкам" а сторонние их не поймут с первого раза. И для них нужно придумать механику обучения. 

 Хороший интерфейс вряд ли бы исправляли) Ну и коллеги у вас те еще жучары - ни какой проф этики) 

*>Начальство занято своими делами и в разногласии не участвует.*  
  

Я бы с такой фирмы уволился. Просрёт бизнес начальство которому до лампочки процессы внутри собственного предприятия. 

> Как объяснить проект-менеджеру где заканчивается его работа и начинается работа проектировщика интерфейсов?

  
  

Скажите менеджеру чтоб сам делал интерфейс, если он/она такой умный.   
  

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

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

В качестве примера ведения у всех на поводу мне сейчас вспоминается совершенно антиюзабельный финт - всплытие описания картинки поверх картинки при ховере. Совершенно бесит и встречается теперь совершенно везде.