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

Empowering designers to code (2)

Diana
June 16, 2016

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.

Diana

June 16, 2016
Tweet

More Decks by Diana

Other Decks in Design

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