The process

I joined Fugro in 2025. We haven’t opened Figma once, and no single method replaced it. In one year I designed five different ways, and each one shipped something. The method follows the question, not the other way round.

A shell of the product

Hi-fi React mockups of the platform, served as static files, with no data restrictions. Anyone in the company can open it, use it, and open a pull request against it.

Walkthroughs replace PRDs. A feature is a sequence of screens with annotations and a status per step, and a step can exist as a placeholder before any screen does. PRDs were never read. Walkthroughs are, because they look like the product.

This is where most work starts, and it later became Dry Run.

Canvases for early exploration

Claude Design canvases when the question is still what is this, not how does this work. Cheap to throw away, which is the point. Nothing on a canvas is a commitment, so nobody defends one.

Straight in the production codebase

When the platform’s own components already answer most of the question, I design in the real branch and open the pull request myself. The code review is the design review.

Real branches have data constraints and permission walls, so this is the wrong place to explore. It is the right place to finish.

Pencil sketches into Claude Code

The fastest brief I ever gave a model was a photo of a drawing. Structure on paper, intent in the margins, a working layout back in the product’s own design language.

Good enough that I kept doing it, then got tired of the photo step and built Inkframe to remove it.

Engineers designing in the same loop

I coach engineers to brief a model, review what it produces, and know when to stop. Then I review their work.

This is the one that scales. The bottleneck stops being me.

The road to production

Whatever the starting point, a design takes the same six steps to a merged pull request. The last two are the ones a mockup tool never had.

Brief. Business goal first, then the constraint that makes this one hard. A sketch, a voice note, or a walkthrough step. Never a pixel-perfect spec. The brief is short because the model will fill in everything I leave out, and I want to see what it fills in.

Generate. The model drafts against the product’s own components and tokens. It never invents a button.

Review. I read what it made the way I would read a junior designer’s work. Does it answer the goal. What did it add that nobody asked for. What is it hiding. Most of the design happens here, in what gets cut.

Rebuild. A design leaving the shell is rebuilt against the platform’s own primitives, never pasted in. Mockups are specs, not pictures.

Pull request. I open it, or an engineer does. Either way the diff is the handover. There is no handover step.

Audit. An AI heuristic UX pass reads every pull request first. I check its findings and spot-check the rest. The feedback loop is minutes, not days.

What it is worth

The number the business watches: project deliveries that run through platform processing went from eight weeks to a week and a half.

Delivery	Weeks
Before	8
After	1.5

The rest of the story, with the decisions behind it, is in the GroundIQ case study.

The rules

Short enough to say out loud in a review. Every one of them was learned by doing the opposite first.

• Business goals first. Pixels last.
• Mockups are specs, not pictures.
• Rebuild against the primitives. Never paste.
• Explore freely. Promote what repeats.
• Review on the way, not in the way.
• When everything can be built, the discipline is restraint.
• Write down why you moved.
• Nothing is set in stone. The method moves with the models.
• Collaboration and flexibility outlast any method.