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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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