Eight years of enterprise UX. Two stories told in full, the rest in brief.

More work, briefly

Not everything needs a full case study. A few other places the eight years went:

Cloud marketplace onboarding

The journey from a cloud-marketplace purchase to a running product: trials, subscription setup, and first-run onboarding for an enterprise SaaS console. My work contributed to a major reduction in onboarding time and real gains in trial-to-paid conversion. FILL Review this entry against your IBM agreements before it goes public: it sits closest to the conflict-sensitive marketplace work.

Air-gapped installation

Install and update experiences for disconnected, high-security environments where nothing can phone home. The constraint changes every design decision: no telemetry, no live documentation, no easy path to fix a mistake after the fact.

Operator-based installation on Kubernetes

The pattern work that preceded the install case study above: a minimum viable install experience for a suite of enterprise products on a Kubernetes container platform, built by documenting every product’s as-is install scenario and interlocking with three major product teams on adoption. I taught myself to deploy the platform’s clusters, cloud and on-prem, and that fluency became the foundation for everything install-shaped that followed.

A private cloud in a box

My first product at enterprise scale: a hyperconverged appliance that enterprises run as a private cloud. I designed its getting-started, software-deployment, and cluster-management experiences and helped plan, moderate, and act on the usability program behind them. Within my first months I had become the design team’s technical lead, the bridge between design and the architects.

Application modernization tooling

The apprenticeship year that made me a designer. I worked on a tool that assesses enterprise Java applications for cloud readiness: complexity scoring, migration recommendations, and connecting the analysis to the application’s actual source code. It taught me to design for exhaustive states early; one integration flow shipped with eighteen documented states covering every way it could fail. FILL Optional: the product is public and long-shipped, so you could name it instead of keeping it abstract. Your call.

Design systems, daily

Eight years working inside Carbon, IBM’s open-source design system: building with it, stretching it where products needed more, and coaching other designers on using it well. Systems thinking is the throughline in everything above.

AI is part of how I work now.

I’m not an AI researcher and I don’t pretend to be. I’m a designer who noticed that these tools reward exactly the skill I’ve spent a career building: describing a system precisely enough that someone, or something, else can build it.

Over the past two years I’ve been building tools with AI agents. I do light editing, but mostly I direct: I know how applications and APIs function, so I can specify what I want technically and evaluate what comes back. A few things I’ve built this way:

• A documentation assistant. A retrieval-augmented assistant that answers questions about our platform by searching product documentation, built on vector search with an enterprise LLM stack, including the data pipeline that feeds it.
• Prompt tooling for designers. A set of reusable, structured prompts that help designers produce user flows, evaluate auth and access patterns, and apply design-system rules with AI assistance.
• Design utilities. Small tools that speed up my own work, including wireframe kits and a Figma annotation helper.
• Early agent experiments. Prototypes exploring how agent-based workflows could handle multi-step platform tasks.

These are working tools, and I’m currently their main user. I treat them the way I treat any prototype: real enough to learn from, honest about what they haven’t proven yet.

What I’ve actually learned from building them: retrieval quality matters more than model choice. Structure in equals structure out, and a well-designed prompt is an act of information architecture. The hard design problems in AI are trust problems: what the system should say when it isn’t sure, and how a person checks its work.

This portfolio was itself built the same way: designed by me, assembled by directing AI tools, which felt like the honest way for a designer who works like I do to build a website in 2026.