Design Talks: Лучшее сотрудничество дизайнеров и разработчиков с Аароном Уолтером из InVision

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

Дизайнерам часто сложно работать с разработчиками и наоборот. Команды с обеих сторон могут многому научиться друг у друга, но уровни сопротивления остаются. Гость этой недели — Аарон Уолтер, вице-президент по дизайн-образованию в InVision, и мы собираемся поговорить о сотрудничестве дизайнеров и разработчиков.

Ааррон опирается на 15-летний опыт управления продуктовыми командами и обучения дизайну, чтобы помочь компаниям внедрять передовые методы проектирования. Он основал практику UX в MailChimp и помог увеличить число пользователей продукта с нескольких тысяч до более чем 10 миллионов.

Его рекомендации по дизайну помогли Белому дому, Государственному департаменту США и десяткам крупных корпораций, стартапов и фирм венчурного капитала. Он является автором бестселлера «Дизайн для эмоций» от A Book Apart. Вы найдете @aarron в Твиттере, где он делится мыслями о дизайне, и можете узнать больше об Аарроне на aarronwalter.com.

Ведущие подкаста Design Better Podcast Ааррон Уолтер и Эли Вулери берут интервью у лидеров дизайна и влиятельных лиц, которые делятся историями о том, как они решают проблемы и о своем карьерном пути. В число гостей входят Дэвид Келли (соучредитель IDEO и основатель Stanford d.school), Джули Чжо (вице-президент по продукту и дизайну в Facebook) и Джейк Кнапп (автор бестселлера Sprint).

Привет, Ааррон, приятно видеть тебя в блоге Toptal Design. Разработчики с Марса, а дизайнеры с Венеры?

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

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

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

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

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

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

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

Дизайнеры также могут попытаться преодолеть разрыв между двумя группами, вовлекая инженеров в процесс проектирования на раннем этапе, чтобы они чувствовали себя вовлеченными в раннюю фазу формирования идей, а не только в последующие этапы. Дизайнеры могут сказать: «Мы придумали эту гениальную идею, идите и сделайте ее для нас!» и это заставляет разработчиков чувствовать, что они не являются частью процесса создания идей. Это просто руки, а кто-то еще мозг.

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

О лучшем понимании пространства друг друга…

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

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

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

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

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

Тем не менее, его можно измерить количественно, поскольку компонент качества принесет измеримую рентабельность инвестиций.

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

О подводных камнях сотрудничества дизайнеров и разработчиков…

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

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

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

В такой среде обосновать необходимость UX-функции для дизайнера чрезвычайно сложно: «Мы должны иметь эту анимацию в продукте, потому что она создаст более привлекательный опыт…», когда есть 75 инженеров, которые говорят: «Это еще 250». строк кода и два дополнительных дня работы. Это действительно того стоит?» И это, вероятно, не так. Им это покажется «глазурью». Но эти анимированные микро-взаимодействия с UX-дизайнером действительно формируют клиентский опыт. Они не единственные, но они важны.

Когда у вас есть эти неравные отношения между дизайнерами и разработчиками, это становится действительно проблематичным. Однако есть решения. Такие компании, как Slack, решают эту проблему с помощью «парного дизайна». Если в одной команде есть один дизайнер на 10 инженеров, и такое же соотношение в другой команде, эти дизайнеры-одиночки тратят около восьми часов в неделю на совместную работу, представляя решения друг другу: «Вот как я решаю эту проблему, имеет смысл для вас? Есть лучший способ сделать это?" Они могут помочь друг другу вырваться из колеи и не чувствовать себя на острове.

О дизайнерах, доказывающих важность UX…

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

Есть несколько эффективных способов сделать это. Большинство дизайнеров, вероятно, сделали это неэффективным способом, напрямую сказав разработчикам: «Эй, добавление дополнительных функций не делает опыт лучше. Люди говорят, что хотят этого, но на самом деле это только усложняет продукт», и разработчики, скорее всего, ответят: «Я не думаю, что вы правы, это мнение. Мы слышим это от наших клиентов, поэтому мы должны следовать их примеру».

Лучше не браться за нее в лоб, а делать это сбоку и говорить: «Давайте лучше вместе разберемся в проблемном пространстве». Я купил обед для нас на завтра и договорился показать вам пятерых наших клиентов, использующих наш продукт.

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

Вы, наверное, слышали проповедь Джеффа Готхельфа о том, что мы должны сосредоточиться на «результатах, а не результатах». Это еще один способ переформулировать наше мышление: результат : «мы выпустили еще пять функций», а результат: «мы сократили отток клиентов на 10 %».

О будущем сотрудничества дизайнеров и разработчиков…

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

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

В связи с этим мы видим, что дизайнеры проводят много времени в Jira, размышляя о пользовательских историях, а также начинают думать с инженерным мышлением. И наоборот, мы видим, как инженеры используют такие инструменты, как InVision Inspect, где они видят спецификации и разбивку системы проектирования и понимают компоненты того, как все это сочетается друг с другом. Благодаря этим инструментам и смешению дисциплин развивается общее понимание.

Независимо от того, являетесь ли вы разработчиком или дизайнером, вы можете начать понимать точку зрения вашего ключевого партнера. Это не означает, что вы должны быть экспертом в области кодирования как дизайнер. Но это не убьет дизайнера, если он немного знает, как использовать Git и как писать HTML и CSS, может быть, немного JavaScript. На самом деле это поможет дизайнерам понять, как создаются вещи, и улучшит сотрудничество между дизайнерами и разработчиками.

Дальнейшее чтение в блоге Toptal Design:

• Как подходить к дизайну для разработчиков
• Беседы о дизайне: исследование в действии с исследователем UX Катрией О'Нил
• Design Talks: Эмоционально интеллектуальный дизайн с Памелой Павлискак
• Беседы о дизайне: В погоне за ценностным дизайном с Ником Дисабато
• Как перейти от UX-дизайнера к UX-консультанту