The structure lives in someone's head
Which regions a page has, what the table shows, which fields the form collects: none of it is in the frame. Engineers reverse-engineer it from screenshots.
Low-fidelity wireframing from Ferrous Labs
Ferrous Studio is where product owners and designers lay out screens, configure the components on them and record who each screen is for. The result exports as one JSON payload an engineer, or an LLM, builds from directly.
Invite-only. Organisations are set up by Ferrous Labs.
The problem
Which regions a page has, what the table shows, which fields the form collects: none of it is in the frame. Engineers reverse-engineer it from screenshots.
Two versions of a picture cannot be diffed. The change log is whatever someone remembered to write down.
Given a screenshot, an LLM guesses at intent and fills the gaps with defaults. Given the structure, it has nothing to guess.
How it works
Each page starts as one region. Split it horizontally or vertically as far as you need, drag the dividers to size them, or let the content decide. Nothing sits at a coordinate unless you ask it to.
Six components cover most product screens: nav bar, list, form, graph, calendar and a free canvas. Each is built from typed elements, so a column knows its data kind and a nav item knows where it goes. Every label on the canvas edits in place.
Nav items and buttons link to a page, or to one region of it, so only that part swaps while the shell stays put. Child pages nest like routes and a page can open as a modal or a drawer. Preview mode clicks through the lot.
Personas, use cases, diagrams, datasets and every wireframe leave as one envelope. There is no proprietary format and nothing the export knows that you cannot already see on screen.
What you get
Components render as the UI they stand for, and every string on the screen is yours to edit. Enough to reason about a screen, never enough to argue about a shade of blue.
Record who each screen is for. Actors from the use case diagram link to wireframes and travel in the export as user types.
Define a list of values once, then bind it to any column, dropdown or filter. Change it in one place and every screen follows.
Save a version whenever a decision is made. Preview any earlier one, restore it, or fork it into a new wireframe.
Annotate any region, component or element for the engineer who builds it. Every change is recorded with who made it and when.
Draw UML in the built-in editor and keep reference files with the project, so the export carries the reasoning as well as the screens.
The export
Copy it into a ticket, commit it beside the code, or paste it into a model's context. The diff between two exports is the change log.
It is plain JSON with no proprietary schema. Any language reads it, and the spec belongs to the team, not to the tool.
Ferrous Studio does not do visual design. Colour, type and spacing are decisions for Figma or for the code, taken once the structure is agreed.
{ "schemaVersion": "1.0", "projectName": "Field Ops", "rationale": "Dispatchers lose an hour a day chasing job status by phone.", "personas": [ { "name": "Dispatcher", "role": "Operations", "jobsToBeDone": ["Assign the right crew fast"] } ], "diagrams": [ { "name": "Job lifecycle", "kind": "state", "model": { } } ], "datasets": [ { "name": "Job status", "values": ["Open", "Assigned", "Done"] } ], "wireframes": [ { "name": "Dispatcher console", "interfaceType": "desktop", "userTypes": [{ "name": "Dispatcher" }], "pages": [ { "name": "Jobs", "route": "/jobs", "layout": { } }, { "name": "New job", "route": "/jobs/new", "presentation": "modal", "layout": { } } ] } ] }
Who it is for
Lay out the screens in a working session and leave with a spec, not a to-do to write one. The export goes straight into the ticket.
Settle structure before style. Decide what each page holds and how it links, then take the visual decisions into your own tools.
Read one JSON tree: splits become rows and columns, regions become containers, child pages become nested routes. Build from it, or have an LLM do the first pass.
On the roadmap
Specified, not yet shipped. Listed so you know where this is heading.