eHealth sells health insurance from major carriers across the country. During my time there the focus was Medicare, specifically supporting the annual AEP cycle where agents enroll seniors in Medicare plans over the phone.

The internal tools I owned were not peripheral. 80 percent of eHealth's company revenue ran through them.

Medicare sales is regulated at both state and federal level. The primary customer demographic made purchases by phone, which meant legal disclaimers and fine print had to be read verbatim on every call. HIPAA compliance, plan recommendations, eligibility checks, power of attorney validations — all of it governed by the government and insurance partners, all of it updated annually.

Every year before AEP, scripts had to be updated to reflect changes from the government and from health insurance partners. Reviewed by legal, compliance, sales leadership, product, and external partners before a single agent could use it. That process took 6 months.

I sat in on live calls with agents before designing anything. What I found was a consistent gap between the process leadership designed and the shortcuts agents used to hit their numbers. They are on commission. They adapt.

The Script Builder had to be strict enough to enforce compliance and flexible enough that leadership could accommodate how agents actually worked. It also had to serve sales leadership, legal, compliance, product, and external partners — each with different needs and different relationships to the script.

The Script Builder is a no-code tool for creating and updating Medicare sales scripts. Users build questions using widget components — radio buttons, checkboxes, date pickers, text fields. Each question can be tied to a parent question creating nested conditional paths. A birthday question can branch into eligibility checks. A power of attorney flag can unlock a different qualification flow. The branching logic lives in the question builder, not in code.

Once a script is assembled it enters an approval flow. Legal and compliance receive an alert and review changes in context rather than in a document. An activity log tracks every change with full history.

The hardest design decision was drag and drop. Reordering questions and assembling scripts visually was significant engineering work and we had to honestly assess whether the interaction was worth the cost. It was. Without it the tool would have been something people worked around rather than worked with.

During my time at eHealth I also worked on a small business insurance initiative that came directly from a presidential administration in response to Covid.

Early calls on the East Coast, late calls with West Coast engineers until midnight. The first deliverable was a public website. We knew from the moment it launched there would be significant traffic — news from that office travels fast.

We made the decision to build the foundation and hand it off to the government to maintain. The work had to be solid because we were not going to be there to fix it. We shipped it.

Sales leadership could make changes directly without waiting on product, design, or engineering. Legal and compliance no longer felt like bottlenecks. Meetings that existed only to hand off the latest document were replaced by asynchronous workflows inside the tool.

The half year that had been absorbed by script maintenance became available for product work. That was the real outcome — not just a faster process but a team that could finally build forward.

The script that every stakeholder looked at for 6 months a year became something that could change in 30 minutes. That did not happen because we built something clever. It happened because we understood who was in the room, what they each needed, and what was actually slowing everyone down.

Sometimes with the correct understanding of users, designers can change the entire trajectory of a company. 80 percent of eHealth's revenue ran through the tools I owned. That is not a design problem. That is a business problem that design solved.