🇵🇱 DevConf PL 2022

ℹ️ Consistent UX at Scale: Lessons learned when I wore the DesignOps hat

The need for Design Systems comes with the need for scale, efficiency, and consistency in design. Those have been one of the major talking points in the design—and front-end—community for the past years. Some love it; some are more skeptical.

In this session, I'm gathering the common denominators I've noticed while working on Design Systems across small, medium, and huge companies, with an eye on points like consistency, themeability, accessibility, the path to deliver designs to actual code, and their adoption.

Transcript

1. Hello, DevConf 🙋 🇵🇱 🌎 CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT • THE 2ND OF SEPTEMBER, 2022.
2. MATHEUS ALBUQUERQUE CONSISTENT UX AT SCALE LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT
3. 🙋 I’M MATHEUS ↝ @YTHECOMBINATOR ON THE WEB ↝ SR. SOFTWARE ENGINEER @ MEDALLIA ↝ MENTOR @ TECHLABS BERLIN
4. Mostly, I discuss features build developer tools measure & optimize perceived perf write TSX code talk about these above
5. A bit of context CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT
6. #QUESTION 🤔 Who here works with front-end? And React?
7. #QUESTION 🤔 Who here has worked on a design system?
8. #EXERCISE 📚 Let’s talk about experiences!
9. COMPANY #1 ⚛ APPLICATION BUILT IN REACT NATIVE WEB 👥 DISCOVERY SIDE-PROJECT (~3 PEOPLE) ⚙ MONOREPO 😬 SHARED COMPONENTS (REACT/REACT NATIVE) Let’s talk about experiences COMPANY #2 ⚛ APPLICATIONS BUILT IN REACT
10. COMPANY #2 ⚛ APPLICATIONS BUILT IN REACT 👥 STARTUP (~8 PEOPLE, INCLUDING FE, BE, ETC.) ⚙ MULTIPLE REPOS 😬 NO DESIGN GUIDELINES; STARTING 100% FRESH Let’s talk about Experiences COMPANY #3 ⚛ APPLICATIONS BUILT IN REACT & ANGULAR
11. COMPANY #3 ⚛ APPLICATIONS BUILT IN REACT & ANGULAR 👥 HUGE CORP (TONS OF ENG & DESIGN TEAMS) ⚙ MULTIPLE REPOS 😬 DIFFERENT STACKS + MULTIPLE UI SDKS Let’s talk about Experiences COMPANY #4 ⚛ APPLICATIONS BUILT IN REACT
12. COMPANY #4 ⚛ APPLICATIONS BUILT IN REACT 👥 HUGE CORP (TONS OF ENG & DESIGN TEAMS) ⚙ MULTIPLE REPOS 😬 APPS NOT BUILT WITH ACCESSIBILITY IN MIND Let’s talk about Experiences
13. #QUESTION 🤔 Who here has been in at least one of those scenarios?
17. THE PRODUCT YOU SEE THE DEBT YOU DON’T SEE
18. This talk is about challenges results of teamwork common denominators moving across the eng. 㲗 design spectrum
19. This talk presents an overview accessibility dark mode delivery adoption conclusions
20. CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT Overview
21. Design Ops CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT AN INDIVIDUAL OR A DEPARTMENT RESPONSIBLE FOR PLANNING, DEFINING, AND MANAGING THE ENTIRE DESIGN PROCESS.
22. Design Ops CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT THEY STREAMLINE DESIGN, REMOVE INEFFICIENCIES, ENABLE THE DESIGNERS TO FLOW, AND HELP OPERATIONALIZE WORKFLOWS.
23. Design System CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT
24. ↝ DESIGN: THE PLAN OF LOOK AND FUNCTION OF SOMETHING ↝ SYSTEM: A COMBINATION OF PARTS WORKING TOGETHER ↝ DESIGN SYSTEM: A COLLECTIVE OF DEFINITIONS THAT WILL DICTATE PATTERNS IN WHICH THE INTERCONNECTING PARTS OF A SYSTEM WILL LOOK, FEEL, AND WORK
25. ↝ DESIGN: THE PLAN OF LOOK AND FUNCTION OF SOMETHING ↝ SYSTEM: A COMBINATION OF PARTS WORKING TOGETHER ↝ DESIGN SYSTEM: A COLLECTIVE OF DEFINITIONS THAT WILL DICTATE PATTERNS IN WHICH THE INTERCONNECTING PARTS OF A SYSTEM WILL LOOK, FEEL, AND WORK MORE THAN LOOKS
26. IT IS ABOUT EXPERIENCE! ↝ USER EXPERIENCE: WITH A RELIABLE AND FUNCTIONALLY CONSISTENT USER INTERFACE. ↝ DEVELOPER EXPERIENCE: WITH EASY-TO-INTEGRATE COMPONENTS AND DEFINED PATTERNS. ↝ STAKEHOLDER EXPERIENCE: WITH A GENERAL OVERVIEW OF HOW THE PRODUCT EVOLVES AND GROWS.
27. TWO APPROACHES: ↝ ORGANIC: TAKE AN EXISTING APP AS A REFERENCE, EXTRACT PIECES OF IT AND ABSTRACT THEM ENOUGH TO BE USED BY ANOTHER APP. ↝ INTENTIONAL: TOKENS, PATTERNS, AND COMPONENTS ARE THOUGHT AHEAD OF TIME.
28. 1. CARRIES FEWER DECISIONS FROM THE GET-GO 2. REQUIRES MORE REACTIVE EFFORT FROM THE TEAM TO ACCOMMODATE NEWLY FOUND REQUIREMENTS 3. ARCHITECTURAL DECISIONS TEND TO BE MADE AS THE NEED ARISES ORGANIC
29. INTENTIONAL 1. HAVING GOALS AND REQUIREMENTS IS AN IMPORTANT STEP TO ALIGN EXPECTATIONS WITH STAKEHOLDERS 2. BOUNDARIES OF AN MVP ARE DEFINED AND THEN WORK STARTS 3. TOKENS, PATTERNS, AND COMPONENTS ARE THOUGHT AOT 1. CARRIES FEWER DECISIONS FROM THE GET-GO
30. Accessibility CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT
32. Keyboard Interactions CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT
33. i18n (RTL layouts) CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT
34. Typeahead CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT
35. Autofill CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT
36. Autofill CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT
38. e.g. Press Interactions CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT
39. THEY CAN HAPPEN ON: ↝ MOUSE CLICKS ↝ TOUCH TAPS ↝ ENTER OR SPACE KEY PRESSES ↝ SCREEN READER VIRTUAL CLICKS
40. TO PROPERLY HANDLE THEM, YOU’D HAVE TO: ↝ USE POINTER EVENTS WHERE AVAILABLE AND FALLBACK TO MOUSE AND TOUCH EVENTS ↝ DISABLE TEXT SELECTION ON MOBILE WHEN PRESSED ↝ HANDLE CANCELING PRESS INTERACTIONS ON SCROLL ↝ NORMALIZE A TON OF CROSS-BROWSER INCONSISTENCIES
42. ↝ IT PROVIDES SEMANTICS ↝ IMPLEMENTATIONS PROVIDED BY THE WEB PLATFORM ARE EITHER NON-EXISTENT, LACKING IN FUNCTIONALITY, OR CANNOT BE CUSTOMIZED SUFFICIENTLY ↝ DEVELOPERS ARE FORCED TO BUILD CUSTOM COMPONENTS; AN INCREDIBLY DIFFICULT TASK
43. #PROTIP💡 Try not to spend too much time implementing keyboard navigation, discussing focus traps, and researching appropriate ARIA techniques for your components.
44. #PROTIP💡 Find an existing component library that is accessible and can be styled to match your brand and your design tokens.
45. THEY CAN BE: ↝ COMPOSITION PRIMITIVES: THE LOWEST LEVEL YOU CAN GET. YOU COMPOSE PRIMITIVES TO BUILD THE COMPONENT YOU NEED. ↝ UNSTYLED COMPONENTS: APPLY YOUR STYLING ON TOP OF THE PRE- BUILD UNSTYLED COMPONENTS. ↝ FULLY STYLED COMPONENTS: GET THE LIBRARY YOU LIKE, TUNE THE STYLING THROUGH THEIR THEMING SYSTEM AND GO.
46. REACT-ARIA DOWNSHIFT Composition Primitives
47. RADIX REACH UI Unstyled Components HEADLESS UI
48. HEADLESS UI REAKIT Unstyled Components
50. MUI CHAKRA UI Fully styled components NEXTUI
51. NEXTUI BASE WEB Fully styled components
52. #PROTIP💡 Which one you'll pick depends on the context, just keep in mind that accessibility is mandatory and they should be able to be styled to match your brand.
53. MY EXPERIENCE: ↝ COMPOSITION PRIMITIVES: WHEN REVAMPING SOME HUGE EXISTING COMPONENT CODEBASE TO BE ACCESSIBLE. ↝ UNSTYLED COMPONENTS: WHEN STARTING A BRAND NEW DESIGN SYSTEM FROM SCRATCH. ↝ FULLY STYLED COMPONENTS: ALL OF MY PERSONAL PROJECTS, INTERNAL TOOLS, HUGE FREELANCING PROJECTS, PROJECTS WITH NO FULL-TIME DESIGNERS, AND WHERE THE DESIGN GUIDELINES ARE A MATCH.
54. #PROTIP💡 Including automated accessibility testing throughout the development process can help quickly catch many accessibility errors.
55. ↝ BUILD PROCESS: INTEGRATE A TOOL LIKE AXE-CORE, JSX- A11Y, LIGHTHOUSE AUDITS, OR ACCESSLINT.JS INTO YOUR PROJECT TO PROGRAMMATICALLY ADD ACCESSIBILITY TESTS AND CATCH ERRORS AS YOU BUILD OUT YOUR APP. ↝ CONTINUOUS INTEGRATION: USE A TOOL LIKE AXE-LINTER OR ACCESSLINT TO FIND ACCESSIBILITY ISSUES IN YOUR GITHUB PULL REQUESTS.
57. #PROTIP💡 Always try to combine automated testing with ongoing manual testing. Manual testing is still the most reliable method to assess accessibility.
61. ↝ QUICK CHECK: USE A TOOL TO QUICKLY CHECK FOR COMMON ERRORS IN YOUR BROWSER. YOU CAN USE AXE, LIGHTHOUSE ACCESSIBILITY AUDIT, ACCESSIBILITY INSIGHTS, OR WAVE. ↝ SIMULATE IMPAIRMENTS: USE TOOLS TO SIMULATE COLOR BLINDNESS, LOW VISION, ZOOM, LOW CONTRAST, HIGH CONTRAST, AND MORE.
62. Dark Mode CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT
64. #EXERCISE 📚 Let's build a color palette with contrast in mind.
65. 0 1 2 3 4 5 6 7 8 9 9 8 7 6 5 4 3 2 1 0
66. 0 1 2 3 4 5 6 7 8 9 9 8 7 6 5 4 3 2 1 0 LINK: BLUE[5] LINK: BLUE[4]
67. 0 1 2 3 4 5 6 7 8 9 9 8 7 6 5 4 3 2 1 0 ICON: GRAY[6] ICON: GRAY[3]
68. 0 1 2 3 4 5 6 7 8 9 9 8 7 6 5 4 3 2 1 0 ICON: GRAY[6] ICON: GRAY[3] ICON: GRAY[4]
69. 0 1 2 3 4 5 6 7 8 9 9 8 7 6 5 4 3 2 1 0 ACCENT: ORANGE[6] ACCENT: ORANGE[3]
70. 0 1 2 3 4 5 6 7 8 9 9 8 7 6 5 4 3 2 1 0 ACCENT: ORANGE[6] ACCENT: ORANGE[3] ACCENT: ORANGE[6]
71. #PROTIP💡 Some colors move significant steps in the scale. Some require quite large adjustments.
72. WHICH IS BOLDER? WHICH IS BOLDER?
73. ✅ WE CAN CONTROL ↝ PALETTE ↝ COMPOSITION ❌ WE CAN’T CONTROL ↝ CONTEXT ↝ OBSERVATION
75. #PROTIP💡 Dark mode is not an inversion—it's dimming the lights.
78. 1. MUNSELL COLOR SYSTEM 2. THREE INDEPENDENT PROPERTIES OF COLOR WHICH CAN BE REPRESENTED CYLINDRICALLY IN THREE DIMENSIONS: ↝ HUE (BASIC COLOR) ↝ CHROMA (COLOR INTENSITY) ↝ VALUE (LIGHTNESS)
79. #QUOTE ✍ "[…] Desire to fit a chosen contour, such as the pyramid, cone, cylinder or cube, coupled with a lack of proper tests, has led to many distorted statements of color relations […]" — Albert H. Munsell, “A Pigment Color System and Notation
83. #PROTIP💡 Collaborate with designers and build extensions to their tools to optimize their work.
84. const theme = { colors: { black: "#1b1f23", white: "#fff", gray: ["#fafbfc", "#f6f8fa", "#e1e4e8"], green: ["#fOfff4", "#dcffe4", "#bef5cb"], dark: { black: "#000", white: "#fff", gray: ["#fafbfc", "#f6f8fa", "#e1e4e8"], green: ["#f5fff8", "#e5ffeb", "#cbf7d5"], }, }, };
85. ERROR? DANGER? CLOSE? DELETE? INFO? LINK? DEFAULT? NOTICE? SUCCESS? OPEN? SAVE? PRIMARY?
86. const theme = { colors: { black: "#1b1f23", white: "#fff", gray: ["#fafbfc", "#f6f8fa", "#e1e4e8"], green: ["#fOfff4", "#dcffe4", "#bef5cb"], dark: { black: "#000", white: "#fff", gray: ["#fafbfc", "#f6f8fa", "#e1e4e8"], green: ["#f5fff8", "#e5ffeb", "#cbf7d5"], }, }, };
87. const theme = { colors: { text: gray[9], white: white, primary: green[5], dark: { text: gray[1], white: black, primary: green[4], }, }, };
88. #PROTIP💡 If we want to achieve color modes and theming, we need an abstraction that is functional and not presentational.
89. Delivery CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT
90. Collaboration Workflow CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT
91. THE STATE OF ADVERTISING IN THE 1940s: 1. THE COPYWRITER TOOK WHAT THE CLIENTS WANTED TO SAY 2. THEY TURNED IT INTO A HEADLINE AND BODY COPY 3. THEY’D HAND THAT COPY TO AN ACCOUNT EXECUTIVE 4. THE EXECUTIVE WOULD FORWARD THAT TO THE ART DEPARTMENT 5. ARTISTS THEN FOLLOWED THE COPYWRITER’S ORDERS COPYWRITER AND THE ARTIST RARELY COLLABORATED.
93. #QUOTE ✍ “This was my first encounter with a copywriter who understood visual ideas and who didn’t come in with a yellow copy pad and a preconceived notion of what the layout should look like.” — Paul Rand
96. DESIGNER DEVELOPER WEEKS → Waterfall — THE HOT POTATO PROCESS, BY DAN MALL
97. WEEKS → Hot Potato DESIGNER DEVELOPER — THE HOT POTATO PROCESS, BY DAN MALL
98. #PROTIP💡 Try to have a flow where ideas are passed quickly back and forth from designer to developer for the entirety of a product creation cycle.
99. #QUESTION 🤔 How do you identify the source of truth in a Design System? Is it code, UI, or documentation?
100. Design to Code CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT
101. #QUESTION 🤔 Anyone here works—or has peers working—with Figma?
102. #QUESTION 🤔 Anyone here knows—or has used—its REST API?
105. #QUOTE ✍ "Design tokens are indivisible pieces of a design system such as colors, spacing, typography scale." — Design Tokens W3C Community Group
106. STYLES COMPONENTS/VARIANTS
107. #COLORS 🎨
109. 1. FETCHING + MAPPING STYLES + CODE GENERATION
110. 2. RUNNING THE AUTOMATION SCRIPTS (LOCALLY/CI)
111. 3. PROFIT!
112. 3. PROFIT!
113. #FONTS 🔤
114. 1. FETCHING + MAPPING STYLES + CODE GENERATION
115. 2. RUNNING THE AUTOMATION SCRIPTS (LOCALLY/CI)
116. 3. PROFIT!
117. 3. PROFIT!
118. SVGO PRETTIER Other Tools FIGMINT
119. Other Tools FIGMINT FIGMA-EXPORT-ICONS
123. #GOTCHA 😱 Designers would still have to ask us to manually run the script!
124. ITERATION #1 ↝ CI TO AUTOMATICALLY CHECK FOR UPDATES ↝ VERSIONING RELIES ON A COMPARISON SYSTEM WITH DIFF FILES ↝ CHANGELOGS AND VERSION BUMPING BASED ON THE DIFF FILE Versioning & Packaging ITERATION #2 ↝ SCHEDULED RUNS WERE REPLACED WITH WEBHOOKS
125. ITERATION #2 ↝ SCHEDULED RUNS WERE REPLACED WITH WEBHOOKS ↝ RESULTS: DESIGNERS WERE ABLE TO CHANGE HUES, ADD COLORS, AND CHANGE FONT VARIABLES WITH NO ENGINEERS’ HELP Versioning & Packaging ITERATION #3 ↝ AUTOMATION CALLS FOR MORE AUTOMATION!
126. ITERATION #3 ↝ AUTOMATION CALLS FOR MORE AUTOMATION! ↝ NOTIFICATIONS FOR FAILING BUILDS AND NEW RELEASES ↝ LINTING VIA CUSTOM FIGMA PLUGINS ↝ FULLY MOVING TO FIGMA TOKENS Versioning & Packaging
130. #PROTIP💡 Aim at version control systems that allow designers to work just like developers, and keep track of all changes.
132. Type Safety CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT
133. AFTER A FEW WEEKS ONBOARD A SASS-BASED CODEBASE, I FOUND MYSELF WITH TWO ISSUES: 1. I HAD DECREASED PRODUCTIVITY WHEN STYLING COMPONENTS IF COMPARED TO OTHER CODEBASES USING UI KITS OR CSS-IN-JS APPROACHES 2. I FOUND QUITE A FEW COMPONENTS ACCESSING NON- EXISTENT STYLES; WHICH COULD RESULT IN UNEXPECTED EXPERIENCES TO THE USERS
134. 1. I HAD DECREASED PRODUCTIVITY WHEN STYLING COMPONENTS IF COMPARED TO OTHER CODEBASES USING UI KITS OR CSS-IN-JS APPROACHES
135. 2. I FOUND QUITE A FEW COMPONENTS ACCESSING NON- EXISTENT STYLES; WHICH COULD RESULT IN UNEXPECTED EXPERIENCES TO THE USERS.
136. 2. I FOUND QUITE A FEW COMPONENTS ACCESSING NON- EXISTENT STYLES; WHICH COULD RESULT IN UNEXPECTED EXPERIENCES TO THE USERS. A TOTAL OF 96 ERRORS ON THE FIRST BUILD OF A CONDUCTED POC ILLUSTRATED HOW OFTEN THIS USED TO HAPPEN.
137. THE OVERALL EFFORT: 1. FIND AND SET UP A WEBPACK LOADER THAT GENERATES TS TYPINGS FOR CSS MODULES 2. FIX BROKEN BUILDS CAUSED BY EITHER INEXISTENT STYLES OR BY INSUFFICIENT TYPE SAFETY 3. RUN SOME TESTS TO CHECK WHETHER IT WORKS AS EXPECTED OR NOT
138. THE OVERALL EFFORT: 1. FIND AND SET UP A WEBPACK LOADER THAT GENERATES TS TYPINGS FOR CSS MODULES → ENABLES ITERATIVE DX 2. FIX BROKEN BUILDS CAUSED BY EITHER INEXISTENT STYLES OR BY INSUFFICIENT TYPE SAFETY 3. RUN SOME TESTS TO CHECK WHETHER IT WORKS AS EXPECTED OR NOT
139. THE OVERALL EFFORT: 1. FIND AND SET UP A WEBPACK LOADER THAT GENERATES TS TYPINGS FOR CSS MODULES → ENABLES ITERATIVE DX 2. FIX BROKEN BUILDS CAUSED BY EITHER INEXISTENT STYLES OR BY INSUFFICIENT TYPE SAFETY → E.G. INTERPOLATED VARIABLES 3. RUN SOME TESTS TO CHECK WHETHER IT WORKS AS EXPECTED OR NOT
140. Results CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT
141. Results CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT
143. / / 😐 Manual and repetitive type CssPadding = 'padding-left' | 'padding-right' | 'padding-top' | 'padding-bottom';
144. / / 😐 Manual and repetitive type CssPadding = 'padding-left' | 'padding-right' | 'padding-top' | ‘padding-bottom'; type Direction = 'left' | 'right' | 'top' | 'bottom'; type CssPadding = `padding-${Direction}` / / Result: 'padding-left' | 'padding-right' | 'padding-top' | 'padding-bottom'
145. / / 😐 Manual and repetitive type CssPadding = 'padding-left' | 'padding-right' | 'padding-top' | ‘padding-bottom'; type Direction = 'left' | 'right' | 'top' | 'bottom'; type CssPadding = `padding-${Direction}` type CssMargin = `margin-${Direction}`
146. Adoption CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT
147. #PROTIP💡 A Design System has to be actively used to make the UX and DX better. Otherwise, it's a waste of effort.
149. #QUESTION 🤔 How do we define usage?
150. Homebrew Components CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT / / Homebrew const BaseButton = ({ children }) = > <button>{children}</button>; / / NOT Homebrew const Button = () = > <BaseButton>Click me<BaseButton/>;
151. / / Homebrew const BaseButton = ({ children }) = > <button>{children}</button>; / / NOT Homebrew const Button = () = > <BaseButton>Click me<BaseButton/>;
152. CALCULATE THE USAGE SHARE: 1. FIND HOMEBREW COMPONENTS 2. FIND DESIGN SYSTEM IMPORTS 3. COLLECT USAGES OF BOTH 4. CALCULATE PROPORTION 5. REPEAT FOR COMMITS IN CODEBASE HISTORY
153. / / Homebrew const BaseButton = ({ children }) = > <button>{children}</button>; / / NOT Homebrew const Button = () = > <BaseButton>Click me<BaseButton/>;
154. / / Homebrew const BaseButton = ({ children }) = > <button>{children}</button>; / / Scenario #1 const StyledButton = BaseButton; const Button = () = > <StyledButton>Click me<StyledButton/>;
155. / / Homebrew const BaseButton = ({ children }) = > <button>{children}</button>; / / Scenario #2 const StyledButton = () = > <View mainButton={BaseButton} />
156. / / Homebrew const BaseButton = ({ children }) = > <button>{children}</button>; / / Usage scenario #3 const withProps = (Component) = > (props) = > <Component { . . . props} />; const ButtonWithProps = withProps(BaseButton); const Button = () = > <ButtonWithProps>Click me</ButtonWithProps>;
157. / / Homebrew export const BaseButton = ({ children }) = > <button>{children}</button>; / / Usage scenario #4 import { BaseButton as Button } from './button' const StyledButton = () = > <Button>Click me</Button>
158. #PROTIP💡 Usage in code is a complicated concept. Find a static analysis tool that does the work for you.
161. Absolute Usage CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT — RADIUS TRACKER, BY RANGLE
162. DESIGN SYSTEM HOMEBREW ↑ USAGE LEVELS ← WEEKS AGO
163. Design System Share CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT — RADIUS TRACKER, BY RANGLE
164. ↑ DESIGN SYSTEM SHARE ← WEEKS AGO
165. SHARE % TIME ❌ BAD ✅ GOOD
166. #PROTIP💡 Usage share is about the entire team, not just the engineers and thus it should be part of your regular governance.
167. CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT Conclusions
168. CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT 1. IS YOUR DESIGN SYSTEM BEING ADOPTED?
169. CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT 1. EVANGELISM IS VERY HARD! IS YOUR DESIGN SYSTEM BEING ADOPTED?
170. CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT 2. BUILD IN ACCESSIBILITY AS YOU GO
171. CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT 2. IF YOU PRIORITIZE AT THE COMPONENT LEVEL YOU GET IT FOR “FREE” BUILD IN ACCESSIBILITY AS YOU GO
172. CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT 3. DARK MODE IS NOT AN INVERSION; IT'S DIMMING THE LIGHTS
173. CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT 4. "PERFECT IS THE ENEMY OF GOOD" — VOLTAIRE
174. CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT 4. EARLY PREVIEW = EARLY FEEDBACK "PERFECT IS THE ENEMY OF GOOD"
175. CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT 5. ENFORCE THE MOST IMPORTANT CODE THINGS BY TOOLS AND AUTOMATION
176. CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT 5. DOCUMENT THE PROCESS IMPORTANT CODE THINGS BY TOOLS AND AUTOMATION
177. CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT 6. CSS CLASSES, TOKEN DEFINITIONS, TYPEFACES…
178. CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT 6. CSS CLASSES, TOKEN DEFINITIONS, TYPEFACES… TOOLING, ACTIVE SUPPORT, AND ADVOCACY
179. CONSISTENT UX AT SCALE: LESSONS LEARNED WHEN I WORE THE DESIGNOPS HAT 7. "IN GOD WE TRUST. ALL OTHERS MUST BRING DATA." — W. EDWARDS DEMING
181. We’re hiring! 🗺 Mostly in… 🇺🇸🇲🇽🇦🇷🇺🇾🇪🇸🇨🇿🇮🇱🇮🇳
182. We’re hiring! 🗺
186. THAT’S ALL, FOLKS! THANKS! QUESTIONS? MATHEUS ALBUQUERQUE