Ask Me Anything
I'm Jacques. I work where design systems, code, and AI meet, building the platforms and practices that let teams ship good work at a sustainable pace.
The quickest way to get an answer is the chat in the bottom corner. It knows this whole site, including my projects, case studies, and writing, and will point you where to look. The questions below are a starting set while the chat becomes the main way to explore.
About Me
Who is Jacques Ramphal?
I work at the seam between design and engineering—designing systems, writing code, and lately, building with AI.
What distinguishes me isn’t a single skill. It’s that I hold the full stack: sketch a concept, build it in Figma, implement it in React, document it in Storybook. I care about quality at every layer.
Outside of work: a designer who thinks seriously about craft, sustainable pacing, and what it means to do good work without burning out.
What does Jacques work on?
My work lives in three overlapping areas:
- Design systems — I architect token-based systems for enterprise teams. The goal is always the same: make it easier to do the right thing than the wrong thing.
- Agentic AI — I led design on Genie, an internal orchestration platform at Orium that uses AI agents to automate routine work, surface risks, and consolidate context. That work forced me to think carefully about trust, transparency, and when automation helps vs. gets in the way.
- Design-to-development bridging — I pair with engineers on implementation, write production code myself, and run design QA operations to close the gap between design intent and what actually ships.
What does Jacques write about?
I write about the edges where design gets complicated:
- How AI changes the role of designers — When UX Becomes AX
- Why design tokens are an underrated organizational strategy — Design Tokens: A Shared Language That Outlasts the Tools
- What it looks like to find your niche without a map — Finding My Lane in a Year of Uncertainty
- The future of design as a set of tensions, not destinations — The Future of Design
- How strong quality baselines make QA less necessary — The Best QA Is the One That Doesn’t Have to Happen
I write to think clearly, not to perform authority.
What kind of work do you actually do day to day?
I lead design on projects where systems, code, and AI all have to line up.
That usually looks like:
- Architecting token-based design systems and component libraries for enterprise teams
- Pairing with engineers to make sure design decisions survive implementation
- Designing UX patterns for Genie, our AI/AX platform for agentic experiences
- Coaching designers who want to move closer to code or systems work
Most of my time is spent making sure the things we design are things we can reliably ship.
How would you describe your design philosophy?
I believe the future of digital products is systems + teams, not just screens.
Design systems are organizational infrastructure. Good systems:
- Reduce design-to-dev friction
- Make it easier to do the right thing than the wrong thing
- Give teams shared language for decisions
At the same time, I’m not interested in systems for their own sake. The point is to free people up—to spend less time on repetitive work and more time on novel problems, deeper discovery, and better decision-making.
Where does AI fit into your work?
Through Genie, I’m focused on agentic UX—how people collaborate with AI agents that can act on their behalf.
That work includes:
- Designing how capabilities are surfaced so people know what an agent can do
- Making reasoning and confidence visible so people know when to trust outputs
- Balancing autonomy and control so it’s always clear who’s in charge
I’m less interested in AI as a “wow” moment and more interested in how it quietly reshapes the work teams do every day.
How does code show up in your design practice?
I still write a fair amount of front-end code. That means:
- Building components in React/Vue that match the system exactly
- Prototyping interaction patterns directly in code when Figma isn’t enough
- Pairing with engineers on architecture decisions that affect UX
Coding keeps me honest. It’s hard to design impossible things when you regularly implement them.
How do you like to work with teams?
I try to make collaboration feel calm and clear rather than chaotic and reactive.
Practically, that looks like:
- Clear expectations around design quality and handoff
- Shared rituals (crits, audits, retros) that actually lead to change
- Mindfulness and emotional intelligence as real tools for better work, not side projects
I’m happiest when teams feel proud of what they ship—and not burned out getting there.
What kind of opportunities are you most excited about?
I’m especially interested in work that sits at the overlap of:
- Design systems architecture for complex products
- AI/AX design for agentic or autonomous systems
- Design-dev integration where designers and engineers genuinely share ownership
If a problem requires both systems thinking and hands-on building, I’m probably interested.
Design Process
What does your end-to-end process look like?
I adjust process to context, but a typical arc looks like:
- Clarify the problem and success criteria with stakeholders
- Map the existing system (users, data flows, constraints)
- Explore options quickly in low fidelity
- Align on a direction through critique and feasibility conversations
- Move into higher-fidelity flows, systems, and component definitions
- Partner with engineering on implementation, QA, and polish
Throughout, I try to keep one eye on the immediate release and one eye on the system we’re evolving.
What tools do you actually use today?
My core stack right now:
- Figma for design systems, flows, and collaboration
- VS Code + Git for front-end work and experiments
- Storybook for documenting and testing components
- n8n / agent frameworks / LLM tooling for Genie and other AI workflows
I reach for other tools when they’re the right fit, but those are my daily drivers.
How do you handle feedback and disagreement?
I try to treat feedback as data, not a verdict.
- First, I clarify what the feedback is solving for (user outcome, business risk, technical constraint)
- Then I propose options: keep as-is with rationale, adjust the design, or change the scope
- If we still disagree, I try to make the tradeoffs explicit and small enough to test
I care a lot about strong opinions, loosely held—and a culture where critique feels safe and useful.
Working Together
How do you like to collaborate with product and engineering?
Ideally, we’re co-owning outcomes, not throwing work over walls.
- With product, I like to collaborate on shaping problems and defining success early
- With engineering, I prefer pairing on constraints, architecture choices, and edge cases before we over-invest in polish
I’ve found the best work happens when everyone feels they had a hand in the outcome—and understands why the decisions were made.
What do you care about outside of the work itself?
I care a lot about how teams feel while doing the work:
- Psychological safety in critique and experimentation
- Mindfulness and emotional intelligence as practical tools, not afterthoughts
- Sustainable pacing—so people can have long, creative careers without burning out
Those things aren’t separate from delivery quality; they’re a precondition for it.
