Prototyping & UI/UX Requirements

Gathering UI Requirements

18 min Lesson 7 of 10

Gathering UI Requirements

Every screen a user sees is the product of decisions made — or missed — during requirements gathering. UI requirements translate raw user needs into precise interface constraints that designers and developers can act on. Without them, prototypes drift from reality, usability suffers, and rework explodes. This lesson gives you a professional workflow for extracting, structuring, and validating interface requirements before a single pixel is placed.

What Are UI Requirements?

UI requirements are a category of functional and non-functional requirements that specify how the system must look, behave, and respond from the user's perspective. They go beyond "the system shall display a form" to answer questions like: which fields are mandatory? In what order do they appear? What feedback does the user receive on error? What happens on a slow connection?

UI requirements live at the intersection of three concerns:

User goals: what the user is trying to accomplish (from use cases and user stories).
Business rules: constraints the organisation imposes (e.g. mandatory consent checkbox for GDPR).
Technical constraints: platform limits (mobile screen size, offline capability, browser support).

The UI Requirements Gathering Process

Gathering UI requirements is not a one-off workshop — it is a structured cycle of discovery, documentation, and validation. The diagram below maps the four-phase cycle analysts follow.

The four-phase UI requirements gathering cycle: Discover → Structure → Prototype → Validate, with iterative refinement.

Phase 1 — Discover: Elicitation Techniques

The goal of discovery is to surface latent needs — the things users need but cannot always articulate. Use a combination of techniques:

Contextual interviews: Sit with users while they perform real tasks. For a clinic booking system, watch the receptionist navigate the current paper log. Note mouse paths, hesitations, and workarounds.
Task analysis: Decompose each job-to-be-done into discrete steps. "Book an appointment" becomes: search patient → check availability → select slot → confirm → print receipt. Each step drives at least one screen requirement.
Personas and scenarios: Define 2–4 representative user archetypes. For a logistics firm: a dispatcher who needs at-a-glance route status on a large monitor, and a driver who needs tap-friendly controls on a phone. Their needs produce very different UI constraints.
Card sorting: Ask users to group functions onto imaginary screens. Reveals the mental model behind navigation.
Competitive benchmarking: Audit similar products to identify established interaction patterns users already know — and gaps you can exploit.

Phase 2 — Structure: The UI Requirements Catalogue

Raw observations become actionable only when structured. A UI Requirements Catalogue records every interface constraint in a traceable, testable format. Each entry should include:

ID — unique identifier (e.g. UIR-012).
Source — the use case, persona, or business rule that generated it.
Screen / component — where the requirement applies.
Statement — a precise, testable condition.
Priority — MoSCoW (Must / Should / Could / Won't).
Acceptance criterion — how you will verify it in a usability test or demo.

UIR-012 | Source: UC-05 Checkout | Screen: Payment form
Statement: The "Place Order" button MUST remain disabled until all mandatory
           fields pass inline validation.
Priority: Must
Acceptance: Tester submits form with empty card number — button stays disabled
            and a red error message appears beneath the field within 200 ms.

Tip — write requirements, not designs. "The error message MUST appear within 200 ms" is a requirement. "The error message MUST be red Roboto 14px" is a design decision — leave it to the designer unless a business rule or accessibility standard mandates it.

Traceability: Linking UI Requirements to Business Goals

A UI Traceability Matrix maps each interface requirement back to a business objective and forward to a prototype screen. This ensures nothing is gold-plated (added without a real need) and nothing is missing.

Sample UI Requirements Traceability Matrix: each interface requirement is linked to a business goal, prioritised, scoped to a screen, and given a testable acceptance criterion.

Categories of UI Requirements

Organising requirements by category prevents gaps. For any screen, ask yourself whether you have covered all of these:

Layout and information architecture: What content appears on screen? In what hierarchy? What is always visible versus hidden behind a tab or modal?
Input and validation: Field types, formats, mandatory/optional, real-time versus on-submit validation, error message wording.
Feedback and system status: Loading spinners, progress indicators, success/failure notifications, undo affordances.
Navigation and flow: Entry points, allowed transitions, back-button behaviour, deep-linking.
Responsiveness and platform: Breakpoints, touch versus cursor, font scaling, offline behaviour.
Accessibility: Keyboard navigation, screen-reader labels (aria-label), colour contrast, focus indicators.
Internationalisation (i18n): RTL layout flipping, date/number formats, text-expansion allowance (~40% for Arabic translations of English labels).
Performance perception: Time-to-first-meaningful-paint targets, skeleton screens, optimistic UI updates.

Practical Example: Logistics Shipment Tracking Screen

A logistics company wants a shipment-tracking screen for dispatchers. After contextual interviews the analyst captures these requirements:

UIR-031 — The screen MUST display up to 50 shipments simultaneously without pagination (Must).
UIR-032 — Each row MUST show status with a colour-coded badge: green = delivered, amber = in transit, red = delayed (Must).
UIR-033 — Dispatchers MUST be able to filter by status and date range in under 2 clicks (Must).
UIR-034 — The table SHOULD be sortable by any column header (Should).
UIR-035 — Hovering a row COULD surface a tooltip with the last GPS ping timestamp (Could).

Warning — avoid UI requirements that embed design decisions. Writing "the status badge MUST be a pill-shaped element with 8 px border-radius" conflates requirement with design, which blocks the designer and creates unnecessary sign-off cycles. Stick to what the interface must communicate, not how it looks.

Validating UI Requirements Before Prototyping

Before handing requirements to the prototype author, run a brief validation pass using the SMART-UI checklist:

S — Specific: Does it name a concrete screen or interaction?
M — Measurable: Can a tester pass or fail it without subjective judgment?
A — Agreed: Has the product owner or business sponsor confirmed its priority?
R — Realisable: Does the dev team confirm it is technically feasible within budget?
T-UI — Traceable: Is it linked to a use case or business objective in the matrix?

Note — UI requirements are living documents. As the prototype is built and tested, new constraints will emerge (a field is too small, a flow step is redundant). Update the catalogue, increment the version number, and notify stakeholders. Traceability makes the impact of changes visible and keeps scope under control.

With a structured catalogue in hand, the analyst and design team share a common language. Wireframes and mockups become artefacts that prove requirements are met, not just pictures that look good — setting up the usability evaluation in the next lesson for meaningful, objective results.