Building a Design System for iOS - Part 1 - Introduction

This is the first in a series of blog posts in which I outline my experience in building the components of a design system for iOS

Recently, I've been working on a mobile app which was going through a major redesign. I was involved in coding the building blocks of the new design values. I started to notice a lot of inconsistencies in color and font values. While auditing, I found remains of many old font families and custom colors being set in storyboard files. There were easily ten variations of gray color. The more I worked on it, stronger I felt the need to build a core design system at the software level so that designers and engineers could speak the same language.

What is a Design System?

A design system defines the visual language of a product's design. It's a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications. Reusability enables managing design at scale.

The concept of Design System is not something new. Companies and brands have had it in different names - Design Library, Visual Language, Pattern Library, Style Guide etc. Sure, there are some differences between them, but their intent is the same - create a collection of resuable components.

Benefits

Understanding not only the what, but the why, behind the design of a system is critical. Design systems can have compounding benefits -

Consistency - Have you ever noticed your design having various hues of the same blue? Standardized components helps achieving parity even across platforms and reduces subsequent design & engineering debts.

Efficiency - When designers & developers are speaking the same language, it definitely helps the team move fast and save time. It also makes iterations quick and painless, and experimentation much faster.

Accessibility - Accessibility is no more an after-thought. It can be baked-in at the component level by optimizing for those with disabilities, on slow Internet speeds, or on special platform.

Software as a continuum

Now that we have an idea what a design system is, it is clear that the standards from the design system encompasses both design and development. Unless you're rewriting the software for every redesign, code created from years ago would still require constant maintenance and upgrades. Writing software for a product is a continuous process. But I realized, as software developers, we've not done a good job at maintaining the consistency of the product language . Yes, we've had contants for colors and fonts but a design system is much more than that. It looks like we should define the entire system at the software level.

Let's look at what we can build part of design system -

Typography - Combination of fonts and sizes.

Colors - Maintaining a single source of truth to manage colors

Interaction - Transitions & animations.

Grid & Layout - Defines how the elements are spaced. This can include even 3D space which will have impact on the shadows.

Iconography - Although mostly images, this will be needed if you're drawing your icons in the code.