Using a templating and documentation generation tool called Fabricator and an object-oriented vanilla JS design pattern, both of which I had experience from when I worked on the Loki CSS framework (the seed of the Ericsson Design System), I was able to release the first version of the design system in little over two months.

The TriOptima Design System (triDS for short) is composed of design and technical writing documentation, a Sketch library, and, most importantly, a technology stack agnostic CSS/JS framework.

Having a library allowed the entire team to quickly produce new design ideas and high fidelity mockups, thanks to very modular components made of interchangeable symbols that could be switched to reflect different UI state changes. It also meant that design changes could be made in the shared library file and inherited by the different mockups with minimal effort doing design updates.

Some weeks later, I also created a second library for wireframing, dropping all colors and detailed graphics so that we could keep the initial conversations with stakeholders focused on the right things, such as user flow and interaction patterns.

At TriOptima, we had five independent product teams that made their own technology choices, and even within the same product, there were different javascript libraries (one used Elm, another language altogether) or frameworks that coexisted. What this meant was that applying a new design forced five different teams with varying levels of frontend knowledge to redo the same interface elements and interaction patterns.

My way to address it was to implement a CSS (started with LESS but rewrote it to SCSS after learning that some teams preferred it) that could be used by itself or complemented with a vanilla JS (ES5 transpiled with Babel for older browser support).

triDS.js followed a class-based, object-oriented design pattern that allowed the creation of interface components that could be enabled or disable at will with a data attribute (data-nojs) on the HTML side. Thanks to contributions from my developer colleagues, later releases of the framework also featured a React inspired state object that could be read by other frameworks and even basic markup structure validation tests. I even include an automated "design review" feature that advised teams of optional but easy to add improvements to their component implementation.

A design system is not complete without well-written documentation, compiled into a single source that could be accessed by everyone in the organization, from designers and developers but also project management, customer support, and any other stakeholder. The idea is to create a shared understanding of what the intended design and user experience should be, even across organizational silos.

This translated into an ever-green documentation site hosted on company subdomain, that was available for anyone within the company virtual private network and gathered not only design guidelines, but also UI writing recommendations and even development instructions. To top it off, you could even preview the different components and their HTML and JS structure under their explanatory documentation.

Having a design library saved the UX team enough time to create clickable prototypes with Sketch, and using Zeplin allowed us to deliver detailed and inspectable hand-offs for development teams.

Even better was having the ability to quickly create HTML prototypes thanks to the CSS/JS framework and our templating/documentation platform. It allowed me to test the framework components in an environment as close to the actual implementation as possible, detecting bugs early before they went into the products and do quality control on new components.

It also worked as a great resource to help teams understand how the layouts were built and reinforce proper markup syntax and structuring on less knowledgeable developers.