As I used the first month to get familiar with the complexity of the product, I first focussed on getting the visual language figured out. After a quick glance, I realized that the application presented a lot of inconsistencies in the UI: the color palette was unclear, the brand was undefined, some component variants were unjustified, and many WCGA guidelines were overlooked.

Since understanding the brand and its personality was crucial for this project, I kicked it off with a short survey. The questionnaire aimed to define the corporate identity, the expected tone of communication, and the message to send to its users.

By the time I got hands-on logo making, I already had a clear idea of the product and its personality. I also knew the company needed to “clean” the logo and avoid a complete 360º rebranding. Therefore, I tried to respect some of those distinctive aspects I saw in my initial examination and adjust the visuals to perform well once used within a design system:

With the logo, the font, and the colors sorted out, I could already proceed to determine the rest of the particles of an atomic design system. I initiated the process by agreeing with programmers on a grid unit that would remain “untouched” from then onwards. That unit was 4, an undividable number I would refer to every time I had to create a component from scratch.

The font hierarchy system built for this project (screenshot below) uses multiples of 4 for line-height (leading) of each font style. This allows the text box to sit perfectly in a grid based on 4x4 pixels.

Creating the design system and adjusting the entire app happened synchronously. I often jumped back and forth between the app and the system to ensure both things were functioning well. So, it took some time to get things up and running, but after three months we were ready for the release. I should admit that it took up to 6 months to really feel like the design system and the app were truly coming to life, but we were making progresses very fast.

Assembling a Design system from the ground up has been a fantastic experience and I reckon that working on a nearly blank canvas was a one-in-a-lifetime opportunity.

There were a few factors that contributed to a very rapid release. The team had plenty of space to explore the brand and the system, we had the support and understanding from the Marketing department, and the app was still in an MVP phase. After only three months of work, we were already prepared to expand the application and add many more functionalities. 

I worked in the same team and product for 3 more years and that helped me understand a few things that I should take into account in my future design systems:

1. A customized design system isn't suitable for every team: Sometimes it can be due to a simple budgetary reason, perhaps there is a management issue, maybe a team is low on resources, or a it's just a matter of being in a company that isn't design-driven. In any case, producing a tailored system is a highly collaborative and cross-department task where everyone should bear some responsibility. It essentially means more time invested in maintaining, updating, adjusting, revising, and creating the system. Not every team is prepared to undertake this commitment and, before making a decision, all stakeholders should discuss this matter thoroughly, including upper management. From a design perspective, the product can only be scalable if designers can fully understand the needs of the business and the expectations from the leadership team.
2. Having a product strategy is everything: ConnectedCare was a new software created by BEWATEC, a company with a long career in building hardware. We started coding an iOS application within a market dominated by Android (Germany). By the time BEWATEC understood that the product should exist on both platforms, our teams and our internal resources were already too specific to adapt to Android. Creating an Android app meant doubling our team, restructuring the whole system, and hiring more designers. So, lacking a product strategy made us produce an infrastructure of resources that would soon turn obsolete.
3. Design systems evolve constantly: even though it might sound pretty obvious, this was one of the most important takeaways from this experience. I always worked on the design system while also focusing on the UX of the application. Everytime I had to jump back to the atoms and molecules of the UI, I often said to myself "I'll change this one bit and then I'll forget about it". But, well, time showed me that this was never the case. I enjoyed having a versatile job, however, I realised that maintaning a complete design system is a fulltime task. If there aren't enough resources to sustain it, things will fall through the cracks before you can see it coming.