When designing a data-entry form, which elements does the form designer specify to guide users and bind on-screen fields to stored data (as opposed to the actual data values themselves)?

Introduction / Context:
Forms are user-interface artifacts that connect people to the underlying database. A form designer chooses labels, positions, and bindings that help users enter and review data accurately. It is important to distinguish between design elements (what the form defines) and data (what users type or what the database stores).

Given Data / Assumptions:

• We are discussing form design, not data content.
• Designers specify which fields appear and how they are labeled.
• Users supply the data values at runtime.

Concept / Approach:
Form design typically includes field designators (bindings to database fields/controls) and prompts (labels, instructions, placeholder text) that guide user input. The data itself is not part of the design; it is dynamic content captured or displayed when the form is used. Keeping this distinction clear helps avoid mixing presentation with content and supports reusable forms across records and users.

Step-by-Step Solution:

Verification / Alternative check:
GUI builders and form designers in common tools separate properties (control bindings, labels) from record instances. Templates can be reused across many data rows, proving that data is not a design element.

Why Other Options Are Wrong:

• Field designators alone or prompts alone: Each is part of design but incomplete by itself.
• Data: Not a design artifact; it is user/DB content at runtime.
• None: Incorrect because designers choose field bindings and prompts.

Common Pitfalls:
Hard-coding sample data into a form; conflating a mockup’s placeholder text with real, stored values.

Final Answer:
Both (a) and (b)