1) Problem statement (co musí obsahovat)

• Kdo (cílový uživatel / segment)
• Kdy a kde (situace, kontext použití)
• Jaká bariéra (mechanismus/pain point)
• Dopad (na uživatele i organizaci)

2) Převod insight → problem statement

• Insight typicky popisuje mechanismus (např. nejistota kvůli nejednoznačnému stavu).
• Problem statement ten mechanismus ukotví do konkrétní situace a aktéra.

3) HMW jako produktivní výzva

• HMW má být:
  • ukotvená v uživateli a situaci
  • otevřená pro více řešení
  • respektující omezení (regulace, bezpečnost, kapacity)
• Anti-příklad: „Jak bychom mohli přidat chatbot?“ (řešení uvnitř otázky).

4) Scope a hranice

• V Define je nutné vymezit:
  • co řešíme teď (MVP/iterace)
  • co odkládáme (backlog budoucích hypotéz)
• Bez scope hrozí „rozpliznutí“ a neuzavření první konvergence.

5) Kritéria úspěchu

• HMW/problém musí mít navázaná kritéria:
  • výstup (output): co dodáme
  • výsledek (outcome): změna chování / metrika
  • dopad (impact): dlouhodobější efekt
• Kritéria jsou klíčová pro pozdější testování a rozhodnutí v Deliver.

6) Kontrola kvality formulace

• Je otázka řešitelná designem? (ne čistě legislativou)
• Neobsahuje technologii jako „jedinou cestu“?
• Lze navrhnout alternativy a hypotézy?

Mini příklad struktury

• Insight: „Uživatelé nevěří, že žádost byla přijata → opakované kontroly.“
• Problem statement: „Noví žadatelé po odeslání… často… protože… což vede k…“
• HMW: „Jak bychom mohli zvýšit transparentnost stavu po odeslání… aby…?“