Not sure if this is what you are after, but we run the following process for user facing features & apps: 1. Product Owner creates mockups of desired flow/func

Not sure if this is what you are after, but we run the following process for user facing features & apps: 1. Product Owner creates mockups of desired flow/functionality in Balsamiq. Including acceptance criteria for QA. 2. Architect questions, reviews mockups, annotates with API calls (existing or new) 3. Mockups passed to UI designer who provides design and resources for developers 4. Development 5. Release, QA & UAT once passed Key to this approach is (a) a product owner who is has a technical background so you start from something sensible, (b) not letting the product owner build UIs but rather flow & functionality (so the designer has free reign), (c) not taking on too much within a single project (eg a fully fledged app from scratch would be multiple iterations of this). If it is an incremental change or a change related to a growth experiment, during step (1) we set the hypothesis (Eg increase conversion rate through funnel X) and on deployment is evaluated. If the change has significant architecture / backend implications the architect specs these out separately using either a checklist or a functional spec which is then broken down into JIRA tickets. We are a small team, but I have found this approach works in larger orgs too. Any time we have started with BRD/PRD etc I find they get outdated fast. Documentation heavy methods have been helpful work for architecture backend changes though.