Things move at a break-neck speed in the tech industry. The life of a UI Designer at Watermark is no exception to that rule. As product development began, the need for a design system became pretty evident when no two people had the same definition for a component.
Disclosure: All colors and fonts have been altered to respect Watermark Insights' identity. This project details the process only.
With MVP 1 in place, we set out to identify inconsistencies and find solutions. The design system should represent a unified and universal set of components, that are easily reusable by any team member- new or old.
We conducted an audit of all the interface elements. We found that there were several hues of colors, minor differences in buttons, margins, etc. This lead to developers implementing the same component, but with a lot of unneccesary differences.
In order to get the best results, we agreed on employing Atomic Design Principles. Following these enabled consistency at a granular level, while providing the building blocks to create new components. We defined design parts as the following:
Atom: The smallest, meaningful, usable element is called an atom. Elements like input fields, buttons, radio buttons, checkboxes, etc. fall under this category.
Molecule: A combination of atoms forms a molecule. For example, putting together input fields, text areas and buttons create a form.
Organisms: More complex combinations of molecules make organisms. This is where components first start emerging. Headers and footers are a good example of organisms- they contain a collection of buttons, text styles and navigation.
With the foundation in place, building templates and pages became an easy task. Patterns started to be used and appeared consistently. Atomic Design permits building the basic blocks and introduce them with ease. It makes a design system extremely scalable and flexible.
I believe the biggest challenge we faced was the process of introducing new components. There have been plenty of instances where designers or developers have created a case specific solution, which wasn't reusable in other parts of the product. After a few weeks of back and forth, the designers were brought to the understanding that a new component should have more than 5 points of usage before being committed to the design system. Similarly, the front end developers were encouraged to use and reuse any components, and introduce a new one to their library for reuse by other developers.
The point burn rate increased significantly with front end developers spending less time creating components for every instance. There was decreased confusion between product team members, which shows in the consistent output of the developers. The UI Team has become, and continues to become, extremely fast and efficient, thanks to Sketch's symbol library.
The design system, now known as "Ripple", was recently published. As a key contributor to the beginnings of this system, witnessing the benefits of a shared understanding has been a remarkable experience. Front end developers, UI Designers, UX Designers and Product Owners have a growing reference to learn about different components and their usage. Slowly and surely, no single component has two meanings when used by two different people.