Elanco Knowledge Systems (EKS) was the internal product surface that let Elanco's commercial, veterinary, and operations teams find, ask, and act on company knowledge. The infrastructure underneath it — discovery, design system, AI tooling — wasn't four parallel projects. It was one program with three deliverables that depended on each other.
EKS started as a discovery effort: who used company knowledge, where it lived, and what got in the way. That work produced a service model that needed a coherent visual + interaction system to land. That system, in turn, became the substrate the AI tooling rendered into. Each piece would have been weaker on its own; the value compounded because they were built together.
Three connected projects — Continuous Discovery, the Elanco Design System, and ElancoGPT — designed and shipped as one operational infrastructure for enterprise knowledge work.
The diagram below maps the dependency direction. Discovery output fed the design system's information architecture and naming. The design system became the rendering substrate for AI surfaces. AI tooling fed structured queries back into discovery's tracking loop.
Each child has its own dedicated case study with the depth a single-project review needs. Here they're framed as members of one program.
The umbrella began with discovery. Who actually used company knowledge? Field interviews across veterinary affairs, commercial sales, regulatory, and customer service surfaced a pattern that had been invisible to the org chart: knowledge work happened in handoffs, not in roles. A regulatory writer's morning question became a vet's afternoon answer became a salesperson's customer email — and the system that should have supported that flow didn't exist as a product, only as a series of inboxes.
The discovery deliverable wasn't a research report. It was a service model — a map of where knowledge originated, where it got transformed, and where it had to land for someone to act on it. That model became the brief for everything that followed.
Fragment of the EKS service model. Bar width = observed knowledge fidelity at each stage. Fidelity loss at "act" was the founding insight.
The discovery output needed a rendering substrate. Elanco had a brand system but not a product design system — color and type guidelines without tokens, no shared component library, no naming convention that survived a sprint. Engineering teams built their own buttons. Product teams couldn't review specs against a source of truth.
The Elanco Design System (EDS) was the answer to that. Tokens-first, Tailwind-aligned utilities, breakpoint-aware components, all governed by a shared decision log. It shipped as the substrate for EKS surfaces first and then propagated to adjacent product teams — the kind of organic adoption a forced rollout never achieves.
EDS uses a paper-and-ink palette as ground, with the brand blue/navy/teal reserved for product surfaces. Sand and paper act as a quiet foundation under content-heavy enterprise screens.
Three different button libraries across EKS surfaces. Color values hard-coded. Spec reviews had to re-litigate hierarchy every sprint.
One token sheet, one component library. Spec reviews focused on flow logic, not visual primitives. New surfaces shipped in 60% the time of pre-EDS comparables.
With the service model and the design system in place, the AI tooling could be designed as a decision surface, not a chatbot. The discovery insight — structure should travel with content — meant ElancoGPT outputs couldn't be loose paragraphs. They had to be parseable into the same fact / inference / risk / action shape downstream consumers were already trained on.
Retrieval-augmented generation handles the source-grounding. The interesting design problem was the output structure: every response is rendered as four typed blocks, each with a confidence indicator, each separately citable, each capable of being attached to a downstream artifact (a customer email, a regulatory note, a sales-call brief). The AI never returns "an answer." It returns a structured argument.
Every ElancoGPT response renders into these four typed blocks. Users can copy any one block independently, cite it, or attach it to downstream artifacts.
If discovery had shipped alone, it would have been an internal report. If EDS had shipped without the service model, it would have been a token sheet without a domain. If ElancoGPT had shipped without either, it would have been a chatbot with no place to land its output. Treating them as one program is what produced compounding value — and the lead-level part of the work.
The service model's role taxonomy became the EDS information architecture. Components were named after the roles they served — RegulatoryCard, VetBrief, CommercialThread — not after their visual shape.
EDS → ElancoGPTElancoGPT renders into EDS components. The four-block response uses the same VerticalSemanticCard pattern as the discovery-side knowledge surface. Users don't have to learn a second visual grammar.
ElancoGPT → DiscoveryStructured queries flow back into the discovery-side analytics, surfacing emerging knowledge gaps in near-real-time. The discovery loop continues running, but now with a signal source it didn't have at the start.
Designing the three projects as one program. The temptation in big orgs is to scope them as independent budgets and ship them independently. The compounding value only shows up if they share substrate from the start — and that requires a designer with the standing to argue for it across three sponsoring VPs.
Invest in EDS contribution tooling earlier. Once adjacent teams started adopting EDS, the contribution model became a bottleneck. A clearer path from "I have a new component idea" to "it's in the shared library" would have accelerated cross-team adoption by months.
This is the program where I learned to think in dependency graphs. Lead-level work is mostly about understanding what depends on what and protecting the shared substrate — because once it's poisoned, every project downstream of it pays the tax.
EKS isn't a consumer product. It's the infrastructure that lets thousands of veterinary, commercial, and regulatory professionals do their work without re-deriving knowledge that already exists somewhere in the org. Invisible when it works, expensive when it doesn't.
The EKS program shaped how I think about infrastructure surfaces. The current work — designing the experience architecture for IoT connectivity at T-Mobile — applies the same dependency-graph logic at a different scale: provisioning, fleet management, and lifecycle across millions of devices. Different domain, same lead-level practice.
Read the IoT case study →Foundational research and service design for EKS. The work that produced the role taxonomy everything else built on.
Read full study → CHILD · 02Tokens, components, governance. The substrate that turned a brand into a product design system.
Read full study → CHILD · 03Enterprise AI as a structured decision surface. Fact, inference, risk, action — never a chatbot.
Read full study →