OpenEye

Computation ≠ Comprehension

OpenEye had pioneered cloud-based molecular modeling at a time when speed itself felt revolutionary. But in making impossible things fast, we had quietly made many ordinary things slow. Actions that once happened instantly—simple calculations, inspecting small models and depictions, making manual edits to processes—now required sophisticated orchestration across remote compute nodes. Scientists were forced to think like engineers, not because they wanted to, but because the system demanded it.

After the company was acquired by a semiconductor firm, this tension sharpened. Life sciences are stochastic and exploratory; chip design is deterministic and tightly constrained. At the same time, the broader biotech ecosystem was entering what many quietly described as a nuclear winter—tightened funding, increased scrutiny, and rising pressure to demonstrate near-term value.

In that climate, the differences between chip design and biology were no longer abstract. They showed up in planning assumptions, success metrics, and expectations about certainty. The underlying question became unavoidable: how do you preserve scientific intuition in systems optimized for computational rigor, especially when economic pressure rewards determinism over discovery?

The issue wasn’t usability in the narrow sense—it was tempo. Computation had accelerated, but comprehension had lagged. Scale and capability did not keep up with speed. And without new utility people could really see and feel, the velocity sometimes started feeling like friction.

When Fast Became Slow

Computational chemistry has proven itself quite useful in many industries - a way to reduce risk when developing new compounds for drugs and materials. Users responded by building their own internal ecosystems—stringing together scripts, workflows, and external tools to try to gain momentum. Handoffs across the DMTA cycle (Design–Make–Test–Analyze) within a branded ecosystem are lossy, and when passing between many tools, they are even more problematic. Context evaporates between steps. Scientists report spending up to 70% of their time assembling presentations (for their own teammates!) instead of doing science.

The problem isn’t just inefficiency; it is fragmentation. Scientific reasoning is happening around these platforms rather than within them. The invisible logic of collaboration—why decisions are made, how conclusions are reached—is being lost.

The work ahead is not simply to make things faster, but to make thinking visible again.

This period also coincides with a growing external enthusiasm for “AI” in biomodeling. Internally, OpenEye is largely hype-averse. Much of what has been newly labeled as AI was, in practice, an extension of statistical and probabilistic methods we have been using for years—under plainer names, with clearer assumptions. The real challenge isn’t adopting fashionable terminology, but ensuring that increasingly sophisticated models remain interpretable, trustworthy, and usable by scientists under pressure.

This grounded perspective reinforces the same core concern: power without understanding doesn’t accelerate discovery—it obscures it.

OpenEye — Designing for Scientific Thought

During my time at OpenEye, I had the privilege of working with some of the most creative, generous, and multidisciplinary engineers and scientists I’ve ever encountered. While I was the first UX designer on the team, I was never a team of one. I collaborated closely with exceptional frontend engineers, world-class backend engineers, chemists, physicists, computational biologists, and deeply thoughtful product and program partners.

The work thrived on productive tension. A core group of us—frontend and backend leads, TPM leadership, consulting chemists, and myself—trusted each other enough to disagree, revise, and re-approach hard problems together. That sustained, respectful friction shaped the quality of everything we built.

Revising the Core Tools Scientists Think With

Much of my work focused on revisiting and strengthening the foundational tools scientists use to think, not just the surfaces they click through.

This included:

• 3D molecular viewing and editing tools — improving how users orient, manipulate, and reason about complex structures
• 2D depiction and alignment strategies — ensuring visual conventions support medicinal chemistry workflows while remaining computationally rigorous for modelers and method developers
• Analysis ecosystems — clarifying how results flow across tools, states, and representations
• Documentation systems — treating docs not as an afterthought, but as part of the product experience (a research session revealed a competitor’s docs ‘make them feel loved’ <3)
• Molecular data organization and delivery — including how protein databases and molecular sources were accessed, explained, and integrated across workflows

Over time, this work required developing real subject-matter fluency—not just in UX practice, but in modeling conventions, chemical representations, simulation outputs, and the ways scientists translate computation into decisions.

Customer Learning as Design Infrastructure

When I joined, OpenEye already had a vibrant customer visit practice supported by a shared reporting template. What was less developed was the confidence to ask broader questions—questions about context, not just product performance.

I helped evolve this practice by:

• Designing short, scientifically respectful research formats
• Expanding inquiry beyond feature feedback toward workflows and constraints
• Modeling synthesis practices so insights could meaningfully travel across teams

Mod-Chemists

Through field research around the world, I encountered three recurring user archetypes: computational chemists, medicinal chemists, and a growing hybrid group I began calling mod-chemists—scientists who bridge modeling and wet-lab practice.

They embodied the future of interdisciplinary science: fluent across domains, impatient with silos, and deeply sensitive to friction. Their feedback clarified the problem in human terms. Interdisciplinary scientists don’t just need more power—they need tools that preserve intuition as complexity increases.

We weren’t just building interfaces for computation. We were designing environments for discovery.

Product-Led Planning & Shipping Faster

I was part of the product team that helped cultivate a product-led planning practice embedded within engineering itself. Planning wasn’t treated as external direction—it was collaborative, grounded in technical reality, and oriented toward shared outcomes.

During this period, OpenEye increased deployment frequency from two releases per year to more than seven, improving feedback cycles and enabling faster learning across teams.

Conceptualizing & Commercializing Molecule Search

One of the most consequential efforts I led was the conceptualization and commercialization of a standalone molecule search product, developed during a period of economic pressure and uncertainty.

The opportunity was clear:

• Our virtual screening and search algorithms were among our strongest assets
• Yet many scientists—especially medicinal chemists—needed a more approachable entry point

Search became the bridge.

The product:

• Aligned with 2D med-chem workflows while gently introducing 3D insight
• Scaled across massive chemical spaces using OpenEye’s core algorithms
• Allowed customers to build curated molecular databases from reagents and reactions
• Integrated naturally with downstream virtual screening and modeling workflows

We shipped molecule search just over a year after deciding to productize it (a little longer than we all would have hoped, tbh). While medicinal chemistry is a difficult audience to reach, the product gained traction through computational chemistry teams—and we even heard, quietly but meaningfully, that medchemists liked it. Our relatively modest user base grew remarkably with the introduction of these new, less expensive licences - and enthusiasm for wet<>dry lab collaborations also expanded.

A Personal Note on Modeling & Simulation

Underlying all of this work was something deeply personal: a long-standing love of modeling and simulation as ways of thinking.

What drew me to OpenEye—and what kept me engaged—was the opportunity to work at the intersection of representation, computation, and human judgment. Designing tools that help people reason about invisible systems is both a technical and philosophical challenge, and it’s one I continue to pursue.

What I Carry Forward

This work wasn’t about isolated features. It was about building:

• Better scientific tooling
• Better product practices
• Better ways for teams to think together

I remain deeply grateful to the people who made that possible.

If you’re working on humane tools for complex science—or exploring the intersection of design, modeling, and meaning—I’d welcome the conversation.

→ caitlin@acmesteam.co