Why it exists
When I joined APA, the UX team had a Pattern Library 1.0 built on Bootstrap 4 — a collection of static HTML/CSS documents used inconsistently across only some sites and apps. The move to 2.0 was driven by Bootstrap 4 reaching end of support, a growing need for new patterns as more projects came in, and my own push to modernize the library into something more usable than a set of static documents. It grew organically out of my early work rebuilding our base framework on Bootstrap 5, predating the E-Commerce Redesign project.
What changed
Our design team shared responsibility for the library, but I took primary ownership given my coding background, doing the bulk of the hand migration — this was before AI tooling made this kind of work faster — across roughly 20 components: accordions, modals, form fields, tooltips, alerts, badges, and more, each covering multiple variants like sizing and dismissible states. Every migrated pattern was checked against Bootstrap 5’s updated responsive classes, browser compatibility, and accessibility, including ongoing ARIA cleanup.
A dual-format system
The library exists in two synchronized forms: a coded component library, with documentation and usage guidelines, used for prototyping and developer reference; and a matching Figma library used for design work. The two are kept in sync through a ticket-based process — whenever a pattern changes in one, a ticket ensures the same change gets made, and tracked, in the other.
Governance
Our process is informal but tracked: any new pattern gets reviewed by the whole team before work begins, Jira tickets track the work itself, and releases follow semantic versioning with a maintained changelog — a lightweight process that scales fine for a small team while keeping everyone visible into what’s changing and when.
Adoption & impact
Adoption grew naturally, with no real resistance — we included the library in mockups from the start and made the case in meetings that it reduced developer styling overhead while increasing consistency across products. It’s now used far more broadly across our team’s sites and apps than 1.0 ever was, sped up my own mockup work directly — including on the E-Commerce Redesign — and some developers have adopted it for proof-of-concept work to stay aligned with established patterns.
It’s not a “here it is, we’re done” artifact — it’s a living collection that evolves as the organization does.
The bigger story
Pattern Library 2.0 isn’t a finished deliverable. Patterns get added, but just as often they get edited and adjusted to fit how the team and organization are growing. That includes current work to reduce technical debt by moving the library’s underlying foundation toward better-maintained, lower-overhead open-source frameworks — part of an ongoing effort to keep the system healthy, not just feature-complete.