Process
prototype

First prototyping Experiments

I have experimented with Claude Code and Figma MCP to find a quick and precise way to make clickable prototypes in code from my design files.

  • prototyping
  • Claude Code
  • Figma MCP
  • process

I wanted to see how far a single prompt could get me, using different methods of translating design in to code. I did several quick experiments, which was an effective way of testing out new tools, and finding a workflow that worked for my needs.

All sketches shown here were built on an interface from Orkla Foods Norway. See the original case here.

First test: Figma MCP in Claude

In my first experiment I connected Claude to my design file the Figma MCP, and used this prompt in the regular Claude chat.

Prompt
implement this figma design file in to an HTML interactive file: https://www.figma.com/design/AO1IML8adicwZKtcn8za0s/Oppl%C3%A6ringsystem?node-id=469-57675

The result was a surprisingly accurate structure, but loss in the details. Even though it looks similar to OpenBridge, it is clear that it has not used the real components and icons. I also think I gave Claude too many frames in one go, that might have made the intended flow unclear.

First test: built from the Figma file in the Claude chatOpen full size

Second test: Claude Code with the code library installed

This time I asked Claude Code to build a prototype inside my existing documentation website. This gave it a proper framework to build in. In addition I installed the OpenBridge component library before prompting, so that Claude had access to the official OpenBridge components. I still used the Figma MCP to allow it to access my design file, but this time I pointed it at the training menu rather than the whole application. I used this prompt:

Prompt
Make an interaktive prototype from this figma design file: https://www.figma.com/design/wtiTkELWhsKULC69463BkK/Prototyping?node-id=46-14474 this is the menu to navigate between different training modes. Use openbridge components for everything possible. For icons that are not on the OpenBridge library, you can probably find them in googles material icons.

The result was a lot better than the first attempt. It used the actual OpenBridge components and icons, and downloaded the icons and illustrations from my Figma file as SVG. The biggest area of improval is the custom components I have built for training. These need some more work.

Second test: built with Claude Code and the OpenBridge componentsOpen full size

Third test: Building custom components

To improve the custom components I tried feeding Claude only the new component, to see if it would be able to implement it in code when given only that task.

Prompt
This is a custom version of the rich button from OpenBrigde. Translate the design to a clickable button in Code: https://www.figma.com/design/wtiTkELWhsKULC69463BkK/Prototyping?node-id=54-26283 Use OpenBridge tokens wherever possible.

It did so very smoothly, and even added it in to the flow, even though I only asked for the button itself.

Third test: the custom rich button, in place on the overview screenOpen full size

Fourth test: How big can the prompt be?

To challenge Claude further, I gave it another prompt, where I asked it to add both the main interface and one of the training sequences:

Prompt
Make a new iteration of the prototype, adding the main interface and the getting started - topping run-through of the application. here is the figma design file: https://www.figma.com/design/wtiTkELWhsKULC69463BkK/Prototyping?node-id=60-17150 The app menu should have an autohide behavior, only appearing when the cursor is moved to a screen edge. The stepper menu in the topping run through should only show when the training menu is clicked. When in the topping run-through the cursor should have the teal 300 as fill color.

This task was a lot heavier than the previous ones, taking Claude about 20 minutes to build. The result was okay, but had more issues than the previous ones, something that tells me it would probably be more effective to give it less tasks at a time. I also see that frames with several custom components should probably be built even slower, in order to give enough description for the things that need building from scratch. Still, it is a great improvement from the first test!

Fourth test: the monitoring screen with the Topping run-throughOpen full size