The New Scratch Paper

The New Scratch Paper

AI + Design Process

I start design work in an LLM the way earlier designers reached for scratch paper. This is the workflow, told through Clara: a time-off manager that lives inside the messaging apps people already use, built as week one of my 52-tools-in-52-weeks project.

Role

Designer & Builder

Duration

January 2026 (one week)

Tools

Claude Code

Cursor

Figma

React

TypeScript

Python

FastAPI

Claude API

The new scratch paper

Somewhere around late 2023 I stopped starting design work in Figma. Not because Figma got worse, but because a working prototype became cheaper than a static one.

I describe a flow to Claude Code or Cursor, get an interface I can actually click, and find out in minutes whether the idea survives contact with reality. It is the new scratch paper: cheap enough to throw away, real enough to learn from.

By 2025 this had become my default. The reason is not speed for its own sake. It is that design earns its seat at the product discovery table by showing up with something concrete while the conversation is still happening.

That is the standard I am working toward, and the workflow I am now helping bring into my team’s process: listen to the pain point, sketch it as working software, and test the idea before the meeting ends.

Clara: designing for natural language

Clara came from a small, personal absurdity. Taking a day off meant logging into two separate platforms, even though I spend my whole working day in Slack and Teams.

PTO software costs companies one to three dollars per employee per month, and what it buys is an interface everyone leaves their actual work to go wrestle with.

So Clara lives where the request happens. You type “I need Thursday and Friday off” into the messaging app you already have open. Claude parses the intent and extracts the dates, and the system validates the request against company rules and vacation balances.

Then it routes. Eligible requests are approved automatically; everything else goes to a manager with the context needed to decide. Calendars update and the right people get notified without anyone touching a second system.

The interesting design problem is that a conversational interface has no visual guardrails. There are no date pickers to constrain input and no required fields to lean on. People phrase requests informally and expect to be understood.

Clara’s answer is to make its interpretation visible. Ambiguous requests come back as a plain question (“Just to confirm, you’d like Monday through Friday off?”), and every action ends with an explicit confirmation naming the dates and whether the request was auto-approved.

The parsing is invisible. The confirmation is the interface.

The first version also had exactly the kind of bug this class of interface invents. One commit message from that week reads: “made changes to ensure that clara responds where it was asked a question.”

In a GUI, the response appears where you clicked. In a conversational system, where to respond is a design decision you have to make on purpose.

Trust is the product

Deciding which requests skip a manager entirely is an organizational decision wearing a technical costume. So Clara makes it explicit and configurable: per-type thresholds that HR controls, not the model.

Clara's admin panel titled Auto-Approval Settings, showing per-request-type day thresholds. Requests within the limits are approved instantly; setting a type to zero requires manual approval.

When it came to deploying Clara internally, the real blocker surfaced fast, and it was not technical. Nobody wanted to own the risk of a system that is simultaneously a tech system and an HR system. It crosses two organizational boundaries at once, so it has no natural owner.

Building the tool is the easy part. Earning organizational trust to deploy it is the real work.

It runs on Python and FastAPI with a React front end and the Claude API, and costs about fifty dollars a month at scale. That is a rounding error next to the six to eighteen thousand dollars a year a 500-person company pays for traditional PTO software.

Where the LLM stops

Working this way has made me precise about what I do not delegate.

Two things get fixed by hand on almost every generated prototype: the copy, which is reliably almost-right in a way that reads as wrong, and design-system alignment, because generated components drift from the tokens and patterns the rest of the product uses.

And one thing never goes to the model at all. An LLM cannot do the task analysis that tells you how well a solution fits into the rest of the system: which adjacent workflows it touches, what it breaks, whether it belongs.

That judgment is still the designer’s job. It may be the clearest definition of the job we have left, and I think it is a good one.