Интервью: Джош Брюер

Джош Брюер — основатель Habitat, бывший главный дизайнер в Twitter, сооснователь приложений 52 Weeks of UX, FFFFallback и the Shares и бывший UX-директор в Socialcast[175].

О чем вы думаете, когда начинаете работать над проектом?

Пользователи, пользователи, пользователи. Люди. Они, наверное, присутствуют всегда и везде. Когда я говорю «люди», я могу подразумевать и что-то маленькое, что строю для себя и кого-то еще, кто втиснется. FFFFallback (ffffallback.com) — отличный пример [инструмента Брюера для проверки запасного варианта выбора шрифта в web]. Веб-шрифты — крайне важная штука. Я сидел за работой и понял: «Эй, если они не загружаются, материал выглядит ужасно», и это не то же самое, что «О, давай запихнем это вот сюда, а затем там пойдет нормальный стек шрифта». Так пришло понимание, что моя работа будет выглядеть ужасно, если веб-шрифты не сработали и не загрузились до конца. Так что надо было сделать что-то, что помогало бы почесать там, где зудит. Я думал о себе и остальных дизайнерах, которые, знаете, могли быть пойманы на месте преступления, если бы JavaScript не сработал.

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

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

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

Так что спроектируйте его максимально быстро, потому что все изменится. Я вам это гарантирую. Вы собираетесь использовать телефон, держа его в одной руке, и тестировать экран большим пальцем или сидеть за ноутбуком с 27-дюймовым экраном, а в темноте или при свете? Я имею в виду, что вы должны на самом деле использовать и тестировать вещь. Трудно сказать «я сделал» [пока я этого не сделал].

Это хороший переход, потому что я хотел бы узнать, как вы работаете. Не могли бы вы рассказать о процессе? Уверен, что во всех случаях (что с Socialcast, что с Twitter, что с вашими собственными проектами) все было по-разному.

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

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

Затем, особенно в Twitter, идет работа в тесном контакте с менеджером продукта, или даже с Майком Дэвидсоном — с кем-то, кто определяет, что за проблему мы пытаемся решить.

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

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

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

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

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

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

Конечно, у каждого продукта свои особенности. Иногда это Keynote, а иногда Photoshop. Иногда это эскиз на салфетке, а иногда действительно высококачественный HTML и CSS или JavaScript.

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

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

Это тяжело. Quartz Composer — как гигантская скала. У некоторых вещей есть кривая обучения, а у него [Quartz Composer] — учебная стена, и я через нее еще не перелез. Я немного с ним играл, и некоторые из патчей, которые люди выкладывают в последнее время, безусловно, помогают.

Думаю, что нам в Twitter действительно повезло, потому что у нас было несколько парней, которые были довольно хороши в [Adobe] After Effects и разработке движений. Мы специально под это наняли несколько человек, которые разбирались в этих программах и могли нам помочь. Так что, когда мы передаем прототип инженерам, они говорят: «Да, отлично, я сделаю». И нам не надо ходить взад и вперед, взад и вперед, взад и вперед.

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

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

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

Я просто хочу иметь возможность идентифицировать компоненты, а затем определить их взаимодействие. Кто знает, может быть, уже завтра кто-то выяснит, как сделать более простой графический интерфейс поверх Xcode. Или Xcode Storyboarding станет проще в использовании, или что-то еще, не знаю. Могу предположить, что Android и некоторые другие компании продолжат подталкивать нас в сторону необходимости прототипирования интеракций и переходов между ними[176].