The data platform for the scientific lab

01The problem

Scientific labs run on data scattered across instruments, formats, and systems that were never meant to talk to each other. A single assay might leave results in a vendor's binary export, a lab notebook, and a LIMS record, none of which agree. The users are data engineers and scientific SMEs who need that raw output turned into structured, harmonized data an AI model can actually reason over.

TetraScience is a Data and AI Cloud built for science, with Eli Lilly as a key customer. The core product is a multi-step replatforming pipeline: connect a source, map raw files to a canonical schema, validate, transform, and publish AI-ready data. Every step has states that matter, from queued and running to partially failed and published, and the stakes are high, because a bad mapping silently corrupts data an entire research program depends on.

02My role

As founding designer, I owned the end-to-end UX of the replatforming pipeline and set the early product and design direction the platform grew on. I designed the source-connection, schema-mapping, validation, and monitoring flows myself, and defined the interaction patterns and component foundation later hires inherited. I drove the decisions, not just the screens: what the v1 pipeline would and wouldn't do, and how much complexity to expose.

03The approach

I interviewed data engineers and scientific SMEs at our design-partner customers, including Eli Lilly, and sat in on real replatforming attempts. The clearest signal: people didn't fail at mapping because it was hard, they failed because they couldn't tell what went wrong when a run broke. That pushed me to make pipeline state and error legibility the spine of the design rather than an afterthought.

For v1 I deliberately scoped to the guided, single-source path and cut the visual any-to-any transformation builder we'd sketched. It was too open-ended to validate against the standards our data had to conform to (OMOP, FHIR, SNOMED), and engineering couldn't guarantee correctness on arbitrary transforms yet. Instead I designed for the states that actually break trust: empty states that explain what a connection needs, per-file validation errors that point to the exact field and expected type, partial-failure runs where some records publish and others quarantine, and long-running loads that report progress instead of spinning. I held these dense operational screens to accessible contrast and keyboard-navigable tables, since people live in them all day.

04What I built

I shipped the connect, map, validate, and monitor surfaces of the pipeline: a source connector flow, a schema-mapping interface that suggests mappings to the canonical model and flags conflicts against OMOP, FHIR, and SNOMED, a validation view with field-level errors, and a run-monitoring dashboard exposing every pipeline state.

Working with PM and engineering, we negotiated scope around a hard constraint: schema suggestions were computed asynchronously on the backend and could take real time on large sources. Rather than block the user, I designed the mapping screen to let people start mapping manually while suggestions streamed in, and to reconcile the two without losing work. That constraint shaped the whole interaction model of the mapping step.

05Outcome

The pipeline shipped and became the foundation the team kept building on as the AI-native platform grew, anchored by a flagship pharma customer. It moved schema mapping from a data-team ticket queue toward self-serve: SMEs who used to file requests to the data team started completing mappings themselves, and setup for a new source dropped from days of back-and-forth to a guided session.

The v1 to v2 change came straight from watching real runs. Field-level errors were correct but scattered, so users fixed one, re-ran the whole pipeline, and hit the next. In v2 I added a consolidated validation summary that surfaced every failing field before re-running, which cut the re-run loops and the support tickets that came with them.

06Reflectionoptional

Cutting the any-to-any transformation builder was the right call for shipping a trustworthy v1, but I under-designed the escape hatch for the edge cases it would have covered, so power users hit a wall and routed around the product. If I did it again I'd ship the guided path with a clearly labeled manual override from day one, rather than treating that as a later concern.