Systems of Systems, 0.1.0

Presented for the first time at Webstock New Zealand, February 2018

Transcript

1. Systems of Systems Webstock — Wellington, New Zealand — Thursday, February 15, 2018 Nathan CurAs
 @nathanacur*s
2. Visual Style UI Components Lato Light / Heavy COLOR TYPOGRAPHY SPACE ICONOGRAPHY BORDERS LAYERING Bu#on Sign In Don’t have an … Link with your… LAYOUT GRID HEADING DECK PARAGRAPH LINK INPUT SELECT BUTTON TABS TAB TAB TAB System Defining Design Systems bit.ly/8s-define-design-systems
3. Product Sign In with your EightShapes account Email Address Don't have an account? Sign up now: Create an account Forgot password? Password Sign In Sign In with your EightShapes account Email Address Password Forgot password? Sign In Don't have an account? Sign up now: Create an account Visual Style UI Components Lato Light / Heavy COLOR TYPOGRAPHY SPACE ICONOGRAPHY BORDERS LAYERING Bu#on Sign In Don’t have an … Link with your… LAYOUT GRID HEADING DECK PARAGRAPH LINK INPUT SELECT BUTTON TABS TAB TAB TAB System
4. SignIn.js CreateAccount.js ForgotPassword.js Sign In with your EightShapes account Email Address Don't have an account? Sign up now: Create an account Forgot password? Password Sign In Enter your phone number or email: Forgot Password? Next Name Email Address Password Confirm Password Learn more about why we ask for this informa;on. Mobile Phone First Last Next Step Create your EightShapes Account Designer Sign In Artboard Create Account Artboard Forgot Password Artboar Engineer 1 Engineer 2 System Product Visual Style UI Components Lato Light / Heavy COLOR TYPOGRAPHY SPACE ICONOGRAPHY BORDERS LAYERING Bu#on Sign In Don’t have an … Link with your… LAYOUT GRID HEADING DECK PARAGRAPH LINK INPUT SELECT BUTTON TABS TAB TAB TAB
5. SignIn.js CreateAccount.js ForgotPassword.js Sign In with your EightShapes account Email Address Don't have an account? Sign up now: Create an account Forgot password? Password Sign In Enter your phone number or email: Forgot Password? Next Name Email Address Password Confirm Password Learn more about why we ask for this informa;on. Mobile Phone First Last Next Step Create your EightShapes Account Designer Sign In Artboard Create Account Artboard Forgot Password Artboard Engineer System System .H TM L System .Sketch Product
6. Designers Engineers Product Manager Others (QA, etc) DESIGN ASSETS A library of design tooling offered in tool(s) relevant to the design community FRONT END CODE A library of reusable HTML/CSS assets (maybe built in a JavaScript framework) Product System Outputs System .H TM L System .Sketch
7. Product Tokens in Design Systems bit.ly/8s-tokens-in-design-systems Designers Engineers Product Manager Others (QA, etc) System Outputs TOKENS A library of hierarchical property/value pairs as an visual language abstracAon. For example:
 
 colors.text.primary.onLight:
 #333333 System .H TM L System .Sketch System .Tokens
8. Product DOCUMENTATION SITE A separate codebase and content corresponding to the documentaAon describing the system. System .H TM L System .Sketch System .Tokens Designers Engineers Product Manager Others (QA, etc) System .D ocs System Outputs
9. Product v1.3.0 System .H TM L
10. Look for the Dependency in /package.json
11. MAJOR
 (BREAKING) MINOR PATCH v1.3.0 semver.org
12. Versioning & Breaking h\p:/ /designsystem.morningstar.com/about/versioning.html Defines, generally, how versioning works Defines, specifically, when updates are considered breaking changes, including: • Style • Markup • Scripts • Tokens • Icons • Fonts
13. System .H TM L Product 2 Product 3 Product 3 Product 1 Product 1 v1.1.0 v1.1.0 v1.1.0 v1.1.0 v1.2.0 v1.2.1 v1.2.1 v1.2.1 v1.2.1 v1.2.1 v1.3.0 v1.3.0 v1.3.0 v1.3.0
14. Products own their desFny.
 System equip products to realize that desFny. Principles of Design Systems bit.ly/8s-principles-systems
15. Intermediary Those that get between a system and those that make with it
16. INTERMEDIARY 1 OF 3 Distributor An en*ty managing packaged dependencies other teams use to make an experience.
17. We’d love to adopt, but we must leverage it through the platform. Otherwise, our hands are tied. “
18. System .H TM L
19. Platform System .H TM L
20. Intermediary 1 of 3: Distributor Platform Disseminate quickly Manage change predictably Signal mature prac*ces Block ini*al adop*on Prevent frequent upgrades Complicate upgrades
 (must sync across products) Product 3 Product 2 v1.8.0 v1.1.0 System .H TM L
21. Distributors Takeaways 1. Can’t adopt without ‘em, so live with them. 2. Forge a strong(er) rela*onship with distributors. 3. Persist with the rest so they make the case: 
 “We need this system, now!”
22. INTERMEDIARY 2 OF 3 Translator An en*ty transla*ng a system (HTML & CSS) into their framework (usually, JavaScript or a CMS).
23. REACT VUE EMBER ANGULAR
24. EMBED INTO A
 JAVASCRIPT FRAMEWORK? RELEASE JUST
 “VANILLA” HTML & CSS? OR
25. System .React
26. System .React Commi?ng to a JavaScript Framework JavaScript is powerful! JavaScript encapsulates! It’s what devs want! (right?) Tes*ng is more complex Unusable by minority adopters
27. System .React Tokens Offer a Back Door to Visual Style System .Tokens
28. System .H TM L
29. System .H TM L System .React System .Vue
30. YOUR CUSTOMERS YOUR SYSTEM THEIR CUSTOMERS System .H TM L System .React System .Vue v1.1.0 v?.?.? v?.?.? v1.2.0 v1.9.0
31. Intermediary 2 of 3: Translator Praise the ini*a*ve! Leverage a community Incomplete features Missing components Different documenta*on
 (if it even exists) Poor support
 (devs have a product to make!) No commitment to upgrade in sync as system improves System .H TM L System .React
32. Could You Support All the Frameworks? Sync releases Integrate documenta*on Integrate support OMG, seriously? Our org is challenged by suppor*ng one! System .H TM L System .React System .Vue v2.0.0 v2.0.0 v2.0.0
33. Translator Takeaways 1. Approach curiously yet cau*ously. 2. Educate them on how to turn an open source passion play into a success. 3. Protect your brand: if they age or don’t meet your standards, they aren’t part of the program.
34. INTERMEDIARY 3 OF 3 Themer A team that themes a system’s UI components with a different visual style (color, type, etc).
35. Team
 1 Team
 2 Team
 3 Team
 4 designsystem.morningstar.com/charts/donut.html CORE COMPONENTS developer.morningstar.com/components/por]olio-x-ray COMPLEX COMPONENTS
 PRODUCTS THEME
 Montserrat Streamline New Colors New Typography New Icons , THEMED
36. TEAM 2 TEAM 3 “DESIGN SYSTEM” CLIENT TEAMS CLIENT 1 CLIENT 2 CLIENT 3 System .Tokens System .U I System .Charts Them e 1 Them e 2 Them e 3 Com plex Com ponents
37. Theming Basics 1. Separate library-wide and component-specific styles. 2. Embed library-wide in design tokens useful across pla@orms. 3. Isolate component variables from CSS selectors and rules. 4. Leverage compiler features, like Sass’ !default.
38. Themer Takeaways 1. Build a sophis*cated theming architecture only if you need one. Avoid it otherwise. 2. Beware the innocuous request that quickly grows into library-wide refactoring (breaking change!).
39. OR O ur System Another System
40. CompeFtor A design system available as a subs*tute for your system.
41. StarLng from Nothing, Teams Have Choices ADOPT A CODE KIT,
 SKIN W/ STYLE ADOPT A LANGUAGE, CODE OURSELVES CREATE DESIGN & CODE FROM SCRATCH OpAon
 1 OpAon
 2 OpAon
 3 OpAon
 4 ADOPT AN 
 IN-HOUSE SYSTEM
42. Limited doc Outdated visual style Rampant accessibility issues across library 2015 MAD HATTER For a Flagship Product MUI-BOOTSTRAP For a Flagship Product &
 “Whoever Else Wants It” 2016 MDS For Everyone 2017 h\p:/ /designsystem.morningstar.com/ When Living, Systems Go Through GeneraLons
43. M U I-B (O ld) M D S (N ew )
44. Rebuild from the ground up. 
 For everyone. Systems Team
 January 25, 2017 at 2pm “
45. Another team is making a library. 
 It’ll be available sooner. So…. we may adopt that instead. 
 Others are considering it too. Lead Product Design working on Flagship Product
 January 25, 2017 at 4pm “
47. M U I-B (O ld) M D S (N ew ) M U I-C (Com petitor)
48. OpLons for Handling CompeLLon 1. Put our heads down: Make ours awesome. Hope for the best. 2. MarkeFng blitz: Our system is the future, not theirs! 3. Complain to leadership: Shut down us or them, now! 4. Live with two: Some use ours, others use theirs.
49. ☎ Op*on 5: Pick up the phone
50. MUI-B CODE MUI-C CODE TO BE
 RETIRED MDS CODE MIGRATE MERGE EFFORTS TO BE
 RETIRED
51. ConsideraLons When ConsolidaLng Systems 1. Agree on approach for a unified, company-wide source-of-truth. 2. Remove redundant services/cost. 3. Improve lack-of-bias for teams to build for more / all teams. 4. Increase capacity to make & doc more than either would have alone. OPPORTUNITIES 1. Deliver in Fmely way 2. Revisit tooling and approach (code style, conven*ons, etc) 3. Blend rituals for Europe & US CHALLENGES
52. OR Another System System
53. AND Another System AND Another System AND Another System System
54. Brand Corporate M arketing Intranet Corporate Site, Governance, Investors, “Brand” Sites .com Home, Marke*ng, eCommerce, Customer Support Web & na*ve product experiences “Portals”, Internal Tools, Expenses, HR, Wikis, etc Feb 2018 Dec 2017 Sep 2016 Mar 2013 Product
55. Brand Corporate M arketing Intranet Feb 2018 Dec 2017 Sep 2016 Mar 2013 Product
56. Customers use Product’s system, and it’s better. Shouldn’t employee tools use it, too? – Design system team members for both Intranet & product systems “
57. ConsolidaFon Ra*onalizing and removing redundant systems that serve non-overlapping sets of products.
58. Feature Product’s System Intranet’s System Visual Style Color
 Typography
 Icons Color
 Typography
 Icons Component Overlap Bu\on, Input, Radio, Checkbox, List Group, ToolAp, Card, Alert, Loader, Menu, NoAficaAon, Dialog, Popover, Range Slider, Switch, Tag DisAnct Components Top Hat, Modal, “Site” NavigaAon, Data Tables, Bu\on Groups, Combo Boxes
 + 14 more Local NavigaAon, “Global” NavigaAon, Carousel, Tiles, Dashboard Module, Filter Bar
 + 2 more Design Assets Sketch AND Figma, FTW! Adobe Illustrator Codebase Vanilla HTML & CSS + React TranslaAon Mustache Templates Team 2 Designers, 3 Engineers (all full Ame) 1 Designer, 1 Engineer (both half Ame) Arial Regular, Arial Bold Font Awesome Montserrat Streamline
59. OpLon 1: Do Nothing Intranet Teams remain focused Avoids costly change from at least one group Doesn’t scale design Sustains duplica*ve efforts Risks morale Product
60. OpLon 2: Start Small, with Tokens Intranet Product Product’s Tokens ’s H TM L
61. OpLon 3: Product “Acquires & ReLres” Intranet System Intranet Scales system investment across broader porkolio Raises Intranet quality Unifies design community Requires costly and unexpected change in Intranet app Increases Product’s burden to support teams not in “our organiza*on” Product Retired
62. N ew OpLon 4: Systems Merge, Building a New System Intranet Opportunity to refresh! Merges as equals as opposed to one feeling subservient Huge, unrealis*c cost Very difficult to coordinate Requires many to relinquish control Product Retired Retired
63. ConsolidaFon Takeaways 1. Expand a system’s boundaries very carefully. 2. Let acquired systems make the asser*ve move. 3. Others – par*cularly intranet tools – must demo they want and are willing to pay for the switch.
64. More on Medium.com bit.ly/8s-systems-medium Read more on systems topics including: Strategy & Planning Design & Development Adop*on Documenta*on Process Teams & Opera*ons
65. Join Design System Slack (5,900+ members) hpp:/ /design.systems
66. Nathan CurAs @nathanacur*s Thanks!