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

Question

Я работаю UX-дизайнер и иметь некоторый опыт работы с пользовательскими историями из гибких проектов в области развития, где они были использованы для документирования функциональных требований к форме:

В [типе пользователя] Я хочу, чтобы [цели ], так что [причина]

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

1. Для меня, как UX-дизайнер [тип пользователя] будет представлять собой персону, в архетипический конечного пользователя или клиента, построенный из исследований пользователей на реальных людей.
2. Один из разработчиков сказал, что [тип пользователя] был ролью в программном обеспечении, например медиком или снайпером в военной игре.
3. Руководитель проекта сказал, что [тип пользователя] представлен командные роли в проекте разработки, например, тестером или разработчиком.

Кто такой? Если все мы правы, разве это не будет общим источником путаницы?

Answer 1

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

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

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

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

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

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

Answer 2

Истории пользователей написаны на языке и с точки зрения конечных пользователей продукта.

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

Примеры включают в себя:

• Врач, используя некоторые медицинские программное обеспечение
• Мнимым с помощью интернет-магазина
• Менеджер по продукции, используя отчет о продукте

Answer 3

Первый и второй правы но они не разные, скорее дополняют друг друга.

Тип пользователя может быть:

• Джо человек.
• Банкир, некоторые rol.
• Joe the banker, a человек, у которых есть rol.

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

Надеюсь, что мой английский может быть установлен =).

Answer 4

Чтобы ответить как можно короче: человек является «держателем доли».

Теперь, что это за держатель? Это человек, имеющий (самую большую) выгоду от задач истории.

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

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

(примечание стороны:. Я никогда не любил этот способ рассказа письма слишком много шаблоннога, но и наш проворный тренер заставляет нас писать рассказы в этом формате)

Answer 5

TL; DR Все полезны , никто не ошибается, и никто не является единственным способом. Читайте больше на blog post Я написал для ответа на этот ответ.

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

Цель пользовательской истории (изначально Кент Бек хотел, чтобы они были просто называемые «истории») - не писать лучшие истории пользователей; он должен выйти за рамки требования и в истинное понимание. Для этого вам нужно, для кого предназначен программное обеспечение, какая проблема для них решается и почему эта проблема ценна для решения.

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

Answer 6

Истории пользователей, которые лучше всего используются для описания требований из отстающих продуктов, чтобы конечный пользователь или заинтересованная сторона увидели и использовали продукт с его точки зрения. И ПО должен быть лучшим человеком, который может прокомментировать правильность истории пользователя. Если ПО принимает участие от команды для разработки пользовательских историй, то нужно больше визуализировать использование продукта, а не , чем просто классифицировать тип пользователя. Хотя тип пользователя важен, но необходимо уделять особое внимание использованию, например, 1. врач, обращающийся к медицинскому веб-сайту, чтобы узнать содержание препарата и его производителя, чтобы какой вид доступа ему был предоставлен с другой стороны, 2. Если аптекарь ищет конкретное лекарство, доступное количество, время отгрузки, тогда необходимо предоставить доступ и рабочий процесс.

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