As frontend developers, we often tends to use existing UI libraries like Material or Bootstrap, thinking developing our own UI library would be a non-sense: others did it better than we could, and that would be a real waste of time, right? Well, that might be true for some kind of projects but implementing your own design system as an UI library is usually not such a bad idea.
A bit of history
When I joined Onna something like two years and a half ago, we were two frontend developers and one UX designer working on what we now call Onna classic (I'm not counting backend people here). Onna classic platform was split in two applications, the main one and an administration panel one, both written in Angular 4 and using Angular Material for UI components.
Quickly enough, our UX designer complained about different things like the look and feel of some components, but also some poor accessibility choices Angular Material had done back then. What our designer wanted us to change was going way further than just applying some theme on Angular Material. So we had the discussion: should we implement our own UI library to fit exactly our designer's specifications, or should we accept the flaws of Angular Material and stick with it?
As frontend developers, it was a tough choice to make and we really balanced pros and cons for both solutions. But at the end, keeping Angular Material didn't make any sense from our designer point of view: Angular Material didn't fit our product design. So we finally decided to accept the challenge of implementing our own UI components. I think we never had any regret on that decision since then.
Should I stay (private), or should I go (public)
Onna has and always has had a strong open source culture. All Onna stack is based on open source technologies and our developers are often also contributors on some open source repositories.
When I started at Onna, some people in our backend team were the main contributors of Guillotina, a Python AsyncIO Rest API framework on which a big part of Onna classic backend stack is based. But on the frontend team, we didn't contribute to any specific open source project at that time. So when our UI components library started to take shape, we thought that would be a good fit to make it open source, and Pastanaga Angular was born.
It's always a good approach to develop a library as an open source project. It leads to better practices as you know your code might be reused by someone else. So you pay more attention to conception details like separation of concerns to name only one. You think more about what is generic enough to go in the library versus what are business related components and should stay in your project. And last but not least, even if you don't have a big community around it (yet), you will probably end up with some folks looking at your work and suggesting some fixes or interesting features and doing so, increasing your code quality.
As I explained earlier, the choice of implementing our own UI library was triggered by our UX designer. That was actually the premise of a design system. At that point, we didn't have the resources required to make it a real design system, but the desire was there already. Later on Onna started to grow quite a lot and quite fast, and our growth allowed us to work on a full design system for Onna.
But what is a design system?
A design system is way more than just some style guides and it's not just some UI components neither. So what it is? In a way, it's all at once and even more. We could define a design system as a collection of styles, UI and code components, as well as the corresponding documentation and design rules around them. Moreover, a design system is meant to be shared and easily reachable widely in the organization: anyone in the company must know where to find it and be able to use it.
Don't see a design system as a quick side project, because it's not. It's a real product meant to live and evolve within the company. It may be small and you may not have a dedicated team working full time on it, but still, you should see it as it should be: a living organism you should feed so it doesn't die.
Sounds like a lot of effort, is it worth it?
As developers, we know the value of using libraries: we don't have to reinvent the wheel all the time and it allows us to build things faster. So building your own UI library might sounds very scary. But it's actually a big win for several reasons.
First, you'll actually implement your design system by developing an UI library, so once you reached the point where it is quite stable, you have the winning points of any library: you reuse tested solutions and build things faster afterward. But that's not the only benefit at all!
Working on a design system improves a lot the communication between developer and designer teams. At Onna we have a weekly meeting where we have frontend developers and UX designers in the same virtual room to talk only about the design system: what's new, what's broken, what is good/bad and so on. So developers are here talking about design and its implementation quite early in the process. We can give feedbacks and find "bugs" on design before designers moved on to something else. That's exactly the same as when testers raise a bug to developers: the earlier the better.
Moreover, having a design system will give consistent solutions to different teams and products and help on scalability. You can start small by developing it by one team for one product, and then apply it to other products/projects and teams one by one. So it's important to have one person who is in charge of the design system and will keep it consistent, but it's also very important to have everybody participating and sharing the ownership of it so it can be broadly used and known.
How can a design system be open source then?
Well, there are basically two solutions. First, you can do like Google did with Material: you develop your UI library totally open source and usable by anyone wanting it. Meaning anyone using it will have an application with Google's look and feel.
We took another approach. As I explained before, we were eager to share our UI library as an open source project. But it was important for us to keep our new design system internal for the use of our own products only.
The new design system was really different from what we did on the first version of Pastanaga Angular used on Onna classic, so we decided to create a version 2 from scratch. It was not totally from scratch as we were able to re-use a lot of knowledge we gained from the first version, but we took a different approach when it came to the style: we built Pastanaga Angular 2 so it could be entirely and easily themed. That way, we are able to share our UI library with an open source theme, and still keeping Onna theme internal.
When developing our platform at Onna, we first took the "easy" path by using a well-known UI library for our basic components. Our UX designer never really liked it as it didn't fit well what our product needed, so we finally started the implementation of our own UI library. Doing so was a big win as we were doing the components we needed the way we needed them, so we were able to keep it small and simple.
Later on, when Onna's growth gave us the resources for doing so, designers started a big rebranding project, giving birth to the roots of a real design system for Onna. From there, we were able to start the implementation of the version 2 of Pastanaga Angular, our UI library. We started from scratch, with a healthier architecture, taking the opportunity to fix what was kind of bugging us and hard to fix on Pastanaga 1. We quickly ended up with a nice, tested and documented open source UI library, serving as the base for our internal design system implementation.
In conclusion, doing our own design system is a list of big wins at every single level. We have a better communication between UX designer team and frontend developers, which is super important when a company is growing at such a pace. But we also have a lot of consistency in all our outputs: products look and feel, websites, communications, marketing and so on.
Building our own design system was definitely the way to go.
Lorenzo Marin's presentation about design systems at 2019 Plone conference: https://www.youtube.com/watch?v=Zn48b0OENVs.