Ortal Lampert UX/UI

Medint design system

Role: UX/UI

Overview

As Medint’s platform became more diverse with more tools and features, it became clear to
me that we need to maintain a consistent style and visual language across all areas of the
 product. We also needed a more systematic way to develop in order to keep up with tight
 schedules and avoid ‘one-of-a-kind’ solutions.

The initial outcome was to have a collection of reusable components, guided by clear principles,
that can be combined to create as simple and as complex experiences, as needed.

 

The challenge

1. Planning and prioritizing
The development team was always working on a tight schedule, so even though the team understood the importance, the need to produce new features usually overcame daily tasks such as working on our design system. It was imperative to find a silver lining.

2. Methodology
When working in a small team in such a rapid development, communication between UX/UI and R&D is crucial. We had to tackle the way we wanted our design system to be maintained and updated. The discussion revolved around the design system’s environment, how to document component behavior, priorities in documentation, additional information, etc.

3. Rallying everyone to the cause
Previously designing the system was made intuitively, so when the design QA was conducted, there was a considerable gap between the original design and the developed feature. We had to align everyone (design, production and development) to a one standard, with a defined design principals and components, which is, our design system.

My goal

A ‘one-source-of-truth’ – one constantly updated resource file for designers and front end developers

    • Creating a design system to keep the platform consistent

    •  Reducing the gap between design output, to development output

    • Improving development time by creating common components to be reused throughout the development process

Discovery

The first step was to review every aspect of the platform and document the components
 to try and find common denominators. I mapped everything from basic assets such as
 colors and fonts, to components such as buttons, cards, tables, filters, etc.
During this process, I tried to group the many inconsistencies I found by visual similarity
and/or functionality.

 
Image 10@2x

Research

I started with an online research, looking for existing researches on methodologies for building
a design system. Finally, I settled on well-known method which I felt will strongly enhance my
 output – the Atomic Design method. The key idea behind this methodology being small,
independent – atomic – parts, can be combined into larger molecular structures.

Next, I examined well-known design systems using this methodology. I eventually
summarized all my research into these parameters: 

    • Suitable platform to build my design system
    • How best to divide the information, and the level of detail for each section
    • Important information for each team member (Design, development, product) and collaboration protocols
    • How to create flexible and reusable components 

Grid

Colors

Typeface

Typeface

Icons

Form elemnts

I used 8 PX grid which means that every
element in the system can be divided by 8

We had a lot of colors after the audit I minimized the as possible till the point it
won’t harm the developed componnets

The main typefaces of the platform were SF and robot.

The main typefaces of the platform were SF and roboto.

The main typefaces of the platform were SF and roboto.

The main typefaces of the platform were SF and roboto.

Primary

Nutruals

Supporting

Bringing all together

Now it was time to pen the ‘atoms’ for the platform – colors, typography, icons, etc. At this stage I started to backtrack and correct inconsistencies.

Now building the components, I started grouping the elements in a one master file to be used as a library. When the library was grew bigger, I separated each component into a different page, sorting them by categories: colors, buttons, fields, cards, tables, etc.

I conducted a team meeting to define the platform that will host our design system, and suggested several solutions. Eventually we decided to go with InVision because its ability to synchronized with Sketch (which was used by design) and because of the developer’s familiarity with it.

 

Mobile

Having a design system in place, creating a mobile version for the platform was much easier.
Being as flexible as I designed to be, I was able to use common components from the design system
when working on the mobile version, and so it was easier for me to communicate the requested changes to features for the mobile version. 

Project learnings

Design system is not a task

It is a way of life. When we as designers start working on a product, we need to start
grooming a design system. This is an ongoing process, and not a one-time task.
It will become a keystone which will evolve and guide the production forward.
It has a great impact on the collaboration quality of the team.

Creating a good design system requires collaboration

Ultimately, the developers need to work with the design system.
They must be familiar with its structure, the platform it was created on, and the rational which was
used to document the features. For that, they MUST be part of the design system
 creation process and contribute their own point of view. 

Introducing a design system at a late stage is a pain

Working on a design when a system is already developed, takes significantly more
 time, and it can become a huge task (for both the designers, and the developers
 who will have to fix inconsistencies). Sometimes it might even be easier to simply
 use this as an excuse to overhaul the design. But In either case, the only way that
 such a design to be adopted, is if the entire team would be willing to accept this
change, and if there is a strong PM to enforce this change. 

More projects