• Прототипы устанавливают новую связь с процессом инжиниринга. Они позволяют осознать цену построения функционала, о котором мечтаете, и постичь логику, стоящую за кажущимися простыми идеями взаимодействий.
• Используйте прототипы, чтобы сломать великую стену спецификаций продукта, выросшую между вами и инженерами, и получить обратную связь от тех, кто будет тестировать ваш продукт, и от потенциальных клиентов. Прототипы создают иллюзию использования реального продукта, что, как результат, дает такую обратную связь, которую невозможно получить каким-либо другим способом.
Сделайте прямо сейчас
• Прототипы необязательно делать с помощью модного инструмента. Попробуйте связать вместе нестилизованные страницы HTML со ссылками, которые открываются на вашем телефоне. Сфотографируйте наброски и поставьте на них ссылки. Делайте что угодно, но заставьте себя думать, что это продукт, готовый для использования. Только тогда вы сможете проверить свои предположения и начать собирать обратную связь.
• Если вы хотите выйти на новый уровень, начните осваивать инструменты прототипирования. Играйте на своих сильных сторонах. Не знаете код? Пробуйте InVision. Знаете JS — идите во Framer. Хотите чего-то особенного? Попробуйте Origami.
• Используйте прототипы, чтобы уничтожать плохие идеи, предотвратить лишние траты времени и устранить недопонимание еще до того, как они появятся. Дайте возможность опробовать продукт команде и представителям целевой аудитории. Следите за их реакцией, но не задавайте наводящих вопросов.
Интервью: Поли Тинг
Поли Тинг — продуктовый дизайнер, который работал с клиентами из Fortune 500, крупными ретейлерами и некоторыми ведущими мировыми автомобильными производителями. Он создавал мобильные приложения, строил ecommerce-экспертизу и многое другое. Он объединял огромные команды, используя прототипы как универсальный язык и способ коллаборации.
Что стало самым большим открытием и уроком после того, как вы сделали создание прототипов обязательной частью процесса дизайна?
Самое главное, что я выучил при быстром создании прототипов, они — это очень мощный катализатор. Я в первый раз увидел, чтобы команды действительно поняли смысл мобильности и гибкости.
Использование таких инструментов, как InVision и Quartz Composer, накладывает обязательства на создателей пользовательского интерфейса и опыта взаимодействия, на менеджеров проектов и инженеров. Они должны вникнуть в дисциплины друг друга, разобраться в них и начать работать вместе.
Например, когда я сотрудничал с Macy’s, менеджер проекта сказал мне: «За все годы работы в компании я в первый раз увидел, как все вдохновлены работой: и разработчики интерфейсов, и пользовательского опыта, и девелоперы — все хотели делать одно дело».
Поэтому у нас практически не бывает конфликтов, все слаженно работают как единая команда. А все потому, что быстрое прототипирование — это даже не инструмент и не методология, это своего рода культура, смысл которой в вовлечении людей. Мы даем возможность всем одновременно выйти на импровизированную трибуну, а не старомодно ждать в очереди. Люди получают возможность быть включенными в процесс, мы наделяем их полномочиями, но при этом определяем рамки, чтобы все осознавали рамки дозволенного.
Я бы сказал, что это передача власти и возможность поделиться результатами своей работы. Но, честное слово, это очень быстрый способ работы. Сложно принять совместное решение с тем, кто не находится рядом. Возьмем, например, вопрос «Какого цвета брюки мне нужно купить?». Я могу прислать фото, могу описать их, могу отправить ссылку и так далее, но все это даже близко не сравнится с тем, как если бы вы просто стояли рядом со мной в магазине.
Присутствуя в магазине, вы становитесь неотъемлемой частью контекста, в котором принимаются решения. И это критически важно для донесения сути проекта и вовлечения команды.
Почему? Потому что мы возвращаемся к старым вопросам, по-новому объясняем вещи (в которых люди, в отличие от вас, не совсем хороши).
Как вы считаете, прототипы заставляют дизайнеров проникнуться большим уважением к процессам инжиниринга? Они помогают им смягчать «сумасшедшие идеи», которые норовят пробраться в пользовательские интерфейсы?
К сожалению, у слишком большого количества UX-дизайнеров нет опыта разработчика и понимания его труда. Они видят что-то «клевое» в приложении, например какой-то конкретный экран, и они очень «хотят это», несмотря на то, сколько усилий уйдет на создание, особенно в моем положении, [на минном поле] с наследуемыми системами, брендированием, юридическими и маркетинговыми командами и т. д. Великолепный пример — меню под кнопкой «+» в приложении Path.
Если я UX-дизайнер с полутехническим образованием, то могу добавлять комментарии в режиме реального времени, стараясь понять, как и где достается информация, как она анализируется и передается. И это очень важный процесс, потому что он означает, что инженеры действительно вовлечены в работу на стадии дизайна продукта, а не когда «мы тут сделали дизайн, а вам теперь его надо реализовать».
Один из главных тезисов моей обратной связи для Macy’s и подобных ей клиентов — необходимость наличия многодисциплинарной команды. Конечно, вам нужны узкие специалисты, но у UX-дизайнера должны быть навыки UI-дизайнера и разработчика, у UI-дизайнера — навыки UX-дизайнера и разработчика, а разработчик должен разбираться в UI и UX.
И самое главное, менеджеры проектов, ключевые члены команд, их лидеры, должны обладать всеми тремя навыками. Им необязательно быть экспертами во всем (хотя я верю в то, что это способствует созданию значительно более совершенного продукта), но они не могут быть невежественны.
Помогите мне понять особенность пути создания прототипа. Какая информация нужна, чтобы его построить? Как выглядит процесс работы над целевой аудиторией?
Я люблю знать, что за намерение за этим стоит. Это практически как хакатон: обычно быстрые прототипы строят, чтобы проверить, подтвердить или осмыслить идею в условиях ограниченного времени или бюджета. Сложности на пути к успеху начинаются тогда, когда люди подходят к процессу как к мощно финансируемому проекту длиной в вечность или без конкретной цели в голове, чтобы просто «сделать что-нибудь».
Еще я бы выяснил, пытаемся мы создать что-то сфокусированное на конкретном пользователе или ориентируемся на всех. Иногда важно сконцентрироваться только на одном пользователе в особом контексте; а иногда мы должны принимать во внимание всех, кто вовлечен, и показать им преимущества и выгоды. Я бы всегда разрабатывал продукт для всех, но в системе с пользовательским лицом и лицом администратора понимание того, что вы делаете продукт для потребителя, помогает сконцентрироваться и там, где необходимо, ссылаться на расширение до уровня администратора, не создавая под него отдельного дизайна.
