Designing for understanding.

Healthcare experience. A wider lens.

Medication schedules and insurance information ask an interface to do more than look simple. It must make choices understandable without removing the detail a person needs. That tension has shaped how I approach product design.

I see that experience as a transferable strength. The same questions appear wherever a product contains rules, unfamiliar information or a task people cannot afford to misunderstand: what matters now, what can wait, and how does someone change their mind?

From the task to the interface.

I work from the task and the available evidence toward flows, wireframes, prototypes and UI. I want a design decision to be explainable: which problem does it address, which trade-off does it make, and what would we need to learn next?

For the MyTherapy and CDPHP work presented here, I was the main designer within the shown scope. The cases describe contribution and decision-making rather than attaching unsupported outcome numbers to the screens.

Design is a shared conversation.

Working with UX, business analysis, QA and developers brings assumptions into the open. A shared UI vocabulary helps, but so do clear states, links between requirements and design, and documentation that reflects the current interface.

My developing AI practice follows the same principle: assistance is useful when its limits remain visible and a person can challenge the result. The demonstrations on this site are teaching concepts prepared for review, not evidence of shipped AI client work.