Home About Services Use Cases Resources Blog FAQ Book a Demo
← Back to resources

Wireframes

A wireframe template where every box lists its content, states and rules

UXUX ResearcherCore tier5 sections

A wireframe template specifies the key screens of a product at low fidelity: the regions on each screen, the content each region shows, where that content comes from, and how the screen behaves when it is empty, loading, failing or denied. It lets a team decide layout and interaction before anyone writes a line of interface code. Specira treats the content-slot table as canonical and generates the schematics from it, so the drawing and the specification cannot disagree.

Hand-drawn wireframes are boxes with lorem ipsum. Nobody states what fills the box, what happens when the name is too long, or which fields disappear for a read-only user, so developers guess and the review catches it in the demo. Worse, the drawing and the requirement live in different files. When the ranking rule changes, the wireframe still shows the old order and nobody notices until a tester does.

What sections does the wireframe template contain?

The governed default template fixes five sections. Three are rendered wireframes generated from the content-slot specs; two are prose synthesized from the discovery session.

SectionDepthHow it is produced
Key Screen WireframescoreRendered wireframe
Responsive VariantsstandardRendered wireframe
Element Sizing & GridstandardProse synthesized from discovery
State VariationsfullRendered wireframe
Micro-Interaction AnnotationsfullProse synthesized from discovery

How does Specira build the wireframes?

The UX Researcher agent owns this artefact and compiles it from the session's typed items: requirements name the screens and the rules each one carries, business rules feed the input specs, and constraints decide which viewports get offered. The sample shows how. In Key Screen Wireframes, the dispatch board's job-queue row is a content-slot table: each slot names its source field, its format and truncation rule, its emphasis tier and its empty-value behaviour, and the schematic is rendered from that table with the longest realistic name deliberately exercised. The state deltas block lists which regions change for empty, loading, error, permission-denied and degraded-feed states, each pointing at a pattern-library reference. Every callout carries one concern and one target, resolving to a functional requirement anchor or a data-model field.

The Red Team Critic consults on every turn and runs the export readiness gate. A screen whose arrangement decision is still open renders as a named gap, never as a plausible box. Each slot and callout carries provenance: who decided, when, on what evidence. Exports go out as DOCX for reviewers, Markdown or JSON for agents, or straight into Jira, Confluence, GitHub or Linear. Clone the template in the Templates module to change the breakpoint set or add a section; every publication is versioned and immutable.

First page of the sample: Wireframes

Rendered sample

Rendered from the Specira governed default template on a fictional company, watermarked, with its diagrams. Read it in the browser or take the PDF.

PDFView online

How do teams use the wireframe document?

What does the wireframe artefact look like in Specira?

The screens below show a wireframe section in the discovery session, the rendered board schematic with its callouts, and the export gate for this artefact.

Screens are from a seeded Specira demo workspace; counts and scores are sample data.

Book a demo and see a discovery session render annotated wireframes your developers can build from.

Book a Demo

What do teams ask about this artefact?

A wireframe template is a structured document that fixes, for each key screen, its regions, the content slots inside them, the states it can be in, and the interactions it supports, at low fidelity. Specira's version makes the content-slot table the specification and generates the schematic from it, so the drawing always matches the rules the team decided.
Both, in that order. The UX Researcher agent compiles a content-slot table per region from typed requirements, business rules and constraints, then the schematic is rendered from that table with real representative content and enforced truncation. A region without its slots is a box, not a wireframe, and the template treats it as a gap.
Through callouts. Each callout carries one concern and one target: a ranking rule points at its functional requirement anchor, a reason-code list points at the data-model field, a staleness display points at the degradation rule. When a requirement changes in the session, the cross-reference shows which wireframe callout it affects.
The responsive section names the breakpoint set and each screen's baseline, and records when a viewport is deliberately not offered, with the constraint that says so. The component library section names the design system and version in use and files missing components as design-system requests. Accessibility is stated at schematic altitude: first focus, tab order and alert roles.
DOCX for humans, Markdown and JSON for agents, and a zip per session or project. Pushes to Jira, Confluence, GitHub and Linear are built in. The Red Team Critic's export gate measures resolved decisions, not pages, so any wireframe still waiting on an arrangement decision ships listed in the gap report.

Which artefacts go with this one?