
Most design work makes simple things feel simple. This project is the opposite problem. I'm designing the controls for powerful, and in some cases, dangerous capabilities. Autonomous AI agents, live production databases, message queues, regulated personal data, on-premise and air-gapped modes, with no cloud safety net. My users need to wield all of that. Most of them are not engineers. The entire design challenge is deciding, capability by capability, what to hide, what to expose, and how to keep the platform honest about what's happening underneath.
NVIDIA and Accenture came together to create a platform that lets people assemble automated workflows that chain together API calls, database operations, human approvals, and autonomous AI agents. All of the capabilities of other workflow engines out there, but injected with Accenture's deep domain and industry knowledge to set it apart.

The people building these workflows aren't a broad consumer audience and they aren't software engineers either. They're business analysts and operations specialists inside regulated organizations: technically literate, but not people who write code day-to-day.

The ultimate vision is bigger than any single workflow tool. In partnership with NVIDIA, the platform aims to equip clients across finance, supply chain, healthcare, and beyond with AI and NVIDIA technology that streamlines the processes they already run. We are aiming to fold AI and accelerated computing into the work our clients are already doing.

A lot of what this platform targets is knowledge work that's still done by hand. Building a customer profile for a process like KYC means a person visiting several disconnected systems, pulling the relevant data out of each, reconciling it, and assembling the profile themselves: slow, error-prone, and impossible to do at volume.
Automation and AI agents can do that gathering and reasoning instead, but until now the only way to build that automation was to write code, which kept it out of reach of the very people who own the work. The platform exists to close both gaps at once: take the manual labor off people's plates, and let the people who understand the process build the automation without writing a line of code.

When I joined, the requirements were dense, the dependencies between capabilities were tangled, and the pace was relentless: a full program increment's worth of new node types, triggers, parallel execution, deployment, and agent integration, much of it depending on engineering work that was still in flight.
My job wasn't just to design screens. It was to make a genuinely complicated technical program legible — to myself, to the team, and to the people who'd build and use it — and to keep it moving without anyone losing the thread.
I went after the engineering directly: how API calls authenticate, how secrets are vaulted, how input/output variables flow between steps, how a sandboxed agent is dispatched and contained. I learned it not to be an engineer, but to know exactly which parts of it the user should never have to see. Along the way I became the person product and engineering route to when a question is about how a capability should feel to use.
I work in Figma to think, sit with product and dev to understand what a feature actually has to do, then translate that into working prototypes in code using Claude Code: designs that match my intent one-to-one and that engineering can read in their own medium instead of interpreting from a static file. It changed how fast we move and how little gets lost between design and build.
A platform this interconnected falls apart if nobody holds the whole map. I track the dependencies between capabilities, flag sequencing risks early, and keep the team oriented so we don't lose context as we sprint. A lot of my value here isn't a screen; it's the team not being overwhelmed.
Every piece had to carry real engineering weight while staying simple enough to use. Here is the work, one screen at a time.
For most of my career, “handoff” meant giving engineering a Figma file and a set of annotations and hoping the build came back resembling the design. On this project I tried something different. Instead of describing a complex node interaction, I built it: a working prototype in code, using Claude Code, that matched my design intent one-to-one.


This is an ongoing, pre-launch project, and we haven't put it in front of real users yet, so I'm not going to claim outcomes I can't back up. What I canpoint to is real: the canvas and node system I designed are the foundation the team is building against; I've become the person product and engineering come to on how these capabilities should work; and the code-prototyping method I pioneered has changed how we hand work off.
This is the project that's defining the next phase of my career. It put me in a small group of designers working on the tools that make AI itself buildable, not by dumbing it down, but by packaging real expertise into it and making even the hardest operations safe to hand to a non-engineer. To do it well I had to learn to speak engineering fluently enough to know what to hide, get comfortable shipping in code, and keep a fast, complex program from losing its thread.
