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

Transcript

1. Go big? Go small? Do ‘em all! Components Nathan Curtis SmashingConf September 2022 Freiburg, Germany
2. 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
3. {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
4. 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
5. Style and UI components Time
6. Style and UI components Time
7. 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
8. 30 2 0 2 0 26 2 0 1 9 50 Atlassian 37 2 0 2 2 2 0 2 1
9. 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
10. Relative to your current component catalog, you need: more components the same component quantity (at a higher quality) fewer components Why?
11. Considerations We don’t make all components. Shared needs Support cost Maintenance Caution
12. Considerations We don’t make all components. Shared needs Support cost Maintenance We need quality, not quantity. Accessibility Usability Performance Caution Optimization
13. 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
14. Should we make bigger components? Should we offer smaller flexible components? Is this the place for shared components?
15. Should we make bigger components? Should we offer smaller flexible components? Is this the place for shared components?
16. 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
17. https://atomicdesign.bradfrost.com/chapter-2/
18. https://atomicdesign.bradfrost.com/chapter-2/ Their experience Design system
19. Organisms are an uncomfortable joke. – James Melzer, EightShapes design systems lead
20. Filter
21. IBM Carbon Shopify Polaris Morningstar Google Filters
22. What’s the same? What’s different? What’s shared? Filter patterns
23. Who makes it? Where do you go to get it? What needs to be made?
24. Typography Button Checkbox Icon button
25. Drawer Search field Nested checkboxes Checkbox drawer Full screen toggle Full screen modal? Responsive design
26. 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
27. 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%
28. 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
29. https://medium.com/eightshapes-llc/design-system-subtasks-by-step-2f43d7d4bce0 https://medium.com/eightshapes-llc/system-features-step-by-step-e69c90982630 Discovery Design Figma assets Tasks to complete
30. Who makes specs? Who composes docs? Who codes? Who maintains the code? Specs Design docs Code Tasks to complete
31. % 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
32. 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.
33. 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.
34. 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.
35. Should we make bigger components? Is this the place for shared components? Should we offer smaller flexible components?
36. 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
37. 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
38. Impressionism Impression, Sunrise Claude Monet Vernazza 3.2 of 5 Colosseum Europe / Florence Bigger and better! Gear and guidebooks Mt. Cook
39. {Title} {Description} {Title} {Description} {Title} {Description} {Title} {Description} {Title} {Description} {Label} {Title} {Description}
40. {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
41. Ä We add a property A l t e r n a t i v e s
42.  We add a propert  You make it all A l t e r n at i v e s
43. % 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
44. 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.
47. pa r t s C o n ta i n e r s
48. CardText CardActions CardContainer CardMedia CardContent
49. Lockups Extensions p a r t s C o n t a i n e r s
50. C o n ta i n e r s pa r t s Combinations Extensions Lockups
51. Lockups Extensions Combinations Repeater p a r t s C o n t a i n e r s
52. Lockups Generic Extensions Combinations Repeater p a r t s C o n t a i n e r s
53. 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?
54. Lockups Generic Extensions Typed Combinations Interactive Repeater p a r t s C o n t a i n e r s CardButton IconButton
55. Lockups p a r t s C o n t a i n e r s 4 8 24
56. 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
57. Reorder Reorient Add behaviors Add nested components Expand use cases Customize actions
58. Flexible Empowering Innovative Unblocking Simpler
59. Flexible Empowering Innovative Unblocking Simpler Inconsistency? Trust? More work? More debt? Awkward tools? Harder to learn? Less performant?
60. 1. Make the very common configurable. 2. Make the less common configurable, as time permits.
61. 1. Make the very common configurable. 2. Make the uncommon composable. 3. Make the less common configurable, as time permits.
62. Should we make bigger components? Should we offer smaller flexible components? Is this the place for shared components?
63. 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 )
64. One-source-of-truth. Singular. Central. Perfect.
65. Local team A group working together to deliver an experience, one fix, enhancement or redesign at a time.
66. 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.
67. People / Team Models / Solitary Central (or “Core”) Federated (or “Community”) https://medium.com/eightshapes-llc/team-models-for-scaling-a-design-system-2cf9d03be6a0
68. From
 core kit made by a central team To
 shared kits made by federated masses
69. Central (or “Core”) Federated (or “Community”) People / Team Models / OR
70. OR Central (or “Core”) Federated (or “Community”) People / Team Models / WRONG MENTAL MODEL
71. People / Team Models / Central (or “Core”) Federated (or “Community”) AND THEN...
72. Shared space?
73. 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
74. .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
75. 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?
76. Shared libraries / Where does it go?
77. Shared libraries / Who is involved? Shared library maintainer Core team steward Shared library maintainer Shared library contributor Shared library contributor Shared library contributor
78. 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
79. 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?
80. Favor community and trust 0ver command and control
81. https://medium.com/@nathanacurtis/lists
82. Thanks!