Интервью: Поли Тинг

Поли Тинг — продуктовый дизайнер, который работал с клиентами из Fortune 500, крупными ретейлерами и некоторыми ведущими мировыми автомобильными производителями. Он создавал мобильные приложения, строил ecommerce-экспертизу и многое другое. Он объединял огромные команды, используя прототипы как универсальный язык и способ коллаборации.

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

Самое главное, что я выучил при быстром создании прототипов, они — это очень мощный катализатор. Я в первый раз увидел, чтобы команды действительно поняли смысл мобильности и гибкости.

Использование таких инструментов, как InVision и Quartz Composer, накладывает обязательства на создателей пользовательского интерфейса и опыта взаимодействия, на менеджеров проектов и инженеров. Они должны вникнуть в дисциплины друг друга, разобраться в них и начать работать вместе.

Например, когда я сотрудничал с Macy’s, менеджер проекта сказал мне: «За все годы работы в компании я в первый раз увидел, как все вдохновлены работой: и разработчики интерфейсов, и пользовательского опыта, и девелоперы — все хотели делать одно дело».

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

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

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

Почему? Потому что мы возвращаемся к старым вопросам, по-новому объясняем вещи (в которых люди, в отличие от вас, не совсем хороши).

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

К сожалению, у слишком большого количества UX-дизайнеров нет опыта разработчика и понимания его труда. Они видят что-то «клевое» в приложении, например какой-то конкретный экран, и они очень «хотят это», несмотря на то, сколько усилий уйдет на создание, особенно в моем положении, [на минном поле] с наследуемыми системами, брендированием, юридическими и маркетинговыми командами и т. д. Великолепный пример — меню под кнопкой «+» в приложении Path.

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

Один из главных тезисов моей обратной связи для Macy’s и подобных ей клиентов — необходимость наличия многодисциплинарной команды. Конечно, вам нужны узкие специалисты, но у UX-дизайнера должны быть навыки UI-дизайнера и разработчика, у UI-дизайнера — навыки UX-дизайнера и разработчика, а разработчик должен разбираться в UI и UX.

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

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

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

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

Мне нравится разбираться, что станет успехом для обеих сторон — и для бизнеса, и для пользователя, — чтобы иметь возможность задать стандарты во всем, что я делаю.

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

И наконец, поверх старого я создал бы новый сценарий (чтобы обозначить выгоды, например — меньше шагов или меньше вариантов). Я бы обозначил цветом, какие экраны необходимы. Так команда поймет, где в масштабном опыте будет находиться цифровой.

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

Насколько функциональными вы делаете свои прототипы? Сценарий целиком? Конкретную анимацию?

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

Когда в процесс включается разработчик? Как это выглядит?

Мне нравится, когда в моей команде есть многопрофильный инженер. Для меня идеальная команда — это менеджер проектов, UX, UI, многопрофильный техлид / инженер при условии, что они все понимают роли друг друга (например, менеджер проектов должен понимать азы кода, дизайнер должен обладать навыками UX, все должны хорошо коммуницировать между собой и демонстрировать баланс коммерческого прагматизма и технической работы).

Чаще всего (за редким исключением) инженеры — самый крупный и лучший источник дизайнерских предложений просто потому, что они уже обладают знанием «А что будет, если мы сделаем это» и «Почему это должно быть разработано именно в таком виде?». Это неоценимый ресурс для получения обратной связи в режиме реального времени, позволяющий понимать, как может работать функционал. Обычно я что-то создаю и затем передаю инженеру, спрашивая: «А что, если сделать вот так?». Это действительно очень хорошо дает им понять, как я думаю, чего пытаюсь достичь, и на основании этого они могут предлагать варианты, строить предположения и предоставлять поддержку.

Кому и когда вы показываете разработку — внутри компании или клиенту? Как работает обратная связь?

Зависит от уровня взаимоотношений с клиентом, но в целом мне нравится сначала сделать, а потом идти за одобрением. У меня есть очень успешные примеры работы с клиентами: например, с применением таких инструментов, как InVision, особенно когда работы много и клиент хочет быть максимально вовлечен, быть в курсе и видеть прогресс. Многие клиенты активно вовлекаются в процесс дизайна, что всегда позволяет сделать более совершенный продукт и легче его продавать.

Как результат — все замотивированы и чувствуют себя профессионалами, частью команды, все ответственны за свой вклад.

Сколько времени обычно занимает стандартный процесс?

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

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

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

Как вы считаете, прототипы помогают создавать лучшие идеи?

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

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

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

Довольно часто я в буквальном смысле менял дизайн посреди дискуссии и спрашивал: «Вы это имеете в виду?». А затем мы его тестировали и обсуждали. Это сэкономило часы и дни, которые иначе пришлось бы потратить на написание электронных писем, встречи, дополнительные обсуждения и дебаты.

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

Работа в команде помогала не-дизайнерам лучше понять, почему принимаются те или иные решения, а дизайнерам — почему необходимы те или иные бизнес- и инженерные решения для изменения продукта[113].