Design Systems shares highlights from Clarity Conference 2020.

2020 has changed the way we work and communicate. With gatherings a thing of the past, the Design Systems team attended our first virtual conference this year. Honestly, it wasn’t that bad.

Clarity Conference is a design system focused conference where designers and technologists from companies like Amazon, Atlassian, Google, and Zendesk, among others, come together to network and share ideas. In this month's newsletter, we'll recap some of the highlights from the conference.

The Importance of Perspective

Ben Colar   |   Baby Grand

Ben's talk focused on how brand positioning can influence design decision making. Whether you're creating a brand from scratch or expressing it through a design system, Ben had a few tips:

Be unwavering about your perspective

Be bold and take a position. Make sure the things your brand says align with the things it does.

Commit to your perspective

Own it. Constantly changing your brand to appeal to others will do more harm than good. A single brand isn't for everyone and that's ok. When people trust that you are who you say you are they can choose whether or not to connect with your brand.

Your personal perspective matters

Even if you're not the target demographic, your opinion about the brand matters. You're a human being first, then a designer.

Don't let anything slide

The devil is in the details. Everything matters.

This work should be fun

Always remember that you're a designer and you get to do something fun every day. There are going to be tough conversations but stay positive and keep after it.

Accessibility beyond color contrast

Allison Shaw   |   Personal website   |   Zendesk

While color contrast is sometimes both the easiest or the most difficult thing to focus on as a team, it's easy to forget that there are many other aspects of accessibility you can, and should, consider.

Accessibility is about people

Allison started by reminding us that accessibility starts with people. In doing so, they provided us with some interesting ways to think about accessibility, often citing Microsoft's inclusive design guidelines.

Disabilities

Allison broke down disabilities into a few types:

• Situational - Imagine having a baby in one hand and a phone in the other.
• Temporary - Imagine having a broken arm in a cast or sling.
• Permanent - Imagine losing a limb.

This stood out as a unique way to make disabilities relatable to everyone.

Inclusion

Allison continued by talking about how inclusive design isn't just for people with disabilities, it's for everyone. For example, remote controls we're originally designed for people with limited mobility to stay seated and sidewalk cutouts were designed for people in wheelchairs. However, these innovations benefit all of us.

POUR

To make a product accessible and inclusive, WC3 states that it should be:

• Perceivable - the content cannot be invisible to the way your users use it
• Operable - anyone can use your product as intended
• Understandable - people can expect your product to work in predictable ways
• Robust - accessed by a wide range of technologies, including assistive ones

Simplicity

Finally, Allison spoke to how inclusive products should be simple. They went on to say that "intuitive design" is a myth and that product design should be rooted in consistency and usability. Consistent products build on prior knowledge, map to our users' conceptual models, and close knowledge gaps.

Beyond color contrast

After establishing a foundational understanding of accessibility, Allison closed with a list of best practices, beyond color contrast, to help us create beautiful, simple, and inclusive products.

Performance

"If it's slow, it sucks." You can't always fix performance but you can help people by fixing perceived performance.

Scale

Bigger UI is easier to use. It's easier to click and it's easier to read.

Language

• Language provides clarity. Use it!
• Don't collect race information if it's not necessary.
• Don't collect last names if you don't need to.
  • Name conventions are different across the world.
  • Make sure designs account for different sentence structures or longer character counts.
• Don't use generic he, use plural pronouns instead.
• Don't call attention to gender when it's irrelevant.
• Don't collect sex information unless absolutely necessary.
  • If you must, always let people self identify.
• Don't skirt around saying disabled.
• Use nondirectional language. Screen readers have no concept of direction.
  • Avoid terms like "click here" for users that aren't clicking.
• Avoid "learn more" for CTAs and links so screen readers can tell users what they might be learning about.
• Always use labels, especially for icons.

Calculating Color: Dynamic Theming with CSS Variables

Una Kravets   |   Personal website   |   Google Chrome

Una showed us how to create dynamic color themes with simple CSS!

CSS Variables

Una gave a brief overview of a few CSS variables including currentColor and @property but ultimately focused on --var()

Una demonstrated how breaking hsl (hue, saturation, and lightness) color values into separate variables can allow us to create dynamic color palettes.

Start with a brand color

--colorBrand: hsl(265, 100%, 47%);

Break that brand color into separate parts

Notice the -h, -s, and -l respectively.

--colorBrand-h: 265; 
--colorBrand-s: 100%; 
--colorBrand-l: 47%;

Define a dynamic brand color using your variables

--colorBrand: hsl(var(--colorBrand-h), var(--colorBrand-s), var(--colorBrand-l));

Create variations

With a dynamic brand color defined, you can use color theory to create variations of that color for different uses such as:

• buttons
• card accents
• light and dark modes
• and even browser art

Take a look at the complementary and triadic variations in this codepen for inspiration.

Make it accessible

Dynamic color theming can have accessibility benefits as well. By creating a contrast threshold, we can look at the luminosity (the "L" in hsl) of our brand color and set the text color accordingly.

:root {
  --contrastThreshold: 45%
}

.element {
  --switchContrast: calc((var(--colorBrand-l) - var(--contrastThreshold)) * -100);
  color: hsl(0, 0%, var(--switchContrast));
}

Browser support

While --var() is pretty well supported, there is a postCSS polyfill fallback available.

An Introduction to Multi-Platform Design Systems

Daniel Banks   |   Personal website   |   Amazon

Danny started by mentioning that less than 10% of public design systems support platforms other than the web. He then asked, "with many products spanning multiple platforms, how can we incorporate other platforms into our design systems?"

Consider cohesion over consistency

Being a good platform citizen and using native conventions does not mean you're compromising on consistency. Applications don't need to look exactly the same across all platforms to deliver a cohesive experience.

Align

Define a rock-solid set of foundations (principles, brand, content strategy, etc.).

Express the visual foundations in design tokens that can be consumed by their respective platform.

Align the team on cross-platform component definitions. Banner, for example, may differ in appearance and implementation across platforms. However, Banner should have essentially the same meaning on IOS, Android, and the web. This work will be challenging because many components likely already exist in a platform-specific way that will need to be adjusted to reflect a new mental model. With new components, Danny recommends starting with documentation first for all platforms before writing any code.

The system should support creators

If we remove the barrier to entry for product development, creators can autonomously build experiences for all platforms. This leads to distributed creation across an organization and teams that rely less on mockups to own the full multi-platform experience. Teams can then work backward from the customer, agnostic of the platform, and build for all platforms at once.

Have questions, feedback, or ideas for the Design Systems team? Send us an email or check out our wiki page to learn more about the team.

If you would like to unsubscribe from this newsletter, please send an email to design-systems-newsletter+unsubscribe@sproutsocial.com.