Slides by Luděk Vepřek (Kiwi.com) - Design Systems Meetup June 2019

1. Luděk Vepřek
@elvepor
Three pillars of components
in the design system

2. Luděk Vepřek
• Design System Engineer at Kiwi.com
• Working on our Design System called
Orbit
• 6+ years of experience with design and
frontend development

3. What design systems are about?

4. What design systems are 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 pillars for 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. Development
🤩

12. Development
• Which principles can we use?
• How should we develop our components?
• What naming should we use?
• How can we prevent unwanted breaking changes?

13. Which principles can we use?

14. Lean approach
Which principles can we use?

15. Which principles can we use?
https://platzi.com/blog/por-que-atomic-design/

16. How should we develop our components?

17. How should we develop our components?

18. styled-components
How should we develop our components?

19. Main benefits
• Thinking in 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 should we use?

22. What naming should we use?
• Inspire in other components libraries
• Make it the most self-descriptive as you can
• Document it somewhere for future reference

23. What naming should we use?
hasError is not the same as error

24. How can we prevent unwanted breaking changes?

25. Have unit tests!
How can we prevent unwanted breaking changes?

26. Have unit tests!
How can we prevent unwanted breaking changes?
Jest + enzyme

27. How can we prevent unwanted breaking changes?
Use static type checking!

28. How can we prevent unwanted breaking changes?
Use static type checking!

29. How can we prevent unwanted breaking changes?
Visual regression testing

33. Documentation
😬

34. Documentation
Create a website for the documentation

39. Documentation
At Kiwi.com, we had specific requirements

40. Documentation

41. Documentation
• Using the power 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 we document components?

43. Documentation
• Design & usages
• Developer API
• Code examples
• Accessibility

44. Documentation
https://orbit.kiwi

45. 🤐
Communication

46. Communication
• How to get their trust?
• How to announce changes?
• Where and how to discuss requests?
• How to ensure two-way communication?
• How to communicate breaking changes?

47. Communication
Slack

48. Communication
#channel for frontend components
#channel for design
#channel for various requests

49. Communication

50. Communication

51. What about requests?

52. What about requests?

53. What about requests?
• Be opened to discuss changes
• Be assertive
• Be proactive
• Respond to everything
• Respond quickly

54. Feedback

55. Feedback
• Teams all over Europe
• Slack isn’t the best way always
• The best solution is feedback loop
• Do it physically!

56. Breaking changes

57. Breaking changes
• Announce breaking changes in advance
• Put it somewhere

58. Breaking changes

59. Takeaways
• Development is just 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 for your attention.
Luděk Vepřek
@elvepor
https://github.com/kiwicom/orbit-components
https://orbit.kiwi/