Текст книги "Как создать продукт, который полюбят"

Резюме

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

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

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

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

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

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

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

• Подумайте, как ваш продукт может сделать пользователей счастливее. Он действительно приносит им радость? Вы действительно можете уменьшить их боль и удовлетворить их потребности?

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

Интервью: Сахил Лавинья

Сахил Лавинья – один из участников первой команды Pinterest. Он принимал участие в разработке знаменитой дизайн-панели, кнопок Pin It и Pinmarklet. После ухода из Pinterest он создал первое приложение Turntable.fm для iOS, а вскоре после этого запустил сервис Gumroad, который помогает художникам продавать свои произведения клиентам по всему миру. Сегодня Сахил занимает пост исполнительного директора Gumroad.

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

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

Как началась ваша карьера?

Осенью 2010 года я учился [в Университете Южной Каролины]. Я планировал получить диплом и не собирался покидать университет. Как раз в это время я начал публиковать множество своих работ в сети и в один прекрасный день задумался: «Я наконец-то в Штатах, в Калифорнии. Пора бы познакомиться со всеми этими людьми, о которых я столько читал». Я начал работать по контракту со стартапами, затем они предложили мне работу на полный день, и тогда я понял, что могу заниматься тем, чем я хочу, и без диплома. Я ушел из университета после первого семестра, то есть через четыре месяца.

В 18 лет я начал работать в Pinterest и проработал там год. Занимался самыми разными вещами – дизайном, фронтендом, бэкендом. Моим первым детищем было мобильное приложение, в котором я создал практически все.

Затем некоторое время я работал на нью-йоркский стартап Turntable.fm, для него я тоже разработал мобильное приложение. А после этого отправился в свободное плавание.

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

Бен [Зильберман, один из основателей и исполнительный директор Pinterest] умеет об этом говорить, особенно сейчас, но на самом деле мы никогда не были известным стартапом уровня Кремниевой долины. Никто вообще не знал, что мы есть. TechCrunch долгое время не было дела до Pinterest. Все, чем мы располагали, – группа преданных пользователей, которым наш продукт действительно нравился.

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

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

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

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

Когда я рассказываю людям из технологической сферы про этот ход, обычно слышу: «Что за ерунда!». Никто ведь всерьез не верит, что бета-версия проекта такая уж секретная. Но подумайте: вот вы получаете в день миллион электронных писем, не так ли? Еще одно погоды не сделает. Но обычным людям, а особенно тем, кто первым начал использовать Pinterest и, вероятно, продолжает это делать сейчас, корреспонденция не приходит в таком объеме. Загляните в их почтовые ящики, и вы увидите письма только от Facebook и Pinterest.

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

Судя по всему, тот факт, что Кремниевая долина вас недооценивала, только подтолкнул Pinterest к дальнейшему развитию?

Да, это довольно забавно. Я помню, как однажды Бен [Зильберман] рассказывал: «Я только что был на встрече, и меня спросили: “Так вы что же, делаете сайт для женщин? Вы не боитесь, что его будут использовать только женщины?” И я ответил: “Да-да, мы очень боимся, что нашим проектом заинтересуется всего 50 % населения Земли”».

И это действительно так. Мне кажется, что среди пользователей Facebook гораздо больше женщин, чем мужчин. У них куда более высокий уровень вовлеченности. Я уверен, что и c Instagram, и со Snapchat такая же ситуация. Но в Кремниевой долине не принято обращать внимание на те вопросы, с которыми работали мы, потому что они считались занудными и не клевыми.

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

Да, и мне нравится, что прозвучало слово «инструменты». В Pinterest мы всегда использовали именно его: «Как создать инструменты, которые помогут нашим пользователям решить проблему?». Многие обращают внимание лишь на общую картину, но к ней можно прийти лишь в том случае, если сервис приносит пользу каждому отдельному человеку.

Я всегда смотрел на нашу работу как на попытку отвлечь людей от папки с закладками в браузере. Internet Explorer был для нас главным конкурентом, и мы увели у него больше пользователей, чем у любой другой программы. Когда мы задумывались о своей цели, то говорили: «Мы должны дать людям набор функций, которые позволят им помечать любую найденную информацию, собирать ее в одном месте, коллекционировать идеи, делиться ими и так далее».

Пользователям требовалось место, где можно было бы хранить все 5000 идей для оформления нового дома. Неважно, сколько рекомендаций, бейджей, рейтингов и других элементов геймификации им предлагали. Все сводилось к одному – им просто был нужен сервис для сбора информации[80]80
  Это интервью приводится в сокращенном виде. Чтобы не пропустить еще много полезных мыслей, прочтите его целиком на http://scotthurff.com/dppl/interviews


[Закрыть].

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

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

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

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

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

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

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

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

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

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

Раскин понимал, что модель Apple II слишком сложна для повседневного использования, и решил разработать основные принципы «простого в использовании» компьютера. В своей книге «Интерфейс»[81]81
  Раскин, Д. Интерфейс: новые направления в проектировании компьютерных систем. М.: Символ-плюс, 2005. Прим. ред.


[Закрыть], опубликованной через два десятилетия после его ухода из проекта Macintosh, он переосмыслил и дополнил основные идеи об интерфейсе «человек – компьютер».

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

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

На первом этапе разработки следует определить, что именно должен сделать пользователь для получения того или иного результата и как система должна отвечать на каждое его действие[82]82
  Цит. по: Раскин, Д. Интерфейс: новые направления в проектировании компьютерных систем. Прим. ред.


[Закрыть].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


[Закрыть].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, сервис Snapchat известен тем, что первым экраном, который видит пользователь, служит камера. Каждый раз, когда кто-то запускает Snapchat, приложение открывает камеру. Все остальное – на втором плане: просмотр чужих фотографий, работа с настройками, добавление друзей. Все, что поощряет в первую очередь создание контента. Кроме того, формируются новые ожидания клиента, связанные с обменом фотографиями (рис. 4.2)[84]84
  http://mentalfloss.com/article/26346/jk-rowlings-plot-spreadsheet


[Закрыть].

Рис 4.2. Демонстрация возможностей Snapchat для бизнеса

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

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

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

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

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

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

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

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

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

• Какая последовательность действий позволяет клиентам решить свои задачи?

• Как они решат эти задачи?

• Что произойдет после?

• Есть ли потенциальные затруднения?

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

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

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

Рис. 4.3. Карта сценариев, которую использовала Кейтлин Фридсон, работая над продуктом для Care.com

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

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

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

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

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

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

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

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

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

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

Рис. 4.4. Схема, которую я набросал, работая над одним из мобильных продуктов

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

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

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

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

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

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

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

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

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