Designing Umbraco with Umbraco: building a backoffice design system in Claude Design

That's exactly what Claude Design lets you do. Below is the workflow we've been using to generate a backoffice design system. Use this to mock up real editing experiences from a live website or to prototype entirely new backoffice sections - all to look like Umbraco, all in a fraction of the time it takes to spec these things by hand.

Why build the design system first

You could skip straight to prompting for mockups based on backoffice screenshots. 

Don't. 

A one-off mockup is a throwaway; a design system is an asset you reuse for every mockup and every prototype after it.

When Claude Design has a proper design system loaded, everything it generates inherits the same tokens, the same components, and the same look and feel. Your fifth mockup looks like your first. Your new-section prototype looks like it was always part of the product. That consistency is the whole point.

Step 1–6: setting it up

The setup screen ("Set up your design system") is simple. Here's how we filled it in.

1. Name it. We called ours Umbraco backoffice Design System and gave it a one-line blurb: supports the creation of content mockups and prototype Umbraco extensions. This isn't cosmetic, the blurb becomes product context the agent reads before it generates anything.

2. Point it at a fork of the UUI library. This is important. Under Link code from GitHub I connected my own personal fork of the UUI Library, not the upstream repo. It has to be a fork you own, because connecting a repo installs the Claude GitHub app on it to grant read access, and you can only install an app on repositories you control. So: fork umbraco/Umbraco.UI to your own account first, then connect the fork.

3. Upload backoffice screenshots. Under Add fonts, logos and assets we dropped in a folder of PNGs of the real backoffice; content editors, trees, tabs, the section bar. The repo gives the agent the code for the components; the screenshots give it the composition, how those components actually sit together on screen.

4. Upload the font. The backoffice uses Lato, so we added the Lato font family here too. Without it the agent guesses at a fallback and the specimen never quite matches; with it, the type is pixel-correct from the first render.

5. Add pointers. The Any other notes? box is where you steer the agent toward the components that matter. Ours listed them explicitly - badges, tags and avatars; buttons; box cards (UuiBox + UuiPropertyLayout, the property-group card used in editors); inputs, toggles and checkboxes; menu lists; content-tree rows with caret and selection; horizontal section navigation; and the workspace tab bar with its underlined active indicator and count badges. The more precise your pointers, the less the agent has to infer.

Here is the full text we used:

—-------

Create a design system that supports the creation of Umbraco backoffice prototypes. It should support:

- Creating mockups of content editing experiences 

- Creating mockups of Umbraco extensions, any extension to Umbraco, including sections and dashboards

Components

Here is a series of components that you should create individually. Together they describe how the backoffice is structured:

- Badges and alerts — badges · tags · avatars

- Buttons — button looks & colors

- Box cards — UuiBox + UuiPropertyLayout: the property-group card used in editors. Fill 100%

- Inputs — text input with slots · on/off toggle · checkbox

- Menu lists — standalone vertical menu for section / settings navigation, with active selection

- Navigation (tree menus) — backoffice content-tree rows with caret, icon & selection

- Navigation (section navigation) — horizontal primary navigation

- Tabs — workspace tab bar with underlined active indicator, icons & count badges

- Reporting tables — collection / report data table with selection, status tags & clickable rows

Overview components

I have uploaded a series of screenshots that show how the backoffice is built. Build one component that recreates this in code as an example.

—-------

6. Generate. Then it goes to work.

What you get back

The agent plans the build openly; explore the screenshots, fonts and repo; write a readme with product context; set up Lato plus the token CSS; build the foundation specimens; copy the icons and assets; build the components; assemble a backoffice UI kit;

A few minutes later you have a full design system:

• Foundation tokens — brand, surface and semantic colours; the Lato type scale; a 3px-based spacing scale (space-1 through space-6 and a layout-3); elevation depths 1–5; and radii (square, 6, 9, 15px, plus a 50% avatar).

• ~18 components rendered as interactive specimen cards — badges, buttons, box/property layouts, inputs, menu lists, section navigation, the reporting table, workspace tabs, and the content tree.

• A backoffice UI kit — an interactive recreation of the content editor and collection views, so you're not starting from a blank canvas.

• readme.md and SKILL.md — the documentation and the machine-readable manifest that let the agent (and your teammates) understand the system and build on it consistently.

That last file matters more than it looks. SKILL.md is what makes the system reusable rather than a static style guide — it's the instruction set the agent leans on every time you generate something new.

From a website to an editing experience

Here's where it gets fun. Start a new design, choose Start with context, and select the design system you just built. Now every prompt is grounded in Umbraco's design language.

We asked it to build the content editing experience for a hotel site — Hôtel Salinas. 

What came back was the backoffice behind that public page: the Rooms & Suites tree with the Marais Suite selected, workspace tabs mapping the page's content model (Content, Gallery, Details, SEO), Hero and About-the-room field groups, a Published badge, breadcrumb, and the Save / Save and preview / Save and publish footer. 

This is faithful down to the navy bar and the coral active-tab underline — because it's all drawn from the system's own tokens and components.

Screenshot of a public website → a plausible, on-brand editor experience for the content behind it. That's a conversation starter that you can put in front of a client in a couple of hours instead of a couple of days.

Iterating with Mark up

It won’t be perfect the first time, and it doesn’t have to be. Claude Design's Mark up mode lets you click an element on the canvas, leave a comment, and send it straight to the agent. "these inputs all need to be 100% width," and it makes the targeted change without you re-describing the whole screen. It's the same tight, iterative loop you'd want from a design review, just with the agent doing the edits.

Prototyping a whole new extension

The final step is the one that got us most excited. With the design system doing the heavy lifting on look and feel, you can prototype a section of the backoffice that doesn't exist yet.

We asked for a booking-agent extension to manage the hotel's integrations, and got back a complete Bookings section: its own entry in the section bar, a sub-navigation, and a Channels & integrations workspace with Connected, Marketplace and Activity log tabs. Each service has a status card and a synced activity feed (Stripe, Booking.com, Airbnb and others), plus a slide-over drawer for connection and room-mapping settings.

It looks like it shipped with Umbraco, because it's built from the same system as everything else.

An honest note on what this is

What Claude Design produces is a high-fidelity, interactive prototype — on-brand HTML/React that looks and behaves like the real backoffice. It is not a compiled Umbraco package you drop into App_Plugins and ship. The booking-agent "extension" is a faithful mock-up of one, not a running integration.

You get to a convincing, clickable artefact fast, validate it with stakeholders, and then take it further: iterate in Claude Design until it does what you need, export it as a React project, and hand that definition to Claude Code with the Umbraco backoffice skills added to build a prototype of the real extension against the UUI components, Management API and backoffice APIs. There's still real work there, but you're building toward a target everyone has already agreed on, from a spec precise enough for an agent to run with, instead of being stuck arguing over wireframes. The possibilities are pretty much endless.

Try it yourself

If you work with Umbraco, the setup cost is genuinely low: fork the UI Library, grab a handful of backoffice screenshots and the Lato font, write a few honest pointers (or use the ones suggested here), and generate. Once the design system exists, simple mockups and quick explorations are a prompt away; give it a bit more specification or definition, and you get a compelling output that fits your requirements. 

And it all looks like Umbraco, because it's built from Umbraco. 

That's only possible because the Umbraco UI Library is open source: the assets we create and share are what let anyone fork them, hand them to tools like this, and build something new on top. Open ecosystems don't just document a design language, they hand you the pieces to build on top of it.

If you want to dive deeper into Umbraco in AI, we have two recommendations for you:

• Watch my Codegarden talk, “Umbraco in AI,” where I will walk you through the latest possibilities with Umbraco as an agent-friendly CMS
  

• Get started by checking out the official documentation on Umbraco in AI