Your Next Lab Build Will Be Defined By What Happens Before Design Begins

During a capital project, the lab programming phase is where the foundation is laid. Yet, you’ve seen it happen: a life sciences facility gets built, the team moves in, and within months the space is already fighting the science.

This isn’t a construction problem; it’s a breakdown in the initial lab programming phase, and it almost always traces back to critical operational questions that were never asked early enough.

The Translation Problem No One Talks About

There’s a persistent gap in most lab projects between what scientists need, what facilities teams document, and what designers actually build. Lab Managers and Directors sit at the center of that tension. But you understand the science. You know the workflows. You know which protocols are evolving and which constraints are non-negotiable. But on most projects, that knowledge doesn’t make it into the design basis in a structured, defensible way.

The result? A facility that was built to a brief, just not necessarily your brief.

At Genesis AEC, we’ve spent years working at exactly that intersection: between the science, the safety requirements, the business drivers, and the built environment. The single biggest differentiator between projects that deliver and those that don’t isn’t budget or schedule. It’s how rigorously the lab programming phase is conducted before schematic design ever starts.

“The questions we ask,  and how and when we ask them, can make all the difference between a project that works and one that doesn’t.”

Kelly Smyth, Lab Design Conference 2026

What a Rigorous Lab Programming Phase Actually Prevents

Consider a real scenario: a facility management team documents a small prep lab as not requiring BSL-2 ventilation. It is a reasonable assumption based on what they were told. But in direct conversations with the researchers using that space, it becomes clear they’re already following BSL-2 protocols for tissue handling and storage.

If that misalignment surfaces mid-construction, you’re looking at massive redesign costs, schedule delays, and potential compliance issues. Caught at the programming kickoff, it’s just a conversation and a simple scope clarification.

That kind of gap—between what is assumed and what is actually true—is more common than most project teams want to admit. It shows up in safety classifications, equipment infrastructure assumptions, and critical adjacency requirements that never made it onto the initial bubble diagram. A structured programming process is specifically designed to surface these discrepancies while it is still cheap to act on them.

Where Your Science Expertise Should Live in the Process

The research-to-commercialization continuum shapes everything about how a lab needs to work. Early discovery requires spatial openness and fluid adjacency priorities; cGMP manufacturing demands strict process controls and rigid quality documentation. Where your program sits on that continuum has direct implications for infrastructure, regulatory compliance, and how flexible or fixed your spaces need to be.

The problem is that most traditional design processes don’t have a structured way to capture and formalize that context early. User interviews happen late or not at all. Questionnaires are generic. Rare is the project where someone maps the safety and hazard classifications against the science workflow and the building code layer simultaneously before schematic design starts.

That multi-dimensional mapping is exactly what a comprehensive lab programming phase produces. It is the mechanism that protects your science requirements from getting value-engineered or compromised downstream when budget pressures hit.

Why the Genesis approach is different

We treat programming as discovery work, not paperwork. That means we come into every project prepared to challenge assumptions in the initial brief, facilitate structured conversations between your scientists and your facilities team, and translate scientific and safety requirements into a documented design basis that the whole project team, architects, engineers, contractors, can actually use.

The outputs aren’t just reports. They’re living documents: room data sheets, adjacency diagrams, space lists, lab cards — tools that carry your requirements through design, prevent scope drift, and give you a defensible record to return to when someone wants to change direction.

Shape the Brief Before the Design is Locked In

Lab Directors and Managers who engage a specialized lab planner early, before the design team is locked in and before the brief is finalized, have significantly more influence over final project outcomes. You’re no longer reacting to a schematic that doesn’t reflect your science. Instead, you’re shaping the brief that the schematic has to honor.

Kelly Smyth presented this framework at the Lab Design Conference, sharing how the programming phase is where the real work happens, and where the right expertise makes the biggest difference.

Watch the Full Session

In her presentation, “Strong Foundations: Building Understanding Through Lab Programming,” Kelly covers our full approach from priority mapping and user interviews to safety classification and design basis documentation. Taking 24 minutes to watch her session could fundamentally reshape how you approach your next capital project.