Redesigning Eyetelligence around the surgeon's day

• —Research synthesis: turned the inherited materials and alignment sessions into working design principles.
• —System analysis: site maps, documented workflows, and a heuristic review of the existing IA.
• —Field research: on-site clinic observations with surgeons and coordinators.

Two Hard Arguments

Two of the loudest disagreements with the marketing team were settled in testing, both by evidence rather than by opinion.

The default theme

The marketing team was certain the light theme should be the default. Then we tested. Every clinician chose the dark theme, because exam rooms and ORs are kept dim and a bright screen is a problem there. The system's theming support stopped being a nice extra and became a clinical requirement.

The calculator

The IOL calculator changed more than anything else in the product: a five-page flow collapsed to two, built around one long calculation view where every change recalculates in place, then a confirmation step. Marketing resisted this hardest. The mental model was different, the order of actions had changed, and they argued the long screen would be inconvenient and wanted a step-by-step wizard instead. Surgeons in testing came down firmly on the side of the long view: they could finally see the whole calculation and how each change moved the result.

The timeline only worked because of the system underneath it. Instead of drawing components from zero, I set up a production component kit and customized it into the Eyetelligence system: tokens, light and dark themes, and a library organized one page per component. Each page is a full specification sheet, with the component's states and sizes, a live demo, and links to the docs the development side works from. It is the reason one designer could produce a full product's worth of screens in ten weeks and keep them coherent.

The harder half was the components a general kit has no answer for: the ones a surgical planning tool needs to hold up against real operating-room workflows. I designed those into the same system, so clinical work was covered by the design system, not bolted on beside it: the eye preview, astigmatism vector analysis, toric cylinder power selection, diagnostic image galleries, and the surgery and appointment cards.

Dashboard personalization

I put the day's work first: surgeons get personal task lists and day views with quick access to OR-ready plans, and coordinators get month views with multi-surgeon task management and practice metrics. Both come straight out of the discovery finding that people wanted their day on screen, not a database.

Streamlined calculations

The calculator is one continuous view. Change an input and the formulas update in place, so surgeons can compare options without paging back and forth. This is the screen the marketing team wanted split into a wizard, and the one surgeons defended in testing.

Facilitated connections

Tasks carry the work between surgeons and their staff. Scheduling an appointment creates the related planning tasks automatically, so handoffs stop depending on someone remembering to ask.

Planning-first patient management

Patient records exist here to serve planning, not to replace an EMR. Surgeons and coordinators track calculations and compare plans without wading through general-purpose record keeping.

The last stretch of the ten-week sprint turned the validated concepts into a prototype covering the product's full functionality, plus everything needed to build it: documented component variants, interaction patterns, and final specifications. From there I stayed with the project through the end of the year, supporting the development team and designing the remaining use cases as they surfaced in the build.