Designing Around Conditional Logic, With R&D in the Room

Working with Menora's R&D taught me that on enterprise insurance products, the interface is the visible tip of an enormous rules engine. Many fields, many roles, many conditional rules — and most of that logic lives in code, not in a mockup. So I treated engineers as collaborators from the first sketch, not recipients of a finished file. For an R&D leader, the value is fewer surprises. When I designed the role-based sales views — the same data reframed for agent, marketing, district manager, team lead, and underwriter — the early conversations were about feasibility: which role-conditional states are real, which combinations can actually occur, where the data model constrains the UI. That's cheaper to resolve in dialogue than in a sprint. Designing the agent-fee flow's multi-axis filtering the same way meant edge cases surfaced as questions, not as bugs. I'd rather hear "that state can't happen" early than discover it in QA. Good design-R&D collaboration on a system this conditional isn't about handing over pixels — it's a shared model of what the system can and cannot do.