From Analysis to System Design

Input & Output Design

18 min Lesson 6 of 10

Input & Output Design

Once the architectural blueprint is in place and modules are decomposed, the analyst turns to the human-facing surfaces of the system: the screens and forms through which data enters, and the reports and displays through which information is returned. Input and output design is where analysis becomes tangible for users — it is the earliest point at which they can see and react to the future system in concrete terms.

From a design perspective, forms and reports are not aesthetic problems; they are contracts between the system and its users. Every field on a form is an obligation: the system agrees to accept, validate, store, and process that value correctly. Every column in a report is a promise: the system agrees to source, compute, and present that figure accurately. Designing these surfaces badly generates defects that surface in production and are expensive to fix.

Principles of Input Design

Good input design follows a small set of principles that apply across technologies — whether the form is a web page, a mobile screen, or a paper document digitised at a scanning station.

  • Minimise input. Ask only for data the system cannot derive itself. If a postcode determines a city, do not ask for both.
  • Use the right control for each data type. A date picker prevents format errors that a free-text field invites. A dropdown constrains a value to the valid set. A toggle is clearer than a checkbox for binary choices.
  • Group related fields. Cluster personal details together, shipping details together, payment details together. Each group should map to one coherent step in the user's mental task.
  • Provide immediate feedback. Inline validation (flagging an invalid email as the user types) is far less disruptive than a full-page error after submission.
  • Default and pre-fill intelligently. Pre-populate a country from the user's locale, default an order date to today, suggest a quantity of one for line items. Fewer keystrokes mean fewer errors.
Design for the worst-case user, not the average. Your most careful user will enter data correctly with almost any form. Design for the distracted, the hurried, and the novice — the edge cases that generate support tickets and corrupted records.

Form Design Anatomy

The wireframe below models a patient registration form for a clinic booking system. Each visual zone maps directly to a design decision. The diagram uses standard wireframe notation: gray boxes for text fields, pill shapes for buttons, an X-crossed rectangle for a file upload target, and lighter rectangles for section groupings.

Wireframe: Patient registration form with validation zones New Patient Registration SECTION A — Personal Details First Name * e.g. Sara Last Name * e.g. Ahmed Date of Birth * DD / MM / YYYY cal Gender * Male Female Other ⚠ Date of Birth is required SECTION B — Contact Information Email Address * user@example.com Mobile Number +966 5X XXX XXXX ✓ Valid email format SECTION C — Identity Document (optional) Drop file or click to upload Accepted: PDF, JPG, PNG Max size: 2 MB Submit Registration Cancel * Required field
Annotated wireframe of a patient registration form: grouped sections (A/B/C), inline validation feedback, file upload constraints, and clear primary/secondary button hierarchy.

Validation Rules as Design Artefacts

Validation is not a developer concern added after design — it is a core design decision. For every input field, the analyst must specify a validation rule that defines what values the system will accept. These rules appear in the design specification and become the source of truth for both front-end and back-end implementations.

Each validation rule should state four things: the field name, the rule type, the constraint, and the user-facing message on failure.

Field | Rule Type | Constraint | Error Message ------------------|-----------------|--------------------------------|----------------------------------- firstName | required | not empty | "First name is required." firstName | length | 2 – 60 characters | "Name must be 2 to 60 characters." dateOfBirth | required | not empty | "Date of birth is required." dateOfBirth | range | >= 1900-01-01, <= today | "Enter a valid date of birth." email | format | RFC 5322 pattern | "Enter a valid email address." phone | format (opt.) | E.164 or local pattern | "Enter a valid mobile number." documentFile | file type | PDF, JPG, PNG only | "Only PDF, JPG, or PNG files are accepted." documentFile | file size | <= 2 MB | "File must not exceed 2 MB."
Specify cross-field rules explicitly. Some validation spans multiple fields: "if paymentMethod is Bank Transfer, then bankAccountNumber is required." These conditional rules are easy to miss if you validate each field in isolation. Document them as a named business rule in the specification.

Principles of Output Design

Output design governs reports, dashboards, confirmation screens, printouts, and data exports. Outputs communicate the value the system generates. Poor output design buries that value under irrelevant columns, inconsistent labelling, and formatting that varies between screens and print.

  • Match the audience. An operations manager wants summary KPIs with drill-down. A warehouse clerk wants a per-item pick list sorted by bin location. A finance auditor wants transaction-level detail with running totals. Design each output for its consumer, not for the database schema.
  • State the data source. Every computed figure in a report needs a derivation rule documented in the specification: "Monthly Revenue = SUM(orderTotal) WHERE orderDate is within the selected month AND status = Paid."
  • Specify grouping and sorting. A report that lists 2,000 orders in primary-key order is unusable. Define: group by region, sort by descending revenue, show subtotals per group.
  • Define filters and parameters. A useful report is parameterised — the user selects a date range, a department, or a product category before it runs. Document each parameter name, type, default value, and whether it is required.
  • Handle exceptions. What does the report show when there is no data for the selected period? Design the empty state — a message like "No orders found for Q2 2025" is better than a blank page.

Report Layout Specification

The diagram below illustrates a standard logistics dispatch report. It shows the canonical zones of a well-designed printed or on-screen report and the annotation a design specification must supply for each zone.

Annotated layout of a logistics dispatch report FastShip Logistics — Dispatch Report Period: 2025-06-01 to 2025-06-30 | Generated: 2025-07-01 09:00 | User: dispatcher@fastship.com Shipment ID Customer Destination Status Value (USD) SH-10041 Al-Noor Trading Riyadh Delivered 4,200.00 SH-10042 Gulf Star Co. Dubai In Transit 8,750.00 SH-10043 Petra Imports Amman Delayed 3,100.00 · · · · · additional rows · · · · · Subtotal — June 2025 (47 shipments) 312,440.00 SUMMARY Total Shipments: 47 | Delivered: 31 | In Transit: 12 | Delayed: 4 Total Value: USD 312,440.00 | Avg. Value per Shipment: USD 6,647.66 Confidential — Internal Use Only Page 1 of 3 Report ID: RPT-DISPATCH-202506 Report Header Zone Column Headers Detail Rows (alternating) Group Subtotal Row Summary / KPI Block Report Footer (page / ID)
Annotated dispatch report layout: six canonical zones — header, column headers, detail rows, group subtotal, summary block, and footer — each with a documented specification responsibility.

Connecting Inputs and Outputs to the Broader Design

Input and output design does not happen in isolation. Every form field must map to a column in the data layer design (Lesson 5) and to a validation rule in the interface specification (Lesson 4). Every report column must trace back to a derivation rule — a SQL expression or business formula — that the data layer can support. When these connections are missing, developers invent their own rules and inconsistencies multiply across modules.

The practical deliverable at this stage is a Form Specification Sheet and a Report Specification Sheet for each surface. These live inside the Design Specification Document (covered in Lesson 7). Each sheet captures: the purpose of the form or report, the actors who use it, the trigger event, the list of fields or columns with their data types and validation or derivation rules, the layout grouping, and any special behaviour (auto-populate, conditional visibility, parameterised filtering).

Never leave "TBD" in a validation rule column. Deferred validation decisions become developer assumptions, and developer assumptions become production bugs. If you discover a rule is genuinely unclear, raise it as an open issue in the specification and resolve it before sign-off — not after development begins.

Summary

Input design asks: what data must enter the system, how should it be captured, and what rules must it satisfy? Output design asks: what information must leave the system, for whom, in what structure, and derived how? Both disciplines produce formal specification artefacts — validation rule tables and report layout sheets — that constrain developer choices and eliminate a wide class of defects before a single line of code is written. In the next lesson, these artefacts are assembled into the overarching Design Specification Document.

Previous Lesson Designing the Data Layer from the ERD
Next Lesson The Design Specification Document
Back to Course