Tags: systems

95

sparkline

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.

Designing design systems | Clearleft

I know I’m biased because I work with Jerlyn, but I think this in-depth piece by her is really something! She suveys the design system landscape and proposes some lo-fi governance ideas based around good old-fashioned dialogue.

Developing a design system takes collaboration between the makers of the design systems and the different users of the system. It’s a continual process that doesn’t have to require a huge investment in new departments or massive restructuring.

It can start small.

Magic Paintbox – Illuminated – Medium

What we get from the pattern library is time and freedom to be creative. I’ve seen people claim pattern libraries are the death of creativity and innovation in design. For us, it’s the opposite of that.

Accessibility is not a feature. — Ethan Marcotte

Just last week I came across an example of what Ethan describes here: accessibility (in a pattern library) left to automatic checks rather than human experience.

Mozilla Protocol - Protocol Design System

Mozilla’s work-in-progress style guide and pattern library.

Weft. — Ethan Marcotte

I think we often focus on designing or building an element, without researching the other elements it should connect to—without understanding the system it lives in.

Badging API Explainer

Here’s an intriguing proposal that would allow web apps to indicate activity in an icon (like an unread count) in the same way that native apps can.

This is an interesting one because, in this case, it’s not just browsers that would have to implement it, but operating systems as well.

Thinking in Triplicate – Mule Design Studio – Medium

Erika has written a great guest post on Ev’s blog. It covers the meaning, the impact, and the responsibility of design …and how we’ve been chasing the wrong measurements of success.

We design for the experience of a single user at a time and expect that the collective experience, and the collective impact, will take care of itself.

Tools In The Basement | Brad Frost

It’s possible to create components in a vacuum, but ultimately you have no idea whether or not those components can successfully address your user and business needs. I’ve witnessed firsthand several design system initiatives crash and burn due to components created in isolation.