What is happiness? It sounds like your last philosophy exam topic, right? Well, let’s treat it as such, just for a start.

The term happiness comes from the Old Norse term happ meaning “luck” or “chance.” It’s also related to the Old English word hæpic meaning “equal.” There’s something quite interesting about this “equal” origin; I like how happiness doesn’t necessarily involve individual people. Besides, in 1725, Francis Hutcheson, an Irish reverend, and philosopher brought a different interpretation of happiness to English speakers with his political philosophy: “that Action is best which accomplishes the greatest Happiness for the greatest Numbers; and that worst, which in like manner occasions Misery.” This quote reminds me of the Greek philosopher Aristotle, for whom happiness can only be considered collectively: we cannot be happy if others are not happy.

Does this mean a design system team can only be happy with the shared commitment of all?

The design system team happiness paradox

It looks like a heart from far away

It’s been a surprise for us at zeroheight, to discover how design systems teams really need a hug. Is it because the more you are involved with your design system, the more you are disappointed with it? Well, it feels like, as the report highlights that “the further removed you are from having to actively manage a design system on an ongoing basis, the more likely you are to be happy with the system you’re working on”, and I can understand, actually. I remember when I built design systems, I could only see the flaws, rather than everything that worked; I only focused on what I could improve.

I think it’s only human after all, and it might be linked with the negative bias (also known as the negativity effect or positive-negative asymmetry) because we have less motivation when an incentive is framed as a means to gain something than when the same incentive will help them avoid the loss of something.

A heart half empty

What is the heart of a design system? Documentation.

Maybe design systems teams are also unhappy because of the lack of their documentation. That’s what we observed in our survey: The average documentation coverage for a happy design system team was 65%, compared to an average of 25% of an unhappy team. One theory on why this bring in another stat that only 39% of design systems have dedicated teams. Obviously, you can’t write proper documentation without investing the right amount of resources in your design system. We’re in 2022 and we still haven’t reached the point where a dedicated team is commonplace, which is surprising, since design systems have never been so trendy as now.

But, I don’t think that being too close to your design system and the lack of resource are the primary reasons that design systems teams are unhappy. I fear that it’s deeper than this, and the reality is maybe a little sad…

Designs systems are ungrateful

Cold, cold heart

As we mentioned before, the less you are involved in a design system, the more likely you are to be happy about it. One reason for this could be that  people only see the shiny part of your design system iceberg, while you, on the other hand, see the whole thing, including the giant dark portion that lurks below the water.

The fact that coverage is a key difference between happy and unhappy teams suggest that while folks on the outside might be happy with the popular, shiny and expected parts of a design system, like color, buttons and typography (which more than 87% cover), what they don’t see is all the things that you don’t cover. The UX Research you aren’t putting into your documentation. The motion guidelines that have been sitting there unloved and unfinished. So, don’t worry, it’s not your fault if you only see the flaws. It’s just you, design system, who gave me a cold, cold heart.

Heart of glass

Another reason why design systems are ungrateful: you don’t notice it unless it doesn’t work. Like most design works, a good design system is invisible. It fits seamlessly into the work that people do day-to-day. A large part of this is having embedded processes and systems that work to support your design system.

Happy teams are 30% more likely to have governance in place and 58% more likely to have a contribution model. Having processes that support quality contributions mean that the improvements to your system aren’t relying on fragile systems and processes that could shatter at any moment.

His heart grew three sizes that day

Most of the people who document a design system are designers (56%). Nevertheless, I always thought that “design system” is a very poor choice of name because it’s saying that design systems are primarily about “design”. That is also why I think, if you want a successful and happy design system team, you shouldn’t have your design system owned by a specific department (designers, engineers…) but have a multi-disciplinary design system team. The report confirms this, in that functioning teams have a balance of design and engineering, but also bring in other profiles, such as product managers/owners and content people.

The happiest teams seems to sit between 4-9 people. Interestingly, the team size does not increase, even as organization size changes, or the design system matures. The more, the merrier? No. But the more diverse, the better? Yes. In fact, we wrote an article about how to build a design system team if you want to know more about the perfect team for your design system.

So, how to make your design system team happy?

I know I said the heart of a design system is documentation. But I don’t think that’s accurate. I think the real heart of a design system is the people behind it. A design system is nothing without its team and nothing without the people using it.

So, yes, from the survey we can surmise that a happy design system team is 4-9 multi-disciplinary people, with the right processes in place, and a good amount of documentation coverage.

However, here are a couple of other things that we’ve picked up through talking to people after we released the report:

A design system team cannot function as a lonely hearts club

A design system is for life, and not just for Christmas. Because design systems are still a bit of a buzzword, it’s not uncommon to find design system teams spun up and put in a corner because it would be cool to have one. This is a fast track to having an unhappy and dysfunctional design system team. A functioning design system team needs to exist in a company that understands the value of a design system and is committed to achieving that value.

A design system is a product at heart

A design system is a product that serves other products. If you don’t treat your system the same way that you treat your other products, especially with respect to resourcing, expectations, and process support, you will find it will probably fail (as any product would). It also means that you’ll likely have a flailing, unsupported team behind it who won’t be too happy.

A design system is the heart of a product organization

Expanding out on the fact that you need a multidisciplinary team to support your design system — if your design system isn’t touching every part of the product process, it isn’t being as effective as it could be. A good design system should be underpinning and supporting the work that is done from product through to engineering. Having a design system that only plays well with design will likely lead to having an unfulfilled design system team.