Long story short
Compartment was already strong where it counts - deployments, access control, audit logs, routes, self-hosted runtime boundaries. The engineering ran deep. What it didn’t have yet was a design layer that could keep pace. So my job wasn’t to make it pretty; it was to turn that product model into a design system, an implementation workflow, and a Codex agent + skill layer the team could lean on - so console work kept shipping even on the days there was no Figma screen to point at.
Problem
This console can’t run on library defaults. It needed its own rules - for screens, states, permissions, tokens, and components - plus a clear line between what the UI owns and what the platform handles underneath.
Solution
I built the console’s UI/UX foundation on shadcn, Tailwind, and Radix: theme and color logic, access-management flows, role/scope architecture, and a drawer pattern for editing without losing your place - then wrapped it in an agentic workflow for building and reviewing new screens.
Result
Design decisions stopped living in my head and became explicit, repeatable, and reviewable. I shipped 5 Codex agents and 5 reusable skills plus a design-audit pass, which helped get the product ready for its first enterprise client - so new platform work can start from product intent, reuse production patterns, and clear a structured audit before handoff.
Context
Compartment is a control panel for developers - a browser platform sitting on top of CLI-owned deploys, access control, routes, logs, and self-hosted runtimes. The engineering was already serious; what was missing was a way for design to move at the same speed. I came in to build that layer: a system, a way of working, and an AI workflow so the console could keep growing even when no one had drawn a Figma screen for it yet.
This was design-ops for a fast-moving infrastructure product - I sat across product design, design engineering, and AI-assisted implementation. Because the console is a control plane over the platform’s deployment workflows, every design choice had to respect the real constraints underneath: contracts, permissions, org context, route ownership, and the system’s architecture.
! Problem
Compartment had a strong engineering foundation, but the console UI had to make a complex access model understandable and safe to use.
The main challenge was not just creating screens. The product had roles, scopes, permissions, organization/project boundaries, and many operational states that needed to be clear for users and consistent for the team.
Access logic was complex
Roles, scopes, permissions, and org/project boundaries were hard to understand at a glance. Users needed a clearer way to review, edit, and move through access-management flows without losing context.
AI-generated UI was not reliable by default
AI could create screens quickly, but the output often missed product logic, edge cases, required states, or used components in a generic way that did not fit Compartment’s access model.
Mockups and component libraries were not enough
shadcn, Tailwind, Radix, and Helium UI gave the team a strong starting point, but they still needed product-specific rules, reusable patterns, and an audit loop so new screens could stay consistent without a designer involved every time.
Design challenges
Designing for infrastructure is less about laying out screens and more about defining an operating model.
Compartment isn’t a blank-slate consumer app. The console gets used for the same operational work over and over, it has to stay dense and compact, and it has to honor strict ownership lines between the browser UI, the API and SDK, permissions, and the codebase. You can’t just drop a pretty layout on top of that.
So the real challenge was making the product safe to extend - defining how future screens get planned, built, and reviewed, even on days with no Figma mock to work from.
That came down to clear rules: screen patterns, required states, semantic tokens, action hierarchy, status components, accessibility, and architecture boundaries - so the next person starts from the system, not from personal taste.
Solutions
What was done an what benefits were achieved for each solution:
Visual & component foundation
First I shaped the basics - theme, color logic, density, and overall style - so the console read as Compartment, not as off-the-shelf library UI.
Then I pinned down how the core patterns behave across the product: buttons, tables, forms, badges, drawers, and every state that’s easy to forget - empty, loading, error, disabled, and destructive.
The payoff: the team finally had a consistent way to reach for shadcn, Tailwind, and Radix instead of guessing each time.
Access management, made legible
I took Compartment’s access model and turned it into UX flows people could actually follow - around scopes, roles, permissions, and org/project boundaries.
A drawer-based pattern for role details let users open, read, edit, and close a role without ever leaving the screen they were on.
Suddenly the access logic felt understandable - less generic admin dashboard, more a real part of the product.
AI Workflow
The team needed a way to keep developing the console without a full-time designer embedded in every workflow. My role was to turn design knowledge into something reusable: Codex agents, skills, references, and an audit layer that could help the team plan, build, and review UI more consistently.
This became one of my core contributions: a design-ops system that teaches Codex how to work with Compartment platform screens - from product intent to implementation and review.
I created 5 Codex agents and 5 reusable skills. Together, they help transform a feature request, missing screen, or UX gap into planned, composed, implemented, and audited console UI.
The workflow keeps new screens aligned with Compartment’s product logic, shadcn/Tailwind/Radix components, required states, permissions, and design rules.
Agents
Agent 01
product-screen-planner
Turns intent into purpose, primary action, success path, states, and contract assumptions.
Agent 02
console-screen-composer
Composes screens from production patterns instead of starting from blank.
Agent 03
frontend-ui-implementer
Builds with shared components, semantic tokens, Tailwind, shadcn-style primitives, and Radix.
Agent 04
console-quality-auditor
Checks states, accessibility, copy, component usage, action hierarchy, and design drift.
Agent 05
console-architecture-guardian
Guards CLI-first contracts, package ownership, permissions, organization context, and boundaries.
4+1 skills:
Skills
Skill 01: plan
$plan-console-screen
Product job, primary action, success path, states, permissions, route/data assumptions.
Skill 02: compose
$compose-console-screen
Production exemplar + component tree + design.md rules + optional Figma component reference.
Skill 03: build
$implement-console-screen
Code in packages/console using shared components and semantic tokens.
Skill 04: audit
$audit-console-screen
Design-system, UX, accessibility, states and architecture boundary review.
Skill 05: RARE
$update-console-design-language
Only for real system gaps: token mapping or stale design.md guidance.
Here's how it runs in practice. A PM, a developer, or an AI coding agent can ship a new Console screen without waiting on a separate Figma mockup.
Before any UI code is written, the agent has to clarify the intent, define the screen plan, find the closest existing production pattern, and pull the shared visual language from compartment-console-design.md.
Only then does it build - shared components, semantic tokens, Tailwind, Radix, and shadcn-style primitives - and the result gets audited for drift: hardcoded colors, one-off UI, missing states, unclear actions, accessibility gaps, or broken boundaries.
And when review keeps surfacing the same gap, that fix goes back into the system - design language, token mapping, component rules, or references - so the next screen starts from stronger ground.
Research, Discovery & Validation
Reading the product & access model
I went through the console structure, roles, scopes, permissions, org/project boundaries, and who really owns each workflow underneath - to figure out what the UI should carry, and where it should stay out of the way.
Testing the flows
I put the access-management flows in front of users and stakeholders to see if role details, drawers, entry and exit points, and permission logic actually read clearly. Their feedback is what simplified how people review and edit access without losing their place.
Pressure-testing components & agents
I checked how shadcn, Tailwind, and Radix held up against Compartment’s theme, states, forms, tables, drawers, badges, and errors - then ran the agents and skills on real console tasks to be sure the workflow could carry actual product work, not just demos.
Impact & Results
The real result: a system the team kept using long after my hands were off the design.
Business outcomes
Helped get the product ready for its first enterprise client.
Took the designer out of the loop for every small UI call.
Gave the team a way to keep shipping console screens without a designer in the team.
Made access-management flows easy to follow - and easy to explain to others.
Let the product move faster while actually getting more consistent.
Process & Design outcomes
A Compartment-specific UI foundation on top of shadcn, Tailwind, and Radix.
Clear patterns for roles, scopes, permissions, drawers, lists, details, and the empty/error states everyone forgets.
5 Codex agents and 5 reusable skills for planning, building, reviewing, and improving console UI.
A design-audit pass that catches missing states, drift, misused components, hardcoded colors, and accessibility gaps.
Design knowledge that now lives in the team and in Codex - not locked in Figma or in my head.
Reflections & Takeaways
The most valuable thing I made here wasn’t a screen - it was a system the team could run without a designer (that's questionable of course as I am pretty sure AI will not change designers in the nearest time). I shaped the visual direction, the access-management UX, the component rules, and the agent workflow.
Reflection
Biggest takeaway: design can become infrastructure - and a designer can work like an engineer.
Once the patterns, states, roles, permissions, and review rules are written down, nobody has to ping a designer for every small decision.
That’s what made it scale. Compartment could take on an enterprise client, keep building without a designer on call, and use Codex more safely - because the design rules were already baked into the process.
