[4]

Пользовательский интерфейс начинается со слов

Правда? Начинать со слов?

По мнению клиентов, интерфейс — это и есть продукт.

Джеф Раскин, эксперт по взаимодействию человека и компьютера и автор проекта Macintosh компании Apple

Представьте, что вы современник проекта Macintosh.

1979 год. Диско. Брюки клеш. Все с нетерпением ждут, когда на экраны выйдет «Империя наносит ответный удар». Кризис с захватом заложников в Иране.

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

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

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

Джеф Раскин, один из авторов проекта Apple Macintosh, помог претворить этот технологический прорыв в жизнь, потому что верил, что компьютер может стать таким же простым в использовании устрой­ством, как телевизор.

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

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

Одна из его ключевых идей: разработчик должен начинать работу с… копирайтинга.

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

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

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

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

Сколько времени вам требуется на то, чтобы ввести слова в текстовом редакторе? А чтобы нарисовать квадраты, в которые вписаны слова, и провести стрелки?

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

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

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

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

Мне нравится, как эту идею сформулировал Джейсон Зимдарс, iOS-дизайнер Basecamp:

Мой любимый инструмент для набросков — iA Writer [минималистичный текстовый редактор].

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

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

Как описать пользовательский интерфейс? В три этапа.

1. Изобразить последовательность действий (так называемые сценарии), которые произведут пользователи, чтобы завершить все задачи.
2. Для каждого экрана пользовательского сценария перечислить компоненты, необходимые для выполнения каждого шага. Формы? Кнопки? Данные? Перечень должен быть максимально подробным.
3. Написать текст интерфейса. Каким будет его заголовок? Контекст? Особенности речевого стиля? Следует ли отразить в тексте личностные особенности? Не используйте Lorem ipsum.

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

Теперь давайте перейдем к описанию пользовательских сценариев.

Описание пользовательских сценариев

Писателям в жанре научной фантастики, фэнтези или триллера приходится следить за большим количеством сюжетных линий. Написание книги — и тем более серии книг — с параллельными или связанными между собой сюжетными линиями требует всеобъемлющей самоорганизации. Вы представляете, как Джорджу Мартину, Джону Толкину или Джоан Роулинг удавалось следить за всеми персонажами и ответвлениями повествования?

Что ж, у вас есть возможность узнать, что происходило в голове у Джоан Роулинг, когда она работала над «Гарри Поттером и Орденом Феникса». В 2010 году в интернете появилась составленная ею от руки таблица сюжетных линий. В столбцы внесены номера глав, вре­мен­ные рамки событий, ключевые моменты фабулы, второстепенные сюжетные линии и названия глав (рис. 4.1).

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

В итоговой версии книги многие элементы претерпели изменения. Так, в таблице профессора Амбридж зовут Эльвира, а не Долорес, а Орден Феникса и Отряд Дамблдора впоследствии обменялись назва­ниями.

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

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

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

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

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

• Требуется ли на этом этапе экран или можно ограничиться всплывающим окном?
• Нужна ли на этом этапе другая форма для заполнения или можно воспользоваться уже имеющимися данными с предыдущего эк­рана?
• Если речь идет о потенциально «опасном» сценарии для пользователя, требуется ли для данного действия двойное подтверж­дение?

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

• Где начинается взаимодействие: внутри самого продукта или после перехода с внешней страницы?
• Каковы ожидания пользователей? Ваши клиенты взаимодействуют с интерфейсом впервые? Они проявляют любопытство или ведут себя осторожно? Или ваши пользователи достаточно опытные и хотят выполнить задачу как можно быстрее?
• Какие решения принимают пользователи на каждом из экранов — и что за ними следует?
• Какую информацию вы должны предоставить пользователям?
• Какие данные должны ввести пользователи?
• Что произойдет, когда пользователи совершат правильные / неправильные действия? Что отображается на экране? Куда вы перенаправляете пользователей?

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

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

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

Например, сервис Snapchat известен тем, что первым экраном, который видит пользователь, служит камера. Каждый раз, когда кто-то запускает Snapchat, приложение открывает камеру. Все остальное — на втором плане: просмотр чужих фотографий, работа с настройками, добавление друзей. Все, что поощряет в первую очередь создание контента. Кроме того, формируются новые ожидания клиента, связанные с обменом фотографиями (рис. 4.2).

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

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

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

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

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

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

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

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

Сценарии призваны дать ответы на несколько вопросов:

• Какая последовательность действий позволяет клиентам решить свои задачи?
• Как они решат эти задачи?
• Что произойдет после?
• Есть ли потенциальные затруднения?

Как происходит взаимодействие? Рисунки? Диаграммы? Интеллект-карты?

Возможно, метод Траутмана вам не подходит из-за минималистичности или недостаточной визуализации.

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

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

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

Разработчики учитывают, что будут действовать в границах определенного итерационного цикла. Например, в Care мы создавали сценарий платежей между физлицами. Мы знали, в какую систему мы интегрируемся и еще о 4–6 кейсах использования, над которыми нам предстоит работать. Мы дали нашим специалистам время на изучение и даже кодирование данных сценариев: интеграцию с API, тестирование и так далее. Помимо прочего, это позволило нам найти ответы на возможные вопросы, не прописанные в спецификации продукта.

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

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

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

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

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

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

В работе над своими проектами я предпочитаю использовать метод Джоан Роулинг: набросать на листе бумаги текст и соединить его стрелками. Как и в случае с Брито, я делаю это прежде всего для себя. Это отличный способ организовать свои мысли и рассмотреть все возможные варианты развития событий. Вот, например, схема, которую я нарисовал, разрабатывая один из мобильных продуктов (рис. 4.4).

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

Обратите внимание: в верхней части схемы я хотел отметить три преимущества, но на тот момент еще не определился с выбором, поэтому не стал останавливаться на них подробно.

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

Например, что, если вы выберете Instagram? А если Facebook? А если вы еще не зарегистрированы в Instagram или произойдет ошибка авторизации (рис. 4.5)?

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

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

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

Итак, мы рассмотрели картину в целом, но как насчет отдельных эк­ранов?

Создание экранов

Проработка особенностей каждого экрана — один из самых важных этапов в создании пользовательского интерфейса. Так, Джеф Раскин в «Интерфейсе» писал: «С точки зрения потребителя именно интерфейс является конечным продуктом».

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

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

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

Райан Шерф, продуктовый дизайнер компании Quirky, согласен с этим высказыванием. «Эскизы (скетчинг) — это суперважно. Не бывает плохих идей. Когда мы обдумываем варианты и отбрасываем некоторые из них, необходимо, чтобы вся команда понимала, что плохих идей не существует и что кто-то должен высказать идею первым, пусть даже она, как правило, оказывается самой худшей».

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

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

• Информация о пользователе (имя, возраст, биография, должность и т. д.)
• Элементы коммуникации, такие как список друзей, интересов или посещенных мест, которыми можно поделиться с другими людьми
• Фотографии, видео, иные мультимедиа
• Главные и второстепенные действия, которые может выполнить пользователь

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

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

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

В реальном мире у вас есть массив данных для загрузки информации и ограничения по формату: рабочий стол, iPhone, Android и т. д. Какие основные элементы интерфейса вам необходимо сохранить? Что именно требуется для того, чтобы экран был идеальным?

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

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

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

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

Признаки хорошего интерфейса

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

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

Джон Траутман из Canary отметает любые попытки вставить на этом этапе текст-заполнитель вроде Lorem ipsum (и даже мой любимый Riker ipsum с цитатами капитана Райкера из «Звездного пути», как бы сильно того ни хотелось):

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

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

КТО ВАША АУДИТОРИЯ?

Кто использует ваш продукт? Пользователям удобно работать с ним на любом экране? Они знакомятся с вашим продуктом впервые или давно о нем знают? Они используют его бесплатно или за деньги?

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

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

В КАКОМ ТОНЕ ВЫДЕРЖАН ТЕКСТ?

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

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

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

КАКОВ КОНТЕКСТ?

Это главная страница? Форма регистрации? Раздел с настройками? Экран, который пользователь видит впервые? Политика доставки товара? Ответ на действие пользователя?

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

Хороший текст учитывает контекстные ограничения. Например, СМС должны быть вежливыми, а общий объем текста не должен превышать 160 символов.

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

НАСКОЛЬКО ВЫ ПОСЛЕДОВАТЕЛЬНЫ?

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

Вы можете «Войти», а затем «Выйти»? Для перехода на новый экран нужно нажать «Продолжить» или «Вперед»? Подтверждение сопровождается кнопкой «ОК», «Отправить» или «Принять»? Базовые команды должны быть одинаковыми для всех экранов продукта.

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

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

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

Для различных культур характерны разные нормы. В Великобритании, например, могут счесть оскорбительным избыток восклицательных знаков. Кто же знает об этом? Знать — ваша работа.

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

Резюме

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

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

• Приступая к работе над следующим проектом, бросьте себе вызов: начните с пустоты — мигающего курсора на белом фоне.
• Подумайте о тональности текста. Должен ли он быть остроумным? Успокаивающим? Как это поможет продукту принести пользу клиентам?
• Скажите решительное «нет» Lorem ipsum (и даже моему любимому Riker ipsum»)!

Интервью: Джон Траутман

Джон Траутман — сооснователь и главный креативный директор компании Canary, которая разрабатывает и продает охранные системы и программное обеспечение для дома. Компания была основана как краудфандинговый проект на Indiegogo и впоследствии стала самым успешно профинансированным проектом, собравшим около двух миллионов долларов. Джон также сооснователь Дискуссионного клуба разработчиков и бывший продуктовый дизайнер коворкинговой компании General Assembly.

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

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

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

Правда?

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

Звучит здорово!

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

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

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

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

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

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

Не кажется ли вам, что в этом случае написание текстов становится более емким процессом, поскольку на начальном этапе все внимание уделяется именно ему?

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

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

Например, работая с сайтом General Assembly, я должен был сначала спроектировать его информационную архитектуру, все правильно структурировать, а затем передать файлы коллегам. Я буквально архивировал HTML-документы и рассылал папку некоторым членам коман­ды. Они извлекали файлы из архива, перетаскивали один из них в браузер и просматривали нестилизованный или предварительно стилизованный сайт. В течение дня они обдумывали увиденное, а я в это время продолжал экспериментировать с дизайном, перемещая элементы и меняя их в HTML, чтобы добиться более высокой точности прототипа.

В какой момент вы и ваша команда принимаете окончательное решение, что прототип готов, и переходите к следующему этапу?

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

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

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

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

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

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

Сейчас я работаю над продуктом компании Canary. Мы создали «первое универсальное умное устройство для охраны дома». Его очень просто использовать: достаточно просто включить его в розетку, чтобы сенсоры и HD-камеры начали наблюдать за вашим домом, а вы могли контролировать ситуацию с помощью своего смартфона.

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

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

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

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

Отправить