Welcome here !

Let me quickly introduce myself and present the purpose of this blog.

My name is Jérémy, I’m a 24 years old front-end React.js developer. I’ve many passions in life like Music, Video Games, history and much mores. But I’m especially passionate about web development and user interface design although I’m pretty bad in design lol.

The purpose of this blog is to document my journey about building a very special project in which I’m going to put all my effort and my energy in the next months.

This project is “simply” a design-system generator with the modest goal that the generator will be able to generate a design-system for the major platforms and not only the web.

Let’s explain how I came up with this idea.

After being graduated from my computing school in France in 2019, I’ve joined an IT Consulting company as a front-end developer. At that time, I already had some experiences as a front-end developer, so nothing was really new to me even though I had to learn React.js. After two years in that job, I decided to move forward to become a freelance developer.

During this first job in an IT Consulting company, the more significant mission was a one-year mission in a big software development company. The purpose of this mission was to build a basic React.js app that match people with some pre-defined criteria. Nothing there was really complex and the project in itself was a little boring to be honest. But the interesting part was not the project in itself but the building of a homemade design-system. To be more clear, the client decided to build a homemade design-system that has to be built in parallel of the main project. My position brings me the opportunity to work on both projects.

Building a design system was really new to me even though I’ve already used many of them like Google Material and Twitter Bootstrap. And that’s why maybe I was able to question the relevance of some decisions or the building process of a design-system in general.

The first thing that intrigued me is the building process in itself. A design-system is by definition a project that mixes several skills and therefore several teams. Synchronising all the people involves in the building process, can be messy and that’s explain why a PO (Project Owner) is essential. His role in addition to having to define a vision for the project is to make the building process fluid for everyone involve in the project. A building process of a design system can be summarised as follows :

• The PO define a use case (let’s take a UI component)
• The PO asks the UI designers team to design a first version of the component.
• The UI designers team design the component
• The PO validate the design
• The PO asks the developer team to develop the component according to the design made by the designers team and the specifications define by the PO
• The developer team develop the component
• The UI designer team validate the component
• The QA (Quality Analyst) team validate the component
• The PO validate the component
• The component is ready to be deployed

This process is obviously missing some steps because each company has its own internal organisation. For the one using Agility method, we need to add to this process all the mandatory meetings of the agility. But in the case that we want to go to the point, the building process previously define is a good representation of the reality.

Let’s imagine now that the asked component is developed and ready to use. Now, a developer wants to use it but find a bug in the component or require a change because the component doesn’t match his needs. What happen in those kind of situations ? The component is back again in development going through all the building process described previously.

As we can see, we have a clear example on why it takes so much time to build a design-system and why many of them do not succeed.

But the main issue for a company is not the time it would takes nor the management or the resources involved. From a company point of view, the main issue is money. This is why there is still a lot of companies that would clearly benefits from a homemade design-system but refuses to commit, simply because it cost a lot of money without having the assurance that the project will go to the end.

This brings me to the second point I wanted to address.

My first mission as a freelancer was a front-end development mission in a big sport bet company based in France. The core product of this company was from a visitor point of view, a simple website where you can see sports results and bet odds. But from a developer side, each page was a distinct project in a distinct repository. And since each page was part of the same website, each page had to be consistent with the graphic charter. This situation is the perfect kind of situation were the need of a design-system is the most obvious. But the company make the deliberate choice of not building one. Even worse, they did not take the opportunity during major redesigns of some page to build one. Why ?

There are two main reasons. The first reason is the one that we already talked about, from their point of view, they see design-systems from a short-term perspective, and for them, it would take too much time and cost too much money.

But the second reason is more tricky. Because they have multiple projects that were not built at the same time, each project is not based on the same technology. For example, the old projects are built in backbone.js, the more recent one in React.js and the current reworked projects are made in React Native. Why a company would take the choice to build a design-system when they need to support three (In reality there is even more lol) technologies ? They could have chosen to build a design-system in React Native while waiting for the other pages to be reworked in React Native but it could take years, so there is no good solutions here.

This example clearly shows a real problem with design-systems. They are built for one support, one framework, one technology. That means today, companies build design-systems to support the top trending languages or frameworks but without being sure that the language or framework will be supported for a long time. The other disadvantage is that the company will have no other choice in the future if it wants to use its design-system than to develop its next projects with the same technology used to build its design-system.

With these two problems in mind, I come up with the idea to build a design-system generator that can export components to multiple platforms and frameworks and that’s what this blog is talking about.

Follow me on my journey and stay tuned.

JG.