Brad Frost speaking at An Event Apart Orlando 2018 on October 9, 2018
By now, ’most every in-house team has some form of design system initiative underway. Yet many designers and developers on those teams still struggle to make the system really take root in their organization. Working together, designers and developers create wonderful, reusable components, tools, guidelines, and documentation. But if those elements don’t reflect the reality of how the organization builds its products, all their effort is for naught. Having spent years creating, evangelizing, and teaching design systems and corporate integration of same, Brad Frost is here to share strategies and methods to ensure your design system stands the test of time. You’ll learn how to keep your system and the products it serves in sync, and you’ll understand how to maintain and evolve your design system to give your users get the best possible experience.
Notes
- Characteristics of compulsive hoarding
- Excessively acquire items that are not needed
- Difficulty throwing out or parting with items
- Inability to organize items
- Characteristics of digital organizations
- Excessively acquire digital properties
- Difficulty updating or sunsetting digital properties
- Inability to organize and coordinate digital properties
- Making maintainable design systems
- 3 avenues to think about when creating design systems:
- Product
- Process
- People
- Product
- We have to change how we think about design systems
- System design and product design need to directly feed one another
- It’s not “start with the components” — it’s not a linear process
- A design system needs to help build real software products
- Your sketch library is not a design system
- Process
- Design tokens — Design tokens are the visual design atoms of the design system — specifically, they are named entities that store visual design attributes
- Design token properties:
- Background colors, type colors, font families, font sizes, font weights, line heights, border colors, border thicknesses, border radii, animation speeds, media queries, margins, padding
- salesforce-ux/theo
- Amazon Style Dictionary
- InVision Design System Manager
- How to get the design system into products?
- Option 1: Installing a design system as a dependency
- Option 2: Link up a design system’s files
- Option 3: Clone or download
- Lonely Planet
- Chasing the Holy Grail: Strategies For Distributing Your Pattern Library and Keeping It in Sync
- Trial it out early
- Technology-agnostic design systems
- Deploying design systems
- Prioritize how to get a design system’s code into real product codebases
- Determine which deployment strategy (or strategies) is best for your organization. Manual downloading is ok, linked assets are even better, but package managers are the best approach
- Do trial runs with several products before the system even exists. This helps iron out workflow and determine which strategies are best
- Figure out how to manage deploying the design system to multiple technology stacks
- How to handle changes to the system?
- Modifying patterns
- Bug fixes, subtle or major visual design tweaks, performance improvements, better accessibility, code refactoring, updating UX best practice, etc
- Design system maintainers need to understand why and when to tweak patterns
- Have a roll out plan
- Adding patterns
- Your design system won’t include every conceivable pattern right out of the gate
- Be judicious adding new patterns. Avoid a bloated, wild west situation
- Is this a one-off solution or a pattern that can be abstracted?
- Removing patterns
- Keep up with industry best practices and real world performance
- Maybe patterns are rarely if ever utilized. Why?
- Establish a plan for removing patterns. Suggest alternative patterns.
- Build into workflow
- Sass Deprecate
- Vanilla pattern
- People
- Design systems are 20% tech, 80% people
- Research
- User interviews
- Round up a diverse group of stakeholders, colleagues, and users who would impact/be impacted by a design system
- Talk about current workflow, pain points, hopes, fears, dreams, frustrations, and other things that can influence the success of the design project
- Synthesize key themes in preparation for kickoff
- Priorities workshop
- Discuss emerging themes from interviews and introduce potential principles and tactics
- Give each person 3 votes for outcomes they care most about
- Discuss results. What won? What lost? Why?
- Goal is to align around a set of shared outcomes and priorities for the design system
- Design system team
- Design system makers
- Have a birds-eye perspective of entire ecosystem
- The ones responsible for maintaining the design system
- Approve changes
- Work with users and business to make sure it’s addressing product needs
- Need to establish a pattern-driven, cross-disciplinary workflow
- Design system users
- Provide an on-the-ground perspective focused on specific applications
- May also be makers, separate development teams, junior-level developers,
- partner agencies, external development shops, and/or other third-parties
- Should coordinate with makers to make sure the system is addressing their needs
- May be widely distributed and process may be extremely waterfall
- Design system team makeup
- Essentially a product team
- UX designer(s)
- Visual designer(s)
- Frontend developer(s)
- Product manager(s)
- QA(s)
- Teams models
- Solitary
- Centralized
- Federated
- Cyclical
- Communication
- Design system roadmap
- Change logs
- Success stories
- Tips and tricks
- Communication tool integrations
- Design system support
- Issue Trackers
- Office Hours
- Slack & chat tools
- Forums
- Outreach
- Training opportunities
- Pair sessions
- Workshops
- Webinars
- Tutorials
- Onboarding
- Create a culture around the design system