Requirements, Design, and Rapid Prototyping

Research is useful only when it helps a team decide what to build. In this part of the walkthrough, the stadium-pickup idea moves from research into a working product proposal. The proposal has a tentative geographic scope, interface mockups, an experiment plan, and a map of the code that may need to change.

The important shift is from “What might be valuable?” to “What exactly are we proposing, how could we test it, and where would it fit in the existing system?”

Four artifacts that answer different questions

These artifacts are related, but they are not interchangeable:

Artifact	Question it answers	What it does not prove
Scope	Where and under what initial boundary should the idea be considered?	That the feature is ready for every market
Mockup	What interaction are we proposing?	That the interaction works in production
Experiment variants	What competing product hypothesis could we compare?	Which variant will win
Code map	Which existing clients, services, and flows are affected?	That the implementation is complete or safe to merge

Keeping these distinctions clear prevents a polished prototype from being mistaken for a validated product.

1. Turn research into a tentative scope

The walkthrough proposes North America as the initial scope for the stadium feature. This is a working product boundary. It gives design and engineering something concrete to reason about without claiming that the same solution is already appropriate everywhere.

For the stadium-pickup scenario, the user needs a pickup location away from a crowded venue. A regional scope lets the team ask focused questions about the first version: which client experiences are involved, which routing behavior is needed, and which existing flows can be reused.

Teaching context: A scope is a decision about where to start, not a statement that the problem exists only there. A narrow first boundary can make assumptions visible and make an experiment possible.

2. Use mockups to align on the interaction

The next artifact is a set of Figma mockups. A mockup depicts the intended interaction before production code exists. In the walkthrough, the pickup experience is shown as two design variants with different button copy.

This is valuable because people can discuss the same proposed behavior. Product, design, and engineering can point at a screen and ask whether the user action, wording, and flow match the problem discovered during research. The mockup is therefore an alignment artifact between research and implementation.

It is not shipped software. It does not establish that the buttons are wired to real services, that the experience works on every client, or that users prefer one version.

3. Make the design experimentally testable

The two button-copy variants create an A/B experiment. An A/B experiment compares alternatives against a defined outcome. Here, the alternatives are two calls to action on the pickup cards.

The logic is:

1. State a product hypothesis in a visible form.
2. Create two plausible versions of the interaction.
3. Define an outcome that can distinguish the versions.
4. Run the comparison later and inspect the evidence.

The mockups accomplish the first two steps. They do not supply the experiment result. A design can make a hypothesis testable without showing which hypothesis is correct.

This distinction matters for agentic development. An agent can quickly produce several coherent alternatives, but speed in producing alternatives does not remove the need to define an outcome or collect evidence.

At about 12:46, the walkthrough shows the side-by-side pickup variants.

4. Map the proposal onto existing code

Once the interaction is concrete, the team can ask how it fits the software that already exists. The walkthrough maps the design to affected iOS, Android, and Go repositories. The mapping connects the visual proposal to mobile client screens and routing-service capabilities.

This is more than a list of files. It is a bounded cross-repository implementation plan:

• identify which client experiences need a new screen or an adapted flow;
• identify which existing behavior can be reused;
• identify where a new service capability is needed; and
• preserve the relationship between the product requirement and each engineering change.

The code map reduces a common failure mode: treating a screen change as a frontend-only task when the user flow also depends on backend or routing behavior. It also prepares the next handoff. The following chapter starts coding from requirements, design, and this multi-repository map rather than from a bare request to “build the feature.”

At about 12:57, the walkthrough shows the affected repositories and the existing or new code surfaces.

Why the process becomes faster

The speakers say that this sequence compresses alignment that previously took weeks. The claimed advantage is not simply that an agent can draw a screen quickly. The faster path keeps connected context available across several roles and stages:

business research
      ↓
initial scope
      ↓
mockups and experiment variants
      ↓
frontend/backend code map
      ↓
prepared implementation handoff

Each step removes a different kind of ambiguity. Scope limits the first question. Mockups make the intended interaction discussable. Variants turn a preference into a testable hypothesis. The code map turns the design into a set of engineering surfaces.

That shared context is the main source of compression. Without it, a team may repeatedly restate the problem while moving from research to design and then from design to engineering. With it, the next participant can work from explicit artifacts.

What rapid prototyping does—and does not—mean

Rapid prototyping should not be read as “the feature is nearly done.” It means that the team can move quickly from an idea to a concrete proposal and an implementation plan.

At this point, several questions remain open:

• Will the proposed pickup experience work in the real clients?
• Can the routing capabilities support the intended flow?
• Which button copy performs better in the planned comparison?
• Will the changes pass later validation and review?

Those questions belong to later building and validation stages. The prototype and code map make those stages more focused; they do not replace them.

Takeaway

This chapter shows a middle layer between business research and code generation. A proposed North America scope defines the first boundary. Figma mockups make the interaction concrete. Two button-copy variants create an A/B hypothesis. A map across iOS, Android, and Go connects that design to existing frontend screens and backend capabilities.

Together, these artifacts give a coding agent a clearer starting point. They also preserve human decisions: the team still chooses the scope, defines what to measure, and decides whether the implementation is worth pursuing.

Source: Agentic SDLC at Uber — Uday Kiran Medisetty & Adam Huda, approximately 12:32–13:19.