Clarity Conf: Crawl, Walk, Run – the Evolution of a Design System
At Clarity Conference in San Francisco, Stephanie Rewis & Brandon Ferrua discussed the creation of the CSS framework that's part of Salesforce's Lightning Design System. Here are my notes:
- Salesforce has 20,000 employees and has made lots of acquisitions. There are internal developers and lots of external developers.
- Historically, CSS was written by engineers who would rather be writing Java. It became very clear they needed a design system.
- There are a lot of developers, but only about 100 people on their UX team. They touch lots of data in addition to the UI.
- Learning to crawl - Launched Salesforce1, and launched a living style guide to go along like it. They got lots of great feedback, including external developers who said "How can my app look like this?"
- Needed a more comprehensive design system to serve all their products and users.
- Design system components: CSS Framework + UI Library. The goals were to eliminate red lines and instead reference real code, and also make it easy for people to copy and paste.
- They did a design audit and inventoried all components in designers' comps.
- Design Tokens: Fonts, Font sizes, weights, line heights, background colors, etc. These are shared attributes across all their products, so they wanted to make a system to keep that stuff consistent.
- Theo is an open source tool that allows Salesforce to share tokens across products using a JSON object that propagates out to all instances (across web and native applications).
- Broke down components down to their smallest patterns and objects.
- Clarity and understandability are key to worthwhile class names. This may lead to more verbose class names, but clarity trumps verbosity.
- Used modified BEM conventions. They had to modify syntax because BEM and XML don't play nicely (double dashes aren't allowed in XML comments)
- Learning to Walk - Enterprise apps are unique. They demand content and data-rich interfaces. They lack vertical rhythm normally found in more document-centric UIs.
- Heading levels may vary and components should be agnostic. They flattened all the font-sizes in headings so developers are encouraged to think about semantics without worrying about visual styling.
- Accessibility - use ARIA roles, REM units (to address users changing default settings),
- Play well with others - The Salesforce CSS framework namespaces their styles to avoid conflicts with legacy/external components (i.e.
.buttoncoming from some other framework). They added a wrapper div to scope components that are specifically Salesforce. - Learning to Run - How do we maintain consistency across a massive organization? How do you scale? How do we keep our design system agnostic?
- Minimize dependencies - didn't overcomplicate things. Didn't overpromise on the system.
- You don't know what you don't know. What makes up your ecosystem? Who are your customers? Try to understand your potential footprints.
- MVP: Tokens, Icons, HTML, CSS, Guidelines. They specifically avoided adding JavaScript to their framework, as different developers use different frameworks: Lightning, React, Angular, jQuery, etc.
- States and variants - The pattern library demonstrates all the states and variants that components could have. The code preview shows what classes are added/removed from the component in order to accomplish that state. This gives designers and developers a good idea of all the permeations of any component.
- Documentation - Show developers how to accomplish with Javascript without being tool-specific. Build accessibility into the documentation and make it easy to implement.
- Avoiding the potholes - We have to be forward thinking but backwards compatible - what happens when a change is written? Salesforce has 3 releases a year that the design team needs to support.
- Design system team need to provide a migration path to get developers to update their applications. Developers need to understand what has been modified, retired, or added.
- Sass deprecate - build deprecation messages into Sass workflow to give warning to developers that code is going away soon.
*[DETAILS]: Device, Environment, Time, Activity, Individual, Location, Social *[RESS]: Responsive Design with Server-Side Components *[CMS]: Content Management System *[GUI]: Graphical User Interface