Question 1

What kinds of projects do you take on?

Accepted Answer

Design systems work, accessibility programs, and AI-native product design and development. I prefer projects where I can lead from the keyboard — design and ship the thing — rather than write decks about it.

Question 2

What does a typical engagement look like?

Accepted Answer

Most start with a short discovery conversation, then a written proposal with a clear scope, milestones, and a fixed fee or weekly rate. From there I work async with weekly syncs, ship in small increments, and end with a hand-off doc your team can run with.

Question 3

How long do projects usually take?

Accepted Answer

Audits and assessments are typically 2–4 weeks. A design system build or accessibility program rollout is usually a 2–6 month engagement, depending on scope and how much of the work I am writing vs. enabling your team to write. I am happy to scope smaller, fixed-shape projects too.

Question 4

What does it cost?

Accepted Answer

I scope every engagement and quote a fixed fee or a weekly retainer based on the work. I do not publish rates because the range is too wide between a one-week audit and a multi-month system build — but I am direct about pricing once I understand what you actually need.

Question 5

Do you work remote?

Accepted Answer

Yes — I am based in the US Eastern timezone and work remote by default. I am happy to travel for kickoffs or workshops when it makes sense.

Question 6

How do we get started?

Accepted Answer

Send me a note on the contact page with what you are working on and what you wish was better. I will reply within a day or two with a few clarifying questions or, if it is a fit, propose a short discovery call.

Question 7

Do I actually need a design system?

Accepted Answer

Probably yes if you have more than one product surface, more than a handful of designers and engineers, or you are spending real time arguing about the same component twice. But "design system" can mean anything from a few tokens to a full multi-brand library — the right answer is whatever makes your team faster, not whatever the biggest company in your space has.

Question 8

We have one already. What would you bring?

Accepted Answer

Usually one of three things: an honest audit of what is actually being used vs. what was built, a tighter token architecture so themes and dark mode stop being a special project, or a governance and contribution model so the system survives the original team moving on. I work with whatever you have rather than rebuilding from scratch.

Question 9

Do you work on tokens, components, or both?

Accepted Answer

Both, and I have a strong opinion that they need to be designed together. Tokens without a component layer become rules nobody follows. Components without a real token layer become a styling shortcut, not a system. The interesting work is at the seam.

Question 10

How do you handle adoption and governance?

Accepted Answer

Adoption is a product problem, not a marketing one. I document what the system covers (and what it deliberately does not), set up a contribution path that does not require permission for the small stuff, and instrument adoption so we can see what is actually being consumed. Governance follows from that data, not from a steering committee.

Question 11

Can you work with our existing Figma and codebase?

Accepted Answer

Yes. I work in Figma and TypeScript every day — React + Vite + CSS Modules + Radix is my default stack, but I have shipped against most modern frontends. Figma libraries, Code Connect, and a tight Figma-to-code workflow are part of the work, not separate from it.

Question 12

What does an accessibility audit cover?

Accepted Answer

A structured pass across the surfaces you care about — typically keyboard navigation, screen reader behavior, color and contrast, focus management, semantics, and motion. I deliver a written report with prioritized findings (blocker / serious / moderate / minor), reproducible steps, and concrete fixes — not a wall of WCAG citations.

Question 13

Do you do remediation, or just identify issues?

Accepted Answer

Both. I can hand over a report and let your team fix things, or I can stay on and ship the fixes — often that means writing code in your repo or in your design system. Remediation moves much faster when the auditor and the implementer are the same person.

Question 14

Which WCAG level do you target — AA or AAA?

Accepted Answer

AA is the practical baseline for most products and the right default. I will design for AAA where it matters — typically text contrast, focus visibility, and motion sensitivity — but treating AAA as a global target usually buys less than the effort it costs.

Question 15

How do you handle accessibility on legacy products?

Accepted Answer

Triage first, then a phased rollout. Legacy products almost always have systemic issues that no single PR can resolve, so I focus on the high-impact, high-traffic flows first, fix them properly, and use those wins to justify deeper structural work later. Trying to fix everything at once usually fixes nothing.

Question 16

Can you train our team?

Accepted Answer

Yes — workshops for designers, engineers, or both. I prefer training that is tied to your actual product and your actual design system rather than generic WCAG slides, so the team leaves with patterns they can use the next morning, not theory.

Question 17

What does "AI-native" actually mean in practice?

Accepted Answer

I use it to describe products and workflows where the model is a first-class collaborator, not a feature bolted on. That changes UI patterns (intent capture, streaming, recoverable mistakes), data model choices (context, memory, retrieval), and team shape (a smaller group can ship more, with better tooling). It is not about adding a chat icon to your product.

Question 18

Are you replacing designers and engineers with AI?

Accepted Answer

No. I am replacing the slow parts of design and engineering work — boilerplate code, repetitive specs, the gap between Figma and a working prototype — so the humans on the team can spend their time on the parts that actually require taste, judgment, and craft. The headcount math changes; the need for good design and good engineering does not.

Question 19

Do you build the AI itself, or design around existing models?

Accepted Answer

Almost always the latter. I design and build on top of frontier models — Claude, primarily — using their tool-use, file, and agent capabilities. Training a custom model is the right answer in a small number of cases; for most product work, the leverage is in context, evals, and good interaction design, not in the model weights.

Question 20

What does Claude bring to design systems work specifically?

Accepted Answer

A lot. I use Claude Code to refactor token architectures, generate and audit Figma–to-code mappings, write component documentation that engineers will actually read, and ship the boring parts of a system (changelogs, ADRs, migration guides) without losing the week. The point is not novelty — it is taking the parts of a design system that usually rot from lack of attention and giving them constant attention for free.

Question 21

What is a recent AI-native project you have shipped?

Accepted Answer

My personal site itself is one — built with Claude as a constant collaborator on architecture, component design, and content. I have also been building Cambium, an AI-native design and engineering agency, around the thesis that small teams plus great context plus AI equals work that used to need ten people.

Question 22

Where are you based?

Accepted Answer

The United States, US Eastern time. I work remote-first and travel when it helps.

Question 23

What is your day job?

Accepted Answer

Director of Design Systems at Spring Health, where I lead the team behind the Verdant design system, accessibility, and the design-engineering practice. The freelance and Cambium work I do outside of that is on nights and weekends and is scoped accordingly.

Question 24

What is Cambium?

Accepted Answer

An AI-native design and engineering agency I am building. The thesis: a small team with great context and AI tooling can do work that used to need ten people. It is early — I am taking selective freelance engagements under the Cambium banner while the studio takes shape.

Question 25

Do I work with you directly, or with Cambium?

Accepted Answer

Right now, you work with me directly. As Cambium grows, larger engagements may bring in a small bench of collaborators I trust — but I will be hands-on on every project I take, not just selling the work.

Question 26

How did you get into design systems?

Accepted Answer

Through years of being the designer who ended up rebuilding the same button for the fourth time on the fourth product. Systems became the only way I could keep my own work consistent across surfaces. The accessibility and AI-native work both grew out of that same instinct — find the underlying structure, then make it serve people.

Question 27

Are you open to full-time roles?

Accepted Answer

Not actively. I am happy in my role at Spring Health and committed to building Cambium on the side. I will read a thoughtful note about a genuinely unusual opportunity, but I am not in market.

Question 28

What kind of role would interest you?

Accepted Answer

A senior leadership role focused on design systems, accessibility, or AI-native product work — somewhere I would be designing and shipping, not just running a team. Companies that take craft and access seriously, and that treat AI as a tool for leverage rather than a marketing line.

Question 29

Are you open to contract or advisory work?

Accepted Answer

Yes — that is what Cambium and the freelance work are for. The contact form is the right place to start.

Question 30

How can I reach you?

Accepted Answer

The contact page. Please include the role, the company, and one or two sentences on why you think it is a fit — anything generic will not get a response.

Frequently asked questions

Working together

Design Systems

Accessibility

AI-Native Workflows

About Greg

For recruiters