Tags: stem



No, design systems will not replace design jobs — DesignSystems.com

No longer focused on recreating the wheel (or icon), designers can turn their attention to different types of challenges.

Design systems and technological disruption – The Man in Blue

Almost every technological innovation over the last 300 years has had side effects which actually increase the number of opportunities for employment. The general trend is that the easier something is to do, the more demand there is for it.

Cameron looks at the historical effects of automation and applies that to design systems. The future he sees is one of increased design democratisation and participation.

This is actually something that designers have been championing for decades – inclusive design at all levels of the company, and an increase in design thinking at all stages of product development. Now that we finally have a chance of achieving that it’s not a time to be scared. It’s a time to be celebrated.

Building and maintaining a design system | susan jean robertson

Susan writes about the challenges when trying to get widespread adoption of a design system. Spoiler: the challenges aren’t technical.

Change is hard. Communication and collaboration are absolutely necessary to make a system work. And the more people you can get involved from various disciplines the better chance you have of maintaining your system.

What’s in a pattern name? — Ethan Marcotte

Ethan emphasises the importance of making a shared language the heart of any design system. I heartily agree!

This isn’t new thinking, mind: folks like Alla Kholmatova and Charlotte Jackson have been talking about this for ages. (And in doing so, they’ve massively influenced how I think about modular, pattern-driven design.)

The Fast and Slow of Design

Prompted by his recent talk at Smashing Conference, Mark explains why he’s all about the pace layers when it comes to design systems. It’s good stuff, and ties in nicely with my recent (pace layers obsessed) talk at An Event Apart.

Structure for pace. Move at the appropriate speed.

the Origins of Opera and the Future of Programming – The Composition

An interesting piece by Jessica Kerr that draws lessons from the histories of art and science and applies them to software development.

This was an interesting point about the cognitive load of getting your head around an existing system compared to creating your own:

Why are there a thousand JavaScript frameworks out there? because it’s easier to build your own than to gain an understanding of React. Even with hundreds of people contributing to documentation, it’s still more mental effort to form a mental model of an existing system than to construct your own. (I didn’t say it was faster, but less cognitively strenuous.)

And just because I’ve spent most of last year thinking about how to effectively communicate—in book form—relatively complex ideas clearly and simply, this part really stood out for me:

When you do have a decent mental model of a system, sharing that with others is hard. You don’t know how much you know.

Fantasies of the Future: Design in a World Being Eaten by Software / Paul Robert Lloyd

The transcript of a terrific talk by Paul, calling for a more thoughtful, questioning approach to digital design. It covers the issues I’ve raised about Booking.com’s dark patterns and a post I linked to a while back about the shifting priorities of designers working at scale.

Drawing inspiration from architectural practice, its successes and failures, I question the role of design in a world being eaten by software. When the prevailing technocratic culture permits the creation of products that undermine and exploit users, who will protect citizens within the digital spaces they now inhabit?

#davewentandroid - daverupert.com

Yeah. Fuck this. That’s creepy. Technically I opted into this feature because Google Maps asked “Google Maps would like to know your location, YES or NO?” Of course my answer was “YES” because, hey, it’s a fucking map. I didn’t realize I consented to having my information and location history stored indefinitely on Google’s servers.

I began all the work of disabling this “feature” but it seemed like a fruitless task. Also worth noting, Google Maps for iOS keeps Location History as well.

Brighton Brains

A directory of the regular science, technology, and creative events happening in Brighton.

Designing Button States - Cloud Four

The canonical example in just about every pattern library is documenting button variations. Here, Tyler shows how even this seemingly simple pattern takes a lot of thought.

Hudl Uniform

This design system takes an interesting approach, splitting the documentation between designing and coding.

Documenting Components – EightShapes – Medium

Part one of a deep dive by Nathan into structuring design system documentation, published on Ev’s blog.

Australian Government Open Language for Design

The design system for the Australian government is a work in progress but it looks very impressive. The components are nicely organised and documented.

(I’ve contributed a suggestion for the documentation in line with what I wrote about recently.)

The People Part of Design Systems – Related Works – Medium

I like the idea of “design bugs”:

Every two weeks or so, a group of designers would get together for a couple of hours to fix what we called “design bugs.” These were things that didn’t hinder functionality and wouldn’t have been filed as an engineering bug, but were places where we were using an old component, an existing one incorrectly, or a one-off alteration.

Questions To Ask Before Building a Component Library | Chromatic

  • What problems will a component library solve?
  • Is everyone on the project behind the component library?
  • How will the component library be used?
  • What tool(s) will be used to build the component library?
  • Where should the component library live?
  • How granular should the library be? How should it be organized?
  • How will component code be scoped? What about page layout?
  • What data will the library use? What else should it have?

Shipping system fonts to GitHub.com · @mdo

A look at the font stack that Github is using.

Design, system. — Ethan Marcotte

Wise words from Ethan on how to react when people create bespoke patterns instead of using something in an existing pattern library.

It’s easy for an organization to look at that one-off pattern as a problem of compliance, of not following the established rules. And in many cases, that might be true! But it’s also worth recognizing when a variation’s teaching you a lesson: namely, that your design system isn’t meeting the needs of the people who’re using it.

How to Redesign a Tech Logo + Subtraction.com

I think Khoi might be on to something here …but I also think this change in priorities is no bad thing:

Consider the macro trend of these brands all visually converging alongside the industry’s current mania for design systems. That juxtaposition suggests that we’re far more interested in implementing ideas than we are in ideas themselves.

Sketching in the Browser – SEEK blog – Medium

A step-by-step account of trying to find a way to keep Sketch files in sync with the code in a pattern library. The solution came from HTML Sketchapp, a more agnostic spiritual successor to AirBnB’s React Sketchapp.

The contract was incredibly straightforward—as long as you generated HTML, you could import it into Sketch.

After some tinkering, Mark Dalgleish came up with a command line tool to automate the creation of Sketch libraries from HTML elements with data-sketch- attributes.

Pace Layering: How Complex Systems Learn and Keep Learning

There’s a running joke at just about any gathering at Clearleft where we measure TTPL—Time To Pace Layers—a measurement of how long we can discuss anything before making an inevitable reference to Stewart Brand’s framing.

It’s one of those concepts that, once your brain has been exposed, you start seeing everywhere. Like bad kerning or sexism.