Design Systems

Orbital Insight's data products each require their own UI to help customers evaluate and draw insights from the data. Since customers often subscribe to multiple products, we wanted to maintain a consistent experience across the products. This became a challenge once we had a team of UI Engineers, each working on a different product line.

To address this issue, we developed a design system which includes common UI elements and data visualization primitives, all coded in React. The design system is maintained as part of the production code base, so any changes made to the components are immediately apparent in the examples rendered in the design system. Keeping the design system files alongside the source code also makes it much more convenient for the UI team to keep the documentation up-to-date, and facilitates use of the design system as a testing framework for the components themselves.

The tooling for the design system is Patternbook, an open-source side project I had created. In Patternbook, components are documented in Markdown, and can include code examples that are rendered inline alongside source code and data context. A shared Patternbook server is deployed off the git master branch. Developers can also run Patternbook in their own development branch, in which case, source code changes are immediately visible in the browser via webpack hot module reload.

Data visualization is a major part of the UI work at Orbital Insight. The UI Engineers were familiar with D3, but we wanted Data Scientists and Product Managers to design visualizations directly and iterate more rapidly on those designs. The design system therefore includes a fair number of data visualization components that can be combined to create charts and maps. The team appreciated the approach taken by D3 (which abstracts out the concepts of series, axis, legend, scale, etc., as separate layers which can be combined to create a wide variety of visualizations from a fairly small set of primitives), so we created an analogous set of React components, many of which were simply wrappers around the D3 equivalents. Designing visualizations in React this way is more intuitive than using D3 in Javascript, because the definitions tend to be more declarative or functional.

The End-User Computing UI team at VMware used a variety of technologies to render their web applications, both server-side and in-browser. Users, however, were unaware of this because the pages all looked consistent; styling was controlled by static CSS files. So when it came to document and formalize our design system, it was clear that effort would be focused on CSS.

I had previously created Styleboard which analyzes the selectors in CSS files to extract the design patterns, based on modular CSS naming conventions and doc strings embedded in CSS comments. The team was already starting to apply the principles of modular CSS (using SCSS) in an effort to be able to share CSS definitions between applications. So a CSS-based design system, called Xydeco, was initiated based on Styleboard.

While the team eventually standardized on AngularJS for all new projects, and many of the components in Xydeco were reimplemented as Angular directives, there was no need to migrate Xydeco to Angular. The same CSS classes were still being used from Angular, and Styleboard was easily adapted to accept examples coded in Angular rather than static HTML.