Я не шучу. Разработка пользовательского интерфейса начинается со слов. Я смотрю на него как на беседу, как на способ рассказать друзьям, что и как они могут сделать.
Слова позволят проникнуть в суть, понять, кто и зачем будет использовать ваш продукт, и не дадут сразу перескочить на то, что и как должно быть сделано. В основе интерфейса должен лежать диалог с будущими пользователями, а не попытки сразу перейти к разработке компонентов. Поскольку, как пишет Раскин: «Пользователей не волнует, что находится внутри коробки, до тех пор, пока коробка делает все, что им нужно».
Как описать пользовательский интерфейс? В три этапа.
1. Изобразить последовательность действий (так называемые сценарии), которые произведут пользователи, чтобы завершить все задачи.
2. Для каждого экрана пользовательского сценария перечислить компоненты, необходимые для выполнения каждого шага. Формы? Кнопки? Данные? Перечень должен быть максимально подробным.
3. Написать текст интерфейса. Каким будет его заголовок? Контекст? Особенности речевого стиля? Следует ли отразить в тексте личностные особенности? Не используйте Lorem ipsum
[83].
Не существует идеального алгоритма действий. Ваша цель — двигаться вперед и добиваться результатов в максимально короткие сроки, при этом не держа в голове все детали продукта. Основная задача составления текстовой основы — четкое понимание, что вы создаете, и налаживание коммуникации с теми, кто будет разрабатывать продукт. Проблемы системной разработки можно обдумать или спроектировать на бумаге задолго до появления первого пикселя или первой строчки кода.
Теперь давайте перейдем к описанию пользовательских сценариев.
Описание пользовательских сценариев
Писателям в жанре научной фантастики, фэнтези или триллера приходится следить за большим количеством сюжетных линий. Написание книги — и тем более серии книг — с параллельными или связанными между собой сюжетными линиями требует всеобъемлющей самоорганизации. Вы представляете, как Джорджу Мартину, Джону Толкину или Джоан Роулинг удавалось следить за всеми персонажами и ответвлениями повествования?
Что ж, у вас есть возможность узнать, что происходило в голове у Джоан Роулинг, когда она работала над «Гарри Поттером и Орденом Феникса». В 2010 году в интернете появилась составленная ею от руки таблица сюжетных линий. В столбцы внесены номера глав, временные рамки событий, ключевые моменты фабулы, второстепенные сюжетные линии и названия глав (рис. 4.1).
Рис. 4.1. Автор «Гарри Поттера» Джоан Роулинг использует написанную от руки матрицу, чтобы структурировать сюжеты своих романов
Если вы знакомы с миром поттерианы, то можете заметить, что некоторые события не упоминались в романе напрямую — в частности, побочные сюжетные линии, отмеченные на правой стороне страницы. Роулинг записала события, происходившие в контексте созданной ею вселенной, чтобы держать в уме даже те моменты, которые не были прямо обозначены в романе.
В итоговой версии книги многие элементы претерпели изменения. Так, в таблице профессора Амбридж зовут Эльвира, а не Долорес, а Орден Феникса и Отряд Дамблдора впоследствии обменялись названиями.
Даже если вы не читали книги про Гарри Поттера (стойте, вы не читали их, но читаете эту книгу? Советую как можно скорее решить эту проблему), вывод очевиден.
Роулинг не сразу приступила к написанию романа. Она скрупулезно планировала повествование, тем самым минимизируя возможные последствия ошибок и неудачных идей. В худшем случае, если бы сюжет не сходился, Роулинг пришлось бы скомкать лист бумаги и выкинуть его. В таблице вы можете заметить зачеркнутые ошибки и неудачные решения — представьте, что было бы, если бы вместо этого она написала всю сцену целиком!
Описанный процесс во многом схож с разработкой пользовательского интерфейса. Создав его схему, вы прорабатываете фабулу, персонажей и второстепенные линии сюжета.
Схемы играют важную роль, поскольку клиенты не выполнят поставленную перед ними задачу с помощью одного экрана. Любой ваш продукт — от регистрации до съемки фото или просто кнопки «ОК» — будет оцениваться в зависимости от того, как экраны… да-да, следуют друг за другом.
Удобная и логичная последовательность действий пользователя — неотъемлемая черта превосходного продукта. Едва ли подобного можно добиться с помощью одного экрана. В большинстве случаев схематизация работы продукта позволит определить наилучшие подходы для каждого этапа. Например:
• Требуется ли на этом этапе экран или можно ограничиться всплывающим окном?
• Нужна ли на этом этапе другая форма для заполнения или можно воспользоваться уже имеющимися данными с предыдущего экрана?
• Если речь идет о потенциально «опасном» сценарии для пользователя, требуется ли для данного действия двойное подтверждение?
Как правило, на этой стадии разработки составление схем необходимо, поскольку оно позволяет выявить следующие детали:
• Где начинается взаимодействие: внутри самого продукта или после перехода с внешней страницы?
• Каковы ожидания пользователей? Ваши клиенты взаимодействуют с интерфейсом впервые? Они проявляют любопытство или ведут себя осторожно? Или ваши пользователи достаточно опытные и хотят выполнить задачу как можно быстрее?
• Какие решения принимают пользователи на каждом из экранов — и что за ними следует?
• Какую информацию вы должны предоставить пользователям?
• Какие данные должны ввести пользователи?
• Что произойдет, когда пользователи совершат правильные / неправильные действия? Что отображается на экране? Куда вы перенаправляете пользователей?
Подобная разведка на ранних этапах избавляет от необходимости удерживать множество деталей в голове. Более того, все члены команды понимают, как из частей образуется целый продукт, и получают возможность адаптироваться к изменениям в работе.
На этом этапе вы ничем не рискуете, поэтому лучше всего обозначить открыто все варианты, с которыми вам приходится иметь дело. С высокой долей вероятности в процессе разработки прототипов интерфейса и, впоследствии, финальной версии схемы претерпят изменения.
С чего начать? Прежде всего, сосредоточиться на основных способах применения продукта и отталкиваться от этого. Спроектировав основные алгоритмы действий, в дальнейшем вы сможете опираться на них при разработке дополнительных. Иными словами, вторичный функционал должен основываться на первичном. Такой подход убедит клиентов в уникальности и удобстве вашего продукта.
