Clarity 2020

This year is hard for every human on planet earth. Especially people who run conferences or similar events either cancel or look for alternatives that come close to their previous in-person events.

Last week I had the privilege to attend a virtual version of a conference I never attended (but always wanted to) before called Clarity. Based on this I can’t compare any previous in-person Clarity event with the virtual version of this year's edition. I can only speak for this year, and it was a great overall experience — just fabulous.

The whole team and the amazing Emcees Catt and Dan did a fantastic job in guiding through these three days. Lots of fun activities and a good amount of dad jokes were included.

On top of the setting, all talks were very solid and each one had bits and pieces that will linger in my brain for some weeks to come. It exceeded my expectations of what a virtual conference can offer.

But let’s focus on my takeaways.

Gaps

One recurring topic in the sphere of design systems is about “bridging the gap” between design and development. In her talk, The Design Systems Spiral, Jina Anne, rightfully asked why this gap even exists in the first place. She also underlined the fact that design systems are not only about the deliverables but people in general.

Additionally, Alex Skougarevskaya talked about the fact that design systems are here to help us with agreeing on things. Likewise, we also should shift our minds more towards a service-driven mindset. We shouldn’t always focus on producing new components, but rather start researching the things designers and developers are using the current components for and how they are using them as a whole. We should invest more in sparring, service desk and customer happiness of your design system.

In Design Systems, or: How I learned to stop fighting and love the team Natalya and Tim Shelburne addressed how design systems can help collaboration and bring individuals to the zone of proximal development. Design systems should be used to communicate mental models and make design decisions explicit.

Design systems are the tool that allows one person to archive the results of another, without having to do the mental overhead to learn the mental model of another.

While design systems can help with these things, they aren't a replacement for soft skills. In teams and collaboration, it should always be Us vs. The Problem and learning together as a team should be the focus.

Never done

Another prominent topic during these three days circled around the fact that, like almost everything, design systems are never done. Design systems are about people, collaboration, and the process itself.

We as people who work on design systems can always improve components and tools, but we should focus more on the intermediate and personal things to solve.

Our way of systematically thinking about problems can also help in other areas like team structures and collaboration. In his talk Designing teams. Designing systems. Farai Madzima talked about the similarities between design and team principles and how a shared language in these areas is needed to successfully collaborate. Create a glossary to improve the meaning of your language — this doesn’t only have to be for your design or development workflows. It also is very helpful for a company to make common words and phrases more clear for new-joiners. In the end, successful collaboration boils down to successful communication.

Happiness & Inclusivity

The last topic I want to talk about in this quick personal summary uses the whole spectrum from inclusive documentation to inclusive and accessible products. In her talk Creating Inclusive Content: Why it Matters Brittney Ball gave a quick guide with an unbelievable amount of actionable suggestions on how to write and improve documentation.

Inclusive content is content that helps everybody, even if they just started out. Documentation shouldn’t make users feel intimidated or trigger imposter syndrome by using words like “easy” or “just” (something I’ve been guilty of myself in the past).

When writing documentation we always should remember how it feels to learn something new and include people from the outside. Ideally, we can bring in juniors or new-joiners to test and help with writing content.

In one of my favorite talks called Accessibility beyond color contrast Allison Shaw showcased what it means to build accessible components and products.

In the past, I also had conversations myself where accessibility only was recognized or thought about in the context of color contrast. This talk was a perfect example of how to improve general arguments and push more for things like performance and especially inclusive writing. All this helps with the goal of inclusive and accessible products.

She also mentioned something that I still need to think about in more detail ⇒ Intuition is a myth! Consistency is intuition!

Summary

There is so much more to talk and think about. As I said already, I liked every talk and learned bits and pieces everywhere — which is an excellent sign for a conference, if you ask me.

I genuinely enjoyed these three days very much and can highly recommend watching all the talks, if they will be published at some point. I don't know the details on this, sorry.

Looking forward to next year!