Prototyping & UI/UX Requirements

Mockups & Interactive Prototypes

18 min Lesson 4 of 10

Mockups & Interactive Prototypes

When a wireframe says there will be a button here, a mockup shows exactly what that button looks like — its colour, label, size, and placement within a polished visual composition. When a stakeholder clicks that button in an interactive prototype and lands on the next screen, they are no longer imagining the system; they are experiencing a simulation of it. That shift from imagination to experience is the central power of high-fidelity prototyping, and understanding it is essential for any analyst involved in UI requirements.

From Wireframe to Mockup: What Changes

A wireframe is a structural blueprint — grayscale, low-detail, focused on layout and information hierarchy. A mockup applies the full visual layer on top of that structure. The jump from one to the other involves four specific additions:

Colour palette — brand colours, semantic colours (success green, error red), background and surface tones.
Typography — specific font faces, sizes, weights, and line-heights for every text element.
Imagery and icons — real or representative photos, product images, and icon sets replace the X-crossed placeholder boxes.
Component styling — buttons, input fields, cards, and navigation bars gain their final appearance: shadows, border radii, hover states, and spacing.

A mockup is still a static artefact — it is a picture, not a program. A designer working on a clinic booking system might produce separate mockup screens for: the patient dashboard, the appointment search results, the time-slot selector, and the booking confirmation. Each screen is a pixel-accurate JPEG or PNG (or an artboard in a design tool). Stakeholders can review them in a presentation, but they cannot interact with the flow between screens.

Analyst role at the mockup stage: Your job is not to produce the mockup yourself (that is usually a UI/UX designer's work) but to review it against the requirements. Walk through each screen and ask: Does this UI expose all the data fields required by the SRS? Does the workflow match the use-case flow? Are mandatory fields marked? Does the error messaging align with the validation rules you specified?

Interactive Prototypes: Adding Clickable Flows

An interactive prototype links mockup screens together so that clicking a button navigates to the correct next screen, filling a form and pressing Submit shows a confirmation page, and tapping Back returns to the previous state. No code runs — transitions are pre-programmed in the design tool — but the experience closely resembles a working application.

For an online store checkout flow, a prototype might include: Cart review screen → Shipping address form → Payment method selector → Order summary → Confirmation screen. A product manager, developer, or end user can walk through this entire flow in minutes and give feedback long before a single line of code is written. The cost of changing a screen layout at this stage is measured in minutes; after development begins, the same change can cost days.

Interactive prototypes serve three distinct purposes in systems analysis:

Requirements validation — stakeholders confirm that the proposed flow matches their mental model of the business process.
Gap discovery — clicking through often reveals missing screens, edge cases not covered in the SRS (what happens if the user leaves the form half-filled?), and ambiguous navigation paths.
Developer handoff — the prototype becomes a visual contract: developers can inspect spacing, colours, fonts, and interaction behaviour directly in the design tool without asking the analyst for clarification.

The fidelity ladder: wireframe (structure only) → mockup (visual design, static) → interactive prototype (clickable, multi-screen flows).

Tools of the Trade

Several professional tools dominate high-fidelity prototyping. As an analyst, you do not need to master any single tool, but you must be fluent enough to review, annotate, and discuss artefacts produced in each.

Figma — the current industry standard for collaborative UI design and prototyping. Cloud-based; multiple team members edit simultaneously. Prototype mode lets designers link frames with interactions (click, hover, drag) and specify transition animations. Developers use the Inspect panel to extract exact CSS values, spacing, and assets. Analysts use Comments to flag requirement mismatches inline.
Adobe XD — Adobe's vector-based design tool with Auto-Animate for micro-interactions. Less common in new projects since Adobe's acquisition of Figma (competition reduced), but still prevalent in enterprises running on the Adobe ecosystem.
Axure RP — the most powerful prototyping tool for complex conditional logic. Supports variables, dynamic panels, repeaters, and conditional interactions that simulate real application behaviour without code. Favoured by analysts and UX architects working on complex enterprise systems with intricate business rules. Steep learning curve but unmatched for logic-heavy flows.
Balsamiq — intentionally low-fidelity (sketch aesthetic), but can be pushed to mid-fidelity with linked screens. Often used for rapid wireframing with stakeholders who tend to debate colour and font when shown polished mockups. The rough visual deliberately keeps attention on structure rather than aesthetics.
InVision / Marvel — prototyping-focused platforms that can import static designs (from Sketch, Figma, or image exports) and add hotspot-based navigation. Simpler to learn than Axure, lower fidelity logic, but adequate for linear flows like onboarding wizards and checkout sequences.

Choosing a tool for analyst work: If your team already uses Figma or XD for design, use the same tool for prototype review — it keeps artefacts in one place and avoids export/import friction. If you need to prototype a logic-heavy flow (e.g., a multi-step insurance claim with conditional branching), reach for Axure. For rapid stakeholder alignment sessions, Balsamiq or even paper sketches evolved to linked PDF screens can be sufficient.

Anatomy of an Interactive Prototype in Practice

Consider a logistics firm commissioning a driver dispatch system. The analyst works with the UX designer to build a prototype covering the core dispatcher workflow. The prototype will include:

Screens — one Figma frame per distinct UI state: Dispatch Queue, Driver Map, Assign Trip modal, Confirm Assignment, Trip Active tracker.
Hotspots — clickable regions on each screen: the Assign button opens the modal; the Confirm button navigates to the Trip Active screen; the Back link returns to the queue.
Overlay interactions — the Assign Trip modal appears as an overlay rather than a new full screen, matching the intended application behaviour.
Error states — a separate frame shows the modal in its error state (driver unavailable) with the validation message, linked from the Confirm button with a conditional branch: success path vs. error path.
Annotations — comments on specific UI elements that flag business rules: "Driver must have a valid licence expiry date in the future before assignment is allowed."

Prototype screen flow for a logistics dispatch system: success path (driver assigned) and error path (driver unavailable) as separate linked frames.

Handoff: From Prototype to Development

In modern toolchains, the interactive prototype is not just a communication artefact — it becomes part of the developer handoff package. In Figma, clicking Inspect on any element reveals the exact CSS properties: padding: 12px 24px, border-radius: 8px, font-size: 14px, color: #1e293b. Spacing tokens, colour variables, and component states are all accessible. Developers reference the prototype to understand the intended flow and the Inspect panel to implement it pixel-accurately — without needing a separate specification document for visual properties.

As an analyst, your handoff role at this stage is to ensure the prototype is annotated with the why behind UI decisions. A developer can read the colour from the tool; they cannot read from the tool that the red error state must appear only after the user attempts to submit, not on first field focus. Those rules belong in annotations or in the linked SRS sections.

Common pitfall — the prototype becomes the spec: Teams sometimes skip written requirements and declare "the prototype IS the spec." This creates serious problems: prototypes do not capture business rules, data validation logic, security requirements, performance thresholds, or integration contracts. The prototype defines the visual behaviour; the SRS defines everything else. Both are necessary.

Summary

Mockups apply the full visual design layer to a wireframe structure, producing pixel-accurate static screens. Interactive prototypes connect those screens with clickable transitions, simulating application flow without code. Together, they compress the feedback cycle dramatically, surface gaps in requirements before development, and provide developers with a precise visual contract. The analyst's role is not to build these artefacts from scratch but to drive their scope from requirements, review them for completeness, annotate them with business rules, and ensure the final handoff package is unambiguous for the development team.