< back to all blog posts

Design Systems London – part 1

Last week, we attended the awesome Design Systems London conference .To kick off this blog, we’re summing up our main takeaways from the first half of the conference, as well as what we learned from the first 5 talks. Hope it’s useful!

Our main takeaways

The biggest predictors of design system success are not what tools and technologies you use, but the following:

  1. good communication – to convince stakeholders, get people to use the system, and recruit contributors
  2. documentation – people can’t use the system or contribute if they don’t know how to
  3. starting small – don’t try and build the perfect design system, ship something, show it to people, and iterate

Design systems don’t inhibit creativity

Design Systems & Creativity by Jina Anne

  1. not everything should be included in the design system
  2. patterns can change over time
  3. innovation is still required to solve more complex problems

How to increase design system contributions

Encouraging participation and contributions by Yaili de León

  1. lead by example, help your team understand how participation works
  2. create online processes so shy/remote people can participate
  3. be transparent – show and tell sessions are better than big reveals

What you can do NOW – ship early and iterate

Design systems for the rest of us by Siddharth Kshetrapal

  1. tokenize existing styles – you can improve things like accessibility later
  2. systemize flagship components – you can take care of legacy later
  3. document UI/front-end components – nobody can use them otherwise

Use scales to speed up design/development feedback

Minimising Complexity by Kellie Matheson & Richard Hallows

  1. color – define brand colors and use 10% white/black increments
  2. spacing, line heights etc. – base them on increments e.g. 4px / 0.25rem
  3. typography – use a base e.g. 16px and x1.125 to get next size up

Tips to deliver systems for native and web

Delivering Flexible Design Systems for Web & Native by Charlie Robbins

  1. documentation is required for people to use the system and contribute
  2. mimicking native styles in React Native is not always best for the user
  3. don’t break production – use DS staging servers and have a rollback plan

That’s all for now! Look out for Part 2 next week 🙂