About
Senior UX Engineer who builds the governance layer, not just the components.
14+ years across digital design, frontend engineering, and AEM architecture — mostly in regulated environments where the decisions compound.
- Role
- Senior UX Engineer · AEM Architect
- Location
- Omaha, NE — open to remote
- Experience
- 14+ years in digital products
- Current
- Enterprise financial services
- Years in digital — Design through engineering
- 14+
- AEM templates governed — Enterprise financial services
- 200+
- WCAG violations shipped — Across every component
- 0
- AA at component level — NVDA · VoiceOver validated
- WCAG
“The interesting problems aren't in the component. They're in what happens to it six months later — when three teams are using it differently and nobody remembers why it was built that way.”
What I do
AEM Architecture
AEM 6.5 and AEMaaCS at enterprise scale — Sling Models, HTL, OSGi, ClientLib architecture, and the component policies that keep shared codebases coherent across teams and years.
Design Systems & Governance
Token architecture, component APIs, and the governance model that determines whether a system survives contact with a real organization.
Accessibility Engineering
Built into the component, not retrofitted after QA. Validated with NVDA and VoiceOver — automated tools catch roughly a third of real failures.
Frontend Engineering
React, TypeScript, and Next.js at production scale — performance, responsive design, and the integration layer between design systems and delivery.
Why UX Engineering
I started in 3D animation — lighting and rendering work where the difference between good and almost-good is entirely visible. That precision followed me into digital product design at Bally Technologies, where I spent five years building UI systems for gaming platforms and learning that design decisions have engineering consequences whether you plan for them or not.
Moving into frontend engineering and then AEM architecture wasn't a pivot — it was what happened when I got tired of describing problems I could see and started being the person who fixed them. The interesting work happens where a design decision meets an engineering constraint and one person has to hold both.
That boundary is where I've worked for 14 years — in environments where the cost of getting it wrong is measurable.
Experience
Lead AEM Developer · Adobe Experience Cloud Specialist
Oct 2020 – Present
PNC Bank Corp · Contract via Indotronix
AEM component system across 3 business units — 200+ production templates governed without a regression. WCAG violations from 47 to zero through architectural remediation, not QA review. Adobe Target A/B testing, Akamai CDN, and headless delivery via Content Fragments and GraphQL.
Lead UI/UX Developer – AEM
Jan 2020 – Oct 2020
Verizon (via Infosys / Innova Solutions) · Contract
AEM components, Sling Models, and React SPA Editor integrations. Next.js SSR for performance and SEO. Component architecture aligned to enterprise design system standards.
Lead UI/UX Developer
Dec 2018 – Jan 2020
Maryland Dept of Human Services · Contract via Innova Solutions
Front-end engineering for a centralized government platform connecting multiple state agencies. Section 508 and WCAG compliance throughout.
Lead UI/UX Developer
Oct 2017 – Nov 2018
Omnicare (via TCS / Innova Solutions) · Contract
UI component libraries and design systems for enterprise healthcare applications.
Senior UI/UX Visual Designer & HTML Developer
Oct 2010 – Mar 2015
Bally Technologies · Bangalore, India
Visual design systems and UI component development for gaming platforms. Where design craft and frontend implementation first became the same problem.
Certifications
Adobe Certified Expert
Adobe Journey Optimizer Developer
Adobe
Adobe Certified Professional
Adobe Experience Manager Developer
Adobe
Things I keep returning to
01 — Foundational
The best frontend work is invisible. It shows up in what doesn't break, what authors can't misconfigure, and what the next engineer doesn't have to undo.
02
Diagnose before you build. The most valuable work on several projects was identifying what already existed.
03
Accessibility is an engineering decision at authoring time. Making it a QA gate just defers the cost.
04
A system that gives authors too much freedom will be used incorrectly. Constraints are a feature.
Good systems are defined less by what they enable and more by what they prevent. The measure of a design system isn't the components it ships — it's the inconsistencies, regressions, and authoring errors that never make it into production.