Скотт Хёрф - Как создать продукт, который полюбят

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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