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

Transcript

1. Adding the foundations after the house has been built Design systems at Auto Trader
2. 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.
3. Magazine issues image?
5. A future in stock photography?
6. Auto Trader is…
7. http://www.full-stackagile.com/2016/02/14/team-organisation-squads-chapters-tribes-and-guilds/
8. So what’s the problem?
9. Too long to roll out design changes
10. Lack of consistency
11. Multiple implementations of the same patterns
12. Some of the older parts of the site, we might not get to… (at least for a while)
13. Many different tech stacks
14. Tech stacks Java stuff
15. Tech stacks Java stuff Bit of Angular over here
16. Tech stacks Java stuff Bit of Angular over here Few bucketfuls of React
17. Tech stacks Java stuff Bit of Angular over here Few bucketfuls of React Found a bit of jQuery over here
18. Tech stacks Java stuff Bit of Angular over here Few bucketfuls of React Found a bit of jQuery over here Ahhh remember Backbone…?
19. 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?
20. 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?
21. Design Systems: The magical cure to all things
22. Reality
23. Always people > tech
24. We’re already busy so how does this get done?
25. What is a design system? • A style guide? • A component library? • Some kind of asset/symbol library? • All of the above? • More than that?
26. –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.”
27. https://designsystemsrepo.com/design-systems/
28. BBC: GEL http://www.bbc.co.uk/gel/
29. GitHub: Primer https://styleguide.github.com/primer/
30. Google: Material Design https://material.io
31. GDS https://design-system.service.gov.uk
32. GDS https://design-system.service.gov.uk
33. Bulb: Solar http://design.bulb.co.uk
34. Co-op https://coop-design-system.herokuapp.com
35. Problem solved! • We just make one of those design system things and… • Have a nice cup of tea… • Go back to step #1
36. 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?
37. Legacy code…
38. 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
39. Step #1 Get the team together
40. 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
41. Step #2 Understand the landscape
42. • 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?
43. Step #3 Gauge the appetite
44. Step #4 Be pragmatic - how would this work?
45. Step #5 Proof of concept
46. 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?]
47. Step #6 Feedback loop
48. • 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
49. Step #7 Work on our differences
50. 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?
55. Dealing with design debt
56. Step #8 Ownership
57. Ownership • Listen • Encourage feedback • Understand and attempt to address concerns • See some tangible, positive outcome they can be a part of
58. Consistency of design
59. Sketch using Craft https://www.invisionapp.com/craft
60. Reducing duplication of code
61. Retail / Portal Custom code
62. Consumer: Storybook https://storybook.js.org
63. The missing piece…
64. Sparkplug
65. Fractal http://fractal.build
66. It goes like this… • Pattern emerges • Validate with designers • Consider use cases and requirements • Code it up and validate • Version the code • Communicate changes
67. Its just a style guide, right?
68. Its just a pattern library style guide, right?
69. Its just a way of communicating design pattern library style guide, right?
70. Bring in good practices
71. Accessibility and inclusive design
72. Design pairing Designer and front-end developer working together
73. 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?
74. Encourage participation Front-end Developers UX Researchers Designers Back-end Developers Content-type people QAs / Testers That guy
75. Non technical input
76. pa11y http://pa11y.org
77. How should we do CSS/Sass A couple of slides of geekiness… indulge me!
78. • OOCSS - Structural model (Object Oriented CSS) • BEM - A naming convention (Block, Element, Modifier) • ITCSS - A organisational pattern (by Harry Roberts)
79. • Maps / arrays for configuration • Added a new layer to ITCSS to allow for local overrides • Use functions to get these values over variables
80. Start with archetypes
82. SassDoc http://sassdoc.com
83. Sparkplug Docs
84. Pragmatism over dogma
85. What constitutes a design pattern?
86. Design to design pattern to component
87. It’s all about the output
88. 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
89. 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
90. 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
91. A design system is a journey
92. 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