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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Написать текст интерфейса. Каким будет его заголовок? Контекст? Особенности речевого стиля? Следует ли отразить в тексте личностные особенности? Не используйте Lorem ipsum [83].

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

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

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

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

Рис. 4.1. Автор «Гарри Поттера» Джоан Роулинг использует написанную от руки матрицу, чтобы структурировать сюжеты своих романов

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

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

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

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

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

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

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