Design System, The What, The Why, and the How
The What:
A Design System* is a set of standards (components, guidelines, resources and styles …) defined to achieve a visual consistency across an application.
In other words a DS provide a comprehensive guide for designers and developers, covering everything from typography, color, and spacing to navigation, accessibility, and animation so that the product is not only aesthetically pleasing but also functional and accessible to users with different abilities.
In digital applications worlds we find mainly three standards:
- Apple Humain Interface Guidelines (HIG) for macOS, iOS, iPadOS, tvOS et watchOS
- Google Material Design for Android and web applications
- Microsoft Fluent Design System for Windows and other Microsoft products
Having those standards doesn’t mean that you don’t have a choice other than complying to the existant. In fact, this diversity can be an inspiration for Designers and Developers.
The Why:
“We’re not designing pages, we’re designing systems of components.” Stephen Hay
The main goal of a DS is to maintain cohesion and consistency across the application. It also helps keeping your application code clear, reusable and highly maintainable associated to the compliance to coding best practices.
- Cohesion and Consistency: for a better user experience it would be more intuitive to use the same component when you need to have the same UI and perform the same action in a single application.
- Clear: all what you need is already put in place, ready to be used just like any system pre-built component.
- Reusable: once you DS is in place the package is available to be used in other apps under the same product label.
- Common language between Designers and Developers.
Without a DS your mobile risk losing its identity.
At BforBank we are 8 Squads that collaborate on the same mobile application, approximately 30 mobile developers (iOS/Android) that constantly push on the same repositories. Imagine if each developer duplicates the same code to create the same component ! That’s why putting in place a shared and reusable component stack is necessary. So that’s it; develop once, use everywhere 😉
The How:
The Method:
All problems have solutions, as long as you follow a method/strategy. Atomic Design Concept is here to help putting in place a DS.
Exported from natural sciences to the binary world, the Atomic Design is based on natural elements structure:
- Atom is the basic particle of a chemical element.
- Molecule is a group of two or more atoms.
- Organism is the minimal functional unit of life.
Atomic design is a method consisting of five distinct phases that work together to create an interface DS in a more thoughtful and layered manner. The five stages of atomic design are :
- Atoms
- Molecules
- Organisms
- Templates
- Pages
“Atomic design is atoms, molecules, organisms, templates, and pages concurrently working together to create effective interface design systems.” Brad Frost
In addition to the atomic design, we also need to support also variation of atoms molecules and organisms! And for that a new concept is born The subatomic particles of atomic design, Ions.
An ion is where we can store all properties that apply to some or all components, whether atoms, molecules or organisms.
It is an additional public property repository that can be shared between components of the atomic design hierarchy; at the same time, the complexity of embedding these properties into atomic design structures is eliminated.
At BforBank:
Here at BforBank we do it by the book. No surprise, we have our own Design System. The DS is published on zeroheight, which is a central hub for designer, developers and other product teams. There you can find the Guidelines, components (including variations and use cases) and all the resources needed (such as Fonts, Illustrations and Colors).
The Design is created and published with Figma, which allow a real time development, share, and feedback to anyone involved in the design process.
Each feature developed is some magic mix between UI and Logic to give the best UX to our users.
At this point we have a DS and a UI, both are dynamic at some extent in an agile context. How could we keep our apps up-to-date with modifications done on the design side?
Hurray, some extra piece of magic ! Style Dictionary is a solution that allows you to define, based on a token system, how to export your DS guidelines. With the help of some content change interception mechanism and Styles Dictionary each time a change is detected, a new Pull Request is created per platform including the change.
Implementation:
DS implementation for mobile application consist mainly of
- Font and Texts styles.
- Graphical Chart including colors and their nuance, colors combination (dark / light), contrast recommendation.
- Reusable component and their derivative (Buttons, Shapes, ImageViews, TextFields …)
- Animations and transitions
iOS DS Library Structure Example :
In a perfect world, once your DS Library is in place the rest is LEGO Assembly.
Keep in mind that you are building a UI framework based on SwiftUI / UIKit so coding best practices / Standards are vital.
Added to that remember:
- Abstraction is your friend, let styles reveals the traits.
- Take a good care of naming you are building the foundation.
- Keep in mind that accessibility starts from here.
Keep In Mind that : the creation and maintenance of a DS require time and a dedicated resources, which is sometimes not given to every product.
Since the product evolve during time, the DS also follow. So to keep up with your clients feedback, all a long the product life cycle, you need to keep transferring the knowledge within your team.
Not all product have an application-specific DS. It depends on the product type, time to market, resources allowed to the project and the product audience.
*DS: Design System
Useful Links:
Introducing “Ions”, an extension to the Atomic Design – Chris Cid ∣ CJCid
