Before working at Vizlib, I had the chance to create new design systems or to better define them for existing products. Vizlib was starting to work on their new product, Astrato, so there was a need to define guidelines and components so that we could develop a strong product from the start.
My role
Working partly as a Product Design and Design System lead designer, I had the responsibility to create a strong shared document that would unify our style so that eliminates ambiguity and the need to reinterpret the product, allowing us, the design team, to deliver distinctive, consistent user experiences, across the whole product. Bringing Designers, Developers, Product/Project Managers, and Stakeholders together.
As a newcomer, I had the chance to look into the low-fidelity wireframes we already had in place, as well as some of the brand guidelines we received from a brand agency to compound basic guidelines for our own design system.
Initial challenge
With the colors and the typo in hand, I defined basic accessibility rules for our main, secondary, and complementary colors. I also defined basic text styles we could start using, based on what we had already in place in the wireframes.
Layouts and Components
Once the basic was in place, I could start working on applying the UI design. The first area I had the chance to explore the brand colors, was on the product’s landing page. That was a great way to start since it was more marketing focus and I could explore a lot of the colors we had as well as create simplistic animations of what the whole team was envisioning the product would soon look like.
The foundation
After defining the users’ entry point, I managed to add some components to our Design System file that could be reused once started working on the product’s wireframes itself.
But at some point, it became a file with a lot of different components with not necessarily an easy way to find them, so my next step was to go back to Design System principles and look again more into existing concepts, such as the Atomic Design.
Using existing concepts can be a great way of solving problems, but also terrible if not adapted for the team’s needs and processes. With that in mind, I decided to use some basic foundations such as the Atoms and Molecules, but tweaked their names and added a few more to our own structure, such as Layouts and WIP (Work in Progress). WIP was a big thing for us as a team since things were moving fast. We didn’t want to mess new components with signed-off ones.
Under each of these definitions, it was easy to find where some existing components would live, as well as where new ones could be placed.
Sharing with the team
As a company, we were moving really fast, and the first to focus on UI was me, the rest of the team was working at full speed on testing and delivering flows in low-fidelity prototypes. But eventually, everyone would have to work on the same file, taking full responsibility for the Design System maintenance and creating new components.
So it was time for me to present the whole Design System idea to the team and do some knowledge sharing on how to create components, managing auto layouts and states, and other Figma different functions. I had some presentations and brainstorms with the team so that we could all feel like we were on the same page and confident we could work on the same file.
Development handover and further documentation
As said before, our company was growing and moving at the speed of light, and there was not much time, in the beginning, to be pixel-perfect. But nowadays, more people are finding the importance of having proper documentation around our components, principles, and guidelines.
With the idea of creating a single source of truth for designers, developers, and stakeholders, I suggested we started using Zero Height to properly explain our decisions and foundations. The idea was sold and now designers have a place for better documenting ideas and sharing basic interactions.
Conclusion
A Design System is a project that needs maintenance and updates constantly. However, nowadays, it’s a lot more solid, which allowed us to focus even more on what matters. Since our designs can be synchronized with Figma, it’s easy to keep things updated and clear for everyone that needs assets of information.
Our developers have also been working on their own components and having mature documentation has helped us deliver better, so they can implement the design in a more pixel-perfect way, which has been great!
In order to make our design even more consistent, I’m also working on the development of a product language, promoting UX writing workshops with the other designs and content team.
