Designing silence

A notification that arrives at the wrong moment isn’t just annoying. In a medical context, it can do real damage.

Pura Health needed a notification framework that could serve two completely different goals at once: keeping users medically informed and safe, while also driving engagement, module adoption, and revenue.

Medical and marketing notifications sharing the same channel — with a user who might be waiting on life-changing test results.

The hardest design problem wasn’t the notifications themselves. It was defining when not to send them — and building a system smart enough to know the difference.

The system is built on three interconnected components. Priority levels. User states. Phased rollout.

Every notification — medical or marketing — passes through the same logic. The components aren’t independent; they’re designed to work together, with each one constraining the others.

“The system never infers emotional states. It works from facts. A test was ordered. Results are pending. Results arrived. The severity is known. That’s enough to behave with genuine sensitivity.”

Starting with principles, not rules.

Before writing a single rule, I defined the principles the system had to hold in every phase — not just at maturity. The most important: the system never infers emotional states. It works from facts. This sounds like a technical constraint, but it’s a design constraint. Every suppression rule had to be grounded in data the system actually has access to.

Medical notifications and marketing notifications are governed separately but need to be aware of each other. I mapped both systems — their priorities, their triggers, their caps — and then designed the relationship between them: the rules that determine when marketing yields to the medical system, and when it can operate freely.

Once the full system was mapped, I worked backwards from maturity to ask: what’s the minimum viable version that ships on day one and still behaves well? Phase 1 had to be respectful, functional, and buildable using only system data and simple rules. I then defined what Phase 1 would teach us, and what that learning would unlock in Phase 2.

One of the more useful things I did was explicitly document what sat outside my remit. Marketing strategy, pricing, campaign planning, development infrastructure — these all touched the notification system but weren’t mine to define. Rather than leave gaps, I documented what the system needed from each team and why. That made the handoff cleaner and the document more useful.

“Phasing isn’t a concession to development constraints. It’s a design decision that determines what you learn and when.”

Notifications are a product decision, not a feature.

Most notification design happens late — someone builds the product, then asks what to notify users about. This project taught me that the notification system needs to be designed in parallel with the product, not after it. Every module, every user journey, every clinical event has a notification implication. If you don’t design the system upfront, you end up with a patchwork of triggers with no coherent logic underneath.

The hardest question is when to stay silent.

Early in the process I focused on what to send. The more interesting design problem turned out to be suppression — the rules that govern when the system holds back. A user waiting on test results doesn’t want to see a marketing promotion. A user who just received a serious diagnosis needs space, not a streak reminder. Defining those moments required thinking about the emotional reality of a medical journey, not just the data model.

Medical and marketing can coexist — if you design the relationship explicitly.

The instinct when building a medical product is to treat marketing notifications as a necessary evil. I pushed back on that framing. Marketing notifications are how the product sustains itself and grows. The design challenge is making the two systems aware of each other — so that marketing knows when to stand down and when it’s appropriate to speak. That relationship has to be designed. It doesn’t emerge on its own.

Designing for a user you can’t observe directly.

In consumer product design, you can watch users interact with your UI. In a medical notification system, the most important moments happen away from the screen — a user reads a result, processes difficult news, decides whether to trust the product enough to keep going. Designing for those invisible moments required thinking through scenarios rather than flows, and writing rules that would hold up in situations I couldn’t prototype.

“The most important design moments in this project happen away from the screen — and can’t be prototyped.”

A notification system designed to be trusted — by users who might be going through the hardest moments of their lives.

The strategy document was delivered to the product and development teams and used directly to inform the build plan. The priority framework, user state model, and phased rollout structure were adopted as the foundation for the notification system. A companion marketing notification document was produced separately for alignment with the commercial team.

Beyond the deliverable, the project established a principle that carried into other work at Pura Health: systems thinking and clinical sensitivity aren’t in tension. Done well, they reinforce each other.