Lessons About Working In AI From A Decade In Design

Maitrik Patel, a decade in design systems, now in AI/ML platform engineering. Views expressed are my own and do not represent my employer.

​When engineers talk about what makes a great AI team, they list the same things: strong ML engineers, solid data infrastructure and fast experimentation pipelines. Design rarely comes up.

After a decade building design systems at DocuSign, Sony, Prosper and OpenText, and then moving into AI and ML platform engineering, I’d argue that’s a mistake. Some design skills transfer directly to AI work. Some will actively mislead you. Both lessons are worth understanding before you build your next AI team.​

A design system is just an MLOps pipeline you can see.

At DocuSign, I built Olive, a unified design system: a React component library with semantic versioning, distributed through a private npm registry. It reached 99% adoption across products. Years later in AI platform engineering, I recognized the identical problem: dozens of teams building ML pipelines independently, no shared standards, no governed execution.

The diagnostic question for AI leaders is the same one a design systems engineer asks: Are teams rebuilding the same foundational capabilities over and over? If your ML teams each maintain their own feature stores, training pipelines and deployment tooling with no shared versioning, you do not have a tooling problem. You have a consistency problem that more tooling will make worse. The solution is governance and shared infrastructure first. More frameworks second.​

Living style guides show why static models fail.

At OpenText post-acquisition, keeping two product lines synchronized required continuous feedback loops, automated regression testing and explicit governance for when teams could diverge. Walk away for a quarter and the system forked silently.