What this prompt does
This prompt turns Claude or ChatGPT into a product designer for a finance budgeting and forecasting tool. You name the [product_name] and the [organization_type] it serves, then describe the [budget_cycle], the [org_structure], the [planning_approach], and the [framework] you'll build in. From that, the model designs seven connected modules: an overview dashboard, an allocation editor, scenario planning, variance analysis, an approval workflow, a forecasting engine, and the framework-specific implementation notes.
The structure works because budgeting is a collaborative, multi-editor problem, not a single-screen form. By forcing the model to reason about [org_structure] (for example a four-level Company > Division > Department > Cost Center hierarchy) and the [planning_approach] (top-down targets meeting bottom-up detail), it produces allocation grids and roll-up logic that match how real finance teams actually negotiate numbers. The [variance_threshold] variable feeds the highlighting rules so the variance module flags only material gaps.
When to use it
- You're scoping a budgeting or FP&A SaaS feature and need a coherent module map before writing code.
- You want a spreadsheet-like allocation grid with formulas, version snapshots, and top-down/bottom-up flows specified.
- You need scenario modeling (best case, expected, conservative) with sensitivity sliders laid out.
- You're designing an approval workflow with thresholds, delegation, and an audit trail.
- You want forecasting UI patterns (rolling forecast, driver-based inputs, confidence intervals) described before integration work.
- You're choosing a grid library and want the
[framework]implementation notes to compare against.
Example output
You get a structured design document, module by module, in the order listed. Each module is broken into concrete UI elements (charts, grids, side-by-side comparisons, status indicators) with the interactions that connect them — for example how promoting a scenario triggers the approval workflow. The final [framework] section translates the design into implementation concerns like a virtualized grid, undo/redo, real-time collaboration indicators, and export formats. It's a spec you can hand to a designer or build directly from, not finished code.
Pro tips
- Make
[org_structure]precise. The number of levels you specify directly shapes the roll-up and drill-down behavior the model designs. - Set
[variance_threshold]as a real rule (for example "10% or $5,000, whichever is greater") so variance highlighting is actionable instead of arbitrary. - Match
[planning_approach]to your reality — a pure top-down org gets a different allocation editor than a hybrid one. - Pin
[framework]to a real grid library (AG Grid, TanStack Table) so the performance and keyboard-editing notes are usable. - If the output is too broad, ask for one module at a time and request component-level detail, states, and empty states.
- Iterate on the forecasting section separately — driver-based forecasting deserves its own pass once the rest is settled.
