The Many Faces of Themeable Design Systems
Very rarely is exactly one design system created to serve exactly one product that expresses exactly one design language. Nearly all the design systems we’ve worked on require a high degree of flexibility in order to properly serve our clients’ needs. Some of this flexibility is achieved by variability in component structure, style, behavior, and content. But advanced aesthetic flexibility is ofte
Atomic Design
Hey there! I wrote a book called Atomic Design that dives into this topic in more detail, which you can buy as an ebook. We’re not designing pages, we’re designing systems of components.—Stephen Hay As the craft of Web design continues to evolve, we’re recognizing the need to develop thoughtful design systems, rather than creating simple collections of web pages. A lot has been said about creating
Design Systems are for user interfaces
We often talk about design systems as singular entities. “The design system saves time and increases quality.” “Oh, the design system provides that.” “Update to the latest version of the design system.” The reality is that a design system is a multi-faceted layer cake, and also operates as part of other layered systems within an organization. Design systems are systems of systems, but not all syst
A Design System Governance Process
You can have a comprehensive design system that contains a slew of well-structured components, thorough documentation, thoughtful guidelines, and a well-considered design language. But if a design system user can’t get done what they’re trying to get done, the whole system risks obsolescence. Product teams’ primary concern is getting work out the door, not to uphold the integrity of the design sys
Where to put one-off components?
A while back, Harry Roberts introduced the concept of shame.css: a stylesheet dedicated to housing your nasty, hacky, quick-fix CSS The idea is to isolate all the stuff that doesn’t belong in your beautiful, well-architected CSS architecture, in order to revisit it when the team has time to refactor code and create more sturdy solutions. Application-specific components At the heart of a design sys
What's wrong with CSS-in-JS?
I have yet to dive deep into CSS-in-JS, but I’ll admit I’m skeptical. This podcast by Chris Ferdinandi lays out a lot of the reasons why I’m a bit apprehensive. Three other observations I’ve noticed as I encounter CSS-in-JS in my consulting clients’ work and other projects I come across: Lack of portability: So much of my work involves helping gigantic organizations create and deploy design system
Creating Themeable Design Systems
TL;DR: Design systems + CSS Zen Garden = Awesome. Is it possible to create a single design system that powers wildly different-looking brands and experiences? The answer is yes! But why would you want to? Different audiences and contexts – The team at GE recently discussed the opportunities and challenges of sending their Predix design system to different audiences within their gigantic, diverse o
Style Guide-Driven Design Systems
There are many facets of a design system initiative, so it can be extremely daunting to figure out where to begin. There are stakeholders to educate, tools to choose, principles to establish, frontend guidelines to settle on, components to build, tokens to create, design guidelines to write, contribution models to sort out, and so on. In my workshops and consulting engagements, I’ll often have tea
Your Sketch library is not a design system redux
I wrote a post where I talk about how a set of components living inside static design tools like Sketch isn’t itself a design system. Pardon my clickbait. Perhaps a better title would have been “Your Sketch library is not a(n entire) design system.” No doubt tools like Sketch are super valuable, and having a set of reusable components inside them helps design teams establish thoughtful and consist
Your Sketch library is not a design system
You can write words explaining how to properly use a toaster, draw pictures of toasters, and even create more efficient ways to draw pictures of toasters. But at the end of the day, if you don’t have a functioning toaster, all that effort is for naught. In my design system workshops at design conferences, I’ll ask attendees where they are in their design system journey. Most hands go up when I ask
Design System Frictions
Creating a design system to serve an organization’s digital products is a delicate dance of decision-making, compromise, and balance. There are some intrinsic frictions that every organization creating and maintaining has to address. There’s no shortage of eternal battles in the web design and development world. All of these tool and technology decisions are perfectly valid. There’s no wrong answe
Interface Inventory
Many are familiar with the concept of a content inventory. Content audits are usually performed in the early stages of a website redesign process to take stock of all a site’s content. It’s a tedious process involving spreadsheets and caffeine, but the hard work pays off. You end up all your content laid out on the table, which gives you a new perspective on what your content is and how to tackle
Things you could be doing instead of designing & building that card component for the umpteenth time
Things you could be doing instead of designing & building that card component for the umpteenth time Making that card pattern more accessible Making that card pattern more responsive Making that card pattern more performant Making that card pattern more agnostic so it can handle different content patterns Making that card pattern more resilient to extreme content edge cases Creating a thoughtful v
Pattern Variations
At the heart of a good design system is a set of solid, flexible components that can be arranged to create cohesive, delightful user interfaces. There’s an oft-repeated misconception that pattern-driven design and development forces teams to use a finite, rigid set of components that stifles creativity and doesn’t serve the real needs of applications. That’s only true if you design the system that
CSS Architecture for Design Systems
We just created a design system for a huge organization and established a CSS architecture we’re quite pleased with. It’s one of the first times I’ve ever gotten to a project’s finish line without wishing I’d done at least a few things differently. So I thought it would be great to share how we went about creating our system’s CSS architecture. To give a bit of a context for the project, we were t
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Design system versioning: single library or individual components?
Better Numerical Inputs for Mobile Forms
Enforcing Accessibility Best Practices with Component PropTypes | Brad Frost
Dealing with Site Headers in Design Systems
Managing Technology-Agnostic Design Systems