Вимоги до продукту й зрозуміла взаємодія

Замовник просить додати перенесення консультації. Інженер уже уявляє кнопку, дизайнер — календар, а адміністратор думає про дзвінки клієнтів. Це може бути одна проблема, а може — кілька різних припущень. Щоб не підмінити потребу готовим екраном, команда спершу фіксує спільне розуміння проблеми, потрібного результату й того, що ще невідомо.

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

Зв’язок із попередньою главою. У главі 7 ми визначили, що перевірити далі, і зберегли докази та невідоме. Тут оформимо ці висновки у вимоги й сценарії. Критерії приймання докладніше розглянемо в главі 10, а архітектуру — у главах 12–17.

Документ вимог — спільна пам’ять, а не повна специфікація майбутнього

PRD (Product Requirements Document — документ вимог до продукту) фіксує контекст, мету, потрібну поведінку, межі, докази й відкриті рішення. Його практична цінність — допомогти замовнику, користувачам, дизайну та розробці говорити про одну проблему. Назва й шаблон різняться між командами: PRD не є міжнародним форматом, який усі повинні заповнювати однаково.

У центрі документа — для кого ми працюємо, що вже знаємо, який результат шукаємо, як людина до нього дійде й що ще може змінити рішення. Таблиця нижче — практичний довідник, а не обов’язковий шаблон для кожного проєкту.

PRD не замінює розмови, контракту з клієнтом, плану реалізації або архітектурного рішення. Він не може наперед описати кожну деталь майбутнього продукту, а його наявність не доводить, що люди зрозуміють інтерфейс. Документ — робоча гіпотеза команди, яку потрібно уточнювати, коли з’являються нові свідчення.

Хороший документ вимог відповідає на сім запитань:

1. Яку ситуацію ми намагаємося поліпшити і для кого?
2. Що ми знаємо з дослідження, а що поки лише припускаємо?
3. Який результат свідчитиме, що зміна допомогла?
4. Які дії людина має виконати, включно з помилками та альтернативами?
5. Що входить до роботи, а що свідомо відкладено?
6. Які обмеження, дані, права, залежності й ризики впливають на рішення?
7. Хто має вирішити невідоме і як це рішення буде зафіксоване?

Не перетворюйте список цитат із зустрічей на вимоги без тлумачення. Якщо людина каже «потрібна кнопка експорту», це — побажання щодо розв’язання. Дослідницьке запитання звучить інакше: у якій роботі бракує інформації, що людина робить тепер і який наслідок має цей обхідний шлях? Кнопка може виявитися правильною відповіддю, але це треба з’ясувати.

У документі корисно позначати тип твердження:

Позначка	Що вона означає	Приклад
Спостереження	Те, що команда безпосередньо побачила або перевірила	У журналі звернень за місяць є запити про перенесення консультації
Свідчення	Те, що конкретна людина повідомила про власний досвід	Адміністраторка розповіла, як узгоджує новий час телефоном
Висновок	Пояснення команди, яке пов’язує свідчення з проблемою	Ручне узгодження займає час адміністратора й клієнта
Припущення	Твердження, яке ще потрібно перевірити	Клієнти хочуть самі вибирати інший вільний час
Рішення	Вибір відповідальної людини з його причиною	У першій версії дозволяємо переносити лише до початку консультації

Позначка сама не робить твердження істинним. Вона допомагає відрізнити слова учасника від виміряного факту, а припущення — від висновку команди. Для важливої вимоги вкажіть джерело, дату, відповідального за питання чи рішення та рівень невизначеності; методи оцінювання доказів розглянуто в главі 7.

Практична структура PRD

Невеликий проєкт може вмістити все на кількох сторінках; великий — посилатися на окремі документи. Потрібний обсяг визначається ризиком і числом людей, які мають координувати роботу, а не бажанням зробити файл довгим.

Розділ	Що записати	Якщо пропустити
Назва й стан	Версія, дата, автор-відповідальний, хто ухвалює рішення, статус чернетки чи погодженої цілі	Учасники можуть сперечатися про різні редакції
Контекст	Бізнесова ситуація, подія або потреба, яка привела до роботи	Команда починає будувати за формулюванням запиту, не розуміючи причини
Користувачі та ролі	Хто виконує роботу, хто платить, хто керує доступом і хто впливає на рішення	Інтерес покупця помилково приймають за потребу користувача
Проблема та наявний спосіб	Що відбувається тепер, де виникає тертя і які є альтернативи	Нова функція може дублювати вже наявний процес
Ціль і показники	Бажаний результат, спосіб спостереження, вихідний рівень або позначка «ще не виміряно»	Кількість готових екранів підміняє користь
Сценарії	Початкові умови, намір, основний шлях, інші шляхи, помилки й завершення	В описі лишається лише успішний випадок
Функціональні вимоги	Що система має дозволити, зберегти, показати або заборонити	Люди по-різному здогадуються про поведінку
Обмеження якості	Приватність, безпека, доступність, час відповіді, надійність, мова й часові зони	Зміна працює в демонстрації, але непридатна в реальному контексті
Дані та інтеграції	Які записи створюються, хто має до них доступ, які зовнішні системи потрібні та як діяти, якщо вони недоступні	Команда не помічає залежностей і правил доступу або не знає безпечної поведінки під час збою
Обсяг і межі	Що входить, що не входить, а що потребує окремого рішення	«Маленька зміна» непомітно обростає новими функціями
Ризики й відкриті питання	Найважливіші невідомі, можливий збиток, власник і наступний крок	Невизначеність маскується впевненим формулюванням
Історія рішень	Що змінилося, ким і чому	Стара домовленість сприймається як чинна вимога
Простежуваність	Ідентифікатори вимог, критеріїв приймання та задач реалізації	Неможливо зрозуміти, яку поведінку має підтвердити кожна робота
Журнал суперечностей	Конфліктні джерела, зачеплені вимоги, власник рішення, статус і наступний крок	Два взаємовиключні правила виглядають одночасно погодженими

Щоб не робити з PRD набір гасел, переформульовуйте побажання в поведінку, яку можна зрозуміти однаково. Наприклад:

Слабкий запис	Чіткіший запис
«Перенесення має бути зручним»	«Якщо до початку зустрічі ще є час і бронювання дозволяє зміни, клієнт може побачити вільні часові проміжки та вибрати один із них»
«Використати сучасний календар»	«Показати доступні дати й час так, щоб людина могла їх обрати за допомогою клавіатури; конкретний компонент інтерфейсу ще не обрано»
«Має працювати швидко»	«Для якого саме кроку, з яким обсягом даних і в якому середовищі важлива швидкість? Власник продукту погоджує ціль після вимірювання поточного досвіду»

Перше чітке речення описує обмежену поведінку, але ще залишає рішення щодо вигляду календаря. Друге не нав’язує компонент без причини. Третє перетворює нечітку прикметникову обіцянку на відкрите вимірюване питання.

Вимога й реалізація — різні рівні

Вимога формулює результат або обмеження з боку користувача чи бізнесу. Рішення реалізації описує конкретну технічну конструкцію. Деякі технічні обмеження справжні: продукт може бути зобов’язаний підтримати наявну систему клієнта, зберігати дані в певній країні або сумісно працювати зі старим пристроєм. Їх теж документують, але з джерелом і відповідальним.

Уявімо, що клієнт каже: «Сторінку бронювання треба зробити на React». Це може бути його вимога до постачання, але вона не пояснює, чого потребує людина, що бронює консультацію. Уточніть, чи є наявна платформа, компетенція команди, інтеграція або договірна умова, що обґрунтовує технологію. Якщо ні, зафіксуйте її як пропозицію, а вибір залиште на технічне опрацювання.

Питання для перевірки кожного рядка:

• Яку проблему або ризик підтримує це твердження?
• Хто просив про нього і чи говорить ця людина за користувача, покупця або власника системи?
• Це обов’язкова вимога, перевірюване припущення чи спосіб реалізації?
• Що відбувається, якщо цього немає?
• Хто може підтвердити або змінити домовленість?

Вимоги також мають джерела. Юридична умова, прохання клієнта, спостереження, системне обмеження й рішення команди — не взаємозамінні. Джерело допомагає знайти потрібну людину, коли вимога змінюється.

Кейс SEEK показує, як може змінюватися робочий процес discovery. Teresa Torres описує команду, яку консультувала: за її самозвітом, команда перейшла від нерегулярного discovery та приблизно п’яти-шести інтерв’ю на квартал до регулярних щотижневих інтерв’ю й явного переліку ризикованих припущень. Це обмежений опис зміни процесу, а не незалежне вимірювання ефективності чи доказ причинного бізнес-ефекту. Авторський висновок для роботи з вимогами: PRD корисно зберігати відомі факти, припущення й відкриті питання, щоб уточнювати їх у міру discovery; це застосування прикладу, а не твердження Torres про PRD. Torres, кейс SEEK.

Описуйте роботу людини, а не лише екран

Сценарій починається з умов, у яких людина опиняється, і завершується її результатом. Екран — лише один спосіб показати можливість продукту. Користувач може мати повільне з’єднання, втратити доступ, помилитися в даті або побачити, що час уже забронювала інша людина.

Коротка форма сценарію:

1. Хто і за яких умов: роль, поточний стан, права.
2. Намір: яку роботу людина намагається виконати.
3. Основний шлях: що вона робить і які зміни має побачити.
4. Альтернативи: що робити, якщо потрібного варіанта немає або вибір недоступний.
5. Завершення: яке свідчення показує, що потрібна робота справді відбулася.

«Сторінка завантажилась» не означає «бронювання перенесено». Для перенесення завершенням може бути збережена нова дата, незмінений старий час у разі невдачі та зрозуміле підтвердження клієнту. Якщо відправлення листа підтвердження тимчасово не спрацювало, документ має пояснити, чи збереглося бронювання та як людина перевірить його стан. Інакше повідомлення може підштовхнути клієнта створити дубль.

Krug: менше невизначеності під час кожного вибору

UX (User Experience — користувацький досвід) — це ширше враження від виконання роботи: від першого пояснення до результату та реакції системи. UI (User Interface — користувацький інтерфейс) — видимі й керовані частини, через які людина взаємодіє з продуктом. Гарно оформлена форма може бути поганим досвідом, якщо її помилки незрозумілі, а після виправлення людина втрачає введені дані.

Стів Круг у прикладі з навігацією звертає увагу не на магічну кількість клацань, а на невизначеність кожного вибору: чітка назва посилання дає впевненість, куди воно приведе. У його поясненні складний вибір іноді потребує короткої, своєчасної й помітної підказки. Це не означає, що кожну професійну задачу треба зробити примітивною або сховати всі варіанти. Це означає допомагати людині прийняти рішення, не змушуючи її здогадуватися про значення назв (Steve Krug, офіційний уривок про ясність вибору).

У вимогах перевірте, чи можна:

• швидко просканувати заголовок, дію і важливе застереження;
• зрозуміти назви розділів без внутрішнього жаргону команди;
• передбачити наслідок дії до натискання;
• повернутися, виправити дані або скасувати дію, коли це можливо;
• виконати основний сценарій клавіатурою та зі збільшенням тексту;
• відрізнити обов’язкові поля від необов’язкових і зрозуміти формат значення.

Реальні інтерфейси треба спостерігати з людьми відповідного контексту. Інтуїція дизайнера, внутрішня згода команди, інтерв’ю про минулу поведінку та перевірка прототипу відповідають на різні питання. Усне «я б це купив» не дорівнює оплаті, а успіх на тестовому завданні з вигаданими даними не доводить, що весь продукт розв’язує бізнес-проблему. Тест прототипу показує, чи зрозумілий конкретний шлях, але не доводить ринкової цінності або готовності платити; межі таких висновків розглянуто в главі 7.

Інформаційна архітектура та переходи

Інформаційна архітектура — спосіб групувати й називати вміст, щоб люди могли знайти потрібну частину продукту. Вимога до навігації має відповідати на три питання: де починає людина, куди переходить і як розуміє, де опинилася. На текстовому рівні це можна записати як ієрархію й маршрут, не нав’язуючи конкретну вебадресу:

Кабінет клієнта
└── Мої записи
    └── Деталі запису
        └── Змінити час

Для сценарію перенесення вимога може сказати: «З розділу “Мої записи” клієнт відкриває майбутній запис, бачить поточний час і стан, а з деталей переходить до доступних варіантів. Після збереження система повертає його до деталей оновленого запису та показує підтвердження». Шлях на кшталт /appointments/:id/reschedule — рішення реалізації; його можна зафіксувати окремо, якщо цю адресу важливо зафіксувати для інтеграції чи навігації.

Перевірте назви, шлях назад і те, чи зберігається контекст після помилки. Текстовий маршрут — гіпотеза для тесту на прототипі, а не доказ зручності (Steve Krug, офіційний уривок про навігацію).

У двох публічних задачах Simpler Grants.gov при Міністерстві охорони здоров’я та соціальних служб США (HHS) описано різні розбіжності між очікуванням і поведінкою форми. В одній інструкція до поля Applicant Type («тип заявника») обіцяла додати результат пошуку клавішею Enter, але перед цим опцію потрібно було окремо вибрати. В іншій помилка в полі дати додатково підсвічувала заповнене Applicant District («округ заявника»), через що людина не розуміла, що саме треба виправити. Ці приклади показують, чому вимога має описувати реальний крок і наслідок; вони не свідчать про поширеність проблеми в усіх формах (Applicant Type, помилкове повідомлення).

Стани, доступність і відновлення після невдачі

Описуйте не тільки готовий екран, а й те, що відбувається під час переходів. Для зміни бронювання можуть бути потрібні такі стани:

Стан	Що має знати людина	Можлива наступна дія
Ще немає бронювань	Чому список порожній і що тут з’явиться	Створити перше бронювання або повернутися до каталогу послуг
Завантаження	Що система ще шукає доступний час	Почекати або скасувати пошук, якщо це безпечно
Успіх	Які саме день і час тепер збережені	Повернутися до деталей або переглянути новий запис
Помилка введення	Яке поле має проблему і як її виправити	Перейти до поля, виправити його; зберегти решту даних
Вибір щойно зайняли	Що обраний час більше не доступний і чи лишився старий запис чинним	Побачити оновлені варіанти або лишити все як було
Немає прав	Чому дія недоступна в цьому обліковому записі	Увійти до належного профілю або звернутися до адміністратора
Немає відповіді від сервісу	Чи могло зберегтися перенесення	Перевірити стан перед повторною відправкою

Запит міг дійти до сервера, навіть якщо браузер не отримав підтвердження; повторна відправка може створити дубль. Вимога має передбачити перевірку стану, а технічний захист від повтору команда обере окремо.

Консорціум Всесвітньої павутини (W3C) та його Ініціатива з доступності вебу (WAI) радять програмно пов’язувати поля з підписами, називати помилку текстом і пояснювати, як її виправити (WAI Forms Tutorial). Наприклад: «Дата консультації вже зайнята; виберіть інший час. Поточне бронювання не змінено» повідомляє більше, ніж «Error 42».

WCAG (Web Content Accessibility Guidelines — настанови з доступності вебвмісту) допомагають перетворити доступність на конкретні сценарії: керування клавіатурою, видимий фокус, озвучування статусів і текстове повідомлення про помилку (Keyboard, Focus Visible, Status Messages, Error Identification). Один приклад або перевірка не доводить повної відповідності WCAG. Окремо вкажіть, що має відбуватися з безпечними введеними даними після помилки.

Не забувайте про дані, права й зовнішні обмеження

Для кожного важливого об’єкта, наприклад запису, платежу чи профілю, опишіть:

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

Для перенесення зустрічі це означає зафіксувати власника запису, історію перенесень, правило скасування та спосіб повідомити клієнта й адміністратора. PRD має виявити, яке продуктове рішення потрібне і хто має побачити результат, але не задає наперед структуру бази даних; інженерна команда окремо обирає спосіб надійної реалізації.

Вимоги до якості прив’язуйте до контексту. «Завжди доступно», «максимально безпечно» чи «відповідає миттєво» майже не допомагають ухвалити рішення. Назвіть важливий сценарій, наслідок збою, цільове середовище й спосіб перевірки. Якщо ціль ще не визначена, зафіксуйте відкрите питання, його власника й наступний крок замість вигадувати число.

PRD поруч із підходом Shape Up

У Shape Up Райан Сінґер описує короткий pitch — пропозицію роботи для рішення про те, чи робити ставку на неї. Такий опис пов’язує проблему, виділений на роботу час (appetite, бажане обмеження часу), основну ідею, ризикові деталі та no-gos — свідомо виключені сценарії (Shape Up: Write the Pitch). PRD часто докладніше фіксує користувачів, стани, дані, вимоги, показники, залежності та невідоме. Це різні документи для різних рішень; команда може використати обидва або поєднати частини, але не повинна вважати їх однаковими.

Наприклад, pitch може сказати: «Виділяємо до двох тижнів на самостійне перенесення ще не розпочатих консультацій. У першій версії немає групових бронювань чи повернення оплати». PRD уточнить, хто має право на дію, що відбувається, якщо час уже зайняли, як зберігається підтвердження і які дані потрібні. Обмеження часу звужує вибір, але не визначає повну архітектуру — воно спонукає розглянути менше рішень.

Це приклад конкретного виробничого підходу, а не універсальна норма. Невелика студія з фіксованим контрактом, регульований продукт і команда зі змінними вимогами можуть документувати роботу по-різному. Незмінним лишається обов’язок не приховувати припущення й межі.

Погодьте проблему та межі до детального дизайну

У главі 7 вже йшлося про діагностику до рекомендації та її межі. Тут перевірте, чи змінює нове побажання проблему, обсяг, ціну, строк або ризики контракту; зафіксуйте нове рішення й того, хто його погодив. Діагностика не мусить бути окремою оплачуваною стадією в кожному проєкті. PRD також не замінює юридичної перевірки договору: за потреби залучіть фахівця з оплати, персональних даних чи прав користувачів.

Блер Еннс у The Win Without Pitching Manifesto підкреслює діагностику до рецепта, спеціалізацію, розмову замість безкоштовного повного проєктування й раннє обговорення грошей та відповідності замовлення (перелік 12 проголошень автора). Для продуктової команди це корисне нагадування: не обіцяти рішення раніше, ніж зрозуміла проблема й умови. Це авторська позиція про продаж професійних послуг, а не правило, що кожне попереднє обговорення обов’язково має бути платним або що клієнтові не можна допомогти до контракту.

Практично це означає окремо погодити:

• проблему, користувачів і бажаний результат;
• обсяг оплачуваної діагностики та які висновки вона має дати;
• що команда вже знає, а які рішення залишаються за клієнтом;
• які межі й припущення внесено до оцінки;
• чи змінює нове побажання ціну, строк або ризики контракту.

Що робити з чернеткою, яку підготував ШІ

ШІ (штучний інтелект; artificial intelligence, AI) може згрупувати нотатки, запропонувати запитання до неоднозначного твердження, зіставити суперечності й підготувати чернетку таблиці вимог. Він не спостерігав за клієнтом і не стає джерелом правди про його поведінку; факти звіряйте з джерелами, а рішення залишайте відповідальним людям.

Безпечний порядок такий:

1. Передати лише ті записи, якими дозволено користуватися; прибрати персональні дані, якщо вони не потрібні.
2. Попросити розділити дослівне свідчення, спостереження, висновок і припущення та зберегти посилання на джерело.
3. Позначити суперечності й пропуски запитаннями, а не заповнювати їх вигаданими відповідями.
4. Перевірити кожен сформульований факт за вихідними нотатками, системними даними або відповідальною людиною.
5. Залишити ухвалення рішення продуктовому власнику та відповідним фахівцям.

Приклад запиту: «Згрупуй надані нотатки про перенесення консультацій. Для кожного твердження покажи фрагмент джерела, тип свідчення, альтернативне пояснення та невідоме. Не додавай вигаданих цитат, частот або ринкових висновків». Якщо з відповіді виходить «дев’ять із десяти клієнтів хочуть мобільний застосунок», але в матеріалах немає такого підрахунку, ця цифра не має потрапити до PRD.

OpenAI у довідці про аналіз даних у ChatGPT описує роботу із завантаженими файлами та радить перевіряти код, результат і припущення, коли аналіз виконується кодом (Data analysis with ChatGPT). Підтримувані типи файлів можуть залежати від моделі, плану, налаштувань робочого простору й можливостей облікового запису; це уточнення стосується саме підтримки файлів. Це конкретна функція ChatGPT, а не гарантія доступу в кожному інтерфейсі й не підстава приймати висновок без перевірки.

Як контекстний досвід, у вкладеній відповіді до обговорення r/ProductManagement один учасник розповідає, що використав модель для першої чернетки карти Jobs To Be Done, яку ще потрібно перевірити розмовами з користувачами. Це самоопис одного коментатора, не дослідження якості методу й не доказ, що згенерована карта точно відображає потреби людей. Він лише ілюструє різницю між чернеткою для перевірки та підтвердженою вимогою. Відповідь від 15 березня 2026 року.

Повністю розібраний приклад 1. Перенесення бронювання

Ситуація. Власник навчальної студії просить «додати кнопку перенести консультацію». Це вигаданий приклад; він не описує фактичну компанію чи дослідження.

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

Проблема для перевірки. «Клієнт, який не може прийти у початковий час, не має простого способу знайти й підтвердити інший доступний час без повторної ручної координації».

Ролі. Клієнт просить про зміну; адміністратор веде розклад; власник студії відповідає за правила й результат; система бронювання визначає доступні проміжки. Людина, яка платить за розробку, може не бути тим, хто переносить зустріч.

Ціль. Дати клієнтові змогу знайти допустиму альтернативу й залишити один чинний запис. Вихідного виміру ручних звернень і цільового показника поки немає. Власник має погодити, як збирати базове значення і як зрозуміти, що новий процес справді допомагає.

Результат проти випущеної функції. Наявність сторінки перенесення — це вихід команди, а не доказ цінності. Результатом для клієнта може бути завершене перенесення без повторного дзвінка адміністратору. Щоб перевірити цю гіпотезу, команда спершу визначає базове значення, а після запуску рахує частку запитів на зміну часу, які клієнти завершили самостійно, і окремо стежить за невдалими спробами та помилковими змінами. Період, джерело даних і прийнятна ціль лишаються відкритими, доки їх не погодить власник; не можна вигадувати успіх за кількістю випущених екранів. Це застосування рамки Marty Cagan: поряд із технічною здійсненністю й зручністю перевіряють цінність для клієнта та життєздатність для бізнесу Cagan, «The Four Big Risks».

Сценарій.

1. Клієнт відкриває вже підтверджене особисте бронювання.
2. Система показує, чи дозволяють правила перенесення змінювати цей запис.
3. Клієнт переглядає вільні часи й обирає один.
4. Система ще раз перевіряє, чи час доступний, перш ніж змінити запис.
5. Якщо час лишився вільним, система зберігає новий час і показує його разом із наступними кроками.
6. Якщо час щойно зайняли, старе бронювання лишається чинним, а клієнт бачить оновлені варіанти.
7. Якщо запис не можна змінити, система пояснює причину й спосіб звернутися до студії.

Вимоги й простежуваність. Таблиця поєднує правило, спосіб перевірити його та приклад наступної задачі. Це навчальні ідентифікатори: коли критерій змінюється, оновіть посилання в обох напрямках, щоб від задачі можна було повернутися до вимоги та її джерела. Детальніше про критерії приймання — у главі 10.

Код	Вимога й підстава	Перевірка та наступна задача
R1	Клієнт бачить лише власний запис, який дозволено змінити; правило підтверджує власник продукту	КП-01: перевірити належність і право на зміну; З-01: перевірка власника та доступу
R2	Перед збереженням система знову перевіряє вільний час, щоб не створити подвійне бронювання	КП-02: час вільний на момент збереження; З-02: повторна перевірка в сервісі бронювання
R3	Якщо час уже зайняли, старий запис лишається чинним, а клієнт бачить інші варіанти	КП-03: підтвердити збереження старого запису й показ альтернатив; З-03: обробка конфлікту
R4	Після успіху клієнт і адміністратор бачать той самий новий час; канали сповіщень ще треба перевірити	КП-04: обидва бачать узгоджений час; З-04: визначити джерело стану та сповіщення
R5	Час показано у визначеній для клієнта часовій зоні; правило має погодити власник	КП-05: звірити підтверджений час; З-05: перевірити відображення в потрібній зоні

Якщо одну вимогу розбито на кілька підзадач, кожна має посилатися на відповідний критерій. Коли критерій змінюється, оновіть обидва боки посилання; з задачі також має бути можливо повернутися до вимоги та її джерела.

Журнал невирішених суперечностей тримайте окремо від погоджених вимог. Наприклад: C-01 — статус: відкрита; джерела: специфікація філії каже «лише призначений фахівець», документ експорту каже «усі співробітники»; зачеплена вимога: R1; власник: власниця даних; наступний крок: підтвердити чинну політику до оцінювання задачі. До відповіді не записуйте обидва варіанти в R1 як прийняті й не вважайте критерій доступу готовим.

Межі. Поки не входять групові зустрічі, зміна спеціаліста, перенесення після початку консультації та повернення коштів. Ці винятки потрібно уточнити, якщо discovery підтвердить, що вони важливі.

Ризики та відкриті питання. Ще треба погодити граничний час перенесення, доступні канали підтвердження й політику скасування. Якщо лист не надійде, клієнту потрібен інший спосіб перевірити, чи збережена зміна.

Рішення. Після підтвердження правил і спостереження за клієнтами та адміністратором команда може оформити самостійне перенесення, спростити запит адміністратору або відмовитися від автоматизації, якщо проблема рідкісна.

Повністю розібраний приклад 2. Повідомлення у формі реєстрації

Ситуація. Людина реєструється на онлайн-семінар і не вказала адресу електронної пошти. Це вигаданий приклад; він показує, як вимога до форми описує не лише текст, а й відновлення.

Варіант	Текст і поведінка	Що лишається незрозумілим
A	Кнопка «Submit»; після відправлення — «Error 42»	Чи завершилася реєстрація, яке поле виправити й що робити далі
B	Після спроби без адреси біля поля «Електронна пошта» з’являється пов’язане повідомлення: «Вкажіть адресу, щоб отримати посилання на семінар»; інші безпечні дані зберігаються, форму не надсилають	Причина й наступна дія зрозумілі до повторної спроби

Зафіксуйте, що помилка пов’язана з полем і пояснена текстом, безпечні введені дані зберігаються, а клавіатурний фокус переходить до проблеми. Під час надсилання покажіть очікування й не допускайте випадкової повторної відправки.

Додайте явні вимоги: кожне поле має видиму зрозумілу назву, а підказка пояснює неочевидний формат; помилка називає поле й причину та підказує наступний крок, якщо він відомий; її передають текстом, а не лише червоним кольором; після невдалої відправки безпечні введені дані зберігаються; клавіатурний фокус переходить до проблеми або підсумку помилок. W3C WAI описує пов’язані підписи, текстову ідентифікацію помилки та повідомлення про результат надсилання. Ці властивості можна перевірити вручну й за допомогою допоміжних технологій, але такий список не є повним аудитом доступності.

Якщо після надсилання зв’язок зник, система могла вже створити реєстрацію. Не стверджуйте, що її не збережено: дайте людині спосіб перевірити стан перед повтором, щоб не створювати дубль.

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

Повністю розібраний приклад 3. До каталогу курсів просять додати оплату

Ситуація. У вигаданому сервісі онлайн-навчання клієнт просить додати оплату перед доступом до матеріалів. Початковий обсяг охоплював каталог курсів і реєстрацію; тепер треба з’ясувати, чи це нова потреба, нова бізнесова модель або побажання поза межами першого запуску.

Діагностика. Команда уточнює: які матеріали платні й коли відкривається доступ? Оплата одноразова чи повторювана? Хто отримує кошти, обробляє повернення й звіряє облік? Чи вибрано платіжного постачальника та узгоджено спосіб інтеграції?

Запитання залежать від початкової проблеми. Якщо оплата стосується вже заброньованої консультації, з’ясуйте, чи можна бронювати без передоплати, чи має передоплата зменшити неявки або спростити касовий процес і як працюють скасування та повернення. Якщо йдеться про курс, уточніть момент відкриття матеріалів, тривалість доступу й реакцію на невдалий або повторний платіж. В обох випадках потрібні бізнесове рішення, правила відповідальності та окремі критерії, а не лише платіжна кнопка.

Оновлений документ.

Частина	Стан до нового запиту	Що змінюється
Проблема	Допомогти людині знайти й переглянути потрібний курс	Треба вирішити, які матеріали платні та коли відкривається доступ
Ролі	Учень і власник каталогу	Додаються працівник, що звіряє оплату, і платіжний постачальник
Дані	Курс, опис, реєстрація	Додаються сума, валюта, стан транзакції й потреба в поверненні
Ризики	Людина не знаходить або не розуміє курс	Додаються подвійне списання, невдала оплата, повернення, приватність та облік
Обсяг	Каталог і реєстрація	Треба окремо погодити оплату, інтеграцію, правила доступу й строки

Рішення. Не додавайте оплату мовчки. Власник може відкласти її за межі першої версії або переглянути обсяг і строк, якщо обидві потреби важливі. Прототип допоможе порівняти правила, але не замінить юридичної, бухгалтерської та технічної перевірки. Навіть якщо ШІ здешевлює написання коду, рішення про гроші, повернення, відповідальність і ризики лишаються за людьми.

Обсяг впливає не лише на список функцій, а й на ролі, дані, інтеграції, відповідальність і критерії успіху. Якщо мета першого етапу — перевірити каталог і реєстрацію, оплату можна явно винести за межі першої версії. Якщо обидві проблеми критичні, команда переглядає домовленість, ризик і строк разом, а не додає платіжну інтеграцію як непомітний пункт.

Підсумок

PRD допомагає команді зрозуміти проблему, результат, ролі, сценарії, обмеження, межі та невідоме. Він не повинен видавати технологічний вибір за потребу користувача чи перетворювати гіпотезу на факт. Описуйте і помилки, і відновлення після помилки; не вважайте завантаження екрана доказом успішного сценарію. Інтегруйте UX, доступність і бізнесові межі у вимоги з самого початку. Коли змінюється запит, оновіть причину, ризики й обсяг до того, як дати нову обіцянку.

Джерела та подальше читання

• Steve Krug, Don’t Make Me Think, Revisited: A Common Sense Approach to Web (and Mobile) Usability, New Riders, 2014, 3-тє видання. Сторінка автора про книгу і офіційний уривок “Animal, Vegetable, or Mineral?”, прочитано 23 вересня 2026 року. Використано конкретний принцип ясності кожного вибору, а не магічної кількості кліків; повну книгу тут не заявляємо як прочитану. Сторінка автора описує третє видання як поточне.
• Marty Cagan, “The Four Big Risks”, Silicon Valley Product Group, 4 грудня 2017 року; прочитано 23 вересня 2026 року. Використано рамку цінності, зручності, технічної здійсненності й життєздатності для бізнесу; це стаття автора, не заміна повного читання Inspired.
• Blair Enns, The Win Without Pitching Manifesto, сторінка автора з переліком 12 проголошень; прочитано 23 вересня 2026 року. Використано теми спеціалізації, діагностики до рецепта, меж безоплатного розв’язання та ранньої розмови про гроші; це позиція автора для експертних послуг, а не універсальна вимога для кожного контракту.
• Ryan Singer, Shape Up: Stop Running in Circles and Ship Work that Matters, онлайн-книга Basecamp, дата доступу 23 вересня 2026 року; зокрема “Write the Pitch”. Використано розрізнення між проблемою, appetite, рішенням, ризиковими деталями та no-gos у pitch; описано як конкретний метод Basecamp, а не єдиний стандарт PRD.
• World Wide Web Consortium, Web Accessibility Initiative (W3C WAI — ініціатива W3C з доступності вебу), Forms Tutorial (оновлено 27 березня 2026 року), User Notification, а також WCAG 2.2 щодо Keyboard, Focus Visible, Status Messages та Error Identification; прочитано 23 вересня 2026 року. Використано для вимог до підписів, клавіатури, видимого фокусу, текстових помилок і повідомлення про успіх; одна перевірка не засвідчує повної відповідності WCAG.
• GitHub, HHS, Issue #6197: “SF-424: Fix usability issue from Applicant Type box”, 2 вересня 2025 року, та Issue #6194: “[BUG] False error message in form UI”, 29 серпня 2025 року; прочитано 23 вересня 2026 року. Використано як конкретні записи про невідповідність інструкції взаємодії та помилкове поле; це контекст одного продукту, не вимірювання поширеності.
• Teresa Torres, “Taking Continuous Discovery to the Next Level at SEEK”, Product Talk, 10 квітня 2019 року; прочитано 23 вересня 2026 року. Авторка описує інтерв’ю команди, яку вона консультувала; це приклад її самозвіту про зміну процесу, не контрольоване дослідження ефективності.
• Reddit, r/ProductManagement, вкладена відповідь про чернетку карти Jobs To Be Done у дискусії про продуктове дослідження, 15 березня 2026 року; прочитано 23 вересня 2026 року. Один коментатор описує модельно згенеровану першу версію карти, яку ще треба перевірити розмовами. Це самоопис, не доказ результативності методу чи узагальнення спільноти.
• OpenAI, “Data analysis with ChatGPT”, довідка Help Center; прочитано 23 вересня 2026 року. Використано для опису аналізу файлів і рекомендації перевіряти код, результати й припущення; підтримка форматів може залежати від моделі, плану, налаштувань робочого простору й облікового запису.