A restaurant POS back office has forty settings forms; when should a design system generate forms from a schema instead of composing each by hand?
answer
- many similar forms, one pattern
- presentation, not just data types
- authored copy, not constraint text
- an escape hatch for odd fields
- not for the flagship flow
basics
~20 sGenerate from a schema when many similar forms must follow one pattern, ideally across platforms; the schema must then carry labels, help, grouping and order, not just types. Hand-compose the few high-stakes flows that need bespoke layout and copy.
solid answer
~50 sGeneration pays off for a **long tail of similar forms** — settings, admin records, configuration — where consistency matters more than bespoke design, and especially when the same form must render on web and native apps or change without an app release. The generator then owns the whole form pattern — single column, groups, required marking, error summary, accessibility — so every generated form gets them for free. The price is that the schema must carry **presentation, not just data**: authored labels, help text and error messages, group and order, which control fits each field, and a declarative rule for conditional visibility. It also needs an **escape hatch**, a registry of custom field renderers, or teams will fork the generator. A guest checkout or onboarding flow that needs tailored copy and layout is still composed by hand from the same components.
go deeper
Know what schema-driven generation is and that generated and hand-built forms share the same field components and form pattern.
Explain what a schema needs beyond types — labels, help, grouping, order, control hints and messages — and why data-model order makes a poor form.
Set the rule for which forms are generated and which are hand-composed, design the renderer escape hatch, and name the inner-platform and copy-ownership failure modes.
Weigh runtime-served schemas against release-bound forms across web and native apps, including schema versioning and who owns form copy.
## What schema-driven generation is In **schema-driven form generation**, a form is described as data — a declarative schema listing fields, their types, constraints and presentation details — and a generator in the design system turns that description into a rendered form built from the system's components. The alternative is **hand composition**: an engineer places each field component in code. Both use the same field components; the difference is who decides structure and layout, a person per form or the generator for all of them. ## When it pays off - **Many similar forms.** A restaurant point-of-sale back office has forty settings forms — tax rates, service charges, printer routing per kitchen station, staff roles, table layouts, opening hours. They are structurally alike and their users want predictability, not delight. - **More than one platform.** When the tablet app, a web back office and a native phone app all render the same settings, one schema rendered by one generator per platform keeps them in step. - **Forms that change without a release.** If the schema is served at runtime, a new setting can appear without shipping a new app build — a real advantage for native apps that wait on store review. - **Enforced quality.** Layout, required marking, error summary, focus handling and labelling are implemented once in the generator and tested once, instead of re-done forty times with forty variations. ## What the schema must carry A schema that only mirrors the data model produces a form that reads like the data model. To produce a good form it needs presentation metadata: | Schema element | Why the generator needs it | |---|---| | Authored **label** and **help text** | Field names like `svc_chg_pct` are not labels; content design must be able to edit copy | | **Group** and **order** | The user's order rarely matches storage order | | **Required or optional** | So the system's marking convention is applied | | **Control hint** | A type alone does not say whether five options are radios or a select | | **Error messages** per rule | Constraint text such as 'pattern mismatch' is not a message a person can act on | | **Visibility rule** | Declarative conditions ('show only when service charge is on') instead of scripted behaviour | ## What the generator owns The generator is where the form pattern lives. It applies the single-column layout and grouping, renders group headings as labelled groups, marks optional fields according to the system convention, composes inline errors and the error summary, and moves focus on a failed submit. Because every generated form shares one implementation, an accessibility fix lands everywhere at once — but the generator still needs its own tests for each combination of field type, rule and state it supports. ## Costs and failure modes 1. **Expressiveness ceiling.** A layout the schema cannot describe is either impossible or leads to a special-case flag, and the flags accumulate. 2. **The inner-platform trap.** Schemas start growing loops, computed values and scripts until they are a second, worse UI framework that only its authors understand. 3. **Copy drift.** When labels and messages live in schemas owned by back-end teams, content design loses control of wording unless the schema is part of their workflow. 4. **Lowest-common-denominator UX.** Every form looks equally fine and none is tailored; that is right for settings and wrong for a flagship flow. 5. **Versioning.** Once schemas are served at runtime, older app versions must render newer schemas, so the schema format itself needs compatibility rules. ## A hybrid rule for the POS product Many systems land on a split: - **Generate** the long tail: back-office settings, admin records, configuration forms. - **Hand-compose** the few flows where wording, layout and sequencing are the product: the guest's pay-at-table checkout, onboarding for a new restaurant. - **Share the parts:** both paths use the same field components, the same error pattern and the same layout tokens, so a hand-composed form and a generated one look and behave like one system. - **Provide an escape hatch:** a registry where a team can plug in a custom field renderer — say, a floor-plan picker for table layout — while the generator still owns the label, help text, errors and position of that field. The interview-grade answer is therefore not 'always generate' or 'never generate' but a rule for which forms belong to which path, and what the schema must carry for generated forms to meet the same bar as hand-built ones.
- How should validation messages work in a generated form?Constraints in the schema drive the checks, but messages are authored per field or per rule in plain language — 'Enter a service charge between 0 and 25 percent' rather than 'Value out of range'. The generator places them in the same inline-plus-summary pattern hand-built forms use. Sharing the rule definitions with the server is a separate engineering choice.
- How do you stop the generator from becoming a second, worse UI framework?Keep its scope to form structure — fields, groups, order, messages and simple declarative visibility rules — and route anything richer through the custom renderer registry or a hand-composed form. When schemas start needing loops, layouts or scripted behaviour, that form should leave the generator.
saying these in an interview costs you the question
- Generating forms straight from the database schema gives a good form without extra metadata.
- Once forms are generated, their accessibility no longer needs testing.
- Every form in the product, including checkout, should come from the generator.
- Constraint text such as 'pattern mismatch' is fine as an end-user error message.
- A schema can be made expressive enough that no custom control is ever needed.