Рекомендации для улучшения взаимодействий с дизайнером (в продукте)

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

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

Иногда возникают недопонимания в работе. Это может быть вызвано разным восприятием некоторых процессов. К сожалению, такие недопонимания могут привести к более серьезным проблемам в будущем, если не будут решены.

Проблемы могут возникать на разных стадиях и в разных областях:

Проблемы возникают из-за различного видения процесса и неясности обязанностей конкретных специалистов.

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

Грубо говоря, процесс проектирования можно разделить на 3 этапа: 1) работа аналитика, 2) работа дизайнера, 3) совместная работа.

Давайте рассмотрим конкретный кейс более подробно.

Аналитику поступает задача разработать “комментарии”. Он прорабатывает функциональные требования с заказчиком и передает их дизайнеру. Примеры функциональных требований:

Аналитик также дает дополнительные комментарии: "Мне кажется, что функциональность Telegram очень удобна, и мы можем сделать что-то подобное. Мы можем разместить комментарии в сайдбаре, чтобы имитировать мессенджер". Такие комментарии от аналитика очень полезны, поскольку дизайнер может использовать их в качестве референса. Главное в этом моменте то, что дополнительные комментарии об интерфейсе должны быть рекомендательного характера, UI и UX — ответственность дизайнера. В итоге может возникнуть ситуация, когда дизайнер, проанализировав Telegram и другие мессенджеры, решит, что лучшим аналогом является Slack, и реализует это в интерфейсе. Аналитик же будет считать, что задача выполнена неправильно, хотя все функциональные требования были учтены. В результате возникают споры, и время на проектирование увеличивается.

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

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

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

В этом блоке описаны основные проблемы связанные с общением и рекомендации, как можно свести к минимуму появление этих проблем. Рекомендации работают в обе стороны.

1. Проблема постановки задачи. Сотрудник не может четко сформулировать свой запрос. Либо руководствуется личными предпочтениями (субъективное мнение). Как итог, получает не то что представлял, либо результат который нравится только ему, но не пользователю.

Как четче донести свои мысли:

2. Недостаточно конструктивный фидбэк. Мало тезисов и информации от принимающей стороны. Либо руководствуется личными предпочтениями (субъективное мнение). Как итог, на этапе доработок, есть вероятность обидеть исполнителя, или отправить его на следующий, безуспешный этап переработки, так как нет четких ответов на вопросы исполнителя

Конструктивный фидбэк:

3. Невосприимчивость к критике. Некорректно трактует фидбэк, принимает все на личный счет, начинает обижаться и отстаивать свое решение. Как итог, нет желания работать или наоборот специалист, начинает яро отстаивать свою правоту

Как принимать фидбек:

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

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

Рекомендации для многоуровневого согласования:

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

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

Тут будет объяснение оставшихся пунктов, чтобы лучше понять о чем думает специалист и что он чувствует.

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

Можно включать дизайнера в звонки с клиентом или в первые обсуждения проблемы и планирование. Это позволит дизайнеру лучше и быстрее погрузиться в проект (в идеальном мире). Однако, это не всегда возможно, так как зависит от загруженности дизайнера и клиента.

Споры с дизайнерами. Это не спор, а скорее дискуссия))) Все стараются прийти к идеальному решению, включая дизайнеров. Однако, необходимо уважать друг друга и следить за тоном разговора. Иногда лучше сделать паузу и вернуться к обсуждению позже.

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

Может показаться, что это все обычные рабочие моменты, которые не имеют никаких последствий, вот несколько примеров, чем это чревато: