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

Джош Брюер — основатель 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, то вместе с ними.

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