Нижче наведено 40 user story, згрупованих за типом продукту: SaaS, e-commerce, мобільні додатки, маркетплейси, фінтех, охорона здоров'я, внутрішні інструменти та AI-функції. Кожен приклад містить критерії прийняття, оскільки історія без них є неповною. Після них: переписування від поганого до гарного, епік, розбитий на історії, та нефункціональні історії.
Оновлено жовтень 2026. Нові до user stories? Почніть з як писати user stories, а потім поверніться сюди за матеріалами для адаптації.
Формат, використаний тут
Кожна історія дотримується шаблону роль-функція-вигода:
Як [тип користувача], я хочу [мета або дія], щоб [вигода].
Критерії прийняття — це короткі нумеровані чек-листи, щоб вони вміщувалися в таблицю; шаблон історії користувача показує альтернативу Given/When/Then. Числа (обмеження часу, пороги) є заповнювачами для ваших власних бізнес-правил.
Приклади user story для SaaS та B2B
B2B-історії обертаються навколо акаунтів, ролей та биллінгу, і одночасно важливі двоє користувачів: той, хто виконує роботу, і адміністратор, який платить.
| User story | Критерії прийняття |
|---|---|
| 1. Як адміністратор робочого простору, я хочу запрошувати колег за електронною поштою, щоб вони могли працювати в нашому акаунті. | (1) Посилання-запрошення дійсне протягом 7 днів. (2) Я обираю роль (Адміністратор, Учасник або Переглядач) перед надсиланням. (3) Спроба запросити людину, яка вже є учасником, призводить до помилки замість надсилання дубля. |
| 2. Як власник акаунта, я хочу оновити доплатний тариф всередині додатку, щоб я міг додавати місця без зв’язку з відділом продажів. | (1) Я бачу ціну та зміни, що стануться, перед підтвердженням. (2) Нові ліміти застосовуються одразу після успішної оплати. (3) Якщо картку відхилено, я залишаюсь на поточному тарифі та бачу причину. |
| 3. Як учасник команди, я хочу вхід через корпоративний акаунт Google або Microsoft, щоб мені не потрібен був додатковий пароль. | (1) Вхід пропонує обидва варіанти. (2) Мій перший вхід з дозволеної корпоративної домену додає мене до цього робочого простору. (3) Акаунти з доменів, які адміністратор не дозволив, відхиляються з чітким повідомленням. |
| 4. Як менеджер, я хочу експортувати звіт про активність у форматі CSV, щоб я міг поділитися ним із фінансовим відділом. | (1) Експорт використовує поточні фільтри. (2) Файл містить рядок заголовків та дати у форматі ISO (YYYY-MM-DD). (3) Експорти понад 50 000 рядків надсилаються поштою як посилання для завантаження замість блокування сторінки. |
| 5. Як новий користувач, я хочу короткий чек-лист онбордингу, щоб отримати перший корисний результат без читання документації. | (1) 3–5 кроків, кожен з яких відмічається автоматично після виконання. (2) Я можу закрити його та відкрити знову з меню допомоги. (3) Прогрес синхронізується між пристроями. |
| 6. Як адміністратор робочого простору, я хочу журнал аудиту змін дозволів, щоб я міг відповідати на запитання щодо безпеки від наших клієнтів. | (1) Кожен запис фіксує, хто змінив що, коли та з якого IP-адреси. (2) Ніхто, включаючи адміністраторів, не може редагувати або видаляти записи. (3) Журнал можна фільтрувати за користувачем і датою та експортувати. |
Приклади історій користувачів для e-commerce
Історії магазинів живуть або гинуть через негативні сценарії: розпродані товари, відхилені картки, затримки доставки та повернення.
| User story | Критерії прийняття |
|---|---|
| 7. Як покупець, я хочу фільтрувати товари за розміром і кольором, щоб бачити лише те, що я можу купити. | (1) Фільтри пропонують лише наявні в наявності розміри та кольори. (2) Результати оновлюються без перезавантаження, а URL зберігає фільтри, щоб погляд можна було поділитися. (3) «Очистити все» скидає список. |
| 8. Як покупець без акаунта, я хочу оформити замовлення без створення акаунта, щоб я міг купити швидко. | (1) Потрібні лише електронна пошта, адреса та оплата. (2) Після оплати я можу створити акаунт одним кліком. (3) Підтвердження надходить на пошту протягом хвилини. |
| 9. Як покупець, я хочу бачити дату доставки перед оплатою, щоб знати, чи встигне замовлення вчасно. | (1) Кожен варіант доставки показує орієнтовний термін доставки. (2) Термін оновлюється, коли я змінюю адресу. (3) Товари, що відправляються окремо, мають власні дати доставки. |
| 10. Як покупець, я хочу отримувати сповіщення, коли розпроданий товар знову з’являється в наявності, щоб мені не доводилося постійно перевіряти. | (1) «Повідомити мене» замінює «Додати в кошик», коли запаси дорівнюють нулю. (2) Я отримую одне повідомлення, коли товар знову з’являється в наявності, після чого сповіщення припиняється. (3) Посилання у повідомленні відкриває товар із попередньо обраним розміром. |
| 11. Як клієнт, я хочу ініціювати повернення онлайн, щоб мені не доводилося писати на підтримку. | (1) Кнопка «Повернути» з’являється лише для замовлень у межах терміну повернення. (2) Я обираю товари та причину й отримую етикетку або QR-код. (3) Статус повернення коштів відображається в історії моїх замовлень. |
| 12. Як менеджер магазину, я хочу створити код знижки з датою закінчення, щоб я міг провести вихідну акцію. | (1) Я встановлюю відсоток або фіксовану суму, дати та ліміт використання. (2) При оформленні замовлення прострочений код показує «Цей код прострочено». (3) Коди не можна комбінувати, якщо я цього не дозволив. |
Щодо процесів оформлення замовлення та відстеження в додатках для доставки, див. обов’язкові елементи додатка на вимогу.
Приклади історій користувачів для мобільних додатків
Мобільні історії потребують критеріїв, які веб-історії часто можуть пропустити: відсутність сигналу, дозволи пристрою та біометрія.
| User story | Критерії прийняття |
|---|---|
| 13. Як пасажир, я хочу мати квитки доступними офлайн, щоб я міг показати їх у потязі без сигналу. | (1) Квитки та їхні QR-коди відкриваються без з’єднання. (2) Офлайн-банер показує, коли дані востаннє синхронізувалися. (3) Дії, що потребують з’єднання, вимикаються з поясненням. |
| 14. Як користувач, я хочу вхід через Face ID або відбиток пальця, щоб мені не доводилося вводити пароль щоразу. | (1) Це пропонується після першого входу за паролем і залишається вимкненим, доки я не підключу його. (2) Додаток вимагає пароль після 3 невдалих спроб або якщо біометрія пристрою змінилася. (3) Я можу вимкнути це в налаштуваннях. |
| 15. Як користувач, я хочу обирати, які push-сповіщення я отримую, щоб додаток не засмічував мене. | (1) У налаштуваннях кожна категорія сповіщень має власний перемикач. (2) Зміни застосовуються одразу. (3) Додаток запитує дозвіл на сповіщення, коли я вперше вмикаю категорію, а не при першому запуску. |
| 16. Як новий користувач, я хочу спробувати додаток перед реєстрацією, щоб я міг вирішити, чи варто це того. | (1) Основний контент можна переглядати без акаунта. (2) Реєстрація вимагається лише, коли я намагаюся зберегти або опублікувати. (3) Усе, що я зберіг як гість, переноситься в мій акаунт. |
| 17. Як користувач, я хочу поділитися елементом у WhatsApp або Messages, щоб я міг надіслати його другу. | (1) Спільне використання використовує вбудований у телефон діалог спільного використання. (2) Посилання відкриває елемент у застосунку, якщо він встановлений, інакше — на вебсайті. (3) Попередній перегляд посилання показує назву та зображення елемента. |
Приклади історій користувача для маркетплейсів та сервісів за запитом
Маркетплейси мають принаймні три ролі (покупець, постачальник, оператор), і функція рідко вважається завершеною, доки для кожної з них не створено історію користувача.
| User story | Критерії прийняття |
|---|---|
| 18. Як клієнт, я хочу відстежувати свого кур’єра на карті, щоб знати, коли бути біля дверей. | (1) Після забрання вантаю позиція кур’єра оновлюється щонайменше кожні 15 секунд. (2) Показується орієнтовний час прибуття, який постійно оновлюється. (3) Спільне використання геолокації припиняється після доставки. |
| 19. Як постачальник послуг, я хочу встановлювати свій щотижневий графік доступності, щоб отримувати лише ті запити, які можу виконати. | (1) Я можу встановлювати години роботи для кожного дня тижня та блокувати конкретні дати. (2) Клієнти не можуть бронювати слоти поза цими годинами. (3) Зміна графіка доступності не скасовує вже підтверджені бронювання. |
| 20. Як клієнт, я хочу оцінювати постачальника послуг після виконання замовлення, щоб інші клієнти могли робити обґрунтований вибір. | (1) Запит на оцінку з’являється, коли замовлення позначено як виконане, і залишається активним протягом 14 днів. (2) Я ставлю від 1 до 5 зірок та можу додати коментар. (3) Оцінити постачальника можуть лише клієнти, які завершили бронювання. |
| 21. Як продавець, я хочу бачити, коли кожна виплата буде отримана, щоб планувати свій грошовий потік. | (1) Для кожного виконаного замовлення показується сума виплати після вирахування комісій та очікувана дата. (2) Історія виплат містить дату, суму та пов’язані замовлення. (3) Якщо виплата не вдалася, мені повідомляють причину та способи вирішення. |
| 22. Як оператор маркетплейсу, я хочу перевіряти оголошення нових продавців перед їх публікацією, щоб заборонені товари не з’являлися на платформі. | (1) Перші оголошення нового продавця потрапляють у чергу на перевірку. (2) Перевірники схвалюють або відхиляють оголошення з зазначенням причини, яку бачить продавець. (3) Після схвалення наступні оголошення продавця публікуються одразу, якщо вони не позначені як підозрілі. |
Приклади історій користувача для фінтех-продуктів
У регульованих продуктах деякі критерії визначаються законодавством, наприклад, перевірка особи або сильна автентифікація клієнтів для платежів у ЄС та Великобританії. Вважайте ці вимоги початковою точкою та узгоджуйте правила зі своїм радником з питань відповідності вимогам.
| User story | Критерії прийняття |
|---|---|
| 23. Як новий клієнт, я хочу підтвердити свою особу в застосунку, щоб відкрити рахунок без візиту в відділення. | (1) Я фотографую документ, що посвідчує особу, та роблю селфі в застосунку. (2) Я бачу, чи успішно пройдено верифікацію, чи вона не вдалася, чи потребує перевірки, а також що робити далі. (3) Зображення зберігаються в зашифрованому вигляді, а кожен доступ персоналу фіксується в журналі. |
| 24. Як власник картки, я хочу миттєво заблокувати свою картку, щоб ніхто не міг її використати, якщо я її втратив. | (1) Блокування діє протягом кількох секунд, і нові платежі карткою відхиляються. (2) Розблокування відновлює ту саму картку. (3) На екрані пояснюється, що відбувається з регулярними платежами під час блокування. |
| 25. Як користувач, я хочу, щоб мої транзакції автоматично категоризувалися, щоб я міг бачити, куди йдуть мої кошти щомісяця. | (1) Нові транзакції отримують категорію протягом хвилини після появи. (2) Коли я змінюю категорію, майбутні транзакції від того самого мерчанта автоматично призначаються до обраної категорії. (3) Місячний перегляд показує загальну суму за кожною категорією. |
| 26. Як власник рахунку, я хочу, щоб великі перекази вимагали другого підтвердження, щоб мої кошти були в безпеці, якщо хтось дізнається мій пароль. | (1) Перекази понад встановлений мною ліміт вимагають підтвердження в застосунку або одноразового коду. (2) Перший платіж новому отримувачу вимагає того ж кроку. (3) Невдалі спроби підтвердження фіксуються в журналі, і мене про це повідомляють. |
| 27. Як власник малого бізнесу, я хочу надсилати рахунки з посиланням на миттєву оплату, щоб клієнти могли платити карткою. | (1) Електронний лист із рахунком містить безпечне посилання для оплати. (2) Рахунок автоматично позначається як оплачений, коли платіж успішно виконано. (3) Прострочені рахунки запускають нагадування у дні, які я обираю. |
Приклади історій користувача для медичних застосунків
Медичні дані підлягають правилам, таким як HIPAA у США та GDPR у ЄС, тому контроль доступу та журнали аудиту фігурують у більшості критеріїв. Узгоджуйте конкретні вимоги з фахівцем, який знає правила, що стосуються вашого випадку.
| User story | Критерії прийняття |
|---|---|
| 28. Як пацієнт, я хочу записатися на прийом онлайн, щоб не мати телефонувати в клініку. | (1) Показуються лише вільні слоти для обраного лікаря та типу візиту. (2) Підтвердження надходить електронною поштою або SMS із посиланням для додавання в календар. (3) Я можу скасувати або перенести візит до встановленого клінікою терміну; після цього показується номер телефону клініки. |
| 29. Як пацієнт, я хочу отримувати нагадування про прийом ліків, щоб не пропускати дози. | (1) Я встановлюю час нагадувань для кожного препарату. (2) Сповіщення на екрані блокування не показує назву препарату, якщо я не дозволив цього. (3) Я можу позначити кожну дозу як прийняту або пропущену та переглядати свою історію. |
| 30. Як лікар, я хочу бачити останні результати аналізів пацієнта на одному екрані, щоб швидко готуватися до візиту. | (1) Результати за останні 12 місяців, від найновіших до найстаріших, із виділенням значень поза межами норми. (2) Екран можуть відкривати лише члени медичної команди пацієнта. (3) Кожен перегляд фіксується в журналі доступу. |
| 31. Як пацієнт, я хочу приєднатися до відеоприйому через браузер, щоб не встановлювати жодних додатків. | (1) Посилання працює в актуальних версіях Chrome, Safari, Edge та Firefox на комп’ютерах та мобільних пристроях. (2) Я чекаю в віртуальній залі очікування, поки лікар не допустить мене. (3) Спочатку проводиться перевірка камери та мікрофона, з підказками, якщо доступ заблоковано. |
Приклади історій користувача для внутрішніх інструментів та адміністративних панелей
Внутрішні інструменти часто створюються без історій користувача, оскільки «це лише для нас», через що вони в кінцевому підсумку містять сотні полів і не мають чіткого призначення.
| User story | Критерії прийняття |
|---|---|
| 32. Як оператор служби підтримки, я хочу бачити останні замовлення та звернення клієнта на одному екрані, щоб відповідати без перемикання між інструментами. | (1) Я можу шукати за електронною поштою, номером телефону або номером замовлення. (2) На екрані відображаються останні 10 замовлень і всі відкриті звернення. (3) Оператори можуть переглядати, але не редагувати дані про оплату. |
| 33. Як менеджер операцій, я хочу оновлювати статуси замовлень пакетно з CSV-файлу, щоб не редагувати сотні записів вручну. | (1) Попередній перегляд показує, які рядки змінюватимуться, а які містять помилки, до застосування змін. (2) Рядки з помилками пропускаються та фіксуються у звіті. (3) Кожен пакетний оновлення логуються з вказівкою, хто його виконав. |
| 34. Як адміністратор IT, я хочу деактивувати акаунт звільненого працівника в одному місці, щоб він втратив доступ до всіх внутрішніх інструментів. | (1) Деактивація негайно завершує всі активні сесії. (2) Їхні відкриті завдання переназначаються їхньому менеджеру. (3) Їхні дані зберігаються відповідно до політики зберігання, а не видаляються. |
| 35. Як керівник фінансового відділу, я хочу, щоб витрати, що перевищують поріг, вимагали затвердження, щоб великі покупки перевірялися. | (1) Витрати, що перевищують поріг, надсилаються призначеному затверджувачу. (2) Затверджувач може схвалити або відхилити запит із коментарем, як з електронної пошти, так і з додатка. (3) Запити, які не оброблені протягом 3 робочих днів, ескалюються. |
Приклади історій користувача для функцій ШІ
Функції ШІ потребують додаткових критеріїв: що відбувається, коли модель не знає відповіді, куди надходять дані та як визначити, чи допомагає функція. Людина має залишатися в контролі щодо всього, що надсилається, публікується або оплачується.
| User story | Критерії прийняття |
|---|---|
| 36. Як оператор служби підтримки, я хочу, щоб для кожного звернення створювався чернетка відповіді за допомогою ШІ, щоб я міг швидше відповідати на типові запитання. | (1) Чернетка з’являється у полі відповіді, позначена як згенерована ШІ, і надсилається лише після натискання кнопки «Надіслати». (2) Вона містить посилання на статті центру допомоги, які були використані. (3) Якщо відповідної статті немає, система повідомляє про це замість того, щоб вгадувати. |
| 37. Як користувач, я хочу ставити запитання щодо своїх документів простою мовою, щоб знаходити відповіді без відкриття кожного файлу. | (1) Відповіді використовують лише ті документи, до яких у мене є доступ. (2) Кожна відповідь містить посилання на джерельні фрагменти. (3) Якщо документи не містять відповіді, система повідомляє, що не знає. |
| 38. Як член команди, я хочу отримувати коротке резюме довгих нотаток із зустрічей, щоб за хвилину дізнатися головне. | (1) Резюме містить список рішень та завдань із вказівкою відповідальних осіб. (2) Я можу перегенерувати або відредагувати його. (3) Нічого не резюмується автоматично: резюме створюється лише за запитом користувача. |
| 39. Як адміністратор робочого простору, я хочу вмикає або вимикати функції ШІ для своєї команди, щоб дотримуватися нашої політики щодо даних. | (1) Один параметр керує всіма функціями ШІ у робочому просторі. (2) На сторінці вказано, який провайдер обробляє дані та чи використовуються вони для навчання. (3) Зміни застосовуються до всіх користувачів протягом кількох хвилин і фіксуються в журналі. |
| 40. Як продуктовий менеджер, я хочу бачити, наскільки часто користувачі приймають, редагують або відхиляють пропозиції ШІ, щоб зрозуміти, чи допомагає ця функція. | (1) Кожна пропозиція фіксується як прийнята, відредагована або відхилена. (2) На панелі керування відображаються ці показники за тижнями. (3) Аналітика зберігає лише результат, ніколи не зберігаючи запит або вміст документа. |
Погано проти добре: 6 переписаних історій користувача
Кожен переписаний варіант називає конкретного користувача, не містить у меті проєктних рішень і надає реальну вигоду.
| Слабка історія | Чому вона не працює | Кращий варіант |
|---|---|---|
| Система має підтримувати експорт у PDF. | Мова вимог: немає користувача та немає причини. | Як бухгалтер, я хочу завантажувати звіт за кожен місяць у форматі PDF, щоб додавати його до наших записів. |
| Як користувач, я хочу, щоб додаток був зручним у використанні. | Неможливо перевірити, немає конкретної мети. | Як користувач, який вперше використовує додаток, я хочу почати свій перший проєкт із шаблону, щоб за кілька хвилин зрозуміти, як працює додаток. |
| Як розробник, я хочу мігрувати на PostgreSQL. | Технічне завдання; цінність для користувача прихована. | Як аналітик, я хочу, щоб місячні звіти завантажувалися менш ніж за 3 секунди, щоб я міг переглядати їх під час зустрічей. Міграція стає завданням у межах цієї історії. |
| Як клієнт, я хочу оплатити. | Набагато занадто велике: приховує способи оплати, помилки та повернення коштів. | Як клієнт, я хочу оплатити карткою на етапі оформлення замовлення, щоб завершити замовлення в один крок. Apple Pay, повернення коштів та невдалі платежі стають окремими історіями. |
| Як користувач, я хочу, щоб у правому верхньому куті був синя кнопка «Зберегти». | Диктує дизайн і не залишає нічого для обговорення. | Як редактор, я хочу, щоб мої зміни зберігалися автоматично, щоб я не втратив роботу, якщо мій браузер закриється. |
| Як менеджер, я хочу бачити звіти, щоб я міг бачити звіти. | Перевага просто повторює ціль. | Як менеджер з продажів, я хочу бачити воронку кожного представника за етапами, щоб я міг виявити застряглі угоди до кінця кварталу. |
Список посібник з історій користувача пояснює чек-лист INVEST, що стоїть за цими переписуваннями.
Від епіка до історій: приклад розбиття
Епік — це результат, який занадто великий для одного спринту. Ось «Клієнти можуть підписатися та оплатити» для B2B SaaS-продукту, розбитий на історії, кожна з яких може бути випущена окремо:
- Як новий клієнт, я хочу почати безкоштовний пробний період без картки, щоб я міг оцінити продукт без зобов’язань.
- Як користувач у пробному періоді, я хочу обрати тариф і додати свою картку до завершення пробного періоду, щоб зберегти свої дані та налаштування.
- Як власник акаунта, я хочу завантажити попередні рахунки, щоб я міг зберегти їх для податкових цілей.
- Як власник акаунта, я хочу отримати електронний лист за тиждень до щорічного поновлення, щоб оплата не стала для мене несподіванкою.
- Як власник акаунта, я хочу, щоб при невдалій оплаті був період логви, щоб моя команда не була заблокована через прострочену картку.
Для MVP історій 1–3 достатньо, щоб почати стягувати оплату; 4 і 5 важливі, коли клієнти поновлюють підписку. довідник зі створення мап користувальницьких історій показує, як провести цю межу.
Приклади технічних і нефункціональних історій користувача
Продуктивність, доступність та надійність також можуть бути історіями. Назвіть користувача, який відчуває проблему, і зробіть критерії вимірюваними:
- Як покупець на мобільному, я хочу, щоб сторінки товарів швидко завантажувалися на телефоні середнього класу, щоб я не здавався, поки сторінка не з’явиться. Критерії: основний вміст відображається протягом 2,5 секунди через 4G на вказаному тестовому пристрої; зображення нижче складки завантажуються ліниво.
- Як користувач екранного читача, я хочу, щоб кожен поле реєстрації мало мітку та оголошувалося, щоб я міг створити акаунт самостійно. Критерії: форма відповідає WCAG 2.2 рівень AA; її можна заповнити лише за допомогою клавіатури; помилки оголошуються.
Як адаптувати ці приклади для вашого MVP
- Замініть ролі на ваших реальних користувачів. «Як покупець» стає «Як батько, що купує шкільну форму», якщо це ваші клієнти.
- Замініть кожне число на власне правило. 7-денні запрошення, 24-годинні дедлайни та 3-секундні цілі, наведені вище, є заповнювачами.
- Залиште лише історії на вашому основному шляху для першого релізу.
- Додайте негативні сценарії, про які ваші клієнти та служба підтримки вже говорять.
- Уточніть кожну історію з людьми, які її реалізують. Скопійована історія все одно потребує обговорення.
Якщо ви вирішуєте, що входить до першої версії без технічного співзасновника, як створити MVP, якщо ви засновник без технічної освіти покриває варіанти. Для порожньої картки з усіма полями використовуйте шаблон історії користувача.
Маєте беклог історій, але ніхто не може їх реалізувати? Наша команда перетворює історії користувача на робоче програмне забезпечення спринт за спринтом. Дивіться наші щомісячні плани розробки.
Часті запитання
Який хороший приклад історії користувача?
«Як постійний клієнт, я хочу повторно замовити попередню покупку одним дотиком, щоб я міг поповнити запаси, не шукаючи знову». Вона називає конкретного користувача, ціль без дизайнерських рішень та реальну перевагу. Додайте критерії, такі як: товари, що більше не продаються, позначаються перед оформленням замовлення, і використовуються поточні ціни, а не початкові.
Який приклад епіка?
«Клієнти можуть підписатися та оплатити» — це епік: один результат, який занадто великий для спринту. Він розбивається на історії, такі як початок безкоштовного пробного періоду, додавання картки до завершення пробного періоду, завантаження рахунків та обробка невдалих платежів.
Як написати технічну історію користувача?
Назвіть людину, яка відчуває перевагу, навіть якщо це колега («Як інженер, що чергує...»), зазначте цінність у частині «щоб...» та надайте вимірювані критерії. Якщо немає жодної цінності, видимої для користувача, це, ймовірно, завдання в межах іншої історії, а не окрема історія.
Скільки критеріїв прийняття повинна мати історія користувача?
Зазвичай від трьох до шести. Менше часто означає, що пропущено неідеальні сценарії; значно більше зазвичай означає, що історія занадто велика і її слід розбити.