< back to all blog posts

What we learned from Clarity – part 2

Last time, we revisited our notes from the first ever dedicated design systems conference: Clarity 2016. This week we’re looking back at some amazing talks from the 2017 conference to see what we learned from the design leaders at companies like Slack, Facebook and Twitter. Let’s roll!

3 design system tips learned the hard way

Source: Doing it Wrong, by Mina Markham @ Slack

  1. Keep it simple: overly generic components introduce complexity and are prone to misuse
  2. Community over control: meet with representatives from other teams regularly to discuss updates and contributions
  3. Share your knowledge: if you can, give back to the community, but don’t let the negativity/hate on the internet get you down

5 areas to focus on as you scale

Source: What Happens Next? by Isha Kasliwal @ Salesforce

  1. Maintenance: as new patterns emerge, make sure design system components remain clear, well-organized, intuitive and flexible
  2. Adoption: run regular office hours, brown bag lunches and review meetings to educate and spread the word about the system’s benefits
  3. Support: develop a strategy/toolset to handle support queries as they may come from many different communication channels
  4. Documentation: make it easy for anyone to contribute to the design system documentation – the core team shouldn’t be a bottle neck
  5. Tooling: improve tooling to increase the efficiency of building products using the design system e.g. make a code playground for components
  6. Strategy: develop a roadmap by considering what your design system users need now and what they might need in the future

3 principles to align your organization

Source: When We Align by Cameron Moll @ Facebook

  • Unity over uniformity: unlike uniformity, unity prioritizes UX and makes it possible to depart from the norm if there’s a good reason
  • Chemistry over culture: don’t be afraid to introduce new ideas and values that challenge your existing company culture
  • People over process: be a steward of the system, but listen to and empower others — design systems are about facilitating not policing

Technology is easy. People are hard.

Source: The People Layer by Josh Silverman @ Twitter

Focusing on people — not tools or design — is the key to delivering great UX. Here are some general best practices on how to create a better work environment:

  • Clarity: align people behind a clear company purpose, define your design principles, have a great onboarding process, set role expectations and provide guidelines on how to give and receive feedback
  • Productivity: ensure that only the right people are in the room during meetings and encourage the use of appropriate communication channels (e.g. non-interruptive vs interruptive)
  • Opinion diversity and inclusivity: make sure that cross-discipline teams talk to each other and that quiet people are heard
  • Growth mindset: spread the idea that skills aren’t innate and can be developed through hard work and mentorship
  • Environment: optimize meeting environments so people can do their best work (snacks, fresh air etc.) and provide bonding opportunities outside of work

3 rules for components

Source: A Working Theory of Components by Elyse Holladay @ Indeed

Components should be:

  • Easy to reason about: well-documented in all their states and unit-tested
  • Context-agnostic: they should behave properly regardless of context and their logic should be self-contained
  • Isolated: their structure and styles should be defined in one place and independently testable

As in our Clarity 2016, Design Systems London part 1 and part 2 posts, the common theme at Clarity 2017 was the following: the hardest aspect of building a design system is dealing with the people involved.

Creating alignment within your organization and developing a scalable process are the biggest factors in design system success. Of course, components, documentation and tools matter, but they are secondary. As Josh Silverman said in his talk

Every tech problem is a people problem