Case Study — Continuous Discovery
Reserved for a swipe-ready hero visual that introduces the research ecosystem, service layers, and ownership model behind the work.
EKS had accumulated complexity faster than it had accumulated understanding. After separation from Eli Lilly and the Bayer Animal Health acquisition, speed was prioritized to keep the business moving. The result was a fragmented ecosystem of tools, workflows, permissions, reports, and backstage dependencies that few people could accurately map end to end.
My role was to establish a continuous discovery foundation that could uncover how the system actually worked, where onboarding and operations were breaking down, and what should be prioritized first. This became the groundwork for HoneyBee, HoneyBee UXR, the EKS design system, Uplook redesign work, and later ElancoGPT.
"The problem was not a lack of ideas. It was a lack of shared visibility into users, workflows, ownership, and the system itself."
Discovery framing
The EKS landscape included account permissions, user permissions, data entry, data processing, notifications, reports, authentication, and operational databases with different rules depending on species, customer agreements, and internal roles. Even experienced stakeholders described confusion around forms, status definitions, and who was responsible for what.
The work drew from Teresa Torres’ continuous discovery habits, Marty Cagan’s product discovery principles, and the Double Diamond. I used that structure to separate problem-space investigation from solution-space prioritization, while keeping discovery continuous enough to inform multiple downstream initiatives instead of a single one-off deliverable.
Operating Model
Use discovery to create a shared decision-making substrate: understand users, map the service, expose backstage dependencies, and turn that into a reusable foundation for multiple product bets.
That meant stakeholder mapping, interviews, service blueprinting, affinity mapping, personas, content inventory, and structural recommendations that could be reused beyond one project.
I started by identifying and mapping stakeholders with a RACI lens, then ran stakeholder interviews focused on background, tools, pain points, barriers, and experience with EKS Passport and surrounding workflows.
Artifact
Artifact
Fig 2 — Core problem-space artifacts from the discovery work
Across HoneyBee and EKS Passport modernization, the same structural themes kept surfacing: lack of standardized processes and documentation, unclear accountability, reactive triage, and fragmented knowledge living inside individuals instead of the organization.
Process standardization
Lack of standardized processes and documentation created more work, more rework, and no clear way to backtrack root causes when issues emerged.
Education approach
A “teach them how to fish” mindset emerged as a consistent lever: job aids, learning paths, better explanations, and narrative context could improve adoption and reduce noise.
Ownership gaps
People repeatedly described not knowing who was responsible for what. Without ownership clarity, triage and escalation stayed reactive and siloed.
Visibility
Teams lacked shared awareness of system health, metrics, and operational dependencies. That visibility gap is exactly what HoneyBee later set out to solve.
As part of content inventory and interface direction, I looked at established system references to benchmark clarity, hierarchy, governance, and reusable components. The goal was not to copy them, but to understand how mature systems communicate structure and reduce ambiguity.
The discovery work produced more than findings. It created a decision-making foundation: clear themes, service design recommendations, a more accurate model of backstage operations, and priorities that could guide future product work.
Recommendation
Create one source of truth for processes and forms, automate what can be synchronized across systems, clarify roles and responsibilities, and use discovery artifacts to prioritize what the organization should modernize first.
This shaped HoneyBee MVP planning, EKS Passport onboarding recommendations, and the broader move toward design system thinking, Uplook redesign, and AI-enabled tooling that depended on a clearer operating model.
This was the foundation case study. Before there was HoneyBee UXR, before the design system matured, before Uplook redesign and ElancoGPT, there had to be a shared understanding of users, backstage delivery, system complexity, and what deserved attention first.
This project changed the quality of later product decisions because it gave the organization a clearer map of users, operations, and constraints before more design and engineering effort was spent.
Outcome framing
You mentioned you already have the diagrams. This page is structured so those can be dropped in next with minimal refactoring.
Add next
Add next
The cleanest next pass would be adding your stakeholder map, service blueprint, and any HoneyBee/EKS diagrams directly into these slots.