Link tags: system

134

sparkline

The Ugly Truth about Design Systems

The video of a talk in which Mark discusses pace layers, dogs, and design systems. He concludes:

  1. Current design systems thinking limits free, playful expression.
  2. Design systems uncover organisational disfunction.
  3. Continual design improvement and delivery is a lie.
  4. Component-focussed design is siloed thinking.

It’s true many design systems are the blueprints for manufacturing and large scale application. But in almost every instance I can think of, once you move from design to manufacturing the horse has bolted. It’s very difficult to move back into design because the results of the system are in the wild. The more strict the system, the less able you are to change it. That’s why broad principles, just enough governance, and directional examples are far superior to locked-down cookie cutters.

Intentional and Emergent Design Systems | Jordan Moore

This is a really interesting distinction:

An intentional design system. The flavour and framework may vary, but the approach generally consists of: design system first → design/build solutions.

An emergent design system. This approach is much closer to the user needs end of the scale by beginning with creative solutions before deriving patterns and systems (i.e the system emerges from real, coded scenarios).

It’s certainly true that intentional design systems will invariably bake in a number of (unproven?) assumptions.

The 2019 Design Systems Survey by Sparkbox

The good folks at Sparkbox ran a survey on design systems. Here are the results, presented in a flagrantly anti-Tufte manner.

The Atlas of Moons

Take an interactive tour of our solar system’s many moons.

How using component-based design helps us build faster

A case study from Twitter on the benefits of using a design system:

With component-based design, development becomes an act of composition, rather than constantly reinventing the wheel.

I think that could be boiled down to this:

Component-based design favours composition over invention.

I’m not saying that’s good. I’m not saying that’s bad. I’m also not saying it’s neutral.

The Guardian digital design style guide

What a lovely way to walk through the design system underpinning the Guardian website.

Bonus points for using the term “tweak points”!

Why Did I Have Difficulty Learning React? - Snook.ca

When people talk about learning React, I think that React, in and of itself, is relatively easy to understand. At least, I felt it was. I have components. I have JSX. I hit some hiccups with required keys or making sure I was wrapping child elements properly. But overall, I felt like I grasped it well enough.

Throw in everything else at the same time, though, and things get confusing because it’s hard at first to recognize what belongs to what. “Oh, this is Redux. That is React. That other thing is lodash. Got it.”

This resonates a lot with Dave’s post:

React is an ecosystem. I feel like it’s a disservice to anyone trying to learn to diminish all that React entails. React shows up on the scene with Babel, Webpack, and JSX (which each have their own learning curve) then quickly branches out into technologies like Redux, React-Router, Immutable.js, Axios, Jest, Next.js, Create-React-App, GraphQL, and whatever weird plugin you need for your app.

Why your design system should include content | Clearleft

Rachel makes the case for integrating content design patterns into component libraries:

Instead of content design systems and visual design systems existing in isolation, the ideal is one design system that accommodates everything, marrying the content and design together in the way it will actually be used and experienced.

The Patterns Day Edition | Amy Hupe, content designer.

Amy’s talk at Patterns Day was absolutely brilliant! Here’s an account of the day from her perspective.

The evident care Jeremy put into assembling the lineup meant an incredible mix of talks, covering the big picture stuff right down to the nitty gritty, and plenty in between.

Her observation about pre-talk nerves is spot-on:

I say all of this because it’s important for me and I think anyone who suffers with anxiety about public speaking, or in general, to recognise that having a sense of impending doom doesn’t mean that doom is actually impending.

Patterns Day

Here’s a nice little round-up of Friday’s Patterns Day.

Weeknotes #16 | Trys Mudford

Just look at these fantastic pictures that Trys took (very unobstrusively) at Patterns Day—so rock’n’roll!

The audience and the stage.

Closing remarks.

The Clearleft crew.

Patterns Day notes

Stuart took copious notes during every single talk at Patterns Day—what a star!

Drop caps & design systems - Vox Product Blog

Sit down and listen to a story from uncle Ethan.

Baking accessibility into components: how frameworks help

A very thoughtful post by Hidde that draws a useful distinction between the “internals” of a component (the inner workings of a React component, Vue component, or web component) and the code that wires those components together (the business logic):

I really like working on the detailed stuff that affects users: useful keyboard navigation, sensible focus management, good semantics. But I appreciate not every developer does. I have started to think this may be a helpful separation: some people work on good internals and user experience, others on code that just uses those components and deals with data and caching and solid architecture. Both are valid things, both need love. Maybe we can use the divide for good?

The Web Developer’s Guide to DNS | RJ Zaworski

At Codebar the other night, I was doing an intro chat with some beginners. At one point I touched on DNS. This explanation is great for detailing what’s going on under the hood.

Norbert Wiener’s Human Use of Human Beings is more relevant than ever.

What would Wiener think of the current human use of human beings? He would be amazed by the power of computers and the internet. He would be happy that the early neural nets in which he played a role have spawned powerful deep-learning systems that exhibit the perceptual ability he demanded of them—although he might not be impressed that one of the most prominent examples of such computerized Gestalt is the ability to recognize photos of kittens on the World Wide Web.

Who Are Design Systems For? | CSS-Tricks

Chris ponders the motivations behind companies sharing their design systems publicly. Personally, I’ve always seen it as a nice way of sharing work and saying “here’s what worked for us” without necessarily saying that anyone else should use the same system.

That said, I think Chris makes a good poin here:

My parting advice is actually to the makers of public design systems: clearly identify who this design system is for and what they are able to do with it.

Improving accessibility with accessibility acceptance criteria — Paul Hayes

Wouldn’t it be great if every component in your design system had accessibility acceptance criteria? Paul has some good advice for putting those together:

  • Start with accessibility needs
  • Don’t be too generic
  • Don’t define the solution
  • Iterate criteria

Public Sans

A free and open source neutral sans-serif typeface, released as part of version two of the design system for the US federal government.

Systems Thinking, Unlocked – Airbnb Design

Some useful lessons here for strengthening a culture of sustained work on a design system.

Creating and maintaining a design system is like planting a tree—it has to be nurtured and cared for to reap the benefits. The seed of our design system has been planted, and now our teams are working together to maintain and grow it. Our new way of working supports gives people recognition, facilitates trust, and creates strong partnerships.