Council Post: Lessons About Working In AI From A Decade In Design
tags:Maitrik Patel, a decade in design systems, now in AI/ML platform engineering. Views expressed are my own and do not represent my employer.
getty
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.
AI leaders should expect the same. Before you deploy a model, build the audit cadence that will tell you when it is drifting. What usage signal will you monitor? What threshold triggers a retraining cycle? If you cannot answer those questions before launch, you are shipping a deliverable, not a living system. The model will be wrong before you know it.
Accessibility work taught something that transferred directly into human labeling.
Building WCAG 2.1 AA compliance into DocuSign’s Olive system required labeling rubrics precise enough for any designer to reach the same conclusion independently: what counts as sufficient contrast, adequate focus state and correct interactive behavior.
Annotation guidelines for ML training data require exactly the same thing. And the edge cases reveal the same lesson in both contexts: Wherever annotators disagree, there is an assumption buried in the taxonomy that nobody made explicit.
When your labeling team produces inconsistent results on a category of input, the right response is not a majority vote or a manager override. Treat it like an accessibility audit failure: Convene a small group, define the edge case explicitly, and update the guidelines. The disagreement is the finding. The taxonomy is what needs fixing.
A/B testing culture is the bridge.
At DocuSign and Prosper Marketplace, data-driven iteration was built into the product culture before any ML was involved. That foundation turned out to matter more than the specific tools.
Before assuming your model metrics will be meaningful, assess your experimentation maturity. Three questions worth asking: Does your team write down the hypothesis before running the test? Do you have baseline measurements running before you introduce a model? Does anyone on the team know how to distinguish a real signal from noise in an experiment result? If the answer to any of those is no, your model performance metrics will be gamed the same way any unaccountable metric gets gamed.
The skills that lied to me.
At Sony, I worked on a platform spanning 110 countries and 30 languages from a single shared codebase. When I shipped a module, it deployed everywhere simultaneously and deterministically. I specified the behavior. It did it. Every time.
That intuition is dangerous in AI. Models do not behave deterministically. Behavior emerges from data and optimization, not from intention. “Usually correct” is often the honest ceiling.
The leadership lesson: Stop setting stakeholder expectations as if AI systems work like software releases. Ship with known limitations documented. Present failure modes alongside accuracy numbers, not as caveats but as core deliverables. Leaders who do this earn more trust, not less, because their systems surprise stakeholders least.
Here are three things AI leaders can do now.
The problems that slow down AI adoption are rarely model problems. They are systems problems: inconsistent pipelines, models that drift without detection or annotation schemas that produce noisy training data.
First, audit for design system problems. If teams are building ML capabilities independently with no shared versioning or standards, treat it the way a design systems engineer would: Build the shared infrastructure before adding more models.
Second, treat annotation disagreement as diagnostic. When labelers cannot agree, update the guidelines rather than resolving by vote. The disagreement is telling you something about your data assumptions.
Third, change how you communicate AI outcomes. Error rates and failure modes are not caveats. They are the product specification. Make them a standard part of every model launch.
It turns out a decade in design was AI preparation all along, just not entirely in the ways I expected.
Disclaimer: Views expressed are my own and do not represent my employer.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?