Requirements are a design surface

The requirements you get are rarely good enough. On complex enterprise software, with business analysts who know the domain but have never designed a form field, the spec you receive is missing the field type, the validation rule, the character limit, the helper text, and the edge case that will derail the developer six weeks in. This is not a failure of the BA; it is a failure of the designer who accepted the brief without interrogating it. Requirements quality is a design responsibility. Treating it as a precondition you either have or don't have is how timelines blow out and technical debt accumulates.

The clean handoff model fails on complex software

The default posture in most product teams is a clean division of labour. The BA writes the requirements, the designer designs to them, the developer builds to the design. It is a tidy model and it fails reliably in any application where the front-end is genuinely complex. Form-heavy applications, dense data tables, transaction workflows with conditional logic are all systems where what a field is at the UI layer is inseparable from what the data is at the domain layer. When a designer takes a vague requirements document, fills in the front-end detail silently inside their Figma file, and hands that file to a developer who has no idea where the design decisions came from, the developer is now guessing. The guessing produces bugs. The bugs produce rework. The rework produces the six-month project that takes nine.

The master data layer is where it starts

At ANZ, working across institutional banking systems, the team had developed a practice of maintaining master data documentation as a shared artefact. Master data in that context meant every attribute in the system captured in a structured format covering the back-end field name, the data type, the API connection, and the front-end treatment (field component type, validation rule, character limit, whether helper text was required and what it said). It was not glamorous work. It was the kind of documentation that disappears from team wikis during crunch and never returns. But on a system with hundreds of fields across dozens of transaction screens, the discipline of maintaining it paid back more than it cost. The designer designed from it. The developer built from it. The QA team tested against it. Everyone was working from the same definition of what the field was.

The challenge with master data is keeping it connected to the work. A table in Confluence that nobody links to is an artefact in decline from the moment it is created. At Woolworths, the approach evolved to close that gap. Annotations in Figma are linked directly to rows in a Confluence database. A developer clicking into a field annotation goes directly to its master data entry, not to a document they then have to search. The annotation is not duplicating the data; it is indexing it. For teams that prefer to work in Jira, a plugin built against the Figma API exposes annotations in a sidebar, and a Gemini-based tool converts them to BDD-style user stories on demand. The intent throughout is to give different parts of the team different entry points to the same underlying data, rather than forcing everyone through the same interface.

The result is what we started calling a quad of requirements, made up of master data, screen baseline, Figma annotations, and the Jira story. The developer is not choosing between sources; they have a hierarchy. The story is the intent. The annotations are the specifics. The master data is the authority.

This is not waterfall

The obvious objection is that this is waterfall by another name, and it is not an unfair challenge. Maintaining a master data set implies upfront investment in specification that agile teams have deliberately moved away from. There is something to this. On discovery-heavy work, or on consumer products where design iteration is the mechanism for finding the right answer, front-loading requirements discipline adds drag without necessarily adding clarity. The quad of requirements is the right tool for complex deterministic software, not for every project. The failure mode is applying agile assumptions to work that is not actually exploratory, where the system's behaviour at the data layer is known, and the question is whether the designer has surfaced that knowledge or left the developer to reconstruct it.

The credibility is in the build

The designer's contribution to requirements is not admin. It is a significant part of what makes a design buildable, and therefore a significant part of whether the design ships at all. Complex software teams that give designers visibility into master data, and that expect designers to contribute to it, produce work with fewer build surprises, fewer late-stage rewrites, and tighter alignment between what was designed and what was shipped. That alignment is not just a quality signal; it is a credibility signal. Developers who see field-level annotation linked to a structured data source learn to trust the design file as an authority, not a starting point for negotiation. That trust, once established, is worth more to the design function than any handover template.