Delivering Flexible Cross Platform Design Systems

Delivering Flexible Cross Platform Design Systems

(Presented at Design Systems London 2018)

The affordances & aesthetics of a design system are only the tip of the iceberg for engineering teams operating at scale. The implementation of colors, typography, individual component interactions, and other aspects of the design language must be flexible enough to enable teams that may use multiple platforms (such as React & React native), multiple CSS approaches (such as class-based or inline-based CSS styling), or even multiple brands (i.e. white labeling).

This talk will explore delivery & implementation approaches for these aspects of design systems with a focus on developer experience. It will provide battle-hardened techniques and strategies that answer some of the most important engineering questions on how to deliver a flexible system into production Web & Native applications consistently across a large organization with several independent product teams.

D43e8ea63b61e7669ded5b9d3c2e980f?s=128

Charlie Robbins

November 16, 2018
Tweet

Transcript

  1. Placeholder Delivering Flexible Cross Platform
 Design Systems Delivering Flexible Cross

    Platform
 Design Systems
  2. None
  3. Who am I? Just

  4. None
  5. SENIOR DIR., UX PLATFORM GoDaddy ON THE INTERNET THEY CALL

    ME @INDEXZERO
  6. UX Platform? …?

  7. None
  8. cross cutting All of our technology user experience A BIT

    MORE THAN JUST OUR DESIGN SYSTEM
  9. None
  10. UXCore2 Our design system ABOUT 50 COMPONENTS REACT BASED OVER

    100 CONTRIBUTORS STARTED IN LATE 2015 SUPPORTS REACT NATIVE ~40% OF FRONT END ENGINEERS
  11. LET’S BREAKDOWN THE PROBLEM

  12. Delivering Flexible Cross Platform
 Design Systems Design Systems Cross Platform

    Flexible Delivering
  13. Delivering Flexible Cross Platform
 Design Systems Design Systems

  14. ELEMENTS of a DESIGN SYSTEM

  15. None
  16. ‘sub-atomic’ First off the

  17. ‘sub-atomic’ First off the atomic design of COLOR PALETTE, TYPOGRAPHY,

    SPACING, “VOICE”
  18. None
  19. COMPONENTS ATOMS & MOLECULES OF ATOMIC DESIGN Lots of

  20. None
  21. LIVING DOCUMENTATION all disciplines for

  22. LIVING DOCUMENTATION all disciplines for ENGINEERS TECHNICAL WRITERS DESIGNERS CONTRIBUTORS

  23. CONSIDER EVEN A SIMPLE BUTTON COMPONENT

  24. CONSIDER EVEN A SIMPLE BUTTON COMPONENT

  25. CONSIDER EVEN A SIMPLE BUTTON COMPONENT

  26. WORKFLOWS

  27. None
  28. governance of system extensibility The

  29. Delivering Flexible Cross Platform
 Design Systems Cross Platform

  30. BEHOLD… THE GLORIOUS INTERTUBES!

  31. BEHOLD… THE GLORIOUS INTERTUBES! WEB (OF COURSE) MOBILE WEB NATIVE

    MOBILE APPS NOT TO MENTION PRINT & VIDEO
  32. None
  33. RESPONSIVE DESIGN Assuming of course …yeah? Not up for debate,

    right?
  34. None
  35. REACT and REACT NATIVE

  36. STYLES

  37. STYLES CSS? INLINE STYLES? DO YOU NEED BOTH?

  38. IS SEEMS THAT IS MOVING IN THE RIGHT DIRECTION

  39. None
  40. native mobile mimic styles religiously?

  41. NO

  42. Well MAYBE IT DEPENDS. YMMV. NO

  43. CONSIDER A DROPDOWN ON WEB & MOBILE (REACT NATIVE)

  44. ‘intuitive familiar’ equals Raskin, ‘94

  45. Delivering Flexible Cross Platform
 Design Systems Flexible

  46. RESPONSIVE DESIGN We already said … FLEX(BOX)IBLE

  47. None
  48. FEATURES HOW MANY IS “TOO MANY”?

  49. None
  50. None
  51. None
  52. None
  53. None
  54. are you one brand? many? or

  55. λ-CALCULUS OF COLOR SELECTION

  56. λ-CALCULUS OF COLOR SELECTION

  57. λ-CALCULUS OF COLOR SELECTION

  58. λ-CALCULUS OF COLOR SELECTION WHAT IF A BRAND WANTS TO

    USE “SECONDARY” FOR “PRIMARY” BUTTON? MORE BUTTON-SPECIFIC VARIABLES FOR REBINDING In λ-calculus this is an “α-conversion”
  59. Flexible Cross Platform
 Design Systems Delivering

  60. None
  61. STAGES of DELIVERY

  62. DEVELOP & PUBLISH & PROMOTE & MAINTAIN & ROLLOUT

  63. None
  64. DEVELOP WHERE WORKFLOW IS KING

  65. None
  66. EASY Make it contributors for any new

  67. None
  68. ENTRY POINT Treat every a FIRST INTERACTION as though IT

    COULD BE
  69. None
  70. small module the most easily is understood

  71. None
  72. monorepo Using a diligence requires

  73. monorepo Using a YOUR PACKAGES/**/README.MD STILL MATTERS! diligence requires AND

    –– npm home your-package
  74. Use Storybook (cross platform is still a little rough)

  75. Use Storybook (cross platform is still a little rough) storybook

    Just use color me seriously impressed
  76. None
  77. HAVE an EXAMPLE STRUCTURE

  78. None
  79. imagine Now 25+ examples

  80. None
  81. EXACTLY WHAT’S A BETTER APPROACH?

  82. None
  83. None
  84. AS SIMPLE possible with as

  85. AS SIMPLE possible with as CLEAR REQUIRE / IMPORT USAGE

    DESIGN DOCUMENTATION PLATFORM SPECIFIC EXAMPLES ZERO CONFIG, SANE DEFAULTS
  86. None
  87. CHECK BACK IN ABOUT SIX WEEKS ^_^

  88. None
  89. PUBLISH WHAT COULD GO WRONG?

  90. None
  91. PRODUCTION begins at PUBLISH TIME

  92. None
  93. can break publishing NPM INSTALL & UNIT TESTS UPSTREAM BUILD

    TOOLCHAINS REACT NATIVE APPS MISCONFIGURED CONSUMERS
  94. None
  95. None
  96. PROMOTE ... CONTINUOUS DEPLOYMENT AND THE NATURE OF DESIGN SYSTEMS

  97. None
  98. too many unknowns there are simply …WHEN OPERATING AT LARGE

    ENOUGH SCALE ANYWAY
  99. Let’s

  100. Let’s ROLLOUT TO PRODUCTION!

  101. WARNING: CONSUMER BUNDLES SHOULD NOT INCLUDE YOUR DESIGN SYSTEM OR

    DEPENDENCIES THAT CHANGE INFREQUENTLY PLEASE BE ADVISED.
  102. None
  103. vendor bundle USE A

  104. There should only be one true version

  105. There should only be one true version design system of

    your in production
  106. None
  107. webpack externals EXPOSE and version them

  108. None
  109. webpack externals? WHAT ARE

  110. ANY ORDINARY WEBPACK BUNDLE

  111. ANY ORDINARY WEBPACK BUNDLE MODULE LOADER – THE “FACTORY”

  112. ANY ORDINARY WEBPACK BUNDLE MODULE LOADER – THE “FACTORY” MODULE

    0
  113. ANY ORDINARY WEBPACK BUNDLE MODULE LOADER – THE “FACTORY” MODULE

    0 module.exports = /* module 0’s code */
  114. ANY ORDINARY WEBPACK BUNDLE MODULE LOADER – THE “FACTORY” MODULE

    0 module.exports = /* module 0’s code */ MODULE 1 module.exports = /* module 1’s code */ MODULE 2 module.exports = /* module 2’s code */ MODULE 3 module.exports = /* module 3’s code */
  115. ANY ORDINARY WEBPACK BUNDLE MODULE LOADER – THE “FACTORY” MODULE

    0 module.exports = /* module 0’s code */ MODULE 1 module.exports = /* module 1’s code */ MODULE 2 module.exports = /* module 2’s code */ MODULE 3 module.exports = /* module 3’s code */ module.exports = window.path.to.module2;
  116. None
  117. None
  118. None
  119. CONSISTENT asset DISTRIBUTION

  120. Your computer npm publish your design system all your users

  121. Your computer npm publish Warehouse.ai your design system all your

    users new request versions every Xm
  122. None
  123. MAINTAIN FIXING FIRES BEFORE THEY HAPPEN

  124. None
  125. DEVOPS WHEN THINGS DON’T GO AS PLANNED

  126. None
  127. FAILOVER CACHING

  128. None
  129. YOU MUST have a ROLLBACK
 PLAN

  130. None
  131. warehouse.ai Using npm dist-tag add @your/package@1.2.3 prod makes this trivial

  132. warehouse.ai Using npm dist-tag add @your/package@1.2.3 prod makes this trivial

    ... TRY IT OUT! HTTPS://GITHUB.COM/GODADDY/WAREHOUSE.AI
  133. None
  134. HYGIENE PAYING TECHNICAL DEBT

  135. ... YOU CAN’T AVOID IT

  136. ... YOU CAN’T AVOID IT WARNING: ON A LONG ENOUGH

    TIMELINE, IF LEFT UNCHECKED ALL SOFTWARE WILL CRUMBLE FROM TECHNICAL DEBT PLEASE BE ADVISED.
  137. UPGRADING TO NEW VERSIONS: REACT, BABEL, WEBPACK, ETC. REMOVING DEPRECATED

    APIS E.G. componentWillReceiveProps, etc. USING LATEST APIS – E.G. PORTALS, REACT@16 CONTEXT, etc.
  138. IT ADDS UP QUICKLY UPGRADING TO NEW VERSIONS: REACT, BABEL,

    WEBPACK, ETC. REMOVING DEPRECATED APIS E.G. componentWillReceiveProps, etc. USING LATEST APIS – E.G. PORTALS, REACT@16 CONTEXT, etc.
  139. MAY THE SOURCE BE WITH YOU SLIDES WILL BE POSTED

    ON TWITTER SHORTLY – FOLLOW ME @INDEXZERO THANKS FOR LISTENING!