Каждому дизайнеру хочется эффективного общения с разработчиками в команде. Здесь я поделюсь несколькими советами из своего опыта.
Что мы знаем о создании продукта, так это то, что дизайнер создает продукт не в одиночку. Многие заинтересованные стороны должны быть вовлечены в процесс создания и вместе формировать продукт.
Дизайнеры во многих компаниях очень тесно работают с менеджерами по продуктам, владельцами продуктов, командами QA, но в большей степени со всеми этими людьми. Дизайнеры очень тесно работают с разработчиками.
С моей точки зрения, очень тесные отношения между дизайнерами и разработчиками оказывают наиболее значительное влияние на конечный продукт.
Им необходимо тесно сотрудничать, чтобы решать проблемы удобства использования и технические проблемы, чтобы приносить значительную пользу клиенту.
Из-за близких отношений важно создать отличные отношения и эффективное общение между ними.
Многие продуктовые команды испытывают трудности в общении друг с другом, дизайнеры не понимают разработчиков, а разработчики не понимают дизайнеров.
Плохое общение создает множество трений и недопониманий между дизайнерами и разработчиками и приводит к переделкам, стрессу и плохим отношениям внутри команды.
Последние шесть лет я тесно сотрудничал с разработчиками, что позволило мне понять их с разных точек зрения.
Цель статьи - поделиться некоторыми советами, которые я узнал об отношениях и общении с разработчиками. Я убежден, что вы найдете эти советы полезными и сможете применять их в своей повседневной работе.
Убедитесь, что все члены команды знакомы с пользователями, продуктом и его назначением
Иногда не все члены команды знают, что делает продукт, кто пользователи и его цель. Сначала это кажется забавным, но иногда разработчики действительно работают над продуктом, не осознавая всех этих аспектов.
В большинстве продуктовых групп продуктовому менеджеру необходимо согласовать это со всей командой, но это не всегда происходит.
Этот пробел в знаниях может вызвать ненужные обсуждения, поскольку разработчики могут не знать об этих ключевых факторах.
Как избежать этого пробела в знаниях?
- Проведите стартовую встречу
Прежде чем ваша команда приступит к работе над большим проектом или важной пользовательской историей, проведите стартовую встречу. На этом стартовом собрании вы и команда рассматриваете все потребности проекта и пользователей, чтобы все члены команды могли согласовать это. На этой встрече команда также может обсудить выполнимость или потенциальные проблемы, с которыми они могут столкнуться в этом проекте. Вы можете взглянуть на веб-сайт Atlassian. У них есть отличный шаблон о том, как организовать стартовую встречу. Я считаю, что подготовка к этой встрече может быть полезной. - Задавайте ключевые вопросы
Если вы разговариваете с разработчиками и чувствуете, что не понимаете друг друга, вы можете задать им следующие простые вопросы:
- Кто наш пользователь , и чего он хочет достичь?
- Чем занимается наше приложение?
Услышав их ответы, вы быстро заметите пробел в знаниях.
Иногда вы обнаружите что они чего-то не понимают в продукте, и иногда вы заметите, что у вас пробел в знаниях.
Если это произошло, поговорите с ними и менеджером проекта, чтобы сформировать общее понимание проекта. - Создайте процесс адаптации для каждого нового разработчика в команде
Один из практических инструментов, который вы можете сделать, - это обучить каждого нового члена команды и создать простой процесс, объясняющий все основные аспекты продукты и пользователь. Практический инструмент, который вы можете реализовать, - это создать четкий процесс адаптации, который объясняет все аспекты продукта и пользователей. в этом случае вы можете обучить каждого нового члена команды и убедиться, что он получит эту информацию
По моему опыту, необходимо объяснить:
-Что делает продукт и как он показывает работает
-Кто наши пользователи, чего они хотят достичь и почему они хотят этого достичь.
Возможно, это не ваша ответственность, но если вы хотите, чтобы с разработчиками все было гладко , вам следует подумать о том, чтобы взять на себя ответственность и убедиться, что новые члены команды будут знать эту важную информацию.
Элегантно говорите, когда возникают проблемы с внедрением
Как дизайнеры, мы очень критически относимся к своей работе. Мы думаем о каждом пикселе на экране, и если реализация чем-то отличается от нашего дизайна, мы можем испытать стресс.
Если это произойдет, мы должны уважительно поговорить с разработчиками и объяснить им различия между дизайном и разработкой.
Когда вы разговариваете с ними, лучше похвалить их за хорошую работу, а после объясните, почему необходимо исправить некоторые детали, потому что это не так, как в дизайне.
Так что будьте спокойны и обсудите с ними все, что им нужно изменить. На встрече объясните, почему вы так разработали и почему это важно для пользователя.
Если вы заметили серию повторяющихся ошибок, постарайтесь понять, почему они возникают, и исправьте их в следующий раз.
Например, если вы заметили, что разработчик всегда ошибается с потоком, поговорите с ним, чтобы понять, как они работают; Может быть, они не замечают блок-схему, которую вы добавляете в файл, или не знают, как использовать прототип в Figma? Я считаю, что показать разработчику, как правильно работать с программой, несложно.
Попросите, чтобы разработчики вас поняли.
Как дизайнер, вы должны быть уверены, что команда вас понимает. В процессе работы мы говорим и объясняемся с разработчиками по многим вопросам. Это может быть обзор дизайна, спринтерская встреча или вялый разговор.
Часто нам нужно объяснить сложный поток или сложное взаимодействие, поэтому не всегда легко объяснить и понять некоторые темы.
Поэтому, когда вы что-то объясняете членам своей команды, всегда спрашивайте, хорошо ли вы это объясняете. Вы обязаны объясниться так, чтобы люди могли понять тему.
Вы можете спросить что-то вроде:
- Я хорошо объяснился?
- Возможно ли, что вы поняли мое объяснение?
Людям не нравится признаваться, что они не понимают, поэтому этот вопрос побуждает их задавать вопросы, чтобы найти пробелы в их понимании.
Я помню, что на одном совещании по обзору проекта мне нужно было объяснить, как работает загрузка в наше приложение.
Я сказал что-то вроде: «Не забудьте добавить скелет экрана до того, как приложение завершит рендеринг».
После того, как я закончил объяснять, я спросил: «Есть ли что-то, что я не объяснил хорошо?» Через несколько секунд младший разработчик, присоединившийся к команде за месяц до этого, спросил меня: «Что такое экран-скелет?»
Объясняйте свои идеи наглядными примерами
При работе над взаимодействиями сложно все объяснить одними словами. Всегда используйте изображения, видео и прототипы, когда представляете свои идеи.
Возьмем пример таблицы данных. Если вы хотите объяснить его полное поведение, включая массовые действия, расширенные параметры и анимацию, это невозможно объяснить только словами.
В этом случае вы можете предоставить видео из других таблиц данных и создать простой прототип каркаса. Эти наглядные пособия поддержат ваше объяснение, обеспечат полное понимание для команды и сократят время вашего объяснения.
Некоторое время назад я услышал прекрасную фразу:
Одно изображение лучше 1000 слов, а одно видео лучше 1000 изображений.
Я считаю, что это хорошо объясняет этот момент.
Говорите просто
Дизайнеры часто полагаются на технические термины, которые понимают только они, такие как высота шрифта по x, дополнительный цвет или названия гарнитуры.
Общаясь с разработчиками, старайтесь говорить как можно проще, чтобы прояснить ситуацию. Если вы заметили, что люди не понимают, спросите их, есть ли что-нибудь непонятное.
Будьте открыты для выслушивания и изучения новых идей.
Дизайнеры иногда считают, что они знают лучше других, но это не так.
У дизайнеров действительно много знаний о пользователях и визуальном дизайне. Тем не менее, я должен сказать, что больше всего я узнал о программном обеспечении от разработчиков, с которыми я работал.
Знание программного обеспечения - важная часть работы дизайнера продукта. Невозможно присутствовать на собрании и понимать только процесс проектирования, потребности пользователя и визуальные аспекты. Необходимо понимать некоторые базовые концепции из развивающегося мира, такие как слияние, ветвление, развертывание, React и API.
Если вы не знакомы с некоторыми основными концепциями, у вас не будет полного представления о продукте, и это может вызвать проблемы при принятии решений относительно дизайна.
Простой пример - когда дизайнер сидит на стартовом собрании, посвященном новому проекту. Дизайнер слышит от разработчиков, что они хотят использовать библиотеку React для более быстрой сборки продукта. Если дизайнер не знает, что такое библиотека React, и не спрашивает, дизайнер не будет знать, что он может использовать библиотеку для более быстрого проектирования визуальных ресурсов.
Поэтому, если вы работаете с разработчиками над проектом, и они начинают говорить о незнакомых вам темах, попросите их объяснить их. В большинстве случаев они будут рады подробнее рассказать об этой теме.
Еще один хороший способ - написать каждую идею, которую вы не понимаете, и прочитать о ней в Википедии или найти ее в Google. Вы будете удивлены, как вы сможете улучшить свои знания с помощью этой техники.
Покажите примеры решения от других компаний
Во многих случаях при разработке решения нам не нужно изобретать колесо. Мы можем копировать решения других продуктов.
Я всегда пытаюсь объяснить это функцией входа в систему. Необязательно разрабатывать его с нуля. Многие компании сделали это, и нам нужно только изучить решение другой компании и скопировать его.
Иногда необходимо адаптировать его к вашим потребностям, но во многих случаях в этом нет необходимости.
Например, если вы хотите объяснить разработчикам, как вы хотите, чтобы функция входа в систему работала, вы можете показать им на встрече, как она работает с продуктом другой компании.
Конечно, также необходимо создать прототип и блок-схему перед передачей, но этот метод можно использовать в качестве социального доказательства решения и может сэкономить обсуждения и встречи. Если Google, Apple и Microsoft используют одно и то же решение, мы можем предположить, что оно сработает.
Информируйте разработчиков о дизайне
Одна из вещей, которые я видел в разных продуктовых командах, заключалась в том, что разработчики не разбираются в дизайне. Конечно, им необязательно знать все о дизайне, но понимание основ является значительным преимуществом.
Основываясь на моем опыте работы с разными командами, я могу сказать, что разработчик с некоторыми базовыми знаниями в области дизайна может помочь нам, когда нам понадобится проконсультироваться по нашим решениям. Кроме того, разработчик, разбирающийся в дизайне, может предложить отличные решения и распознать, когда мы делаем ошибки в дизайне.
Представьте, что вы застряли в чем-то, и разработчик помогает вам разобраться в этом, основываясь на принципах дизайна. Это круто, нет?
Итак, если вы хотите это сделать, вы можете начать с базового, назначив встречу, чтобы объяснить:
- 10 эвристик юзабилити для дизайна пользовательского интерфейса от Нормана Нильсена.
- Ваша дизайн-система
- Основы типографики
- Основы пользовательского интервью
- Как провести тест юзабилити
Вы можете приглашать команду на ежемесячное собрание и делиться этой информацией. Это медленный процесс, но со временем у вас будет гораздо более мощная продуктовая команда, которая сможет поддерживать вас и помогать создавать более качественные продукты.
Если некогда назначать встречи. Попытайтесь объяснить это в процессе. Например, когда вы представляете решение команде, пожалуйста, объясните, почему вы выбрали это решение и как оно работает с принципами проектирования.
Они оценят вас, если вы попытаетесь поделиться с ними этой информацией. Часто я слышу от разработчиков, что они хотят получить эти знания, но не знают, с чего начать.
Вовлекайте разработчиков в процесс проектирования.
Обычно продуктовые группы проводят собрание по рассмотрению дизайна перед отправкой проекта на реализацию, чтобы убедиться, что все члены команды понимают одно и то же и спрашивают их мнение. Это нормально. Тем не менее, я рекомендую вовлекать разработчиков в процесс проектирования и работать совместно с самого начала, а не откладывать это на последнюю минуту до начала фактической реализации. Вы можете быть удивлены, насколько они могут помочь сформировать раствор.
В некоторых случаях, помимо того, что я спрашиваю их мнение, я также провожу упражнения, как сумасшедшая восьмерка. Вместе мы намечаем некоторые решения и обсуждаем, что нам следует выбрать.
Когда разработчики активно участвуют с самого начала и добавляют свое мнение и идеи, происходят три вещи:
- Они лучше понимают решение.
- Команда заранее решила технические вопросы.
- Они более привержены дизайну.
Некоторые действия, которые вы можете сделать:
- Покажите им дизайн в процессе и спросите их мнение. Для этого не нужно назначать встречу. Также могут помочь 5 минут обсуждения.
- Вместе выполните упражнение на дизайн-мышление.
- Пусть поиграют с прототипом и спросят их мнение.
- Пригласите их на пользовательское интервью или юзабилити-тесты.
Вот важный момент. Если вы спрашиваете их мнение, вы должны быть открыты для внесения изменений. Недостаточно просто узнать их мнение о шоу. Необходимо учитывать их идеи и никогда не оставлять их без внимания.
Как можно меньше отвлекать внимание разработчика
Сегодня иногда сложно работать и сосредоточиться весь день. Многие сообщения Slack, электронные письма, люди задают вопросы, звонят сообщения мобильного телефона и другие отвлекающие факторы затрудняют сосредоточение внимания на задаче.
Трудно вернуться к сосредоточению, когда что-то мешает нам сосредоточиться, поэтому, если у вас есть вопросы к разработчикам, лучше потратить полчаса с ними и задать им все вопросы. Альтернативный метод для команд, которые работают в разных часовых поясах, - это создание видео и постановка всех вопросов в нем или добавление заметок в инструмент для совместной работы, такой как Figma.
Если вы задаете им новый вопрос каждые 5 минут, они могут почувствовать, что вы их задаете, поэтому постарайтесь сгруппировать все свои вопросы и задать их за один раз, чтобы уважать их время.
Договоритесь с разработчиками, чтобы упростить работу
Во время разговора с разработчиками, чтобы объяснить решение, спросите их о сложности разработки.
Лучше сделать это, потому что разработка - это сложная работа, и если мы отправим разработку решения большой сложности, на его сборку и выпуск может уйти время.
Примером может быть что-то вроде этого:
Представьте, что разработчикам нужно четыре недели, чтобы внедрить ваше решение, но команде нужно выпустить его через две недели. Вы можете спросить их, сколько вы можете сделать за две недели?
С этого момента вы можете разделить решение на две части. В первом выпуске команда завершает функцию с помощью основных персонажей, а во втором выпуске должна быть завершена вся функция.
Владелец продукта или менеджер по продукту обычно управляет этой ситуацией. Однако, если роль не существует в команде, ожидается, что вам потребуется помощь в решении этих проблем.
Изучите, прежде чем задавать вопросы
Прежде чем задать вопрос разработчикам, попробуйте изучить тему сохранения сообщений Slack, звонков и, конечно же, встреч.
Вы можете прочитать документацию по продукту и задать несколько тем в Google. Я считаю, что помимо экономии времени ваших колледжей, ваша уверенность растет, когда вы можете самостоятельно находить информацию.
Конечно, необходимо прийти после этого и согласовать с ними тему, но лучше пойти после того, как вы исследуете то, что хотите спросить, потому что вы пришли с какой-то идеей, и разработчикам не нужно ее объяснять. ты с нуля.
Когда вы это сделаете, люди, которые работают с вами, почувствуют, что вы берете на себя ответственность за работу, и вы не будете задавать им каждые пятиминутные вопросы, потому что вам лень найти информацию самостоятельно.
Организуйте хорошо и поделитесь всей информацией
У нас всегда много информации о продукте, над которым мы работаем. В большинстве компаний мы работаем с системой дизайна, которая помогает нам организовать визуальные ресурсы и шаблоны дизайна в одном месте, и это отлично.
Помимо визуальных ресурсов, мы также хотим предоставить больше информации, такой как потоки и прототипы, а также некоторые пояснения к решению. Если вы хотите хорошо передать это, хорошо систематизируйте информацию и поделитесь ею с командой.
Необязательно помещать все это в один инструмент для совместной работы, такой как Figma, но будет хорошо, если команда всегда знает, как легко получить доступ к информации.
И, конечно же, не забудьте предоставить доступ ко всей информации, которой вы делитесь с командой (пожалуйста, избегайте сохранения важной информации на вашем локальном компьютере).
Таким образом, разработчики не будут спрашивать вас, где эта информация и почему они не могут получить к нему доступ.
Проведите ретроспективные встречи
Если вы заметили проблему в своей команде и что дела у нее идут не очень хорошо, назначьте ретроспективную встречу.
Ретроспективная встреча - это встреча, проводимая командой, чтобы рассмотреть, как команда работает и как ее можно улучшить. Могу сказать вам, что у меня возникла проблема с командой разработчиков, когда мне нужно было доставить проектные активы.
Проведя несколько ретроспективных встреч, мы разработали лучший метод предоставления им информации. Это улучшило нашу работу в команде, и многие разногласия исчезли.
Если вы хотите узнать больше о ретроспективной встрече, я делюсь ссылкой на шаблон от Atlassian, который подробно объясняет его, и я очень рекомендую ознакомиться с ними.
Создайте настоящие отношения
Может быть, это самое главное, чем я могу поделиться с вами в этой статье.
Лучший способ хорошо работать вместе - наладить человеческие отношения с разработчиками, обсуждая вещи за пределами офиса.
Я хочу поговорить с ними о повседневной жизни, проблемах и интересах в их повседневной жизни. Тем самым вы заслужите их доверие. Вы станете для них другом, а не только товарищем по команде.
Одним из факторов, вызывающих у людей сочувствие, является понимание жизни человека. Например, если вы знаете, что ребенок члена вашей команды идет в школу сегодня, вы можете спросить: «Привет, сегодня первый день вашего ребенка в школе». Они взволнованы?
Может, это и кажется пустяком, но такое сочувствие и понимание составляют на самом деле отношения между людьми.
Надеюсь, эта статья вам поможет. Не стесняйтесь поделиться им с друзьями или членами команды, и если у вас есть какие-либо вопросы, не стесняйтесь оставлять комментарии.
