3. Презентуй свои решения

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

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

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

🍿

Рассказывай связно

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

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

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

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

✋

Не торопись

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

🦖 🐳 🦄

Многообразие вариантов

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

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

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

То есть общее правило такое: изменились условия, появилась новая информация — заново решай задачу. Обычно удается исправить лучшее из решений, а не проектировать задачу с нуля.

Почему команды хотят выбирать из множества вариантов?

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

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

Не могу выбрать лучшее

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

Ты можешь провести коридорное тестирование своих решений. По-началу это может казаться диким. Но тут все свои. И даже если ты не знаком с ребятами со своего этажа, мало кто откажется, если на кухне ты подойдешь к незнакомому человеку с вопросом, может ли он помочь протестировать задачку. Если не знаешь, как правильно задавать вопросы, как показать задачу для тестирования, ребята из твоей дизайн-группы или наставник тебе помогут.

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

Выводы

Хороший рассказ о задаче помогает понять команде, почему и как ты принимаешь решения, у ребят формируется доверие к твоей работе. Не стоит вываливать команде несколько вариантов решений для выбора. Разберись сначала сам, что лучше, и презентуй этот вариант.

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

Прошлые заметки этой серии
1. Начинающему проектировщику.
2. Общайся.