👈 Home

OneSpan Design System: Accessibility at Scale

Hired to unify a fragmented multi-app portfolio into a single design system — then had to adapt strategy when engineering buy-in stalled.

Impact

The Mandate — and the Gap

I was hired specifically to build OneSpan's design system — which meant the executive mandate existed, but the organizational alignment didn't. Engineering buy-in was never guaranteed, and closing that gap became as much of the job as building the system itself.

Discovery First

Before touching a component, I audited OneSpan's products to map the problem space:

• Identified reusable patterns to reduce redundant design and dev work
• Mapped visual and functional inconsistencies across the product portfolio
• Catalogued accessibility gaps against WCAG 2.1 AA standards

Leadership already had ADA compliance on their radar — our resident accessibility expert conducted regular audits and filed bug reports continuously. The audit gave me the data to prioritize which gaps to close first and to frame the system as risk mitigation, not just a design efficiency play.

Opinionated by Design

The most important product decisions weren't about what to include — they were about what to exclude and what to enforce.

Knowing that accessibility knowledge varied widely across the team, I built the system so that the accessible path was the path of least resistance:

• Form controls include labels and help text by default — no critical context can go missing
• Deliberately excluded problematic patterns: tooltips, disabled buttons, placeholder text
• Pre-validated accessible color pairings built into every component — designers never have to guess what's compliant

These weren't aesthetic choices. They were guardrails that made doing the right thing easier than doing the wrong thing.

Stress Testing the System

I validated the library's flexibility by running workshops where designers used it to rebuild complex external interfaces — including Twitter. Edge cases surfaced immediately, component gaps were identified fast, and designers learned to work within principled constraints without reverting to old habits.

When Buy-In Stalls, Adapt

Despite four years of demonstrated ROI in design velocity and risk mitigation, I couldn't close the gap to a company-wide engineering rollout. Leadership remained focused on short-term features over long-term infrastructure — a familiar tension.

Rather than stall, I pivoted scope. I refocused the system on maximizing the UX team's internal efficiency, which delivered 400K+ component insertions without a mirrored code library. Not the outcome I was hired for — but the best outcome available within the constraint.

The lesson: organizational buy-in is a product problem, not a design problem. A system nobody uses is a system that didn't ship.

👈 Home

Let's connect

I'm always up for a chat about design, working together, and .

Forked from resume-template and subsequently hand-adapted by Francis Wu © 2026