Components: Go big? Go small? Do 'em all!

Slide 1

Slide 1 text

Go big? Go small? Do ‘em all! Components Nathan Curtis SmashingConf September 2022 Freiburg, Germany

Slide 2

Slide 2 text

Hi, I’m Nathan Live near Washington, DC EightShapes @nathanacurtis @nathanacurtis 2000 2006 2007 2015 AT T R I B U T E S S i n c e

Slide 3

Slide 3 text

{label} {label} {label} {Title} {Details} {Label} {Label} {label} Value {help text} Body Large Body Medium (Default) Body Small {label} {label} {label} S e p t e m b e r 2 0 2 2 SmashingConf Fun Learn C a r d A l e r t I n p u t B u t t o n c h e c k b o x I c o n o g r a p h y T y p o g r a p h y C o l o r S t y l e U I c o m p o n e n t s

Slide 4

Slide 4 text

Style and UI components Time C a r d A l e r t I n p u t B u t t o n c h e c k b o x I c o n o g r a p h y T y p o g r a p h y C o l o r

Slide 5

Slide 5 text

Style and UI components Time

Slide 6

Slide 6 text

Style and UI components Time

Slide 7

Slide 7 text

79 S h o p i f y p o l a r i s 85 S a l e s f o r c e l i g h t n i n g 39 I B M C a r b o n 50 62 At l a s s i a n d e s i g n A d o b e s p e c t r u m

Slide 8

Slide 8 text

30 2 0 2 0 26 2 0 1 9 50 Atlassian 37 2 0 2 2 2 0 2 1

Slide 9

Slide 9 text

2 0 1 7 2 0 1 8 2 0 1 9 2 0 2 0 2 0 2 2 18 28 44 47 45 https://designsystem.morningstar.com Morningstar

Slide 10

Slide 10 text

Relative to your current component catalog, you need: more components the same component quantity (at a higher quality) fewer components Why?

Slide 11

Slide 11 text

Considerations We don’t make all components. Shared needs Support cost Maintenance Caution

Slide 12

Slide 12 text

Considerations We don’t make all components. Shared needs Support cost Maintenance We need quality, not quantity. Accessibility Usability Performance Caution Optimization

Slide 13

Slide 13 text

Considerations Our challenge ISN’T components. Documentation Adoption Measurement Testing Pipeline Communications Support Onboarding Contributions We don’t make all components. Shared needs Support cost Maintenance We need quality, not quantity. Accessibility Usability Performance Caution Optimization Expansion

Slide 14

Slide 14 text

Should we make bigger components? Should we offer smaller flexible components? Is this the place for shared components?

Slide 15

Slide 15 text

Should we make bigger components? Should we offer smaller flexible components? Is this the place for shared components?

Slide 16

Slide 16 text

We need organisms! – d e s i g n s y s t e m p r o d u c t m a n a g e r

Slide 17

Slide 17 text

https://atomicdesign.bradfrost.com/chapter-2/

Slide 18

Slide 18 text

https://atomicdesign.bradfrost.com/chapter-2/ Their experience Design system

Slide 19

Slide 19 text

Organisms are an uncomfortable joke. – James Melzer, EightShapes design systems lead

Slide 20

Slide 20 text

Filter

Slide 21

Slide 21 text

IBM Carbon Shopify Polaris Morningstar Google Filters

Slide 22

Slide 22 text

What’s the same? What’s different? What’s shared? Filter patterns

Slide 23

Slide 23 text

Who makes it? Where do you go to get it? What needs to be made?

Slide 24

Slide 24 text

Typography Button Checkbox Icon button

Slide 25

Slide 25 text

Drawer Search field Nested checkboxes Checkbox drawer Full screen toggle Full screen modal? Responsive design

Slide 26

Slide 26 text

Filter patterns Design system Filter as drawer Filter as drawer with nested multi-selection Account filter as drawer integrated with back-end Teams that need... 0% 50% 25% 75% 100% Teams in the enterprise

Slide 27

Slide 27 text

Filter patterns Design system Filter as drawer Filter as drawer with nested multi-selection Account filter as drawer integrated with back-end built and configurable as spec’ed Teams that need... Teams commited to use within 12 months... 0% Teams in the enterprise 50% 25% 75% 100%

Slide 28

Slide 28 text

https://medium.com/eightshapes-llc/design-system-subtasks-by-step-2f43d7d4bce0 https://medium.com/eightshapes-llc/system-features-step-by-step-e69c90982630 Discovery Design Specs Figma assets Design docs Code Tasks to complete

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Who makes specs? Who composes docs? Who codes? Who maintains the code? Specs Design docs Code Tasks to complete

Slide 31

Slide 31 text

% Broad need for a filter drawe % All teams in need agree to use i! % Great experiment to build and learn Core team build and own a Filter drawer that’s back-end integrated Adoption (~30% of all products) Consistent experiences Efficient delivery by product Satisfied implementing teams Great learning investment. Worthwhile feature investment. Filter

Slide 32

Slide 32 text

Data table Calendar O U T C O M E Adoption (~50% of all repos!) Consistency, efficiency I N R E T R O S P E C T Great investment. O U T C O M E Adoption (Little to no usage) Dissatisfied team, wasted time I N R E T R O S P E C T Bad investment.

Slide 33

Slide 33 text

Design system 1 Design system 2 Editor Richly formatted text and even ! @mentions maintainer Core team OUTCOME Low adoption Opportunity cost Maintenance cost IN RETROSPECT Bad investment. maintainer Dev community OUTCOME High adoption Consistent, rapid innovation Unclear relationship to core? IN RETROSPECT Great investment. Low / no central cost.

Slide 34

Slide 34 text

Organisms must serve a worthwhile shared need. Mostly, keep “smart” organisms local or in a shared space. Demo organisms with patterns, templates, and demo apps Organisms may lack support: priorities ≠ supporting other teams.

Slide 35

Slide 35 text

Should we make bigger components? Is this the place for shared components? Should we offer smaller flexible components?

Slide 36

Slide 36 text

Great! Let’s add a property. I need something for my product. I want something from the system. S y s t e m u s e r S y s t e m m a k e r

Slide 37

Slide 37 text

Figma Designer Engineer Anatomy Properties Code Property Type Default disabled false boolean error false boolean errorText string helperTextPlacement bottom bottom right , inlineLabel boolean false label string required boolean false

Slide 38

Slide 38 text

Impressionism Impression, Sunrise Claude Monet Vernazza 3.2 of 5 Colosseum Europe / Florence Bigger and better! Gear and guidebooks Mt. Cook

Slide 39

Slide 39 text

{Title} {Description} {Title} {Description} {Title} {Description} {Title} {Description} {Title} {Description} {Label} {Title} {Description}

Slide 40

Slide 40 text

{Title} {Description} {Title} {Description} {Title} {Description} {Title} {Description} {Title} {Description} {Label} {Title} {Description} CAN’T CAN’T CAN’T CAN’T CAN’T CAN’T

Slide 41

Slide 41 text

Ä We add a property A l t e r n a t i v e s

Slide 42

Slide 42 text

We add a propert Â You make it all A l t e r n at i v e s

Slide 43

Slide 43 text

% We add a propert# Ç% You make it al Ã% You put it together,  with smaller parts A l t e r n at i v e s

Slide 44

Slide 44 text

E x a m p l e d e s t i n at i o n Mt. Cook New Zealand Card CardMedia CardText Subcomponent An independent UI component with a well-defined API intended for use only within a specific parent.

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

pa r t s C o n ta i n e r s

Slide 48

Slide 48 text

CardText CardActions CardContainer CardMedia CardContent

Slide 49

Slide 49 text

Lockups Extensions p a r t s C o n t a i n e r s

Slide 50

Slide 50 text

C o n ta i n e r s pa r t s Combinations Extensions Lockups

Slide 51

Slide 51 text

Lockups Extensions Combinations Repeater p a r t s C o n t a i n e r s

Slide 52

Slide 52 text

Lockups Generic Extensions Combinations Repeater p a r t s C o n t a i n e r s

Slide 53

Slide 53 text

Lockups Generic Extensions Typed Combinations Repeater p a r t s C o n t a i n e r s Icon? Image? Video player? Spot illustration?

Slide 54

Slide 54 text

Lockups Generic Extensions Typed Combinations Interactive Repeater p a r t s C o n t a i n e r s CardButton IconButton

Slide 55

Slide 55 text

Lockups p a r t s C o n t a i n e r s 4 8 24

Slide 56

Slide 56 text

B e h av i o r s l ay o u t a n d s pa c i n g c o m p o s i t i o n Include states in or offer ? Force padding? Lack padding? Offer an inset prop? Include with inset or add margin to ? CardContainer CardButton CardContent CardText

Slide 57

Slide 57 text

Reorder Reorient Add behaviors Add nested components Expand use cases Customize actions

Slide 58

Slide 58 text

Flexible Empowering Innovative Unblocking Simpler

Slide 59

Slide 59 text

Flexible Empowering Innovative Unblocking Simpler Inconsistency? Trust? More work? More debt? Awkward tools? Harder to learn? Less performant?

Slide 60

Slide 60 text

1. Make the very common configurable. 2. Make the less common configurable, as time permits.

Slide 61

Slide 61 text

1. Make the very common configurable. 2. Make the uncommon composable. 3. Make the less common configurable, as time permits.

Slide 62

Slide 62 text

Should we make bigger components? Should we offer smaller flexible components? Is this the place for shared components?

Slide 63

Slide 63 text

Great! Let’s add that? I have something I want to share. I think other people need this. S y s t e m u s e r ( d e s i g n e r o r e n g i n e e r ) S y s t e m m a k e r ( d e s i g n e r o r e n g i n e e r )

Slide 64

Slide 64 text

One-source-of-truth. Singular. Central. Perfect.

Slide 65

Slide 65 text

Local team A group working together to deliver an experience, one fix, enhancement or redesign at a time.

Slide 66

Slide 66 text

Local library A local library is a set of styles and/or UI components addressing a team’s unique needs that is built and supported by that team for use by that team.

Slide 67

Slide 67 text

People / Team Models / Solitary Central (or “Core”) Federated (or “Community”) https://medium.com/eightshapes-llc/team-models-for-scaling-a-design-system-2cf9d03be6a0

Slide 68

Slide 68 text

From  core kit made by a central team To  shared kits made by federated masses

Slide 69

Slide 69 text

Central (or “Core”) Federated (or “Community”) People / Team Models / OR

Slide 70

Slide 70 text

OR Central (or “Core”) Federated (or “Community”) People / Team Models / WRONG MENTAL MODEL

Slide 71

Slide 71 text

People / Team Models / Central (or “Core”) Federated (or “Community”) AND THEN...

Slide 72

Slide 72 text

Shared space?

Slide 73

Slide 73 text

Nathan Curtis https://medium.com/eightshapes-llc/design-system-tiers-2c827b67eae1 Gerrit Kaiser, Marina Posniak, Shaun Bent Robin Cannon, IBM Carbon https://spotify.design/article/reimagining-design-systems-at-spotify Reimagining Design Systems at Spotify Design System Tiers https://shinytoyrobots.substack.com/p/the-hub-and-spoke-design-system-model The hub and spoke design system model

Slide 74

Slide 74 text

.com Components .com Components In Design System - Edited 3 minutes ago Onboarding Onboarding In Design System - Edited 3 minutes ago Media Content Media Content In Design System - Edited 3 minutes ago Conversational Conversational In Design System - Edited 3 minutes ago Editor Editor In Design System - Edited 3 minutes ago Tokens Tokens In Design System - Edited 3 minutes ago Core components Tokens In Design System - Edited 3 minutes ago Charts Charts In Design System - Edited 3 minutes ago Search Search In Design System - Edited 3 minutes ago Navigation Navigation In Design System - Edited 3 minutes ago For iOS System for iOS In Design System - Edited 3 minutes ago For TV Platforms System for TV In Design System - Edited 3 minutes ago For Android System for Android In Design System - Edited 3 minutes ago CMS kits Patterns Component sets S y s t e m a s p l at f o r m S y s t e m a s p r o d u c t Core Platform kits Other concepts

Slide 75

Slide 75 text

Shared library Expansion packs Feature library Supplementary library Library extensions Community library Product component library (PCL) Product UI kit Shared libraries / What is it called?

Slide 76

Slide 76 text

Shared libraries / Where does it go?

Slide 77

Slide 77 text

Shared libraries / Who is involved? Shared library maintainer Core team steward Shared library maintainer Shared library contributor Shared library contributor Shared library contributor

Slide 78

Slide 78 text

Shared libraries / How does it work? Setup Who decides that a library can be created? Who names the library, such as “Shop” or “Editor” or “iOS”? Who owns the library’s Figma team, project, and file? Who are editors of the file’s main branch? Who administers access and permissions for the library? Plan Produce Who organizes features across pages? ️ Who prioritizes features that will go in the library? Who approves that work on a specific feature can begin? Who names and scopes the feature? Who audits relevant experiences for existing patterns? Who scopes and solicits feedback on feature requirements? Who designs the feature? Who builds the Figma component, layers, props, styles, etc? Who specs the feature enough to be coded by a developer? Who documents the feature with use when, examples, …? Anyone can do it Must involve library maintainer or steward Always involve with steward Only the steward as admin

Slide 79

Slide 79 text

Shared libraries / How does it work? How does it work? Setup Who decides that a library can be created? Who names the library, such as “Shop” or “Editor” or “iOS”? Who owns the library’s Figma team, project, and file? Who are editors of the file’s main branch? Who administers access and permissions for the library? Plan Produce Who organizes features across pages? ️ Who prioritizes features that will go in the library? Who approves that work on a specific feature can begin? Who names and scopes the feature? Who audits relevant experiences for existing patterns? Who scopes and solicits feedback on feature requirements? Who designs the feature? Who builds the Figma component, layers, props, styles, etc? Who specs the feature enough to be coded by a developer? Who documents the feature with use when, examples, …? Anyone can do it Must involve library maintainer or steward Always involve with steward Only the steward as admin Review Who approves that the feature is designed sufficiently? Who approves that the feature is built well (layers, props, ...)? Who tests the feature prior to publishing? Publish Monitor, maintain, & upgrade Who publishes library styles and UI components? Who communicates changes to that library’s users? Who can promote a feature from a shared to core? Who pays attention to usage via Figma analytics? Who responds to requests for enhancements and fixes? Who extends existing features with enhancements? Who fixes defects in published things? Who upgrades and refactors when core libraries change?