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.

Transcript

1. Placeholder Delivering Flexible Cross Platform
 Design Systems Delivering Flexible Cross Platform
 Design Systems
3. Who am I? Just
5. SENIOR DIR., UX PLATFORM GoDaddy ON THE INTERNET THEY CALL ME @INDEXZERO
6. UX Platform? …?
8. cross cutting All of our technology user experience A BIT MORE THAN JUST OUR DESIGN SYSTEM
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
16. ‘sub-atomic’ First off the
17. ‘sub-atomic’ First off the atomic design of COLOR PALETTE, TYPOGRAPHY, SPACING, “VOICE”
19. COMPONENTS ATOMS & MOLECULES OF ATOMIC DESIGN Lots of
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
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
33. RESPONSIVE DESIGN Assuming of course …yeah? Not up for debate, right?
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
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
48. FEATURES HOW MANY IS “TOO MANY”?
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
61. STAGES of DELIVERY
62. DEVELOP & PUBLISH & PROMOTE & MAINTAIN & ROLLOUT
64. DEVELOP WHERE WORKFLOW IS KING
66. EASY Make it contributors for any new
68. ENTRY POINT Treat every a FIRST INTERACTION as though IT COULD BE
70. small module the most easily is understood
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
77. HAVE an EXAMPLE STRUCTURE
79. imagine Now 25+ examples
81. EXACTLY WHAT’S A BETTER APPROACH?
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
87. CHECK BACK IN ABOUT SIX WEEKS ^_^
89. PUBLISH WHAT COULD GO WRONG?
91. PRODUCTION begins at PUBLISH TIME
93. can break publishing NPM INSTALL & UNIT TESTS UPSTREAM BUILD TOOLCHAINS REACT NATIVE APPS MISCONFIGURED CONSUMERS
96. PROMOTE ... CONTINUOUS DEPLOYMENT AND THE NATURE OF DESIGN SYSTEMS
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.
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
107. webpack externals EXPOSE and version them
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;
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
123. MAINTAIN FIXING FIRES BEFORE THEY HAPPEN
125. DEVOPS WHEN THINGS DON’T GO AS PLANNED
127. FAILOVER CACHING
129. YOU MUST have a ROLLBACK
 PLAN
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
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!