UI Component Libraries, a common language for designers and devs.
As part of the growth of the design team within CEMEX we had made important progress in reaching a basic stage of maturity.
Our todo list kept getting shorter. We developed the software application style guide, created a design language around it, and then we created our symbol library.
The inner workings of the design team were streamlined.
Everything was running smoothly on the inside, but we started experiencing issues whenever we interacted with development folks within product teams.
Whenever we delivered a composition, some feature visuals or even an InVision prototype, the developed counterpart stood always short from the standard we wanted to set for our products. To be frank sometimes the adequate word for the outcome was “butchered”.
This is a very common issue when working with interdisciplinary teams, and it is more evident for the design fellows, as we train our eyes daily for that pixel perfection. Other participants within a team might not be as sensitive to UI flaws, and it is likely for them to let them pass through.
Since our approval is required for features to go through, it represented a strain on the product teams, as the corrections required to invest more time on things PMs, scrums and devs thought were ready. Sprints were not closing in time and features rolled over to following sprints so that the mishaps from the previous ones could be corrected.
The design approval was starting to be seen as a burden for the rest of the organization. Nobody liked this situation, especially us.
Being seen as a bottleneck is not pleasant.
We decided it was time for our team to have a UX development branch. It was a pleasure for me to join this effort, as my background involves both designing and development.
We made an initial effort of establishing the necessary HTML, CSS, and javaScript to reproduce the desired artifact for each and every component we had in our Sketch library.
From our point of view, there could be no excuse for misrepresenting our compositions if you had a library where to take the code sample from.
The devs within the organization started to do their component libraries based on the design comps and some of the code recommendations we published.
Their approach was straightforward, if they saw a UI element more than once, they funneled it through their factory. The result was bulky oftentimes, as they focused on the Swiss knife approach for each component when sometimes all they needed was a razor blade.
There were many libraries built, as many as front end frameworks were being used. Angular, React, AngularJS, vanilla, you name it.
This of course wasn’t an ideal situation, as the codebase for each one of those is unique, and our recommendation could not always be followed due to the diverse html structure used within the specific framework. There are issues such as encapsulation that work differently across them, so the result was that there were slight differences across UI elements on diverse products. An OCD nightmare.
Along came Stencil.js
Stencil.js is a fairly new framework that has especially been designed with this exact issue in mind. The description on their website reads “Stencil is a toolchain for building reusable, scalable Design Systems. Generate small, blazing fast, and 100% standards based Web Components that run in every browser.” That hit right in the spot for us, and then there’s this other thing why we adopted it: “Stencil components are just Web Components, so they work with any major framework or no framework at all”. This means React, Angular, Vue, Ember, etc.
Getting dirty with the code.
We laid the framework foundation, and sat a basic rule that we still keep. Our components are dumb. This means they have no business logic at all. If you want the componente to have a business logic, then you create a wrapper around it within your code base. No exceptions.
The UX Dev team owns the library. If you want a new component, then we have to run it through the whole design/approve/sketch/code process.
This means that when a component is ready, it comes bundled with all the variants it may need, a default responsive version, a proper RTL implementation for Hebrew and Arabic languages and all the interaction patterns defined in the design language.
This has proven to be very useful for components like tables, as they come bundled with a default responsive fallback, and other components that do not necessarily look alike when rendered in mobile devices. Say a menu that turns into a floating action button.
An Angular and React adaptation of the core library is automatically shipped with every build and we also host the core library in a CDN so that you can create applications by using a sole HTML file, which has come very handy when we need to create a high fidelity prototype for User Testing, so that there is an actual software artifact instead of a prototype made out of renders.
We have even made Storybook playgrounds for the developers to get close to the components and explore their capabilities.
The component library has radically changed the way our development teams interact, as we do have a common language to communicate around. Devs analyze and perform tasks around the components to avoid having to invest time in feedback loops with design. They also do recommendations to the product teams to stick with the Design Language System in order to work more efficiently.
The disconnect between design and development has ceased and the maturity of the UX within CEMEX has taken a big step forward.
