Empowering designers to code (2)

Learning to code is a journey, and the first milestone for designers is often learning HTML and CSS. A great style guide can really propel a designer on their journey to becoming a key contributor. The same attributes that make a style guides great for designing in the browser also help with CSS maintainability, scalability, performance, and can even make it enjoyable to work with CSS again. This talk delves into what makes a great style guide for designers and everyone else, with some tips on the process of building style guides.

Transcript

1. Empowering
   designers to code
   Diana Mounter
   @broccolini
   

   View Slide

2. Product Designer &
   Design Systems Lead
   GitHub
   !
   

   View Slide

3. Git is not GitHub
   

   View Slide

4. Git is
   a free and open source distributed
   version control system
   

   View Slide

5. GitHub is
   a collaboration platform built on top
   of Git, where you can host and share
   code
   

   View Slide

6. GitHub is
   a collaboration platform built on top
   of Git, where you can host and share
   code
   

   View Slide

7. Design Systems
   Goal: to build a robust, composable,
   and flexible system, that works across
   platforms and context, providing
   guidance on visual language, voice and
   tone, and implementation.
   

   View Slide

8. …but right now
   We’re mostly focussed on improving
   our CSS style guide. !
   

   View Slide

9. View Slide

10. “it’s all relative” - @jsavalle
    

    View Slide

11. Learning to code is 

    a journey
    

    View Slide

12. www
    

    View Slide

13. Setup dev
    environment?
    Git commit what?!
    How to push O_o
    Where is all the code?
    How to run tests?
    www
    

    View Slide

14. HTML & CSS
    prototypes
    Contributes
    to production
    Contributes
    to style guide
    Builds tools
    for others
    Fixes CSS bugs
    Refactors
    front-end code
    Improves
    performance
    

    View Slide

15. HTML & CSS
    prototypes
    Contributes
    to production
    Contributes
    to style guide
    Builds tools
    for others
    Fixes CSS bugs
    Refactors
    front-end code
    Improves
    performance
    

    View Slide

16. Style guides are a gateway 

    drug for empowering 

    designers to code
    

    View Slide

17. Style guides for
    designers
    

    View Slide

18. What makes a style guide
    good for designers?
    

    View Slide

19. What makes a style guide
    good for designers?
    1. Highly reusable and flexible styles
    

    View Slide

20. What makes a style guide
    good for designers?
    1. Highly reusable and flexible styles
    2. A clear and consistent naming convention
    

    View Slide

21. What makes a style guide
    good for designers?
    1. Highly reusable and flexible styles
    2. A clear and consistent naming convention
    3. Up-to-date and well written documentation
    

    View Slide

22. 1.Highly reusable and
    flexible styles
    

    View Slide

23. 1.Highly reusable and
    flexible styles
    Styles that can be mixed and
    matched to achieve many different
    layouts, independent of their
    location.
    

    View Slide

24. Components
    Frequently used patterns.
    !
    !
    !
    x
    x
    

    View Slide

25. !
    Layout objects
    Common layout patterns.
    The media object
    Grid systems
    ♥
    

    View Slide

26. !
    Layout objects
    Common layout patterns.
    The media object
    Grid systems
    ♥
    

    View Slide

27. !
    Layout objects
    Common layout patterns.
    The media object
    Grid systems
    ♥
    

    View Slide

28. Utilities
    Single-purpose classes that do one thing well.
    .h1
    .h2
    .h3
    .h4
    .CAPS
    .strong
    .regular
    .underline
    .no-underline
    .p-1 .p-2 .p-3 .p-4
    .text-gray
    .text-blue-light
    .text-blue-dark
    .text-blue
    .text-turquoise
    .text-green
    .text-yellow
    .text-orange
    .text-pink
    .text-red
    .mt-1
    .mt-2
    .mt-3
    .mt-4
    .mr-1
    .mr-2
    .mr-3
    .mr-4
    .py-4 .px-4
    

    View Slide

29. https://www.etsy.com
    

    View Slide

30. View Slide

31. https://www.etsy.com/shop/HookAndMatter
    

    View Slide

32. View Slide

33. Open/closed principle
    Open for extension, closed for
    modification.
    

    View Slide

34. Base component styles only contain
    styles shared across all variations.
    

    View Slide

35. Modifiers add variations on top of those
    styles, and don’t override base styles.
    ♥
    

    View Slide

36. 2.A clear and consistent 

    naming convention
    

    View Slide

37. 2.A clear and consistent 

    naming convention
    • Make it easy to understand what styles are
    being applied
    

    View Slide

38. "If I’m reading html, I want to know what
    the css is going to do.”
    - Adam Morse, CSS and Scalability
    

    View Slide

39. 
    
    Saved!
    
    

    View Slide

40. 2.A clear and consistent 

    naming convention
    • Make it easy to understand what styles are
    being applied
    • Follow a consistent pattern
    

    View Slide

41. .text-gray-dark
    .text-gray
    .text-gray-light
    .bg-blue-dark
    .bg-blue
    .bg-blue-light
    .btn
    .btn--small
    .btn--green-dark
    .card
    .card--small
    .card--large
    

    View Slide

42. 2.A clear and consistent 

    naming convention
    • Make it easy to understand what styles are
    being applied
    • Follow a consistent pattern
    • Promote reuse of styles
    

    View Slide

43. // Do
    .btn-orange {…}
    .alert-error {…}
    // Don’t
    .homepage-cta-button {…}
    .registration-form-error {…}
    Use presentational or functional names
    rather than location-specific
    

    View Slide

44. // Do
    .btn-orange {…} // Presentational
    .alert-error {…}
    Use presentational or functional names
    rather than location-specific
    

    View Slide

45. // Do
    .btn-orange {…}
    .alert-error {…} // Functional
    Use presentational or functional names
    rather than location-specific
    

    View Slide

46. // Do
    .btn-primary {…} // Functional
    .alert-red {…} // Presentational
    Use presentational or functional names
    rather than location-specific
    

    View Slide

47. Choose what’s right for
    your team.
    

    View Slide

48. “The most reusable components are those
    with class names that are independent of
    the content.”
    - Nicolas Gallagher, About HTML semantics and 

    front-end architecture
    

    View Slide

49. 3.Up-to-date & well-written
    documentation
    

    View Slide

50. 3.Up-to-date & well-written
    documentation
    • Explain how to use styles with production code
    examples
    

    View Slide

51. • Name
    • Description
    • Example
    • Code snippet
    

    View Slide

52. View Slide

53. CSS
    Style guide
    documentation
    Production
    website
    

    View Slide

54. 3.Up-to-date & well-written
    documentation
    • Explain how to use styles with production code
    examples
    • Keep documentation regularly updated
    

    View Slide

55. Show the status of styles, such as:
    experimental, stable, or deprecated
    Examples from: Salesforce Lightning Design System
    

    View Slide

56. • Use routine events as a reminder to make updates
    

    View Slide

57. • Use routine events as a reminder to make updates
    • Make it part of your code review checklist
    

    View Slide

58. • Use routine events as a reminder to make updates
    • Make it part of your code review checklist
    • Make it easy for everyone to contribute
    

    View Slide

59. View Slide

60. View Slide

61. CSS
    Style guide
    documentation
    Production
    website
    Markdown docs
    GitHub.com
    repo
    

    View Slide

62. View Slide

63. 3.Up-to-date & well-written
    documentation
    • Explain how to use styles with production code
    examples
    • Keep documentation regularly updated
    • Include principles and coding guidelines that
    explain the CSS behind the styles
    

    View Slide

64. Teach people the what, the how
    and the why, so they’ll become
    champions of your style guide.
    

    View Slide

65. Most importantly…
    A style guide should rarely
    require you to write new CSS.
    

    View Slide

66. Designing in the browser
    can be productive and fun!
    

    View Slide

67. Designers need a safe
    way to practice with
    production code.
    

    View Slide

68. Prototyping tools
    

    View Slide

69. Prototyping tools
    ✓ pulls in the style guide
    

    View Slide

70. Prototyping tools
    ✓ pulls in the style guide
    ✓ can share a URL to the prototype
    

    View Slide

71. Prototyping tools
    ✓ pulls in the style guide
    ✓ can share a URL to the prototype
    ✓ is tracked in Git
    

    View Slide

72. Prototyping tools
    ✓ pulls in the style guide
    ✓ can share a URL to the prototype
    ✓ is tracked in Git
    ✓ allows you to write custom JavaScript or CSS
    

    View Slide

73. Prototyping tools
    ✓ pulls in the style guide
    ✓ can share a URL to the prototype
    ✓ is tracked in Git
    ✓ allows you to write custom JavaScript or CSS
    ✓ includes a simple templating language
    

    View Slide

74. HTML & CSS
    prototypes
    

    View Slide

75. Contributes
    to production
    Contributes
    to style guide
    Builds tools
    for others
    Fixes CSS bugs
    Refactors
    front-end code
    Improves
    performance
    HTML & CSS
    prototypes
    

    View Slide

76. The issues with CSS
    that affect designers
    are often problems for
    everyone else too.
    

    View Slide

77. What makes a style guide
    good for designers everyone?
    1. Highly reusable and flexible styles
    2. A clear and consistent naming convention
    3. Up-to-date and well written documentation
    

    View Slide

78. Building style guides
    

    View Slide

79. 1. Write down your principles
    

    View Slide

80. Sure!
    You’re gonna make it OOCSS/
    functional/atomic/BEM right?
    

    View Slide

81. When you actually see the code.
    

    View Slide

82. Lots of arguments
    vibrant discussions
    

    View Slide

83. Principle led development!
    

    View Slide

84. 2. Design for systems
    

    View Slide

85. View Slide

86. View Slide

87. Spacing scales
    Use highly composable numbers, such as
    16 or 12. Not 10.
    

    View Slide

88. 16 breaks down
    8 8
    4 4
    4 4
    2 2
    2 2
    2 2
    2 2
    

    View Slide

89. 16 breaks down, and adds up to whole
    numbers more easily.
    32 32
    32 32
    32 32
    32 32
    64 64
    64 64
    128 128
    64
    

    View Slide

90. Type scales
    Type scales based on powers of two often
    end up in more sensible numbers.
    

    View Slide

91. - Brent Jackson, Mathematical Web Typography
    Type scales based on powers of two
    often end up in more sensible numbers.
    

    View Slide

92. 3. Evaluate decisions based on
    user needs
    

    View Slide

93. What’s important for your
    naming convention?
    • Searchablity
    • Clarity
    • Scannability
    • Intention
    

    View Slide

94. Treat your style guide
    like a product.
    

    View Slide

95. Style guides are design
    tools for the web.
    

    View Slide

96. • Reduce barriers
    

    View Slide

97. • Reduce barriers
    • Improve workflows
    

    View Slide

98. • Reduce barriers
    • Improve workflows
    • Build a better user experience
    

    View Slide

99. • Reduce barriers
    • Improve workflows
    • Build a better user experience
    • Empower designers to code
    

    View Slide

100. View Slide

101. Diana Mounter
     @broccolini
     Thank you.
     

     View Slide