< back to all blog posts

Design Systems London – part 2

This week we’re delivering Part 2 of our Design Systems London round-up… Here’s what’s in store:

  1. Design Systems London – Part 2 takeaways
  2. What’s a design system? Definitions from the conference
  3. Key lessons from the talks

Bonus: links to available slides Enjoy!

Our main takeaways

Very much like Part 1, this part of the conference revolved around the idea that people and processes are the key to DS success:

  1. What does your team need? Know what problem your DS is solving
  2. To increase adoption, make using the DS easier than the alternative
  3. To boost contributions, create a great contributor experience

What’s a design system? Definitions from the conference

“A design system is not a pattern library, brand guidelines or a Sketch file. It’s a system of living principles, guides and components used by designers and developers to build consistent products and experiences. A design system is a product: it has users, roadmaps, releases, features, maintenance, bugs, documentation and support.”

~Yaili de León

“A design system is: universal principles and culture, assets, patterns, guidelines, discipline-specific principles”

~Hana Lodhi & Antonas Deduchovas

“A collection of products that help scale our design practice”

~Sarah Federman

Tips from IBM

You’ve built a design system… now what by Bethany Sonefeld

  1. Don’t enforce adoption – instead, be available, have good documentation and demonstrate value
  2. Make it easy for people to contribute… don’t do it on your own!
  3. Have a 6-8 months roadmap for your DS – what do its users need?

Accessbility tips from GOV UK

Accessibility in the GOV.UK Design System by Nick Colley

  1. Meet accessibility guidelines (WCAG)
  2. Include accessibility testing in your user research
  3. Accessible patterns can give a false sense of security – don’t let them replace your design process!

Tips from Deliveroo

Building DS at Deliveroo: Learnings and Frustrations by Matt Vagni & Raph Guilleminot

  1. Adopting the DS should be 10x easier than the alternative
  2. A DS team should have:
  • 1 designer & 1 engineer minimum
  • people with experience and influence
  • domain experts for the targeted platforms e.g. React

3. What does your company need from a DS? Do the research

Culture and principles are priority #1

Your Design System has a Heart by Hana Lodhi & Antonas Deduchovas

  1. If there is misalignment between stakeholders about what success means for the DS, resolve that first
  2. Do the research and interview stakeholders – define the problem your DS is solving
  3. Establish a culture and principles to unify everyone around core values

Tips from Adobe

Design Systems at Scale by Sarah Federman

  1. Use a documentation site to centralise and showcase the DS
  2. Design tokens are the key to managing styles at scale
  3. “What’s measured is managed” – track adoption and compliance

Focus on the developer experience

Design System API’s and the Developer Experience by Diana Mounter

  1. Start by designing the public API of your components – you can fix what’s behind later
  2. Use bots and linters to help with DS compliance
  3. Provide release notes, deprecation warnings and good documentation
  1. Design systems for the rest of us ~Siddharth Kshetrapal
  2. Accessibility in the GOV.UK Design System ~Nick Colley
  3. Delivering Flexible Design Systems for Web & Native ~Charlie Robbins
  4. Design Systems at Deliveroo: Learnings and Frustrations ~Matt Vagni & Raph Guilleminot

That’s a wrap for our Design Systems London 2018 round-up – we hope it was useful!