Link tags: ems



The cost of convenience —

I believe that we haven’t figured out when and how to give a developer access to an abstraction or how to evaluate when an abstraction is worth using. Abstractions are usually designed for a set of specific use-cases. The problems, however, start when a developer wants to do something that the abstraction did not anticipate.

Smart thoughts from Surma on the design of libraries, frameworks, and other abstractions:

Abstractions that take work off of developers are valuable! Of course, they are. The problems only occur when a developer feels chained to the abstractions in a situation where they’d rather do something differently. The important part is to not force patterns onto them.

This really resonated with parts of my recent talk at CSS Day when I was talking about Sass and jQuery:

If you care about DX and the adoption of your abstraction, it is much more beneficial to let developers use as much of their existing skills as possible and introduce new concepts one at a time.

The collapse of complex software | Read the Tea Leaves

Even when each new layer of complexity starts to bring zero or even negative returns on investment, people continue trying to do what worked in the past. At some point, the morass they’ve built becomes so dysfunctional and unwieldy that the only solution is collapse: i.e., a rapid decrease in complexity, usually by abolishing the old system and starting from scratch.

Reflections on Design Systems and Boundaries - Jim Nielsen’s Blog

Jim shares his thoughts on my recent post about declarative design systems. He picks up on the way I described a declarative design systems as “a predefined set of boundary conditions that can be used to generate components”:

I like this definition of a design system: a set of boundaries. It’s about saying “don’t go there” rather than “you can only go here”. This embraces the idea of constraints as the mother of invention: it opens the door to creativity while keeping things bounded.

“Design System Coverage,” an article from SuperFriendly

I completely agree with Dan that when it comes to design systems, completeness is an over-rated—and even counter-productive—goal:

Some organizations seem to hold up the ideal that, once a design system exists, everything in an interface can and should be built with it. Not only is that an unrealistic goal for most enterprises, but it can often be a toxic mindset that anything less than 100% coverage is misuse of a design system at best or utter failure at worst.

Design Systems Aren’t Cheap

Just like jQuery dominated the front end yesterday, React dominates it today. There will be something new that dominates it tomorrow. Your design system team will continue doing the same work and incurring more and more costs to keep up with framework churn. And let’s not forget the cost of updating tomorrow’s legacy apps, who are consumers of your soon to be legacy design system.

An incoherent rant about design systems • Robin Rendle

No matter how fancy your Figma file is or how beautiful and lovingly well organized that Storybook documentation is; the front-end is always your source of truth. You can hate it as much as you like—all those weird buttons, variables, inaccessible form inputs—but that right there is your design system.

Some tough design system love from Robin.

Here’s my advice: take all that aspirational stuff out of your Figma design system file. Put it somewhere else. Your Figma docs should be a mirror of the front-end (because that’s really the source of truth).

Code & Pixels

This forthcoming podcast about design engineering sounds like my cup of tea!

Functions and the future of design systems || Matthew Ström, designer-leader

Despite their name, most design systems aren’t all that much like systems. Granted, they are designed according to a system, and there’s a logical consistency to how their components and tokens are defined, but really, most design systems work like a dictionary: look up a component, get the instructions for using that component.

Mathew goes on to advocate moving towards a more function-centred approach to systematic design. It makes a lot of sense.

By the way, this isn’t directly related—other than metaphor being used—but I wrote about web standards, dictionaries, and design systems a while back.

The difference between correct-ness and useful-ness in a design system • Robin Rendle

I remember Lara telling me a great quote from the Clarity conference a few years back: “A design system needs to be correct before it’s complete.” In other words, it’s better to have one realistic component that’s actually in production than to have a pattern library full of beautiful but unimplemented components. I feel like Robin is getting at much the same point here, but he frames it in terms of correctness and usefulness:

If we want to be correct, okay, let’s have components of everything and an enormous Figma library of stuff we need to maintain. But if we want to be useful to designers who want to get an understanding of the system, let’s be brief.

Little Big Updates: dispatches from Quality Week

This is a wonderful piece of writing by Marcin, ostensibly about bug-fixing but really an almost existential examination of the nature of coding.

Bugs are, by definition, a look backward—at past behavior, at code that already exists, at the old work of engineers whom you’ve never met. It can feel more fun to write new code, chart new territories, add new functionality.

But the past can be fun, too. A good bug is a puzzle. A mystery. A whodunit. To solve a bug, sometimes you have to be a scientist: observe and measure, chart out the logic, follow the math. But then, two minutes later, you need to wear a hat of a very particular detective—take your flip notepad and interview different pieces of code to understand not what they claim they do, but what they actually do.

A Quick History of Digital Communication Before the Internet - Eager Blog

A potted history of communication networks from the pony express and the telegraph to ethernet and wi-fi.

Why you should prioritise quality over speed in design systems by Amy Hupe, content designer.

Speed for the sake of speed means nothing. If our design systems don’t ultimately lead to better quality experiences, we’re doing it wrong.

When we rush to release one-size-fits-all components, without doing the work to understand different contexts before curating and consolidating solutions, we sacrifice quality at the hands of speed.

The irony? In the long run, this will slow us down. We end up having to undo the work we’ve done to fix the problems we’ve created.

Ultimately, when we prioritise speed over quality, we end up with neither.

The Design System Priority of Constituencies - Cloud Four

Jason applies my favourite design principle to design systems.

User needs come before the needs of component consumers, which come before the needs of component developers, which come before the needs of the design system team, which come before theoretical purity.

Also: how frickin’ cool is it that the Cloud Four office has the priority of constituencies emblazoned on the wall!

A History of Design Systems on the Web - The History of the Web

It’s great to see former Clearlefties like Nat, Paul and Anna rightly getting namechecked in this history of designing for the web in a systemic way. It’s a tradition that continues to this day with projects like Utopia.

The word for web is forest | New_ Public Magazine

The wood wide web has been a powerhouse metaphor for popularizing the mutualistic relationships of healthy forests. But like a struggling forest, the web is no longer healthy. It has been wounded and depleted in the pursuit of profit. Going online today is not an invigorating walk through a green woodland—it’s rush-hour traffic alongside a freeway median of diseased trees, littered with the detritus of late capitalism. If we want to repair this damage, we must look to the wisdom of the forest and listen to ecologists like Simard when they tell us just how sustainable, interdependent, life-giving systems work.

A beautiful piece by the brilliant Claire L. Evans.

The project of decentralizing the web is vast, and only just beginning. It means finding a way to uproot our expression and communication from the walled gardens of tech platforms, and finding novel ways to distribute the responsibilities of infrastructure across a collective network. But we needn’t start from nothing.

Rationality Is Not A Way Out Of Group Action Problems like Climate Change and Covid – Ian Welsh

Rationality does not work for ethical decisions. It can help you determine means, “what’s the best way to do this” but it can’t determine ends.

It isn’t even that great for means.

Dancing With Systems - The Donella Meadows Project

We can’t control systems or figure them out. But we can dance with them!

  1. Get the beat.
  2. Listen to the wisdom of the system.
  3. Expose your mental models to the open air.
  4. Stay humble. Stay a learner.
  5. Honor and protect information.
  6. Locate responsibility in the system.
  7. Make feedback policies for feedback systems.
  8. Pay attention to what is important, not just what is quantifiable.
  9. Go for the good of the whole.
  10. Expand time horizons.
  11. Expand thought horizons.
  12. Expand the boundary of caring.
  13. Celebrate complexity.
  14. Hold fast to the goal of goodness.

Don’t Feed the Thought Leaders - Earthly Blog

A great tool is not a universal tool it’s a tool well suited to a specific problem.

The more universal a solution someone claims to have to whatever software engineering problem exists, and the more confident they are that it is a fully generalized solution, the more you should question them.

A Lifetime of Systems Thinking - The Systems Thinker

I don’t agree with all of the mythbusting in this litany of life lessons, but this one is spot on:

The best thing that can be done to a problem is to solve it. False. The best thing that can be done to a problem is to dissolve it, to redesign the entity that has it or its environment so as to eliminate the problem.

Remember that next time you’re tempted to solve a problem by throwing more code at it.

Design System Day, Thursday 22 July 2021

This looks interesting: a free one-day Barcamp-like event online all about design systems for the public sector, organised by the design system team:

If you work on public sector services and work with design systems, you’re welcome to attend. We even have some tickets for people who do not work in the public sector. If you love design systems, we’re happy to have you!