Tags: ems

92

sparkline

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.

Pattern Library First: An Approach For Managing CSS — Smashing Magazine

Rachel goes into detail on how she uses pattern libraries—built with Fractal to build interfaces. I know it sounds like we paid her to say all the nice things about Fractal, but honestly, we didn’t even know she was writing this article!

After discovering Fractal two years ago, we have moved every new project — large and small — into Fractal.

Pixels vs. Ems: Users DO Change Font Size – Evan Minto – Medium

I have to admit, I didn’t realise that text reszing behaved differently for user preferences compared to page zoom. For that reason alone, I’m going to avoid setting font sizes in pixels.

If 2 to 3% (or more!) of your users are relying on a custom font size, you should know that so you can either support that user preference or make a conscious decision to not support it. Doing anything less is frankly irresponsible, especially considering that users with larger font sizes may be using those sizes to compensate for visual disabilities.

Introducing the GOV.UK Design System - Government Digital Service

The Gov.uk design system is looking very, very good indeed—nicely organised with plenty of usage guidelines for every component.

Guidance on using components and patterns now follow a simple, consistent format based on task-based research into what users need in order to follow and trust an approach.

The three lessons that changed how I think about design systems

  1. Know where you stand before starting the journey
  2. Make sure everyone is speaking the same language
  3. Integrate the right tools into your team’s workflow

DesignOps Handbook - DesignBetter.Co

This looks like a really good (and free!) online book all about design ops.

(Alas, it is, once again, driven by janky JavaScript that makes it a bit of a chore to scroll and read.)

“Distinct Design Systems,” an article by Dan Mall

Dan asks:

Do we have too many design systems?

Spoiler: the answer is “no”. There. Saved you a click.

(Not really; you should definitely click.)

5 ways having a shared design system has helped us ship our designs faster – Product at Canva

The steps that the Canva team took to turbocharge their design ops.

I’ll talk about why creating a shared design system has boosted our organizational productivity—and how you can help your teams improve product quality while reducing your company’s ‘design debt’.

Solving Life’s Problems with CSS | CSS-Tricks

It turns out that Diana Smith isn’t just a genius with CSS—she’s a fantastic writer too. This post is somehow heartfelt and lighthearted at the same time. It’s also very humorous, but beneath the humour there’s an excellent point here about the rule of least power …and doing things the long, hard, stupid way.

Because something about those limitations just calls to me. I know I’m not alone when I say that a rigid set of restrictions is the best catalyst for creativity. Total artistic freedom can be a paralyzing concept.

That can sometimes be the case with programming. If you have the most powerful programming languages in the world at your disposal, it starts to seem natural that you should then have no difficulty solving any programming problem. With all these amazing tools offering countless solutions to solve the same problem, it’s no wonder that we sometimes freeze up with information overload.

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?

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.

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.)