Как предотвратить расползание функций с помощью лучших практик пользовательской истории

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

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

В ходе этого процесса мы лихорадочно генерируем множество UX-артефактов: доски настроения, карты сайта, потоки пользователей, персоны и карты эмпатии, и это лишь некоторые из них. Лодка загружена, но плывет без руля и карты. Затем однажды мы просыпаемся, и нас осеняет: « Зачем мы делаем этот продукт, как мы определяем его функции и как мы расставляем их по приоритетам? ”

Классический будильник.

Ужасная «фича ползучесть» подкрадывается ближе прямо у нас под носом.

К счастью, есть средство борьбы с ним. Это дизайнерская тактика, называемая пользовательскими историями .

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

Для большинства Agile-команд пользовательские истории являются основным средством поэтапной доставки программного обеспечения. Проворный Альянс

Что такое пользовательская история?

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

Пользовательская история короткая, конкретная и целенаправленная. Это одно предложение, составленное с точки зрения пользователя и имеющее следующую структуру:

« Как (тип пользователя) я хочу (цель), чтобы я мог (получить выгоду). ”

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

Если есть какой-то принцип, священный для тех, кто занимается дизайном пользовательского интерфейса и взаимодействием человека с компьютером, то это принцип « знай своего пользователя ». Дон Норман, соучредитель и почетный директор Nielsen Norman Group

Согласование пользовательских историй между дизайном и Agile

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

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

Эти убеждения до некоторой степени обоснованы, но также ошибочны .

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

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

Пользовательские истории для тестирования продукта и метрик UX

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

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

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

Кроме того, пользовательские истории можно использовать для определения результатов UX (оцениваемых с помощью метрик успеха UX) и помогающих дизайнерам проверять эволюцию продукта с помощью метрик прогресса UX.

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

Как создавать отличные пользовательские истории

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

Дизайнеры могут взять существенные повествования UX, основанные на персонажах и целях пользователей, и разделить их на более мелкие части: пользовательские истории . Например, допустим, мы работаем над мобильным банковским приложением. Целью Epic будет «управлять деньгами на ходу». Затем эту более крупную пользовательскую цель можно разделить на более мелкие пользовательские истории, например:

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

Как мы придумываем такие пользовательские истории? Используя различные методы исследования UX, такие как затенение (метод наблюдения), дневниковые исследования и интервью с пользователями. В качестве альтернативы дизайнеры могут использовать аналитику продукта для выявления моделей поведения пользователей и выявления базовых структур, которые управляют этими моделями.

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

Как писать и расставлять приоритеты пользовательских историй

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

Как техника, пользовательские истории должны быть компактными и легкими, позволяя командам быстро создавать продукты. Как упоминалось ранее, они должны быть записаны как простое утверждение из одного предложения с точки зрения пользователя: « Как (пользователь), я хочу (сделать что-то/цель), чтобы я мог (достичь желаемого результата). ”

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

Чтобы написать отличную пользовательскую историю:

• Оно должно быть четким, целенаправленным и действенным.
• Он должен запечатлеть историю так, чтобы она казалась ценной.
• Его можно перевести в характеристику продукта.
• У него есть приемочный тест (достигнута ли цель?).

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

Несколько аспектов влияют на индекс приоритета пользовательской истории:

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

Преимущества пользовательских историй в дизайне

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

Работа с пользовательскими историями имеет несколько преимуществ:

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

Улучшенный дизайн продукта с картированием пользовательских историй

Дизайнеры не должны полагаться только на пользовательские истории при разработке продукта — комплексный процесс разработки продукта включает в себя множество других методов и артефактов. Хорошо интегрированные пользовательские истории должны дополнять друг друга, как кусочки головоломки, составляющие UX всего продукта. И наоборот, разрозненные пользовательские истории будут нарушать связность пользовательского опыта.

Другие потенциальные проблемы при использовании исключительно пользовательских историй для управления дизайном:

• Отсутствие контекста (игнорирование общего результата UX)
• Отсутствие чувства полноты (неуверенность в том, что достигнуты более крупные цели)
• Путать пользовательские истории с вариантами использования
• Отсутствие развития продукта (пользовательские истории не фиксированы, они имеют тенденцию меняться со временем)

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

Резюме

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

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

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

Поделитесь с нами вашими мыслями! Пожалуйста, оставьте свои мысли, комментарии и отзывы ниже.

• • •

Дальнейшее чтение в блоге Toptal Design:

• Сила Figma как инструмента дизайна
• Подробное руководство по дизайну уведомлений
• Make It Count — руководство по измерению пользовательского опыта
• The Mind's Eye — Взгляд на психологию визуализации данных