Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Adding the foundations after the house has been built: Design systems at Auto Trader

Dan Donald
August 06, 2018

Adding the foundations after the house has been built: Design systems at Auto Trader

Dan Donald

August 06, 2018
Tweet

More Decks by Dan Donald

Other Decks in Design

Transcript

  1. An epic saga following many brave warriors from nearby villages

    Design and Development as they venture through the murky swamps, sinking sands…scale the sides of extreme, mountainous terrain…all in the name of brining peace to the land of Auto Trader with the one ring of Design Systems.
  2. Some of the older parts of the site, we might

    not get to… (at least for a while)
  3. Tech stacks Java stuff Bit of Angular over here Few

    bucketfuls of React Found a bit of jQuery over here
  4. Tech stacks Java stuff Bit of Angular over here Few

    bucketfuls of React Found a bit of jQuery over here Ahhh remember Backbone…?
  5. Tech stacks Java stuff Bit of Angular over here Few

    bucketfuls of React Found a bit of jQuery over here Ahhh remember Backbone…? Not even sure what that is….is it used anywhere?
  6. Tech stacks Java stuff Bit of Angular over here Few

    bucketfuls of React Found a bit of jQuery over here Ahhh remember Backbone…? Not even sure what that is….is it used anywhere?
  7. What is a design system? • A style guide? •

    A component library? • Some kind of asset/symbol library? • All of the above? • More than that?
  8. –Katie Sylor-Miller Senior Software Engineer Design Systems team at Etsy

    “Your technical approach doesn’t matter as much as creating a living, breathing system that’s flexible, maintainable, stable, scalable, and successful in the long-term.”
  9. Problem solved! • We just make one of those design

    system things and… • Have a nice cup of tea… • Go back to step #1
  10. Reality Bites • We already have component libraries in different

    tech stacks • Because everyone else seems to be doing doing it, is it right for us? • We have our own story through design and code we need to work with - legacy we still need to build and work with • There’s going to be compromises - too many to stop it from being viable?
  11. We had problems to solve • Consistency in design •

    Consistency in the implementations of these designs • Avoid duplication of effort - how could we share code? • Improve communication
  12. Team Awesome • Which designers should be involved? • Which

    front-end developers? • Thinking about deployment… web platforms folk…? • Keep the team small but representative to begin with from discipline and area of the business • Get to know each other
  13. • What was used in all parts of the business?

    • How did we get here? • What issues might we encounter? • Is creating something shared viable? • Would doing it be worth the effort? • What would success look like?
  14. Buttons for all! • What was the original design of

    our primary button? • What versions do we have coded up in the wild? • What could be improved? • How do we get some code to our developers? • How could we do this in a managed way? • Oh wait, there’s another version over here 
 used in [edge case] and over here [what even is that?]
  15. • Inventory • Find live examples • Learn from the

    design and code • Describe use cases • Create new or refactored version • Loop in the Inclusive Design Guild • Create feature branches, encourage code reviews over pull requests
  16. Typography • Conversations had been going on for ages •

    Different usage between Retail and Consumer • Appetite to find a resolution • Inconsistency in implementation • Too many choices for designers?
  17. Ownership • Listen • Encourage feedback • Understand and attempt

    to address concerns • See some tangible, positive outcome they can be a part of
  18. It goes like this… • Pattern emerges • Validate with

    designers • Consider use cases and requirements • Code it up and validate • Version the code • Communicate changes
  19. End to end • Joined up existing conversations • Got

    us to communicate better across the business • Encouraged more refinement and alignment of existing patterns • Considered how we share code across the business • How we establish a base pattern that is extensible without loads of overrides?
  20. • OOCSS - Structural model (Object Oriented CSS) • BEM

    - A naming convention (Block, Element, Modifier) • ITCSS - A organisational pattern (by Harry Roberts)
  21. • Maps / arrays for configuration • Added a new

    layer to ITCSS to allow for local overrides • Use functions to get these values over variables
  22. Outputs • A design you know is consistent • Leverage

    UX research, growing knowledge of accessibility, product/service thinking • Be far more collaborative • Develop style-guide or component library first • Think of the CSS that will be generated try to only output what is needed
  23. Downsides • Someone has to shepherd the process along so

    could be a bottleneck • People can’t always contribute because of time constraints • There will be bumps in the road. Until the code is used in these hostile environments, it’s not ready • It takes time to integrate with existing code - mostly added with new pieces of work
  24. Advice • Be prepared to be wrong about your approach

    • It has to work for the people that work on the site(s) • Be adaptable - requirements may change, 
 designs might diverge • Be pragmatic - don’t hold on to an ideal that ends up putting barriers in the way • Focus on bringing value to your teams • Set realistic expectations
  25. Dan Donald @hereinthehive Twitter: @autotraderlife Instagram: @autotrader_life Facebook: Auto Trader

    Life LinkedIn: Auto Trader UK https://careers.autotrader.co.uk/jobs/technology/UX-Developer