Rebuilding the leader platform for eye care training
I led product strategy and design for a replacement platform that launched on October 10, 2026, ahead of AAO. Two engineers built it. I scoped it, designed it in Figma and led design QA through launch.
My role
Chief Product Officer and sole designer: strategy, phased roadmap, UX/UI, design QA
Team
CEO (final approval), Head of Sales, Head of Marketing, two platform engineers, one engineer on NOVA
Constraints
Two engineers, a limited budget and a launch date set by AAO
Where it stands
Launched October 10, 2026. Approximately 100 existing practices migrated.
The practice leader dashboard: team progress, who needs a nudge, and reminders in one place. Animated from my Figma designs with demo data.
The problem
Our legacy platform couldn't support the customers we were trying to grow into. It had three gaps:
No automated subscriptions. Buying and changing licenses depended on our team.
No enterprise account hierarchy. A health system with regions and many locations couldn't be set up the way it actually operates.
No way for leaders to see learner performance. Practice leaders couldn't tell where their technicians stood.
Self-service purchasing had a specific business goal: free our Head of Sales to focus on enterprise accounts instead of routine transactions.
What we launched, and what we held back
With two engineers and AAO as the deadline, I scoped the first phase to leader accounts and kept learning in Absorb, our external LMS. Leaders buy, manage licenses and need visibility. That's where the gaps were.
In phase 1
Leader dashboards, self-service subscriptions, an org structure for multi-location accounts, and proficiency validation. Three account types: Solo, Growth and Enterprise.
Held back
A native learner portal, which I designed but we held for a later phase, and replacing Absorb, which was a call about bandwidth and resource control.
The trade-off is a split experience for learners, who start in NOVA and continue in Absorb. In exchange, the release stayed within what our team could build and support before AAO.
Key decision: an org structure that fits real practices
The hardest design problem was the account hierarchy, because no two customers were organized the same way. The structure decides who a leader can see, which licenses they control and where reminders go.
Our first model reflected one large organization with regions and locations. Others were single locations, practices that share technicians across sites, and groups where the person overseeing training isn't the practice leader. When technicians move between locations, a location-by-location hierarchy adds work without adding visibility, so I recommended those practices skip it.
Adding a level and allocating licenses to a region. Animated from my Figma designs with demo data.
1 · Designed
Engineering proposed a node-based structure. I designed the interface, permissions and setup flows on top of it. Before launch, we reviewed it with a large enterprise customer.
2 · Shipped
To hold the launch date, we shipped a simpler version: one fixed sequence of levels, with no inserting, deleting or renaming levels. Several rollout fixes landed within days.
3 · Concept, not built
After launch, I mapped a large customer's real structure with them and designed a flexible model. We chose to extend the shipped structure instead.
Language that leaders already use
Node, parent and child confused non-technical leaders, so I used group, sits under and levels instead. When our CEO suggested renaming "Add new level" to "Add New Practice / Location," I kept the original: in larger accounts, a new level can be a region or division, not only a location.
What rollout taught us
A level couldn't be created without licenses. Engineering fixed it, and we agreed that building a structure should never require licenses.
A level created at the wrong type couldn't be removed. This became part of the editing work.
The Move option disappeared when two groups shared a name.
Creating the first group in a new structure failed. Engineering fixed it on October 16, which unblocked two enterprise setups.
Two follow-ups shipped the week after launch: subscription management for leaders at any level, and moving up to 10 people at once between groups, which I requested for the enterprise setup.
The proposal we didn't build
The large customer's structure had four levels, mixed geography with functional departments, had groups led by more than one person, and was still changing. I designed a flexible structure in response: organizations name their own levels, a group can skip a level, groups move by drag and drop, and edits wait in a review step that shows who gains or loses visibility before anything goes live.
We decided to extend the existing structure with rename, delete and combine instead, within one constraint we agreed on: keep the number of new buttons low. Renaming is in testing, and I'm designing the delete flow on engineering's validation rules.
Completion isn't proficiency
Finishing a learning path shows a technician learned the material. It doesn't show they can perform the skill. I designed proficiency validation as a separate record so leaders can see both and never confuse one for the other.
A learner passes the Path Mastery exam for their level. Only then do they appear in the practice leader's validation queue.
The leader assesses the technician and scores each skill on a rubric.
Proficiency is approved only when every skill scores 3 or higher, or is marked not applicable.
The reviewer and the employee sign, and the provider can sign as well.
I designed the rubric, the approve and deny flow, the queue, the signatures and the reminders. Our CEO, who owns the curriculum, chose the skills and set the scoring rule. When the rubric's download button had nothing behind it, I hid it rather than ship a control that did nothing.
Validation is live for practice leaders. It records proficiency without blocking a learner from advancing. Next is an optional setting for organizations that want skill check-ins required before a learner moves up a level.
A leader validates proficiency after the learner finishes the path. Animated from my Figma designs with demo data.
Self-service that shows what you'll pay
Practices can now buy up to 50 licenses on their own. Larger purchases go to a sales call, a threshold our Head of Sales set. I designed the subscription and license management screens: monthly and annual plans, and adding, removing and allocating licenses.
Testing with our Head of Sales before launch, we found that switching from annual to monthly showed no price change, because the screen displayed the amount already paid. License removal also appeared on annual plans, where it shouldn't. I proposed labeling the figure "Upcoming payment" on monthly plans and "Annual price" on annual ones. Engineering shipped both fixes.
Inviting people and changing license types without a call to our team. Animated from my Figma designs with demo data.
How we worked
CEO. Final approval and feedback from customer calls. I adopted it where it made things clearer for leaders, and explained my reasoning where a change would have broken larger accounts.
Engineering. Proposed the node model and set validation rules for editing. I designed within those rules and reviewed builds against Figma in a shared QA tracker, where a fix counted as verified only after a second person retested it.
Head of Sales. Tested the platform and subscriptions with me, set the self-service threshold, and owned the migration plan.
Marketing. Owned the website content. I designed the new site and built it with Claude, and engineering reviewed the code.
Before launch, input came from our CEO, our Head of Sales and our medical board, plus a working session with a large enterprise customer. Since launch, I've met with that customer directly, and I send the team a weekly product agenda and recap.
Launch
We onboarded our medical board members' practices in August and September, then launched officially on October 10, 2026. Engineering migrated approximately 100 existing practices. After AAO, our CEO shared that several existing customers had stopped by our booth to say they liked the new tools and interface.
Next: editing for the org structure, an optional requirement to validate skills before advancing, and learner accounts.