Building UI: Design to Code

How to read these notes

This lesson is a design session that ends in code. Most of it goes on the part beginners skip: input, output, golden pairs, a verifier, and the reasoning behind one interface choice. The Gradio part is short on purpose. An FDE's first deliverable at a customer is usually a working interface in front of a real user, and this is how you work out which interface that should be.

01Before You Start: One Observation, One Real User

The prerequisite for this lesson is one observation, one hypothesis and a conversation with at least one real user. A single interview counts.

Two framing points come before any design. First, you are not married to one observation. Until you commit to one, the more observations you try and the more people you speak to, the better you get at testing your assumptions against the world. Second, that is the skill that matters now. When building becomes a commodity, finding the right users and solving their problem is the part AI cannot yet do. It is also most of an FDE's job: sitting with a customer and finding the process worth building around.

02Start From One Person, Not a Persona

The worked example is Aarav, your first customer: the business analyst at a mid-sized IT company in Pune, sitting at his desk with three tabs open, AI-aware and overwhelmed. The observation behind him: ambitious early career professionals in urban India arrive AI-aware and motivated, but fail at selection, scoping and first proof. They see AI at the category level (sales automation, HR tools, a productivity agent) and cannot turn it into one grounded workflow. Notice what the observation does not contain: a solution. An observation reports what you saw, from lived experience, and stops.

The hypothesis then states the assumption and how to test it: they are stuck because they lack a method to go from broad AI possibility to one scoped workflow. The test: provide a structured workflow diagnosis system followed by a guided build sprint, and 60% of active students will identify one real user, map one repeated workflow, build a working AI-assisted version and present a credible demo within 90 days. At 10 people, that is 6 of 10.

Then the move that shapes everything after it: do not solve for a category (marketers, cafe owners, doctors). Solve for one named person. Once it works for that one person, talk to more people like them. That is how the test base grows.

03The Cheapest Test Is Three Boxes on a Whiteboard

The hypothesis names two solutions: the diagnosis system (part one) and the build sprint (part two). Take only part one and ask for the cheapest way to test it with Aarav. The answer is three boxes on a whiteboard.

The input came from a message to Aarav: what is the one thing you repeat every day or every week, in 3 to 4 lines? Say he replies that he opens Jira, checks status, and emails his manager an update. That reply, compressed, is the input. The output is a plan for automating part of it. And the success test is not whether Aarav likes the plan. It is whether following it saves him time, say 1 hour a week. If it saves nothing, the impact is zero and the plan failed.

No code was written and no system was designed. Designing meant understanding what the user needs and the minimum solution that tests it. It does not mean opening Figma.

04A Second Observation, and the Stranger Test

Here is a second learner's observation, written for the same exercise: organizational project knowledge exists, but access depends on personal memory and network, so under deadline pressure people reuse the precedent they remember rather than the best fit, and nobody sees what was not found.

The format to write yours in: observation, North Star, hypothesis, user, input, output.

05Ten Golden Pairs Before One Line of Code

One input and one output is an example. It is not enough to build against. Write at least 10 to 20 pairs; for production it can be 100 to 200. Each pair is the exact text a real user would type and the output that would solve their problem, gathered by talking to real users. If you cannot talk to your users, do not move ahead. If you are the user, write them yourself and check them with people like you.

This is the golden dataset: ideal input and output pairs. The output you believe solves the user's problem, paired with its input, many times over. The same idea returns later in the roadmap, for evals and fine-tuning.

Recall the verifier game: how do you verify an app that adds two numbers? You write 1 + 2 = 3 and a few more, paste them in, and compare. Same output, it works. Different output, it does not. The golden dataset is what lets you decide whether your verifier will be deterministic, probabilistic or a human in the loop.

06The Verifier Is a Threshold, Worked in Minutes

Say the email step is Aarav's biggest time sink: 15 minutes a day by hand. Drag the slider to see when the plan passes the 1 hour a week bar.

With the plan it takes 5. That saves 10 minutes a day, and over a 5-day week, 50 minutes, close to the 1 hour threshold. The plan passes. Now say the plan cuts it only to 10 minutes. That saves 5 a day, 25 minutes a week, below the threshold. Same plan shape, same tool, and it fails.

The written verifier for Aarav's first golden pair asked for four things in the output: a metric with a baseline, the named bottleneck, a test on past input with known answers, and a list of what is out of scope.

07Test-Driven Development, Written in English

This is an old idea. Test-driven development (TDD) says write the test before the software; once the software passes your codified tests, you know it works. It is hard to keep up, which is why few people do. What changes now is only the language: most of the tests you write will be in English. The philosophy does not change.

Tie it back to the bigger picture: almost everyone uses AI, utilization sits under 20%, and the impact on real earnings is in single digits. Building without a verifier is how that gap stays wide.

The spec now reads: observation, North Star, hypothesis, user, golden dataset, verifiers. Mask anything proprietary (use percentages or X, Y, Z) but share it, because that is what makes feedback possible. The North Star sits slightly outside the spec and tells you if you are still pointed the right way.

08Two Systems, One Interface

Back to the core question. Two systems: Aarav, a human, and a workflow diagnosis plan generator that can run on a machine. What sits between them? A user interface. It needs a common language (English, text fields) and a set of rules (the web's HTTP). Aarav's prerequisites are a PC, a browser and an internet connection.

Golden pair 1 is concrete enough to design against:

From it: the input type is text and the output type is text. That has a useful side effect. If both ends are text, you can run a manual MVP before building anything: take Aarav's description on a call, write the plan yourself (with or without ChatGPT), send it as a document, and see if it saves him time.

09The Vote That Lost

Three candidate interfaces: a Google-style search box, a Google Form, and a chat. Before you read on, pick one yourself. When this lesson was run live, the room voted like this.

Now replay the golden output: a day-by-day build plan with time saved as the metric. Aarav reads it and asks:

How do you ask Google a follow-up? The room named the cost: Aarav would have to remember the plan, retype everything, and search again. The missing property: no memory, no context. And it does not look like a conversation. The majority choice fell to one question, and the golden output is what surfaced it.

Rule of thumb for now: around 90% of first problems fit one of these three.

Build the cheapest one first, and do not add anything until it is verified. That is the V0, or MVP.

10Vibe Code or First Principles: The Difference Is Control

Two routes to the same chat UI. Vibe code it: one prompt to Claude Code, Lovable, OpenAI or Gemini. Or write it from first principles in Python, with AI allowed, but understanding what every line does and why it is there. Both produce a working chat. The difference is control. Neither is declared the better one here. Your task is to do both and write a three-line review of what each gave you.

11Why Python, and Why Gradio

The web is HTML. Styling and scripting languages grew around it, and JavaScript came from that; Python was never part of web development. Until about 2021, this course taught UI in JavaScript, HTML and CSS, and the repeated feedback was that beginners had to learn three languages to ship one thing. In 2026, Python libraries bridge that gap, so one language covers this whole block.

This lesson's job is a chat that takes input and returns output, so Gradio.

12Four Lines That Are the Whiteboard

The Gradio Hello World takes a name and returns a greeting. Hover a line to see which box of the whiteboard it is.

Read it as the whiteboard. The function argument is the input. What follows return is the output. The function body is the process that turns one into the other, which here is almost nothing. gr.Interface is the interface from section 8: it declares the input type and the output type, the common language and the rules. fn just means function. This is the smiley exercise, solved: you cannot get someone to draw a smiley without a shared language and rules; Gradio gives you both for machines.

For chat, swap the interface. Gradio's own chat example just echoes you:

Same template: define the input, the output and the process, then hand the function to the interface. Later the process becomes a call to a model. For now, echo is enough.

One instruction repeated: learn Gradio from its documentation, not from an LLM. Asking Claude gets you an answer; reading the docs gets you the rabbit holes in the left rail (website widgets, Slack bots and more).

13Setting Up, and the Errors You Should Want

1. Install Python from the official site. Two or three steps for your operating system.
2. Install one IDE. Cursor or VS Code. An IDE is a notepad for code where you read and review before you push anything anywhere. VS Code is fully free; Cursor has a paid plan for its models.
3. Make a folder (for example 100x test on the desktop), open it in the IDE, create app.py and paste the Hello World.
4. Run pip install gradio, then python app.py, and open the local link it prints.

You will hit errors: Python not found, Gradio not installed. That is the point. Solving them yourself is the start of the debugging muscle. If def, return and functions are unfamiliar, finish the Python bigbinary prerequisite first; these lessons do not teach Python syntax. The build guide walks you through your errors, then deploys your app to a shareable link.

Step-by-step setup with tests for each tick: the build guide and the checklist.

14From the Q&A

15Vocabulary From This Lesson

16Action Block

• Write your spec on one pageObservation, North Star, hypothesis with a number, one named user, input, output.
• Write 10 golden pairs with a real userPlus one verifier with a baseline and a threshold.
• Replay one pair and write the follow-up your user will askPick search, form or chat from it.
• Get Hello World running locally in Gradio, then the chat echoKeep a list of every error you hit and how you fixed it.
• Build the chat twice and write the three-line reviewVibe coded and first principles.

Start from the output. The interface follows.Next: the practice set turns this into one real user, ten golden pairs and a chat on your machine.