<?xml version="1.0" encoding="utf-8"?><?xml-stylesheet type="text/css" href="https://www.aaron-gustafson.com/c/feed.min.css" ?><feed xmlns="http://www.w3.org/2005/Atom"
      xmlns:amg="https://www.aaron-gustafson.com.com/amg-dtd/"><title>Aaron Gustafson: Content tagged pattern libraries</title><subtitle>The latest 20 posts and links tagged pattern libraries.</subtitle><id>https://www.aaron-gustafson.com</id><link href="https://www.aaron-gustafson.com/feeds/pattern-libraries.xml" rel="self"/><link href="https://www.aaron-gustafson.com"/><author><name>Aaron Gustafson</name><uri>https://www.aaron-gustafson.com</uri></author><updated>2026-04-29T12:30:00Z</updated><entry><id>https://www.aaron-gustafson.com/notebook/links/ai-assisted-coding-transforms-pdf-to-web-app-using-nys-design-system/</id><title type="html"><![CDATA[🔗 AI-assisted coding transforms PDF to web app using NYS Design System]]></title><link href="https://www.aaron-gustafson.com/notebook/links/ai-assisted-coding-transforms-pdf-to-web-app-using-nys-design-system/" rel="alternate" type="text/html" /><link href="https://www.linkedin.com/posts/plasticmind_designsystem-ai-civictech-share-7420295564430450688-0RM5/" rel="related" type="text/html" /><published>2026-04-29T12:30:00Z</published><content type="html" xml:base="https://www.aaron-gustafson.com"><![CDATA[<p>This is a compelling illustration of what becomes possible when a design system is structured well enough to be usable by both people and machines.</p><p>What’s exciting to me here is not “AI turned a PDF into an app” so much as what made that possible: components, tokens, utilities, and enough design-system clarity to give the model something useful to work with. That’s a big part of the story so many people miss. If your system is inconsistent, vague, or poorly documented, AI is just going to amplify that mess.</p>]]></content><amg:twitter><![CDATA[A well-structured design system is not just a delivery mechanism for consistency; it’s also critical infrastructure for AI-assisted coding.]]></amg:twitter><amg:summary><![CDATA[This is a compelling illustration of what becomes possible when a design system is structured well enough to be usable by both people and machines.]]></amg:summary><summary type="html"><![CDATA[<p>This is a compelling illustration of what becomes possible when a design system is structured well enough to be usable by both people and machines.</p>]]></summary><category term="AI/ML" /><category term="pattern libraries" /><category term="web development" /><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://media.licdn.com/dms/image/v2/D5622AQFo6j6tbFv-DA/feedshare-shrink_800/B56ZvovfsWIcAo-/0/1769136324329?e=2147483647&amp;amp;v=beta&amp;amp;t=r42eIGZqMXi54JFEnnbEc0X6GBPXxDIBEq9mOos1Qm0" /></entry><entry><id>https://www.aaron-gustafson.com/notebook/links/design-systems-cant-automate-away-all-of-your-accessibility-considerations/</id><title type="html"><![CDATA[🔗 Design systems can’t automate away all of your accessibility considerations]]></title><link href="https://www.aaron-gustafson.com/notebook/links/design-systems-cant-automate-away-all-of-your-accessibility-considerations/" rel="alternate" type="text/html" /><link href="https://zeroheight.com/blog/design-systems-cant-automate-away-all-of-your-accessibility-considerations/" rel="related" type="text/html" /><published>2026-04-23T12:10:00Z</published><content type="html" xml:base="https://www.aaron-gustafson.com"><![CDATA[<p>Eric does an excellent job outlining the kinds of accessibility issues design systems and automated tooling can reduce, but never fully eliminate.</p><p>This is the part too many teams miss: accessibility doesn’t end at the component boundary. A well-built component library can give you a stronger foundation, but it can’t guarantee the right labels, the right heading structure, the right focus management, or the right overall experience once those pieces are assembled into an interface. That work still requires judgment, care, and testing with actual people.</p>]]></content><amg:twitter><![CDATA[Passing automated checks is not the same thing as delivering an accessible experience.]]></amg:twitter><amg:summary><![CDATA[Eric does an excellent job outlining the kinds of accessibility issues design systems and automated tooling can reduce, but never fully eliminate.]]></amg:summary><summary type="html"><![CDATA[<p>Eric does an excellent job outlining the kinds of accessibility issues design systems and automated tooling can reduce, but never fully eliminate.</p>]]></summary><category term="accessibility" /><category term="inclusive design" /><category term="pattern libraries" /><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://zh-marketing-wordpress-uploads.s3.amazonaws.com/wp-content/uploads/2025/11/blog-feature-computer-yellow.png" /></entry><entry><id>https://www.aaron-gustafson.com/notebook/planning-adaptive-interfaces-the-workshop/</id><title type="html"><![CDATA[✍🏻 Planning Adaptive Interfaces: The Workshop]]></title><link href="https://www.aaron-gustafson.com/notebook/planning-adaptive-interfaces-the-workshop/" rel="alternate" type="text/html" /><published>2016-02-21T23:56:05Z</published><content type="html" xml:base="https://www.aaron-gustafson.com"><![CDATA[<p>For the last few years I’ve been running a workshop alternately titled “Planning Adaptive Interfaces” or “Beyond Responsive”, depending on the conference. It’s been one of my favorite workshops to run for a number of reasons, but before I get into that, let me explain what it is and how it works.</p><p>I think we all recognize how much Ethan’s seminal article <a href="http://alistapart.com/article/responsive-web-design">“Responsive Web Design”</a> (and <a href="https://abookapart.com/products/responsive-web-design">his follow-up book</a>) shook up our industry. It changed the way we look at visual design and kindled (or in some cases re-kindled) an interest in catering an experience to mobile devices. But simply incorporating responsive design’s three core strategies—fluid grids, flexible media, media queries—is not the goal; meeting our user’s needs is. Responsive design is not an end in itself… it’s just the beginning.</p><p>We need to embrace the heterogenous nature of the Web—myriad connected devices with vastly different screen sizes (if they even have screens), network connectivity, and capabilities in use by countless individuals, each with their own special needs—and craft experiences that will work anywhere at any time. We need to build robust systems that adapt in ways far beyond aesthetics. I designed this workshop to explore the rich variety of use cases that often get overlooked in the course of building web projects and to show how we can begin considering them as early as possible.</p><p>When I was starting out, I gave “workshops” that basically amounted to a half-day or (worse) a full day for folks to listen to me blather on about one topic or another. People liked them, but I wouldn’t call them fun. And, in hindsight, I question how much value people got from an extended survey of what’s possible without the opportunity to put that knowledge to use. Workshops should encourage attendees to get their hand dirty.</p><p>I kick this workshop off with a relatively brief discussion of the considerations that we should be aware of—beyond screen size and pixel density. I also provide examples of how to adapt interfaces so they rise to meet our customers’ needs. Then I throw out a list of common interface patterns—modals, tabs, etc.—and turn the floor over to the attendees, asking them to build small teams that each examine a single pattern in detail with these considerations in mind. They then spend the rest of the workshop planning out how that interface would adapt to consider factors like accessibility, screen dimensions, device capabilities, JavaScript availability, and so on. All the while, I circulate among the groups, asking and answering questions, pressing them to go a little further with each iteration. Some teams sketch, some prototype, and all spend a lot of time debating, which is awesome!</p><p>I leave the last hour or so for a group discussion of what each team’s accomplished. It gives them a chance to talk through their approach, what they learned, what their pain points were, and how they overcame them. Not does it celebrate their work, but it helps the other attendees discover novel ways to approach these common UI constructs.</p><p>It’s been a blast and I have learned so much from the teams I’ve coached. Each workshop is completely different because each group of attendees is completely different. I’ve run it with groups ranging from 12 to 120, for internal teams at large companies to mixed audiences from all over the world. Everyone who has attended one of these workshops has brought a unique perspective and helped us all get better at our jobs. That’s been one of the best parts of this experience for me.</p><p>If a workshop like this sounds up your alley, I’ll be giving it a few more times in 2016. Your next opportunity will be at <a href="http://enhanceconf.com/workshop.html">EnhanceConf in London in early March</a>. Later in the year, I’ll be giving it as part of <a href="https://buildright.io/maker-series/2016/aaron-gustafson">Sparkbox’s Build Right: Maker Series</a>. I’d love the opportunity to work with you if you can make it!</p>]]></content><amg:summary><![CDATA[For the last few years I’ve been running a workshop alternately titled “Planning Adaptive Interfaces” or “Beyond Responsive”, depending on the conference. It’s been one of my favorite workshops to run for a number of reasons, but before I get into that, let me explain what it is and how it works.]]></amg:summary><summary type="html"><![CDATA[<p>For the last few years I’ve been running a workshop alternately titled “Planning Adaptive Interfaces” or “Beyond Responsive”, depending on the conference. It’s been one of my favorite workshops to run for a number of reasons, but before I get into that, let me explain what it is and how it works.</p>]]></summary><category term="conferences" /><category term="progressive enhancement" /><category term="responsive web design" /><category term="pattern libraries" /><category term="empathy" /><category term="Adaptive Web Design" /></entry><entry><id>https://www.aaron-gustafson.com/notebook/unum-releases-their-pattern-libraries/</id><title type="html"><![CDATA[✍🏻 Unum Releases Their Pattern Libraries]]></title><link href="https://www.aaron-gustafson.com/notebook/unum-releases-their-pattern-libraries/" rel="alternate" type="text/html" /><published>2015-08-04T17:55:34Z</published><content type="html" xml:base="https://www.aaron-gustafson.com"><![CDATA[<p>Insurance company <a href="http://www.unum.com/">Unum</a> has just released the “UX Toolkits” (a.k.a. patten libraries) they use for both Unum and Colonial Life. They are pretty bare-bones right now, but I am hopeful they will flesh them out over time.</p><ul><li><a href="http://toolkit.unumux.com">Unum UX Toolkit</a></li><li><a href="http://toolkit.coloniallifeux.com">Colonial Life UX Toolkit</a></li></ul><p>I love it when companies share stuff like this.</p>]]></content><amg:summary><![CDATA[I love it when companies share stuff like this.]]></amg:summary><summary type="html"><![CDATA[<p>I love it when companies share stuff like this.</p>]]></summary><category term="web design" /><category term="pattern libraries" /></entry></feed>