Case study · Team enablement · AI prototyping

Code-ready prototyping

Sangoma UI is the component library our customer-facing products are built with. As lead designer on this project, and a contributor to the library's front-end code, I set it up so every designer on the team could prototype in Claude with the same components developers ship, and hand off code-ready designs. I proved it on a real feature, then ran a hands-on workshop to roll it out to the design team.

Role Lead designerAlso Front-end contributor to the libraryLibrary Sangoma UI, in production useWorkshop 1 hour, 3 designers and 1 developer

The problem

Our customer-facing products are built by much larger development teams, on a React library that supports theming and is shared across independently deployed apps. Designers, though, worked outside it: they prototyped in Figma, and each screen was rebuilt by hand in code.

With several designers and several teams, the cost added up. Library gaps surfaced late, often in QA, and every handoff needed someone to explain states and behaviour the mockup couldn't show.

The goal: put the production library into every designer's process, so the whole team hands off code-ready designs instead of pictures.

Why I led it

I'd already taken our admin platform from mockups to code: I built its component library and prototyped every feature on it with a small engineering team (Mockups to code). I also contribute to Sangoma UI itself and review developers' components against the design specs, so I know how it's composed, how props and tokens drive styling, and where its limits are.

The next step was scaling that way of working from one designer to the whole team. That meant setting the library up in Claude the way developers actually use it, and teaching other designers to design within it.

What I did

I used Claude to turn the production component library into a design system the team could prototype with. Because I knew the codebase, I designed the approach and the rules myself, and tested it before anyone else used it.

1
Started from the code.
The same components, props, tokens and Storybook stories developers use, at our current release.
2
Packaged it as a design system.
41 components with live previews, the tokens, and a check that catches props the library doesn't have.
3
Wrote the rules.
Use library components only. Anything the library can't do is flagged as an override, never quietly invented.
4
Built in the handoff export.
I added scripts to the design system so that when anyone, designer or developer, prompts export for development, Claude generates the full handoff package automatically: the working prototype, markdown docs, and TSX files with development-ready code.
5
Tested it.
Compared rendering against our Storybook and rebuilt real modals from Figma before sharing it.
6
Shared it.
Published it in Claude for the team to pick when they start a new design.

Proving it on a real feature: New fax

To show it worked, I took our New fax modal from a Figma frame to a working prototype in six short prompts. Three of them:

1Recreate the frame

Using the Sangoma UI design system, recreate this Figma frame as a design. Use only library components. Before building, list how each element maps to a component and anything that has no library equivalent.

Asking for the gaps first means I decide them, not the AI.

3Add the behaviour

Make it interactive: a recipient becomes a chip when I type a comma, and invalid numbers show an error. Preview fax is enabled only when a file is attached. Message is limited to 150 characters with a counter. Send fax shows "Sending" for 2 seconds, then closes and resets.

Behaviour is written as plain rules, the same way I'd write acceptance criteria.

6Hand off

Export for development.

One prompt. The scripts built into the design system generate the whole handoff package.

The handoff package, generated automatically

Prototype: clickable, opens in any browser with no setup.
TSX: development-ready React code built on Sangoma UI, using the same components and props developers already work with.
Markdown: a one-page handoff listing the files, library version, 8 overrides, behaviour and icons.
Assets: every icon as an SVG file.

The exported New fax prototype: each prompt, the behaviour rules it added, and the handoff package.

Rolling it out: the workshop

As lead designer, I ran a 1-hour session for the other designers on the team and the front-end developer who owns the library, and kept most of it hands-on. My front-end experience let me explain why the library works the way it does, not just how to prompt it.

0–5 min	Sangoma UI development library. Components and tokens explained using Storybook.
5–15 min	The library in Claude. What it is and how to pick it.
15–25 min	How to use it. The design process from Figma, a screenshot or a prompt to the handoff package.
25–35 min	Live demo. New fax, prompt by prompt.
35–55 min	Hands-on. Each designer tested the Claude library live, with Q&A.
55–60 min	Why it matters. What changes for customer-facing work.
Take-home	Build a prototype using this method. To be discussed in a follow-up session.

Result

Adoption: 3 designers and 1 front-end developer took part. New features are now prototyped this way, and work on optimizing the handoff process is in progress.
Handoff in one prompt: Export for development produces the prototype, markdown docs, TSX code and icons, with no manual handoff prep. Our front-end developer provided feedback on how to better structure the deliverables.
Earlier gaps: Library gaps now come up during design as a list of overrides, not as surprises in QA. Edge cases are caught and addressed from the start.
Designs within the library: Designers now build with the same 41 components developers ship, so a design can no longer assume something the library can't do.

What I learned

Hands-on mattered more than the demo. People bought in once they had built their own screen.

One change per prompt gives far more reliable results.
Asking for the states explicitly (errors, empty, loading) is what makes a prototype reviewable.
Calling overrides out by name turned library gaps into a design system conversation instead of a workaround.

Back home

Case study · Team enablement · AI prototyping

Code-ready prototyping

Role Lead designerAlso Front-end contributor to the libraryLibrary Sangoma UI, in production useWorkshop 1 hour, 3 designers and 1 developer

The problem

With several designers and several teams, the cost added up. Library gaps surfaced late, often in QA, and every handoff needed someone to explain states and behaviour the mockup couldn't show.

The goal: put the production library into every designer's process, so the whole team hands off code-ready designs instead of pictures.

Why I led it

What I did

1
Started from the code.
The same components, props, tokens and Storybook stories developers use, at our current release.
2
Packaged it as a design system.
41 components with live previews, the tokens, and a check that catches props the library doesn't have.
3
Wrote the rules.
Use library components only. Anything the library can't do is flagged as an override, never quietly invented.
4
Built in the handoff export.
I added scripts to the design system so that when anyone, designer or developer, prompts export for development, Claude generates the full handoff package automatically: the working prototype, markdown docs, and TSX files with development-ready code.
5
Tested it.
Compared rendering against our Storybook and rebuilt real modals from Figma before sharing it.
6
Shared it.
Published it in Claude for the team to pick when they start a new design.

Proving it on a real feature: New fax

To show it worked, I took our New fax modal from a Figma frame to a working prototype in six short prompts. Three of them:

1Recreate the frame

Using the Sangoma UI design system, recreate this Figma frame as a design. Use only library components. Before building, list how each element maps to a component and anything that has no library equivalent.

Asking for the gaps first means I decide them, not the AI.

3Add the behaviour

Make it interactive: a recipient becomes a chip when I type a comma, and invalid numbers show an error. Preview fax is enabled only when a file is attached. Message is limited to 150 characters with a counter. Send fax shows "Sending" for 2 seconds, then closes and resets.

Behaviour is written as plain rules, the same way I'd write acceptance criteria.

6Hand off

Export for development.

One prompt. The scripts built into the design system generate the whole handoff package.

The handoff package, generated automatically

Prototype: clickable, opens in any browser with no setup.
TSX: development-ready React code built on Sangoma UI, using the same components and props developers already work with.
Markdown: a one-page handoff listing the files, library version, 8 overrides, behaviour and icons.
Assets: every icon as an SVG file.

The exported New fax prototype: each prompt, the behaviour rules it added, and the handoff package.

Rolling it out: the workshop

0–5 min	Sangoma UI development library. Components and tokens explained using Storybook.
5–15 min	The library in Claude. What it is and how to pick it.
15–25 min	How to use it. The design process from Figma, a screenshot or a prompt to the handoff package.
25–35 min	Live demo. New fax, prompt by prompt.
35–55 min	Hands-on. Each designer tested the Claude library live, with Q&A.
55–60 min	Why it matters. What changes for customer-facing work.
Take-home	Build a prototype using this method. To be discussed in a follow-up session.

Result

Adoption: 3 designers and 1 front-end developer took part. New features are now prototyped this way, and work on optimizing the handoff process is in progress.
Handoff in one prompt: Export for development produces the prototype, markdown docs, TSX code and icons, with no manual handoff prep. Our front-end developer provided feedback on how to better structure the deliverables.
Earlier gaps: Library gaps now come up during design as a list of overrides, not as surprises in QA. Edge cases are caught and addressed from the start.
Designs within the library: Designers now build with the same 41 components developers ship, so a design can no longer assume something the library can't do.

What I learned

Hands-on mattered more than the demo. People bought in once they had built their own screen.

One change per prompt gives far more reliable results.
Asking for the states explicitly (errors, empty, loading) is what makes a prototype reviewable.
Calling overrides out by name turned library gaps into a design system conversation instead of a workaround.

Back home

Case study · Team enablement · AI prototyping

Code-ready prototyping

Role Lead designerAlso Front-end contributor to the libraryLibrary Sangoma UI, in production useWorkshop 1 hour, 3 designers and 1 developer

The problem

With several designers and several teams, the cost added up. Library gaps surfaced late, often in QA, and every handoff needed someone to explain states and behaviour the mockup couldn't show.

The goal: put the production library into every designer's process, so the whole team hands off code-ready designs instead of pictures.

Why I led it

What I did

1
Started from the code.
The same components, props, tokens and Storybook stories developers use, at our current release.
2
Packaged it as a design system.
41 components with live previews, the tokens, and a check that catches props the library doesn't have.
3
Wrote the rules.
Use library components only. Anything the library can't do is flagged as an override, never quietly invented.
4
Built in the handoff export.
I added scripts to the design system so that when anyone, designer or developer, prompts export for development, Claude generates the full handoff package automatically: the working prototype, markdown docs, and TSX files with development-ready code.
5
Tested it.
Compared rendering against our Storybook and rebuilt real modals from Figma before sharing it.
6
Shared it.
Published it in Claude for the team to pick when they start a new design.

Proving it on a real feature: New fax

To show it worked, I took our New fax modal from a Figma frame to a working prototype in six short prompts. Three of them:

1Recreate the frame

Using the Sangoma UI design system, recreate this Figma frame as a design. Use only library components. Before building, list how each element maps to a component and anything that has no library equivalent.

Asking for the gaps first means I decide them, not the AI.

3Add the behaviour

Make it interactive: a recipient becomes a chip when I type a comma, and invalid numbers show an error. Preview fax is enabled only when a file is attached. Message is limited to 150 characters with a counter. Send fax shows "Sending" for 2 seconds, then closes and resets.

Behaviour is written as plain rules, the same way I'd write acceptance criteria.

6Hand off

Export for development.

One prompt. The scripts built into the design system generate the whole handoff package.

The handoff package, generated automatically

Prototype: clickable, opens in any browser with no setup.
TSX: development-ready React code built on Sangoma UI, using the same components and props developers already work with.
Markdown: a one-page handoff listing the files, library version, 8 overrides, behaviour and icons.
Assets: every icon as an SVG file.

The exported New fax prototype: each prompt, the behaviour rules it added, and the handoff package.

Rolling it out: the workshop

0–5 min	Sangoma UI development library. Components and tokens explained using Storybook.
5–15 min	The library in Claude. What it is and how to pick it.
15–25 min	How to use it. The design process from Figma, a screenshot or a prompt to the handoff package.
25–35 min	Live demo. New fax, prompt by prompt.
35–55 min	Hands-on. Each designer tested the Claude library live, with Q&A.
55–60 min	Why it matters. What changes for customer-facing work.
Take-home	Build a prototype using this method. To be discussed in a follow-up session.

Result

Adoption: 3 designers and 1 front-end developer took part. New features are now prototyped this way, and work on optimizing the handoff process is in progress.
Handoff in one prompt: Export for development produces the prototype, markdown docs, TSX code and icons, with no manual handoff prep. Our front-end developer provided feedback on how to better structure the deliverables.
Earlier gaps: Library gaps now come up during design as a list of overrides, not as surprises in QA. Edge cases are caught and addressed from the start.
Designs within the library: Designers now build with the same 41 components developers ship, so a design can no longer assume something the library can't do.

What I learned

Hands-on mattered more than the demo. People bought in once they had built their own screen.

One change per prompt gives far more reliable results.
Asking for the states explicitly (errors, empty, loading) is what makes a prototype reviewable.
Calling overrides out by name turned library gaps into a design system conversation instead of a workaround.