Download as PDF, PPTX
Uploaded byCzech Design Systems Community
Three pillars of components in the design system
The document discusses the three essential pillars for developing frontend components in a design system: development, documentation, and communication. It focuses on development principles like atomic design and styled components. For documentation, it recommends creating a website with code examples, design usages, and accessibility info. Finally, it emphasizes effective communication through channels like Slack, responding to feedback and requests quickly, and announcing breaking changes in advance. The overall message is that components require development as well as comprehensive documentation and transparent communication.
More Related Content
Similar to Three pillars of components in the design system
Three pillars of components in the design system
- 1. Luděk Vepřek @elvepor Three pillarsof components in the design system
- 2. Luděk Vepřek • DesignSystem Engineer at Kiwi.com • Working on our Design System called Orbit • 6+ years of experience with design and frontend development
- 3. What design systemsare about?
- 4. What design systemsare about? 1. Design principles 2. Visual style & brand 3. Components & patterns
- 5. 1. Design principles 2.Visual style & brand 3. Components & patterns What design systems are about?
- 6. Three essential pillarsfor frontend components
- 7. 25 % 35% 40 % Three essential pillars for frontend components
- 8. 25 % 35 %40 % Three essential pillars for frontend components Development
- 9. 25 % 35% 40 % Three essential pillars for frontend components Development Documentation
- 10. 25 % 35% 40 % Three essential pillars for frontend components Development Documentation Communication
- 11.
- 12. Development • Which principlescan we use? • How should we develop our components? • What naming should we use? • How can we prevent unwanted breaking changes?
- 13. Which principles canwe use?
- 14. Lean approach Which principlescan we use?
- 15. Which principles canwe use? https://platzi.com/blog/por-que-atomic-design/
- 16. How should wedevelop our components?
- 17. How should wedevelop our components?
- 18. styled-components How should wedevelop our components?
- 19. Main benefits • Thinkingin components • Only the styles which are currently in use on your screen are also in the DOM • Bundle size • Unit tests • Full CSS and JS support
- 21. What naming shouldwe use?
- 22. What naming shouldwe use? • Inspire in other components libraries • Make it the most self-descriptive as you can • Document it somewhere for future reference
- 23. What naming shouldwe use? hasError is not the same as error
- 24. How can weprevent unwanted breaking changes?
- 25. Have unit tests! Howcan we prevent unwanted breaking changes?
- 26. Have unit tests! Howcan we prevent unwanted breaking changes? Jest + enzyme
- 27. How can weprevent unwanted breaking changes? Use static type checking!
- 28. How can weprevent unwanted breaking changes? Use static type checking!
- 29. How can weprevent unwanted breaking changes? Visual regression testing
- 33.
- 34. Documentation Create a websitefor the documentation
- 39. Documentation At Kiwi.com, wehad specific requirements
- 40.
- 41. Documentation • Using thepower of custom taxonomies • Friendly also to non-developers • Fetching different files from GitHub • Built-in full text search • SEO friendly • Easily extendable
- 42. Documentation How should wedocument components?
- 43. Documentation • Design &usages • Developer API • Code examples • Accessibility
- 44.
- 45.
- 46. Communication • How toget their trust? • How to announce changes? • Where and how to discuss requests? • How to ensure two-way communication? • How to communicate breaking changes?
- 47.
- 48. Communication #channel for frontendcomponents #channel for design #channel for various requests
- 49.
- 50.
- 51.
- 52.
- 53. What about requests? •Be opened to discuss changes • Be assertive • Be proactive • Respond to everything • Respond quickly
- 54.
- 55. Feedback • Teams allover Europe • Slack isn’t the best way always • The best solution is feedback loop • Do it physically!
- 56.
- 57. Breaking changes • Announcebreaking changes in advance • Put it somewhere
- 58.
- 59. Takeaways • Development isjust small part of the whole • Focus on consistency and maintainability • Document everything you can • Announce breaking changes in advance • Be as transparent as you can
- 61. Thank you foryour attention. Luděk Vepřek @elvepor https://github.com/kiwicom/orbit-components https://orbit.kiwi/