From brief to behaviour.A UX process built for developers.
When UX artifacts become the spec, developers stop guessing what the design meant. They build against a contract everyone has already agreed on.
The app that ships isn't the app that was designed
The PO briefs, UX designs, and developers (or an AI on their behalf) interpret. Each handoff loses something. It's worst on greenfield products, where no codebase carries the context.
Personas
Say who the product is for.
Jobs to be done
Say why they need it.
Mockups
Say what it looks like.
Missing: the rules
Nothing writes down how the app must behave, like "Confirm stays locked until the disclaimer is ticked." So developers guess, and AI just guesses faster.
As PO-UX, I write the behaviour, not just the screens
Each step produces an artifact that feeds the next. Nothing moves forward until the PO confirms it.
-
01
Research
Start from real users: interviews and surveys at live events, plus session recordings of how people actually use the product.
InterviewsSurveysSession recordings -
02
PRD
One source of truth: epics and numbered user stories with acceptance criteria, kept in sync with the team's wiki and backlog so every story maps to a ticket.
EpicsUser stories US-01…Changelog -
03
Mockup
Not a picture of the app: a coded, working mockup of every flow. It runs on desktop and mobile, pulls live ETF prices through a small server, remembers the user's session, and includes the first-run guided tour and cookie consent. The PO, real users and developers all react to the same thing. Every change to it, even a colour, is logged back to the PRD.
ReactResponsiveLive dataSession persistenceReference implementation -
04
Personas
Archetypes grounded in research, PRD and mockup, including anti-personas: who the product is not for.
P-01…Anti-personasAI-assisted -
05
Jobs to be done
For each persona, the job they hire the product for, mapped step by step into job stories, ranked unmet needs and scenario seeds. Jobs stay solution-agnostic; the UI is only how they're carried out.
Jobs J-01…Needs N-01…Seeds SS-01…AI-assisted -
06
BDD scenarios
Plain-language Given / When / Then scenarios grouped into features, each tagged back through the whole chain. Every behaviour has a reason, and every reason has a test.
.feature filesFully traceableAI-assisted -
07
Handoff
The scenarios are the contract. Developers, or a coding agent, build until every scenario passes. If a scenario is ambiguous, they don't weaken it. They raise it, and the spec gets fixed upstream.
Behavioural contractNo silent rewrites
How AI fits in: it drafts, I decide
For personas, jobs and scenarios (steps 4–6) I use three AI agents I set up myself, one per step.
Every line of behaviour can be followed back to a reason
Each scenario carries tags that link it to the need, job, persona and user story it comes from. Click each link to see the real ETF artifact behind it.
A behaviour written in plain language that anyone can read and a machine can test. It started as scenario seed SS-02 in the JTBD file:
"The user hasn't accepted the disclaimer yet: the button to continue stays locked until they tick the consent box. Once they accept, they continue without losing the profile values already entered."
@boundary @seed-ss02 @need-n03 Scenario: Block confirmation until the disclaimer is accepted Given the user has filled in their profile And has not ticked the educational disclaimer When they try to confirm Then confirmation stays blocked And they can still open the Terms without unlocking it
Translated from Italian. The tags link it to the seed and the need it proves.
A need is an outcome the user wants to improve, written so it can be measured. This one is a compliance need stated by the PO.
- Type
- Compliance
- Importance
- 4
- Satisfaction today
- 4
- Opportunity
- 4 · status unmet
Ranked against the other needs of the same job, so the team knows what to build first.
The job the user "hires" the app for, with no mention of screens or features.
Job map: the steps of the job
- Define the profileage, target year, risk, contribution type
- Accept the educational disclaimerthis is where our scenario lives
- Get a "Recommended ★" portfolio and an alternativewith the reason why
- Explore its compositionallocation, funds, ISIN, TER
- Decide whether to continuesavings plan, tracking, or stop here
Job story JS-02, for the highlighted step
Understands the theory from the ETF course but gets stuck turning it into practice, because the Excel file used today is an obstacle. Opens the wizard to get a first concrete portfolio without building it alone.
Frustrations
- The Excel file stands between theory and practice
- Financial jargon with no explanation in context
Constraints
- No previous experience with ETFs or brokers
- Must accept the educational disclaimer before continuing
Success looks like
Reaching the recommended portfolio's detail page with advice they understand, or starting to track it.
Open question kept visible: digital skill is inferred from the PRD, not from user tests yet, so it still needs validating.
Acceptance criteria
- The button to continue stays locked until the consent box is ticked
- The terms can be opened from a dedicated link
- Every screen shows the "For educational purposes" label
Each acceptance criterion becomes one or more scenarios. The first one is the scenario in the first tab.
The ETF mini app
An educational web app that takes retail investors from ETF theory to a first real portfolio, a savings-plan simulation and ongoing rebalancing.
What lands on the developer's desk
One package: the working mockup plus every artifact behind it, in the folder structure the AI agents read. Nothing lives only in someone's head.
Less guessing, more engineering
A clear definition of done
Nothing left to interpret. If the scenarios pass, the feature is done.
Specs before code
Scenarios written up front, ready to become an automated test suite.
Traceability
Any behaviour can be followed back to the business reason behind it.
Time for real engineering
Architecture, security and performance, instead of rebuilding intent from mockups.
Honest limits
The spec can run ahead of the build
On ETF, one epic was in the PRD but not yet in the product. It stayed a hypothesis, with no scenario written for it, because scenarios only describe what exists.
Upkeep is real work
Every change, even a colour, flows back into the PRD and its changelog. That costs PO time, and it's what stops the spec from going stale.
Scenarios must run to enforce
Their full value arrives once they're wired to an automated test runner.
BDD can't judge feel
Visual quality and interaction polish still need a designer's eye.
The team argues over sentences, not shipped code
By the time anyone writes a line of code, PO, UX and developers already agree on what "working" means.
