Craft is time on stone

In the first post in this series, I wrote that taste is trained judgment. Taste helps us see the gap between something that works and something that is good.

Craft is what happens when we stay with that gap.

The investigation workflow from the first post began as an engineer-led project that AI had helped take from zero to one. Every step, from creating the workflow to viewing it, lived on a single route. You could complete the job, and the team had a working demo.

Functionally, it was all there.

Then I used it in a browser window.

The creation flow, long forms, and final view were all competing for the same space. Major forms lived inside dialogs. The main view asked someone to hold so much information at once that understanding what mattered became work of its own.

The workflow worked, but it wasn’t resolved.

I moved the large creation form onto its own focused route and gave it a proper flow. I added the labels the fields needed. I removed illustrative and decorative icons that weren’t helping anyone understand the interface. Some actions that had been presented as manual steps became automatic because the product already knew enough to do the work.

None of that changed the fundamental capability. It changed how clearly someone could use it.

Craft isn’t polish

Polish makes it sound like the workflow was already shaped and I came along to make it nicer. That isn’t what happened.

Moving the form changed the information architecture. Adding labels changed whether someone could understand and navigate it. Automating unnecessary actions changed the workflow itself. Removing decoration gave the important information room to do its job.

Those are product decisions, not finishing touches.

This is the distinction I care about when I say something needs craft. The question isn’t whether the spacing could be tighter or the interface could feel more designed. The question is whether the thing is shaped correctly in the first place.

• Does the hierarchy match the decision the user is trying to make?
• Does this step need to exist, or can the product do the work?
• Does the interface still hold together with real data, long labels, failures, loading states, and awkward edge cases?
• If we remove this element, what actually gets worse?

Craft begins with something concrete enough to inspect and change. A working implementation gives us that material. It doesn’t mean the work is over. It means we can finally see the work.

Subtraction is harder than addition

Dieter Rams gave designers a useful principle: “less, but better”. His tenth principle expands the idea:

Good design is as little design as possible.

The through line is restraint. Restraint is care under pressure. It’s the ability to look at something that could have more and decide it shouldn’t.¹

More cards, more badges, more counting, more icons, more gradients, more shadow, more helper text. More custom components when a better battle-hardened version already exists in the blessed component library. This is ornament, just in React and Tailwind.

AI is very good at more. Adding gives us something visible to point at, which can feel like progress. Subtraction is harder because it forces us to decide what the product is really trying to help someone do.

In the workflow, removing decorative icons was the easy part. The harder subtraction was recognizing that creation didn’t belong beside every other step, and that some of the manual actions didn’t need to exist at all.

That kind of subtraction isn’t about making an interface sparse. It’s about removing competition, ceremony, and work until the important thing has enough room to be understood.

The useful question isn’t simply, “Can we remove this?” It is, “What gets worse if we do?” If the answer is nothing, the element probably hasn’t earned its place.

Subtraction still needs judgment. Remove things indiscriminately and the result isn’t clear. It’s just empty.

Taste gives restraint a direction. It helps us decide what matters enough to remain. Craft is how we protect that thing while working through the constraints of the real product.

We’re all working on the same block

The metaphor I keep coming back to is a Renaissance sculpture studio. In some studios, the master made a wax model and specialists carved the marble to match it. The design was fixed. The execution followed.

That isn’t how modern product work feels to me, especially with AI in the loop. There usually is no perfect model that contains every behavior, state, edge case, and interaction detail. There’s the thing itself, partly formed, being shaped by people with different specialties.

I think of an engineer-led implementation as a rough-out. It establishes the broad shape, proves the technical path, and gives us something real to use. AI helps us get to that material faster.

You can see the shape. You can see where it’s going. But nobody mistakes a rough-out for the finished work.

The rough-out makes different kinds of work visible. It can satisfy the ticket while still missing the product. Craft is the part where we refuse to let “it exists” become the same thing as “it’s done.”

I don’t use Figma for this work. I work in the codebase itself. The engineers rough in the functionality, then I take out the finer tools and work through the hierarchy, interaction, accessibility, and details that make the workflow feel resolved.

We’re all standing around the same block of marble.

Time on stone is when we shape the real material together, inside the product and its constraints. This is where the rough-out becomes a product experience.

The component structure gets simpler. The spacing stops being arbitrary. The action moves to where the user expects it. The scary state gets clearer. The generated copy gets deleted. The empty state stops trying to be charming and starts being useful.

Small things, but not shallow things. Product quality rarely falls apart all at once. It drifts one decision at a time.

That is the part of craft I think AI makes more important, not less. When output gets faster, someone still has to stay with the material long enough to ask: what is this becoming?

Review is part of the craft

When an engineer-led rough-out reaches me, I don’t start by changing the frontend. I read the engineer’s architectural design documents first.

I need to understand why the feature was built that way, which constraints are real, and what I might be missing. If something isn’t clear, I ask the engineer before I start moving things around. I also reach out to stakeholders who actually use the workflow when I need to clarify my thinking along the way. That isn’t ceremony. It keeps me from resolving the wrong problem.

Then I work on the frontend design myself, in the codebase.

Review can sound like someone arrives at the end to approve or reject the work. This is closer to joining the work once the material is concrete enough to react to. The architecture, functionality, and interface are different parts of the same product. Changing one can reveal something about the others.

The workflow at the beginning of this post still did the same fundamental job after I worked through it. It just stopped asking the user to carry the shape of the implementation in their head.

That is what time on stone is for.

Craft is not decoration. Craft is the visible result of decisions made carefully enough to disappear.

Taste helps us see what matters. Craft helps us remove what does not.

When the same craft decision keeps returning in review, it stops being only a review problem. It becomes a leverage opportunity.