Observia Design System

UX Design

The Context

At Observia, we build solutions to give patients and healthcare providers a highly personalized experience. Until my arrival, Observia was building each project bespoke, with custom code components for each client. While this is okay in the short term, Observia has product-driven ambitions for the long-term. I knew that a design system would help to streamline our development process and reduce maintenance costs.

The Mission

Seeing as Observia does not sell products branded with its own style, but rather adapts to the branding of our clients, creating a design system flexible enough to accommodate this while being rigid enough to be able to build out solid, reuseable components and patterns proved to be an interesting challenge. However, before I was able to begin work on the system itself, I would have to sell the idea to internal stakeholders.

A preview of just a few of the components I designed.

Selling the design system

When you're not a product company, it's very difficult to convince the executive team to allow a significant time investment on something not directly related to a client project. It's an understandable stance - project work is paid for by the client, whereas developing internal tools does not have a direct and visible ROI. I knew that a design system would speed up our future project work, at the cost of my time and the time of some of our front-end team. But how do you convince an executive team with no design or technical background?

Luckily, I had an important ally in this mission: my manager. He's the Head of Product, therefore holds a lot of sway with the executive team. He championed the idea for me and got me an all-important presentation slot in front of the decision makers. After consulting with him and our front-end lead, I managed to persuade the stakeholders by using the following arguments:

First, by explaining what a design system is in simplified terms
That building from a design system will allow for a more consistent and overall better experience for users
That industrializing this process will ultimately lead to less dev time (meaning money saved)
Introducing a scaleable design system now (while our needs are small) would be a relatively low investment cost for a potentially huge gain in the long-term

Building the design system

Now that I had the green light to invest a decent amount of time into our design system, I started to look at how I could start to build one.

As with any other project of this scale, I started with research. A lot of research. Two of the resources that helped me the most were Andrew Couldwell's incredible book, Laying the Foundations, and the Design Systems Handbook from Invision (starring the design systems queen herself, Jina Anne). I also perused many of the top brands' design systems online.

Once I had a good idea of the basics, I was ready to begin. But before drawing a single line, I wanted to set down some principles for the design system to abide by, for the eventual day when I'm not around anymore.

The Observia Design System principles.

I began with the most core aspects of the design system, the very backbone upon which all the components are built: the grid system.

I established a 12-column grid, spaced 32px apart on all viewports, in order to maintain a consistent visual experience across devices. After consulting with our lead front-end, we decided that basing the design system on Bootstrap and Vue.js (a technology we were already beginning to implement slowly) was the best way to quickly get us up and running with a good base. Therefore, many aspects of our system are similar to Bootstrap, with some modifications. I knew that this would present us with some design limitations (mostly related to page layout), but given that the majority of our projects were very similar in nature, yet were being developed with custom code every time, it was a sacrifice I was willing to make in order to speed up dev time and improve user experience.

It was also important to me to set up a consistent vertical pixel grid. Given our needs, a simple 4px grid seemed most appropriate to me. Using spacing slugs of 4, 8, 16, 32, and 64 pixels, as well as ensuring that the typographic hierarchy also uses line-heights of multiples of 4, creates a consistent, vertical rhythm on pages. This principle is explained clearly in this article.

The grid system and typography system.

Solving the puzzle of adaptation

With the core of the design system set up, now all I had to do was build components on top of it! I had even established a list of our most-used components that I could begin standardizing: free text field, datepicker, progress bar, radio button, checkbox, button, modal, and dropdown list.

However, I was immediately hit with a conundrum. How do you design a component when you don't know what colors, styles, or font to use?
‍
Our client projects often use the styles, colors, and fonts given to us by the client - usually their corporate identity. At the time, Observia did not build or sell products under its own marketing identity or branding. So how is one supposed to create a design system for that? After a lot of strategic discussion with the team, I realized that the main advantage of the design system was going to be the pre-built components for our front-end devs to be able to plug-and-play instead of building from nothing each time. Common patterns such as landing pages, login forms, accordeons, and button states could be pre-determined at the system level, with styling such as font, color, border-radius, and images changed at the project level.

Take for example this simple login page template:

Comparison between the design system components at system level and at project level.

On the left, we can see the system level components, and on the right, the same page template but at project level, with our client's identity and styling applied. Having common templates like this pre-built and ready to go before a project even begins massively reduces developement and testing time, because we already know it will work. All we have to do is change a few lines of CSS, swap out an image, (and in this case, the language) and our page is ready.

Here is another example with the same project:

See how close they are?

Reflecting on the future

Using this system of templates, I was able to build out entire platforms and solutions easily and quickly. While we only started with a handful of components, I can happily report now that we have dozens and dozens of them.

Once we used the design system on a couple of projects successfully, we realized just how much time and effort we managed to save. Sure, the initial investment slowed down our project work a little, but we increased our overall output in terms of dev time saved by over 100%. Naturally, there were some downsides. Notably, it's the lack of flexibility when it comes to layout - however, this is something we are working on right now for future projects.

The next aspect that we had to deal with was how to properly organize the documentation for the design system so that new designers and developers can quickly get up to speed on how to work with it.