Design systems

Recently we realised we didn't have a written browser support policy. We decided to rectify that. We wanted a policy that would focus on outcomes for the user: rather than fixating on specific browsers, we needed to consider capabilities. It turns out there’s an initiative for that.

Eight talks on design systems in one fun day.

The Patterns Day conference, the workshop the day after, and an Indie Web Camp on the weekend.

Is your design system really a system …or is it more like a collection of components?

There’s an ever growing battle between efficiency and flexibility. How do you deliver an efficient white label product experience while allowing the flexibility for true brand expression between each roll out?

How can we adapt our tools for better testing?

We share the answers to a few big unanswered questions on integrating content with your design system.

That's a wrap!

Design systems are neither good nor bad (nor are they neutral).

Citing Frank Chimero, Debbie Chachra, and Lisa O'Neill.

There’s a pattern here.

We were 3 good friends - peers with similar industry experience - talking the same language, about the same things, but our definitions and understandings of those things were quite different.

Building a great design system takes more than just visuals. I take a look at the companies already including content fundamentals in theirs.

Governance models for design sytems don't need to be complicated. A little bit of dialogue goes a long way.

From pattern portfolios to Fractal.

The pattern library map is not the design system territory.

Defining the damn thing.

I’m all for design systems. They reduce time, save on costs and promote modular, systems-based thinking. But I’ve noticed a growing bias towards design systems focusing on the components first. This suggests they’re designed components-first. They’re not. Nor should they be.