Tagged “designsystems”

Hard to argue with Brad’s logic.

Right now, vast numbers of human beings are devoting their time and energy to designing, building, documenting, and maintaining the exact same set of common components.

Our efforts to reduce duplicative work at the individual level are resulting in duplicative work at the inter-organization level.

A Global Design System would improve the quality and accessibility of the world’s web experiences, save the world’s web designers and developers millions of hours, and make better use of our collective human potential.

Here’s Eric Bailey with some very relatable thoughts on the need to tell design system stories even though it’s difficult.

The component works. And because it works, nobody pays attention to it.

This is the promise of a design system made manifest: Consistent, quality experiences for complicated interactions, distributed at scale with minimal fuss.

This is objectively great. The problem, however, is how we talk, or fail to talk about this type of success.

The FT’s design system Origami not only has a cool name but also some interesting metrics.

In this talk at State of the Browser, Amy offers some suggestions for making work feel more meaningful.

Nathan on how complex components require comprehensive specifications rather than ill-advised assumptions, and how Figma can be used to guide engineers to reliably build such components.

I’m still amazed when designers schlep together a few pictures, publish a configurable Figma component, point their developer counterparts at the main component and say “Use Figma’s inspect tool.”

Things have changed. Components are more complicated. Designers are delivering to many different developers. Accessibility has risen to the fore. For design systems that scale, teams are finding it necessary to write down all the details again.

This Design System reference website sports a smart architecture with some interesting sections.

Two lovely new websites (or website updates) appeared on my radar this last week that I wanted to note here for future front-end inspiration.

Vitaly Friedman’s Smart Interface Patterns has had some lovely animation and component work from Clearleft alumni Cassie Evans and Trys Mudford. Given Vitaly’s obsession with creating accessible, user-friendly components and the collaborators he has on board, I expect this site to be choc-full of well crafted nuggets for reference! It looks ace, too.

I noted a while ago that the W3C had a new Design System, and now the W3C has a new website in beta too. I imagine it might use components from that Design System alongside other carefully-considered patterns of markup, style and behaviour.

Nice job on these sites, to all concerned!

I was delighted to discover that my talented colleague Anda has her own website and uses it to write articles like this! This one is obviously pretty relevant to me too, given that I work on the same team.

Something we often talk about in our Design System team is that components should not be like Swiss Army Knives. It’s better for them to be laser-focused because by limiting their scope to a single task they are more reusable and support a more extensible system through composition.

Adam Silver’s collection of accessible form-related components – a companion to his book Form Design Patterns – is a brilliant reference.

The component gallery is an up-to-date list of interface component examples. It’s really helpful for looking up existing naming conventions. It also contains a list of Design Systems.

There’s so much to admire in Nord Health’s Design System and specifically its reference website.

We want to find out if adding a 'date picker' component to the Design System is a good idea.

We're currently looking for: examples of date pickers in services: screenshots, prototypes, links to live services; use cases: explanations of why a 'date picker' was used in a service instead of a 'date input', or something else; research: how well 'date pickers' tested with users to complete different tasks.

Over the last couple of days I’ve been watching an interview with Brad Frost on Storybook’s channel. I’m still only halfway through but it’s great so far.

Alex Page, a Design System engineer at Spotify, has just asked:

What open-source design systems are built with web components? Anyone exploring this space? Curious to learn what is working and what is challenging. #designsystems #webcomponents

And there are lots of interesting examples in the replies.

Here’s an interesting development in the block link saga: GOV.UK have introduced one (named .chevron-card) on their Homepage, citing how it’ll improve accessibility by increasing mobile touch targets. It’s not yet been added to their Design System while they’re monitoring it to see if it is successful. They’ve chosen the approach which starts with a standard, single, non-wrapping anchor then “stretches” it across the whole card via some pseudo elements and absolute positioning magic. I’m slightly surprised at this choice because it breaks the user’s ability to select text within the link. Really interested to see how it pans out!

A Storybook UI explorer containing the components and layouts for making the front end of a BBC web experience.

A history of Design Systems by Jay Hoffman taking in (amongst other milestones) the notion of Front-end Style Guides, followed by the arrival of Bootstrap, then Brad Frost’s Atomic Design, culminating in the dawn of the Design System movement with Jina Anne’s Clarity Conference.

The W3C have just published a new Design System. It was developed by British Digital Agency Studio 24, who are also working (in the open) on the redesign of the W3C website.

Here’s a great tutorial from Eleventy guru Stephanie Eckles in which she explains how to create a page that displays multiple code demos, similar to SmolCSS.dev.

There are (at least) three cunning ways in Eleventy to get “reusable snippet” or “reusable component” functionality.

Nathan (of EightShapes) discusses how to unify anatomy and props across code and design tools.

One interesting aspect of the Duet Design System is that they use Eleventy to not only generate their reference website but also to generate their Design Tokens.

Here’s a lovely Design System that interestingly uses Eleventy for its reference website and other generated artefacts:

We use Eleventy for both the static documentation and the dynamically generated parts like component playgrounds and design tokens. We don’t currently use a JavaScript framework on the website, except Duet’s own components.

The GOV.UK Design System is a nice Design System success story. At 3 years old it’s reporting high traffic, usage and satisfaction ratings. GDS do so much great, thoughtful and inclusive work (which they also share with the community) and it’s inspiring to see it being a success.

There are now more than 900 live cross-government services using the GOV.UK Design System - 75% more than a year ago. It’s being used in more than 2,600 repositories on GitHub and has been forked more than 200 times.

I should have bookmarked it long before now, but just revisiting the Lightning Design System I’m reminded that is really well organised and executed.

SLDS saves time and energy, freeing designers and developers to focus on larger issues of usability and meaning. Standardized, reusable components support collaboration, reinforce branding, and provide a consistent look and user experience.

Absolute gold here regarding accessibility, bloated components, and purpose versus appearance.

It’s easy for a component to become bloated and its purpose increasingly ambiguous.

Here’s an interesting new article from Ethan Marcotte, in which he muses on better ways to think about Design Systems based on his recent experience.

Once you’ve identified the root causes, you’ll be in a far, far better place to choose the right things — and, more importantly, to create a system that finally supports your design.

From 2015: Alla Kholmatova reflects on the difficulty in choosing between molecule or organism when categorising components using atomic design at FutureLearn. She also provides some handy insights into how they handled it.

When thinking about complexity of elements, it helps viewing molecules as “helpers” and organisms as “standalone” modules.

An excellent article from Brad Frost in which he gives us some vocabulary for separating context-agnostic components intended for maximal use from specific variants and one-offs.

Interesting insight into the BBC design system and the five areas it’s split into: Foundations, Components, Layout Components (including Stack, Grid etc) Levers and Containers.

Rachel Andrew explains how to write CSS for a nicely optimised printed page that uses a minimum of ink and paper and ensures that content is easy to read.

My point with all this is that it’s easy to see every problem or design as a new component or a mix of currently existing components. But instead, we should make components that can slot into each other neatly, rather just continue to make more components.

Use this design system to make your service consistent with GOV.UK. Learn from the research and experience of other service teams and avoid repeating work that’s already been done.

This is a nice whistle-stop tour of the the Guardian’s current digital design system. Apart from looking great, some of the terminology is interesting (fronts, kickers and thrashers) and I like the way they have different Card types for different types of article, “each having its own flavour and tone”.

It’s a collection of shared patterns and practices that allow our team to build quality user interfaces consistently and quickly.

The original call-to-arms and manual for Design Systems.