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

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

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

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

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

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

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

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

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

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

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

• Требуется ли на этом этапе экран или можно ограничиться всплывающим окном?

• Нужна ли на этом этапе другая форма для заполнения или можно воспользоваться уже имеющимися данными с предыдущего экрана?

• Если речь идет о потенциально «опасном» сценарии для пользователя, требуется ли для данного действия двойное подтверждение?

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

• Где начинается взаимодействие: внутри самого продукта или после перехода с внешней страницы?

• Каковы ожидания пользователей? Ваши клиенты взаимодействуют с интерфейсом впервые? Они проявляют любопытство или ведут себя осторожно? Или ваши пользователи достаточно опытные и хотят выполнить задачу как можно быстрее?

• Какие решения принимают пользователи на каждом из экранов – и что за ними следует?

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

• Какие данные должны ввести пользователи?

• Что произойдет, когда пользователи совершат правильные / неправильные действия? Что отображается на экране? Куда вы перенаправляете пользователей?

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

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