Alcon Healthcare Platforms

Cataract surgery replaces the eye's cloudy natural lens with a clear artificial intraocular lens, or IOL. Before surgery, clinics collect diagnostic measurements, review patient history, discuss lens options, prepare surgical plans, and help patients understand decisions that can affect both vision and cost.

Alcon already had a strong presence across this ecosystem through surgical products, devices, and planning tools. The product challenge was to make clinical planning, patient education, consultation, and surgical handoff feel more connected over time, even when the first release needed to ship as standalone product experiences.

Across the work, I designed clinical planning and patient engagement experiences, shaped role-based setup and data-heavy review workflows, explored future integration paths, and helped improve production UI quality through coded prototypes and frontend collaboration.

My work sat across two connected product areas: clinical planning and patient engagement. Clinical planning helped clinic teams manage setup, roles, patients, ophthalmic history, diagnostic measurements, and surgery planning; patient engagement helped admins configure educational content, automate what patients received, and give counselors clearer context before consultation.

Across both areas, I designed workflows that reduced fragmented effort across the care journey, including role and clinic management, measurement review, post-surgery data capture, patient education packages, questionnaires, daily preparation views, and patient-level engagement details. I also prototyped how standalone releases could later fit into the broader planning platform, helping the team make clearer decisions about information architecture, shared interaction patterns, and where patient engagement belonged long term.

The product was caught between a legacy design system originally created for physical surgical devices and a newer software design system being introduced in parallel. The legacy system supported touch and accessibility well, but made dense software screens feel heavy; the newer system better fit the future, but the team did not have resources for a full migration. Meanwhile, the component library was early-stage, design and production had drifted apart, and developers were applying patterns inconsistently or creating one-off UI fixes.

I partnered with the development architect to create a practical bridge instead of pushing for a broad redesign. Using AI-assisted development workflows, I prototyped how newer design-system variables could improve the existing component library, helped bring those patterns into the product UI, created component backlog items, reviewed implementation quality, and ran sprint-by-sprint sessions with frontend developers. That shifted my role from Figma handoff to technical design partner, improved consistency between Figma and production, reduced one-off styling, and influenced how design leadership thought about applying this model across other products.

1. Strong design partnership starts earlier

I learned that strong design partnership requires more than responding to requests. Being involved earlier in product and engineering discussions helped me ask why a feature was needed, what problem it solved, and how it fit into the broader workflow. Those questions sometimes created tension, but that tension was often productive because it helped the team clarify assumptions, understand the problem space, and align on better decisions.

2. AI adoption is not only a tooling decision

This project reinforced that AI-assisted design and prototyping can move faster than security review, procurement, and governance processes, especially in healthcare. I had to work within approved tools while still exploring how AI-assisted prototyping could improve speed and fidelity.

3. AI adoption requires team alignment

I learned that there is still more work to do around team alignment when adopting AI-assisted workflows. The workflow can look different from conventional design processes, especially when designers have different levels of comfort, access, and experience with AI tools. For AI-assisted prototypes to be useful beyond individual exploration, the team needs shared expectations for how decisions are documented, reviewed, and translated back into Figma, prototype code, and production components.