[6]

Механика дизайна интерфейсов

Гибкие прототипы vs. выверять все до пикселя

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

Франсуа Помпон, французский скульптор и анималист

Один из моих любимых художников новейшего времени Франсуа Помпон родился в 1855 году и поначалу проявлял свои скрытые таланты в качестве помощника знаменитых скульпторов Огюста Родена и Камиллы Клодель. Только в 1922 году, в возрасте 67 лет, собственные работы принесли Помпону известность.

Его огромная скульптура L’ours Blanc, «Белый медведь» (рис. 6.1), — нечто поистине уникальное. В ней нет ничего лишнего. Она не пытается казаться реалистичной. Перед зрителем предстает белый медведь в своей чистой форме и сути. Помпон отказывается от мелких подробностей, чтобы дать зрителю возможность сфокусироваться на том, что делает медведя медведем.

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

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

Затем мы удаляем ненужные детали, увеличиваем точность своей работы и двигаемся в направлении того, что мы можем предложить клиентам (рис. 6.2). В  мы создали образец пользовательского интерфейса и на его основе начали моделировать сценарии и внешний вид экранов. В  пользовательские пути начали объединяться во что-то материальное, что-то, что мы могли бы использовать для проверки своих идей. Мы начали чувствовать, как может вести себя наш продукт.

Теперь мы наконец готовы превратить все элементы в ингредиенты для приготовления крутого пользовательского интерфейса.

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

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

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

После создания текстов интерфейса и сценария вам придется заняться выверенными макетами.

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

Этот подход в его крайней форме любит использовать Apple. Здесь подобная технология называется «10 : 3 : 1». Разработчики компании должны создать десять абсолютно разных высокоточных моделей для каждой функции будущего продукта. Затем из десяти идей выбираются три, лучшие элементы которых объединяются в конечное решение.

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

Почему? Потому что детально проработанные модели — это идеальное средство коммуникации, они могут быть интегрированы в макеты и заполнены уже готовыми текстами. Вуаля! Теперь можно сказать всем, что у вас есть готовый продукт. Недоверие исчезает, и вы получаете искренние комментарии и мнения. Кроме того, пиксельные модели в сочетании с макетами представляют собой идеальную инструкцию для инженеров.

Так что запуск окончательной версии продукта никого не застанет врасплох.

Лично я готов променять любую так называемую функциональную спецификацию на эти преимущества.

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

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

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

UI-стек: пять слоев дизайна интерфейса

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

Если да, то вы знаете, как выглядит неловкий UI.

Неловкий UI — это отсутствующий индикатор загрузки; это ситуация, в которой вы забываете сказать пользователю, что что-то пошло не так, или делаете это при помощи сообщения об ошибке; это странно выглядящие графики всего с несколькими точками; это сбой системы при вводе новых данных. Если вы еще не поняли, что такое неловкий UI, вот вам простой пример из реальной жизни. Я смотрю Apple TV. Очень часто. (Честно сказать, я это делаю и сейчас, когда пишу эти строки.) Каждый раз, когда я открываю папку с купленными фильмами, я вижу картину, которая представлена на рисунке 6.3.

Каждый раз я на секунду пугаюсь. А я ведь открываю эту папку очень часто. Я знаю, чего ожидать.

Но что меня пугает? Из-за чего мой мозг считает, что я вижу именно то, что Apple TV хочет мне показать?

На этом экране отсутствует индикатор загрузки, равно как и любые другие следы деятельности. Так что через мгновение в моей голове появляются жуткие вопросы: где мои фильмы? Я их потерял? Удалил? Их кто-то украл?

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

Как же это бесит!

Сравните эту процедуру с воспроизведением фильма. Нажав кнопку Play на пульте, я вижу индикатор, что «Назад в будущее» готовится к запуску (рис. 6.4).

Видите разницу в ощущениях?

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

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

Вот только мы не разговариваем двоичным кодом. Мы мыслим сценариями и живем в физическом мире. Когда дверь открывается, она описывает полукруг. Когда предмет перемещается, мы видим его движение. Когда что-то падает, оно отскакивает от земли.

Неловкий UI выходит на сцену, когда разработчик продукта всего этого не учитывает. Это значит, что где-то в процессе работы нарушаются какие-то правила.

Что это за правила?

Правила UI-стека. Давайте-ка поговорим о нем.

ЧТО ТАКОЕ UI-СТЕК?

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

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

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

Будьте честны сами с собой. Когда вы в последний раз создавали экран, состоящий только из одного слоя? Даже если вы разрабатываете приложения для прогноза погоды (здесь должна быть шутка про Dribbble), одного слоя вам не хватит.

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

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

Вот почему каждый экран, который вы создаете, может иметь до пяти состояний:

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

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

Но для начала давайте совершим краткий экскурс в историю интернета. В 2004 году компания Basecamp (ранее известная как 37signals) выпустила книгу, которая, как мне кажется, перевернула разработку цифровых продуктов с ног на голову. Эта книга называлась The Three State Solution («Решение с тремя состояниями»), и в ней говорилось, что каждый экран должен рассматриваться в трех возможных состояниях — «обычном, пустом и ошибочном». Это открытие изменило мое сознание и заставило иначе взглянуть на дизайн сетевых продуктов.

Но интернет меняется. Сначала произошла революция AJAX (совпавшая с появлением Web 2.0, как его тогда называли), затем появились мобильные приложения, потом началась массовая коммерциализация продуктов для мобильных телефонов, планшетов и сети в целом.

Изменились и требования, и ожидания от UI. UI-стек — это моя адаптация идеи, которую Basecamp создал более десяти лет назад.

А теперь давайте поговорим об идеальном состоянии.

ИДЕАЛЬНОЕ СОСТОЯНИЕ

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

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

И все эти изменения имеют огромное значение для остальных слоев.

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

Если вы еще не до конца понимаете, что я имею в виду под идеальным состоянием, давайте рассмотрим несколько примеров (см. рис. 6.6–6.8).

ПУСТОЕ СОСТОЯНИЕ

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

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

Главная проблема с пустыми слоями в том, что их часто оставляют на потом. В итоге получается либо полная мешанина (рис. 6.9), либо холодный и безликий интерфейс.

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

Давайте поговорим о состоянии первого использования более по­дробно.

ПЕРВОЕ ИСПОЛЬЗОВАНИЕ / ЗНАКОМСТВО

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

Это состояние кажется мне похожим на то, что в литературе и кино называют «путешествием героя» (рис. 6.10). Это понятие, введенное Джозефом Кэмпбеллом, лежит в основе мифологических сюжетов всего мира, от «Одиссеи» до «Звездных войн». Краткое описание того, что оно в себя включает, выглядит так.

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

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

Но как это сделать? Вот вам несколько идей.

• Напишите воодушевляющие и мотивирующие тексты, чтобы чест­но рассказать о том, что вы делаете. Слова вроде «здесь нет ничего интересного» не говорят вашему клиенту, чего ему следует ожидать, и вряд ли кому-то хочется увидеть их, начиная работу с новым продуктом. Вместо этого попробуйте рассказать клиенту, какую кнопку ему нужно нажать и зачем.
• Используйте контент своего продукта, чтобы объяснить клиенту, что ему следует делать. Например, если вы создаете продукт для обмена сообщениями, то можете начать с отправки сообщения клиенту. Попробуйте сделать заголовком такого сообщения фразу вроде «нажмите, чтобы открыть», а в тексте объяснить, как можно управлять сообщениями и отвечать на них.
• Покажите, как должен выглядеть экран вашего продукта в идеальном состоянии. Так ваш клиент почувствует, что он может достичь чего-то похожего. К тому же вы продемонстрируете, насколько полезным может быть ваш продукт.
• Отслеживайте прогресс клиента и реагируйте соответствующим образом. Если он слишком долго задерживается на каком-то экране, напишите ему в чат и спросите, не нуждается ли он в помощи.

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

Тема экранов для регистрации и первого использования настолько широка, что ей можно было бы посвятить отдельную книгу. И, оказывается, такая книга существует. Если вы хотите заняться этим вопросом более подробно, рекомендую великолепную работу Сэмюэля Хьюлика The Elements of User Onboarding («Элементы адаптации новых пользователей»).

ДАННЫЕ, УДАЛЕННЫЕ ПОЛЬЗОВАТЕЛЕМ

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

Этот слой дает возможность вознаградить клиента или мотивировать его на дальнейшие действия (рис. 6.15). В вашем почтовом ящике больше нет писем? Отлично! Получайте за это красивое фото. Вы загрузили всю музыку? Здорово, теперь прослушайте ее. У вас больше не осталось уведомлений? Вот еще парочка, которые могут вас заинтересовать.

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

ОТСУТСТВИЕ РЕЗУЛЬТАТОВ

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

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

В случае с Pinterest (рис. 6.17) результаты не совсем такие же, как в Amazon, но, в конце концов, это Pinterest. Учитывая, как их поисковая система обрабатывает запрос, клиент легко может скорректировать его, чтобы получить желаемое.

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

СОСТОЯНИЕ ОШИБКИ

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

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

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

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

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

НЕТ! ДА! МОЖЕТ БЫТЬ?

Наконец, вот пример контекстного сообщения об ошибке, которое легко понять. Юмор делает его более человечным (рис. 6.19).

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

Кроме того, состояния ошибки не должны выглядеть слишком драматично или непонятно. Помните «синий экран смерти»? Или «панику ядра» на старых iMac? Или, если вы совсем уж ветеран, команды Abort, Retry, Fail? Каждое из этих состояний указывало на существенную системную ошибку, требовавшую перезагрузки или повтора операции. Мы не забыли их до сегодняшнего дня из-за того шока, ужаса и непонимания, которое они вызывали.

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

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

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

Итак, хорошее сообщение об ошибке должно быть:

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

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

ПРОМЕЖУТОЧНОЕ СОСТОЯНИЕ

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

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

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

В данном случае можно использовать некоторые принципы разработки игр. Я не говорю о том, что ваш пользователь должен собирать кристаллы, как в Clash of Clans (рис. 6.21), речь идет об «ускорении», которое можно задействовать на этом этапе.

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

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

На рисунках 6.22–6.24 представлены прекрасные примеры промежуточного состояния.

СОСТОЯНИЕ ЗАГРУЗКИ

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

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

Об этом пишет Люк Вроблевски, эксперт в области продуктового дизайна, руководивший дизайнерскими отделами в eBay, Yahoo и Google (где он работает и по сей день после продажи своего стартапа Polar, занимавшегося созданием мобильного приложения для проведения соцопросов).

Вроблевски и его команда заметили, что после того, как они добавили к каждому опросу круговые прогресс-бары, пользователи Polar начали жаловаться, что приложение работает медленнее, чем обычно: «Приходится долго ждать обновления и загрузки страниц. Предыдущая версия была быстрее».

Вроблевски пишет о своем осознании:

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

КАРКАСНЫЕ ЭКРАНЫ

Благодаря этому пониманию родилось то, что Вроблевски называет «каркасными экранами» (рис. 6.25). Эта технология, в частности, используется в десктопных и мобильных версиях Pinterest и Facebook.

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

Pinterest не только применяет концепцию каркасных экранов, но и обогащает ее некоторыми уникальными чертами. Например, определяет «средний цвет» изображения и заполняет им фон до тех пор, пока само изображение не будет загружено. Таким образом, вы получаете примерное представление о картинке еще до того, как ее видите. Сегодня та же технология применяется и в поиске Google Images.

Facebook разработал аналогичный метод для своего мобильного приложения Paper, а позднее включил его и в десктопную версию (рис. 6.26). Пользователь видит стилизованный каркасный экран с формами, похожими на контент. Чтобы показать, что контент загружается, формы слегка пульсируют. Facebook называет это движение эффектом мерцания.

ОПТИМИСТИЧНЫЕ ДЕЙСТВИЯ КАК ПОКАЗАТЕЛЬ ВЕРЫ В УСПЕХ

«Никому не нравится ждать, даже пока он ждет», — сказал основатель Instagram Майк Кригер в 2011 году, описывая инженерные решения, формирующие впечатление высокой скорости работы его приложения (рис. 6.27).

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

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

Оптимистичные действия позволяют уменьшить воспринимаемое время загрузки. Instagram начинает загружать фото сразу после того, как вы выбрали для него фильтр, а не когда вы нажали «Готово». Это не оптимальное инженерное решение (ведь если пользователь передумает, загруженные данные могут оказаться ненужными), но зато с пользовательской точки зрения загрузка происходит очень быстро. Правило «Перемещайте биты, пока никто не видит» позволяет сделать скорость работы продукта одним из его преимуществ.

ГИПОТЕТИЧЕСКИЙ ПРИМЕР

Мы рассмотрели несколько примеров UI-стека и его пяти слоев по отдельности (рис. 6.28). Но как они взаимодействуют друг с другом? Как пользовательский интерфейс обеспечивает переход из одного состояния в другое?

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

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

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

Итак, с чем нам предстоит иметь дело в нашем приложении?

Сначала у нас вообще не будет сообщений. Это наш пустой слой.

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

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

Во время диалога может произойти ошибка, например сообщение не будет отправлено.

Можно забыть о механизме устранения ошибки и попытаться отправить сообщение еще раз. Это будет еще одна версия слоя загрузки.

Наконец, мы достигнем идеального состояния — когда одно сообщение превратится в беседу.

ГИПОТЕТИЧЕСКИЙ МЕССЕНДЖЕР

Предположим, Марти и Док Браун из фильма «Назад в будущее» обменялись контактами, и Марти хочет рассказать Доку о том, что он видел в магазине Twin Pines Mall.

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

Но что происходит с этим состоянием, когда кто-то отправляет сообщение? Нам нужно аккуратно перейти с пустого слоя в промежуточный. В данном случае промежуточное состояние наступает, когда Марти отправляет Доку первое сообщение.

Давайте перейдем к моменту, когда Док ему отвечает (рис. 6.30). Он уже отправил одно сообщение, но разговор еще не закончен! Поэтому появляется индикатор набора текста, еще одна форма состояния загрузки.

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

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

Что произойдет, если наше сообщение не будет доставлено (рис. 6.32)? Экран перейдет в состояние ошибки. Вместо индикатора загрузки появится красный маркер, и сообщение по-прежнему будет выглядеть тусклым.

Нажав (или, в данном случае, кликнув в Quartz Composer) на неотправленное сообщение, пользователь сможет повторить попытку.

На этот раз нам повезло. Агрессивный красный восклицательный знак пропадает, сообщение становится ярким, и мы видим индикатор доставки.

Вот так, друзья, работает UI-стек.

Я рассказал о пяти состояниях экрана и плавных переходах между ними. Без переходных элементов наш клиент может смутиться или растеряться, когда перед ним появится экран в новом состоянии. А доставлять дискомфорт, вроде бы, не входит в наши должностные обязанности.

Кстати, о комфорте. Давайте перейдем к вопросам эргономики, которые должен учитывать UI в современном мире тачскринов и мобильных устройств.

Эргономика: зоны для больших пальцев и области нажатия

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

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

Нет-нет, мы не попали в фильм «Особое мнение», и нам не доведется работать с потрясающими голограммами, которые создает для Тони Старка его друг ДЖАРВИС (хотя друг ли он ему? Хм…)

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

Даже если сейчас вы не создаете продукты для тачскринов, очень скоро это время придет.

Не верите? Посмотрите на рис. 6.33. ДА, ЭТО МЛАДЕНЕЦ С iPAD.

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

Что же делать?

Помните, в  я рассказывал об истории разработки цифровых продуктов? Я рассматривал работы Лиллиан Гилбрет, Генри Дрейфуса и Скотта Кука. В чем была их основная тема?

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

Что ж, нам повезло.

Эксперт по мобильным технологиям Стивен Хубер провел такое исследование в начале 2013 года и привлек к нему 1333 респондента. Он выяснил, что люди держат телефоны так (рис. 6.34).

• Одной рукой: 49%
• Между плечом и ухом: 36%
• Двумя руками: 15%

Из тех, кто держал телефоны в руках:

• 67% касались экрана большим пальцем правой руки
• 33% — большим пальцем левой руки

Хубер отметил, что левши составляют лишь 10% населения. Соответ­ственно, выявленная им высокая доля пользователей, предпочитавших держать телефон в левой руке, должна была объясняться тем, что те одновременно делали что-то еще: курили, ехали на велосипеде, пили кофе, ели хот-дог и так далее.

Судя по всему, мобильные устройства с диагональю 3,5 и 4 дюйма очень скоро будут забыты. А это значит, что те из нас, кто зарабатывает себе на жизнь созданием приложений, быстро адаптирующихся сайтов и веб-продуктов, оптимизированных под мобильные устройства, должны что-то изменить в своей работе.

Закат подобных устройств уже начался. В отчете 2014 Mobile Benchmark Report от Adobe говорится, что в мае 2014 года поиск с мобильного телефона с диагональю 4 дюйма осуществляли на 11% меньше пользователей, чем за год до этого (рис. 6.35).

Но это исследование касается только телефонов, проданных до мая 2014 года. Если помните, Apple объявили о самом успешном квартале в истории своей компании в январе 2015 года. Тогда было продано почти 75 миллионов iPhone, а iPhone 6 стал самым популярным продуктом Apple.

Это значит, что сейчас нам, как никогда раньше, важно научиться разрабатывать продукты для тех, кто предпочитает взаимодействовать с мобильными устройствами при помощи больших пальцев. Радует то, что размеры экранов этих телефонов будут практически универсальными. Беглый обзор самых популярных размеров экранов телефонов с Android указывает на диапазон от 5,1 до 5,7 дюйма.

Apple несколько упростят нам работу по мере исчезновения смартфонов с небольшими экранами. Диагонали iPhone 6 и iPhone 6+ составляют 4,7 и 5,5 дюйма соответственно.

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

Для меня это звучит как предупреждение. Почему люди должны подстраиваться под мое приложение? Чем оно отличается от других? Почему бы не создать более удобные элементы управления?

ДИЗАЙН ДЛЯ БОЛЬШОГО ПАЛЬЦА

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

Но это сложнее, чем может показаться. Возьмем, к примеру, телефоны с сенсорными экранами. Мы бессознательно слегка перемещаем свой телефон в руке, чтобы иметь возможность коснуться тех или иных элементов на экране. Готов поспорить, что в течение дня вам то и дело приходится тянуться или наклонять телефон в разные стороны, чтобы добраться до той или иной точки на экране.

Но с чего-то нужно начинать. Исследования Хубера показали, что большинство из нас держит телефон так, как показано на рис. 6.36 — основание большого пальца касается правого нижнего угла экрана.

ЗОНА БОЛЬШОГО ПАЛЬЦА

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

• Одной рукой
• Большой палец правой руки на экране
• Основание большого пальца находится в нижнем правом углу экрана

На рис. 6.37 представлена карта зоны большого пальца для мобильных телефонов разного размера, от 4 до 6 дюймов по диагонали.

А вот более подробное сравнение двух больших экранов с диагональю 4,7 и 5,5 дюйма (рис. 6.38).

Обратите внимание, что удобные зеленые зоны остаются практически неизменными (чуть ниже мы поговорим о том, чем самый большой экран отличается от остальных). Это потому, что наш большой палец не увеличивается в размере как по волшебству. Очень жаль, ведь в детстве в игре Street Fighter моим любимым персонажем был Далсим (рис. 6.39).

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

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

ДРУГАЯ ХВАТКА

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

Вот как это работает для экранов с диагональю 4,7 и 5,5 дюйма (рис. 6.40).

Интерфейсы для большого пальца

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

Но как это должно выглядеть? Давайте рассмотрим несколько интерфейсов, удобных для управления большим пальцем.

AIRBNB

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

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

Тем не менее Airbnb переняли у Apple скользящее движение от одного края к другому, что позволяет избежать нежелательного растяжения пальцев при попытке нажать на стрелку возврата сверху.

TINDER

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

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

Размещение контрольных элементов в нижней части экрана, если ваш продукт предназначен для устройств с тачскрином, кажется разумной тактикой. Так они окажутся в зоне досягаемости большого пальца. Даже если ваш пользователь держит телефон одной рукой, а управляет второй, продукт все равно будет оптимизирован под одну руку. Не забудьте, где контрольные элементы размещают производители (Apple — кнопку Home, Android — контрольную панель, а Windows Phone — старт, кнопка Home и поиск). Все они находятся в нижней части устройств.

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

Кросс-платформенный дизайн

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

На самом деле все еще сложнее. На индивидуальном уровне мы используем более широкий ассортимент устройств (рис. 6.43). Утром это планшет, мобильный телефон или телевизор, в дневное время — ноутбук, «умные» часы или бортовой компьютер в автомобиле, вечером — снова комбинация из планшета, смартфона и телевизора.

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

Как же справиться с этим огромным морем устройств, для которых нужно разрабатывать единые и последовательные продукты? Как создавать продукты, которые выдержат испытание будущим и при этом все равно будут бороться с проблемами клиентов, каким бы устрой­ством они ни воспользовались?

С этим важным вопросом я обратился к Бенедикту Ленерту, директору по дизайну в успешной кросс-платформенной компании Wunderlist. Wunderlist работает на множестве платформ, от iOS до Kindle Fire, в том числе на iPhone, iPad, Apple Watch, Mac, Android, Windows Phone, Windows и в десктопных приложениях. В июне 2015 года Wunderlist приобрела компания Microsoft.

Ленерт согласился дать нам несколько комментариев по этому во­просу.

ЧЕГО ХОТЯТ И ЖДУТ ВАШИ КЛИЕНТЫ?

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

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

Именно на таком принципе основывается вся работа в Wunderlist.

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

Сознательно или нет, берлинская компания Wunderlist наполняет свои продукты для любых платформ свойствами, которые важны для ее клиентов, — скоростью, простотой, ясностью и человечностью. Эти характеристики доступны на любых платформах, от iOS до Kindle Fire.

СПЕЦИФИКА ПЛАТФОРМЫ

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

«Кросс-платформенный продукт должен одновременно соответствовать характеристикам основного продукта и платформенным парадигмам каждой операционной системы, — говорит Ленерт. — Наша задача как разработчиков состоит в том, чтобы понимать эти парадигмы и в них уметь ориентироваться». Создавая продукт для нескольких платформ, важно соблюдать нормы. Например, на Android контрольные элементы системы находятся в нижней части устройства, а на девайсах с iOS их заменяет одна кнопка Home. Это существенно влияет на подход к продуктам для мобильных телефонов и планшетов.

Это верно и для любой платформы. Разрабатываете продукты для телевизионных приставок? Значит, вы должны знать характеристики каждого пульта или контроллера. Roku, Apple TV, Google Chromecast, Xbox, PS4 и так далее — у каждого из них свои нюансы. Знание этих нюансов и умение включить их в свой продукт находятся в зоне ответ­ственности дизайнера. Но эта ответственность ограничена. «Для того чтобы понимать, где нужно следовать правилам ОС, а где можно их нарушить для обеспечения единообразия на всех платформах, требуется определенный опыт и мастерство», — утверждает Ленарт. В конце концов, мы создаем продукт для клиентов. Каковы их потребности? Если требования платформы, для которой создается продукт, вступают с ним в конфликт, как вам следует поступить?

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

Один из примеров такого подхода — жест «потянуть для обновления», заменивший кнопку обновления. Его ввел Лорен Брихтер в Tweetie, а после приобретения компании его включили в функционал Twitter (рис. 6.44).

Это идеальный пример того, как пользовательский интерфейс эволюционирует под влиянием платформенных ограничений. В Tweetie 1.0 кнопка обновления располагалась в верхней части ленты. Это решение было порождением своего времени — Брихтер просто не смог добавить ее в панель навигации. В следующей версии он решил это исправить. Он задался вопросом: «Почему бы не сделать обновление элементом самого движения пролистывания?». Так родился жест «потянуть для обновления» (рис. 6.45).

ПОЛЬЗОВАТЕЛЬСКИЕ СЦЕНАРИИ ДЛЯ КАЖДОГО УСТРОЙСТВА

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

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

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

Вот почему, к примеру, для Apple Watch отсутствует полноценная версия Wunderlist. Вместо нее используется лаконичный, сокращенный вариант программы, который просто сообщает пользователю то, что ему нужно знать, в соответствующее время (рис. 6.46).

«Одна из наиболее интересных характеристик Wunderlist для Apple Watch — бесконтактная работа приложения. Вам не нужно лихорадочно жонглировать телефоном, — говорит Ленерт. — Достаточно идти по супермаркету и вычеркивать пункты из перечня покупок или даже использовать голосовое управление, чтобы составить список дел на завтра».

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

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

Резюме

• Самое важное — баланс. Если бы копирайтинг для интерфейсов, создание выверенных макетов и рабочих макетов были частями космического корабля, это были бы реактивные двигатели. Только при их скоординированной работе наш корабль смог бы успешно проходить космические шлюзы.
• Независимо от того, что написано в вашем проектном документе (спецификации, пользовательской истории, или как вы называете его у себя в компании), и от того, как выглядят созданные вами макеты, вам все равно потребуется полностью проработанная версия интерфейса для вашего продукта.
• Потому что детально проработанные модели — это идеальное средство коммуникации, они могут быть интегрированы в макеты и заполнены уже готовыми текстами. Вуаля! Теперь можно сказать всем, что у вас есть готовый продукт. Недоверие исчезает, и вы получаете искренние комментарии и мнения. Кроме того, выверенные макеты в сочетании с прототипами представляют собой идеальную инструкцию для инженеров. Но не забывайте, что этот подход будет эффективным лишь после того, как вы пропишете пользовательские сценарии и создадите рабочие прототипы. Иначе часть пользовательских сценариев, а то и весь продукт, могут провалиться.
• Неловкий UI — это отсутствующий индикатор загрузки; это ситуация, в которой вы забываете сказать пользователю, что что-то пошло не так, или делаете это при помощи сообщения об ошибке; это странно выглядящие графики всего с несколькими точками; это ошибки при вводе новых данных.
• Для борьбы с неловким UI можно использовать UI-стек. UI-стек — это сочетание пяти слоев, или состояний (идеального, пустого, промежуточного, ошибочного и состояния загрузки), а также переходы между ними.
• Для эргономичного дизайна учитывайте расположение зоны большого пальца. Это своего рода тепловая карта, показывающая, насколько легко наш большой палец может дотянуться до той или иной области на экране.

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

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

Интервью: Диогенис Брито

Диогенис Брито — разработчик и продуктовый дизайнер, работавший в Slack, LinkedIn и Squarespace.

Я хотел начать с твоего недавнего поста «Что означает быть дизайнером и разработчиком: это не так сложно, как вы думаете». Ты очень четко и понятно описал роли разработчика и дизайнера. Многих людей интересует пересечение областей дизайна и разработки. А как ты пришел к выводу о том, что у хорошего дизайнера и хорошего разработчика много общего? Мне бы хотелось понять ход твоих мыслей.

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

Если ты разработчик-фрилансер, заказчик воспринимает тебя как универсала, и у тебя нет выбора, кроме как делать все и сразу. Когда я накопил достаточно опыта, то задумался: а могу ли я говорить о себе как о дизайнере и разработчике одновременно? Как на это отреагируют люди, поверят ли мне? Это казалось мне нереальным.

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

Я задумался, почему многие люди считают дизайн и разработку диаметрально противоположными областями. Мне кажется, что в некоторых случаях это воспринимают как противостояние художника и… не знаю, не могу подобрать пример. Кажется, у Бейлза были бариста и инженер ракетостроения.

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

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

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

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

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

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

Да, последний пункт кажется мне очень интересным. Я всегда думал, что не могу делать и то и другое. Наступает ли момент, когда нужно выбирать? И как с этим справиться?

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

Музыканты мирового уровня играют только на одном инструменте. Понимаешь, о чем я?

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

Можно быть профессионалом, можно даже совмещать обе должности на работе, но я бы сказал, что в Squarespace я занимался, скорее, фронтендом, а не дизайном. Сейчас я поменял приоритеты.

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

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

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

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

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

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

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

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

Кажется, когда-то я начал с книги Emotional Design («Эмоциональный дизайн») Дона Нормана. Она заставила меня задуматься о некоторых животных инстинктах, которые необходимо учитывать в дизайне для людей.

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

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

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

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

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

Кстати, это напомнило мне о еще одной книге — «Интерфейс: новые направления в проектировании компьютерных систем» Джефа Рас­кина.

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

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

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

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

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

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

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

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

Важно помнить, что 100% ваших пользователей — люди. Технологии могут стремительно изменяться, но с человеческой мотивацией ничего не произойдет. Пирамида потребностей Маслоу останется прежней.

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

Мне нравится эта фраза: «Если строить свой дизайн исходя из того, чего хотят люди, он продержится дольше».

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

Отправить