Tags: systems

103

sparkline

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.

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.

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?

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

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.

Blockchain and Trust - Schneier on Security

Honestly, cryptocurrencies are useless. They’re only used by speculators looking for quick riches, people who don’t like government-backed currencies, and criminals who want a black-market way to exchange money.

Bruce Schneier on the blockchain:

What blockchain does is shift some of the trust in people and institutions to trust in technology. You need to trust the cryptography, the protocols, the software, the computers and the network. And you need to trust them absolutely, because they’re often single points of failure.

On Simplicity | Max Böck - Frontend Web Developer

We assume that complex problems always require complex solutions. We try to solve complexity by inventing tools and technologies to address a problem; but in the process we create another layer of complexity that, in turn, causes its own set of issues.

The Principle of Least Power looms large over this:

Some of the most important things in the world are intentionally designed “stupid”. In any system, the potential for error directly increases with its complexity - that’s why most elections still work by putting pieces of paper in a box.

The World’s Writing Systems

What a lovely timeline of civilisation. This site makes for a nice companion piece to that database of dimensioned drawings—they’re both delightful to explore.

Resources about Front-end Architecture and Design Systems, etc. | Lara Schenck

A great selection of links about design systems, collected and categorised.

When your design system fails — HeyDesigner

You could create components that strike the perfect balance between reuse and context sensitivity. But defining the components of your design system is just the first step. It has to make its way into the product. If it doesn’t, a design system is like a language with no extant literature or seminal texts.

Marissa Christy outlines the reasons why your design system might struggle:

  1. The redesign isn’t prioritized
  2. The tech stack is changing
  3. Maintenance takes discipline

But she also offers advice for counteracting these forces:

  1. Get buy-in from the whole team
  2. Prioritize a lightweight re-skin on older parts of the product
  3. Treat a design system like any other product project: start small
  4. Don’t wait for others. Lead by example.
  5. Finally, don’t compare yourself to others on the internet

Workplace topology | Clearleft

The hits keep on comin’ from Clearleft. This time, it’s Danielle with an absolutely brilliant and thoughtful piece on the perils of gaps and overlaps in pattern libraries, design systems and organisations.

This is such a revealing lens to view these things through! Once you’re introduced to it, it’s hard to “un-see” problems in terms of gaps and overlaps in categorisation. And even once the problems are visible, you still need to solve them in the right way:

Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.

Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.

That last part dovetails nicely with Jerlyn’s equally great piece.