Книга: Как создать продукт, который полюбят
Назад: [4] Пользовательский интерфейс начинается со слов
Дальше: [6] Механика дизайна интерфейсов

[5]

Осязаемое превосходит теоретическое

Прототипы в тысячу раз лучше макетов

Дизайн — это ясная коммуникация любыми известными или доступными вам способами.

Милтон Глейзер

В 1977 году, работая над «Звездными войнами», Джордж Лукас хотел сделать невозможное — снять сцену воздушного боя в открытом космосе.

Лукас говорил об этом так:

Я не имел ни малейшего представления, как буду это делать. [Поэтому] объединил свои усилия с теми людьми, которых пригласил участвовать в создании ILM. Чтобы добиться нужного эффекта [в киноленте], мы должны были разработать новую техно­логию.

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

Мы были вынуждены прибегнуть к ловкости рук… В ход пошли сырая анимация, съемки реальных воздушных боев и различные документальные фильмы, из которых [мы все вместе вырезали] видеоматериалы, чтобы визуализировать движение.

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

Мы записали на кассеты все военные фильмы с воздушными судами, которые когда-либо появлялись на телевидении. Так нам удалось собрать огромную библиотеку эпизодов старых военных фильмов — «Разрушители плотин», «Тора! Тора! Тора!», «Битва за Британию», «Летчик», «Мосты у Токо-ри», «Эскадрилья 633» и еще примерно 45 других фильмов. Мы отсмотрели их все и выбрали те сцены, которые хотели бы перенести в свой фильм.

Кадр за кадром смонтированные сцены практически досконально дублировали события будущей киноленты. Например, в фильме «Звездные войны. Империя мечты» есть видеоряд, где «Сокол тысячелетия» улетает от «Звезды смерти» и параллельно с ним — черно-белые клипы, которые Лукас нарезал из военного фильма 1943 года «Военно-воздушные силы». Последовательность сцен, движение моделей на экране, реакции актеров — это практически доскональное цитирование.

Лукас использовал все возможные приемы и все доступные инструменты, чтобы извлечь идеи из своей головы и перенести их на большой экран.

Для последней сцены в «Новой надежде» я нарезал несколько кусочков из документальных фильмов о Второй мировой войне и футаж полетов военных самолетов — в общем, все в таком духе. <…> Для эпизода в фильме «Империя наносит ответный удар» мы сделали небольшие мультипликационные ролики со взрывами, движущимися тяжелыми шагающими танками и прочими штуками. Для «Возвращения джедая» мы построили миниатюрные модели [гравициклов Эндора] и снимали небольшие видео, как эти модельки на палочках проходят сквозь рамку.

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

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

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

Рис. 5.1. Примеры предварительной визуализации для сцен фильма «Железный человек — 3» (студия Westlawn Productions). Это те техники, которые помогли Джорджу Лукасу стать первооткрывателем цифровых технологий киноиндустрии в приквелах «Звездных войн». «Пре-визы» включают в себя диалог, музыку и видоизмененные звуковые эффекты, которые соответствуют смысловой нагрузке сцены. В фильме финальный видеоряд был максимально близким к пре-визу, но в нем были задействованы настоящие актеры, настоящий звуковой ряд и итоговые спецэффекты

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

Используя раскадровку в качестве черновика, редактор, вооружившись обычной цифровой камерой, в буквальном смысле слова отправлялся «в поля» с дублерами актеров фильма, которые читали строки сценария. В качестве муляжа транспортных объектов использовался Ferrari самого Лукаса или старый муляж-гравицикл Люка из «Новой надежды».

Лукас говорил: «Вам нужно проработать видеочерновики, чтобы как редактору понимать, куда вы идете, насколько длинными будут сцены и работает ли это вообще, потому что фильм — абсолютно кинетическая материя… и в нем все должно рассматриваться в движении».

Затем Лукас брал рабочие сцены и соединял их в видеоряд, руковод­ствуясь ранее составленным им наброском. С течением времени он перемонтировал видеоряд, снимал новые сцены, подгонял тайминг — и так до тех пор, пока все не складывалось в единую картину. После этого создавалась цифровая реконструкция, которую демонстрировали актерам (например, Юэну Макгрегору), параллельно с тем, как снимались их настоящие сцены.

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

«Я не смог бы [снимать эти фильмы] без превизуализации процесса», — комментировал Лукас.

Во время просмотра этого документального фильма меня захлестнула волна дежавю. Процесс казался мне донельзя знакомым. Параллель с разработкой продуктов была просто невероятной. Одностраничный набросок видеоряда Лукаса? Звучит очень похоже на сценарии, которые мы описывали в предыдущей главе. Черновые раскадровки и видеоряд, отснятый «в полях»? Это лукасовская вариация прототипирования.

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

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

Рис. 5.2. Прототип максимально эффективен, когда вы знаете, кто на него будет смотреть, когда вам нужно его сделать, насколько он должен быть отполирован и насколько уверенно вы себя ощущаете с имеющимися в вашем распоряжении инструментами

Точность

Достаточно ли точно выбранный формат передает идеи вашего дизайна?

Имеющееся время

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

Аудитория

Кто будет принимать ваши дизайнерские идеи? Есть ли у них все необходимое, чтобы их понять?

Комфорт

Насколько уверенно и комфортно вы себя чувствуете при использовании выбранных вами инструментов?

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

Кайл Браггер, соавтор Exposure (инструмента для фотографов от студии программного обеспечения Elepath), считает, что прототипирование — это «сделать что-то, что будет работать, и отполированное до той степени, что способно заставить мозг думать: «Ага, это продукт, я могу его использовать. Я могу повертеть его в руках и посмотреть, каков он в деле».

Браггер использует ранние прототипы, чтобы проверить свои предположения.

Почему это должно быть таким? Почему мы это так делаем? Вот самые важные вопросы. Они не про эстетику, не про модные фишки и навороты [или] самые последние тренды. «Зачем я это создаю? Для кого я это создаю? Какую проблему я решаю?»

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

Одно очень старое изречение советует всем писателям при создании персонажей своих произведений «показывать, а не говорить», то есть представить и оживить историю как опыт переживаний персонажа, а не писателя.

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

При помощи игры в шарады? Я думаю, что кое-кто из вас прибегал к этим древностям. Сознаюсь: я тоже.

Отсутствие возможности «показать» взаимодействия и динамику в нашем дизайне — знаковая, общая проблема, с которой мы регулярно сталкиваемся, разрабатывая продукты.

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

Статика, таким образом, не позволяет рассказать историю нашего продукта.

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

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

Больше чем популярное словечко

В знаменитой дизайн-компании IDEO есть поговорка, что если картинка стоит тысячи слов, то прототип стоит тысячи встреч.

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

Для меня было достаточно удивительно обнаружить, что темп в этом направлении задают большие компании. Оказалось, что такие гиганты, как Airbnb, Evernote, Facebook и Google, невероятно благосклонны к публике и без утайки показывают, как интегрируют прототипирование в свои рабочие процессы. Более того, они служат для нас полезным примером подобного поведения.

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

«InVision — мой первый инструмент прототипирования, во многом потому, что он не только быстрый и простой в использовании, но также дает возможность сразу же поделиться полученными результатами, — говорит Поли Тинг, продуктовый дизайнер, который работал с клиентами из списка Fortune 500, крупными ретейлерами и мировыми автопроизводителями. — InVision не требует технических знаний, а значит, с ним могут работать люди без технического образования, то есть барьер для сотрудничества, вовлеченности в процесс дизайна довольно низкий. Это самый быстрый инструмент для создания практически совершенного опыта».

Apple Keynote и Microsoft Powerpoint также пожинают плоды успешного роста за счет прототипирования.

«Особо важную роль анимация играет в дизайне приложений. Например, я на скорую руку делал несколько анимаций с низкой детализацией, чтобы объяснить, что будет происходить, когда пользователь начнет нажимать на экран или перелистывать страницы, — комментирует Тимони Вест, ветеран продуктового дизайна из Flickr, Foursquare и Alphaworks, которой принадлежит сейчас его собственная студия дизайна Department of Design. — Чаще всего анимации используют вместе с раскадровкой, цепочкой экранов. К сожалению, Keynote все еще лучшее, что есть на этот момент. Я не знаю другого такого простого продукта, который позволял бы вырезать и вставлять изображения в векторе, а также делать базовую анимацию с мгновенным предпросмотром».

Но если какая-то компания и достигла мастерства в создании таких интеракций в прототипах, что те воспринимаются как нативные и настоящие, так это Facebook. Facebook занял лидирующие позиции в прототипировании с момента запуска Origami — полного набора инструментов и расширений, надстроенных к Quartz Composer от Apple. Изначально созданная внутри компании, в Facebook Creative Labs, с целью развития новых взаимодействий для iOS приложения Paper (рис. 5.3), она дала старт появлению таких конкурентных инструментов, как Pixate, Google Form и Framer. Даже дизайнерская компания IDEO решила поучаствовать в общем забеге, выпустив собственный набор для прототипирования под названием Avocado.

Рис. 5.3. Интеракции Facebook Paper пленили и захватили дизайнерское сообщество. Позже журнал Wired писал, что они были разработаны с помощью Origami

Общеизвестным было и то, что компания Apple также располагает собственными продвинутыми инструментами прототипирования. Говорят, что один из них Mica был специально разработан для UI-дизайнеров, чтобы тем было намного проще создавать интерактивные интерфейсы. Предполагалось, что Mica заменит Quartz Composer в проекте 1 Infinite Loop и будет использоваться для создания всего — от интерфейсов до профессиональных итоговых плагинов.

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

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

Это просто-таки святой Грааль.

[На этом месте играет музыкальная тема Джона Уильямса из фильма про Индиану Джонса.]

Признаться, в недавнем прошлом я скептически относился к прототипированию. Я считал, что у меня совершенно нет на это времени и что мои бизнес-партнеры встретят в штыки новый этап в процессе.

Одновременно с освоением искусства создания прототипов и внедрением их в рабочий процесс я начал перенимать опыт дизайнеров — ветеранов прототипирования: Стива Мезароса (продуктовый дизайнер Wildcard) и Поли Тинга (продуктовый дизайнер, который работал с такими крупными компаниями, как Macy’s, SiriusXM и Jaguar).

Мезарос занимался растущим продуктом Wildcard вместе с Хой Вином, бывшим директором по дизайну New York Times, которого Fast Company назвала одним из 50 самых влиятельных дизайнеров Америки. Мезарос и Вин отвечали за дизайн интерфейса Wildcard и его интерактивность, стремившись объединить производительность и опыт нативных приложений с охватом всего интернета.

Тинг возглавлял отдел пользовательского опыта в Tigerspike, дизайн-компании, которая разрабатывала приложения и мобильные сайты для клиентов Fortune 500 — от ретейлеров до интернет-гигантов. В его задачи входило, по большому счету, удовлетворение запросов не только клиентов компании, но и руководителей этих клиентов, а также клиентов их клиентов.

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

Цели прототипирования

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

«Это как хакатон», — говорит Тинг.

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

«Прототипы интеракций и анимаций были важнейшим элементом цикла разработки в Wildcard и позволяли нам просто и ясно формулировать даже самые сложные идеи», — говорит Мезарос.

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

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

Но и это еще не все. Один из самых важных вопросов: насколько вы ограничены по времени? Ответ на него позволяет подобрать правильные инструменты для выполнения проекта.

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

Мне очень нравится, как продуктовый дизайнер Twitter Пол Стаматиу описывает компромисс, к которому он пришел, разрабатывая Twitter Video.

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

Поли Тинг, в свою очередь, пишет:

Быстрое прототипирование — это концентрация внимания в течение намеренно ограниченного времени, что позволяет отсечь все лишнее, второстепенное и посредственное. Никто не отрицает, что чем более «отполированным» будет опыт использования прототипа, тем выше шансы, что клиент его купит. Мы должны принимать решения, всегда помня об этом. Если конкретное взаимодействие критично для демонстрации новых / лучших / более простых способов навигации или для использования продукта, тогда да — мы его сделаем. Но если это просто глянец, тогда не стоит тратить время.

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

«Прототип способен решать многие вопросы и подходить для нескольких целей. Например, с его помощью можно продемонстрировать идею, изучить, протестировать или даже продать ее, а также собрать MVP», — комментирует Тинг.

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

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

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

Когда прототип будет готов к передаче в разработку, команда должна его обсудить и решить, как продолжить работу.

Хороший пример — Twitter (да, снова) в той форме, в которой вы его никогда раньше не видели. В середине 2006 года Twitter можно было принять за клон Craigslist. CSS не было. Простое текстовое окно, простые изображения (желтая звезда и эскиз стартовой страницы), кнопка отправки и нестилизованные <ul>, которые представляли последние обновления статусов людей, на которых вы подписались, в обратном хронологическом порядке (рис. 5.4).

Рис. 5.4. Один из первых прототипов Twitter

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

Помимо скорости, у построения прототипов есть еще одно неоспоримое преимущество. Этот процесс позволяет прийти к согласию не только внутри компании, но и с клиентами. Прототип становится универсальным языком общения, который все понимают.

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

«Визуализация [и тестирование] взаимодействий помогает нам вести конструктивный диалог с крупными командами, — говорит Мезарос. — Прототипы играют важную роль в получении и использовании обратной связи от всех команд: от стратегии до дизайна. Создавая прототипы, мы гораздо лучше контролируем последствия процесса. В Wildcard оценка стоимости играла критически важную роль для достижения конечной цели. Вот почему я яростный сторонник дизайна и прототипирования в любом возможном контексте. Мне кажется, что лучший вариант — встраивать все части пользовательского интерфейса так же, как может быть в финальном продукте».

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

«Одна-две недели — это хорошее время, чтобы прийти с качественными идеями и реализовать их без лишних наворотов и крутизны. Его вполне достаточно, чтобы остановиться, выдохнуть и принять продуманное решение, но и не слишком много, чтобы бездумно его тратить, — отмечает Тинг. — Самое главное, что я выучил при быстром создании прототипов, — это очень мощный катализатор. Использование таких инструментов, как InVision и Quartz Composer, накладывает обязательства на создателей пользовательского интерфейса (UI) и опыта взаимодействия (UX), на менеджеров проектов и инженеров. Они должны вникнуть в дисциплины друг друга, разобраться в них и начать работать вместе. У нас практически не бывает конфликтов, все слаженно работают как единая команда. А все потому, что быстрое прототипирование — это даже не инструмент и не методология, это своего рода культура».

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

«Мы можем улучшать и корректировать [проект] очень быстро в режиме реального времени — за считаные секунды или минуты, — говорит Мезарос. — Подобный уровень контроля действительно восхищает. Это и есть искусство интерактивного дизайна, и прототипирование дает нам определенные преимущества».

Подготовка к использованию

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

Рис. 5.5. Модель процесса создания продукта максимально эффективна благодаря прототипированию

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

В зависимости от выбранных инструментов передача кода в руки инженеров может проходить в разных формах. Вы или передаете код, написанный в Framer.js, или делитесь своими раскадровками в Xcode, или, если вы использовали Quartz Composer / Origami, переправляете композиционные файлы и самые важные моменты, такие как переходы и время анимации. Чем больше информации вы предоставите, тем быстрее будет готов ваш продукт.

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

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

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

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

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

Резюме

Сделайте прямо сейчас

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

Поли Тинг — продуктовый дизайнер, который работал с клиентами из 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-дизайне — я подключал свой опыт и высказывал профессиональное мнение, когда требовалось принять определенное решение. Я постоянно тестировал идеи, отталкиваясь от цели и запросов пользователей, для которых все это разрабатывалось.

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

Назад: [4] Пользовательский интерфейс начинается со слов
Дальше: [6] Механика дизайна интерфейсов