A well documented design system has the opportunity to serve as a watering hole for the entire organization.
I work at a product company where we primarily focus on design and development of large in-house enterprise and customer apps. With growing demands and to keep up with the products scalability, plus with a major revamp of the full technology stack, its was a right opportunity to introduce atomic design system to have a scalable design that can balance with a scalable product.
With an already existing well established brand guidelines, its was a pretty clear road to establish a design documentation, challenge was to figure out practical implementation for multiple products.
Thats when I stumbled upon Atomic design principles by Brad Frost. A scalable methodology to craft interface design system and a opportunity to create a ‘watering-hole’ for my organization- all products feeding from the same pool.
Let’s take a deep dive into understanding the basic fundamentals of an atomic design system, advantages of the methodology when compared to other traditional approach, challenges that we faced while implementing it. We’ll also look at it with two lens – one from a designer perspective using tools such as Sketch, Invision or Brand.ai and two from an actual product development with React and .Js frameworks.
Session 1 – Early day trials with ‘Open source frameworks’.
I’m not gonna get into details of how frameworks came into existence. All I’d say is there several out there: Bootstrap, Materialize, Foundation, you name it. As one would say without re-inventing the wheel, we tried Bootstrap which had tons of reusable components and reusable chunks of code.
- Unfortunately it was more of a developers thing than a designer which led to back tracking and endless cycle of spot the look alike game for development teams and since designers don’t see what they were designing, designers often introduced new design elements, which constantly meant additional development time.
- Using framework also meant that we were subscribing to other developers naming structure. Trying to fit our design into an existing structure and subscribing to framework meant that we had to use the entire bank even though there might be 0 usage of some component in the design adding, carrying the dead weight around and bringing down performance of the product.
- It was not the out of the box solution, since we were building internal ecosystems team was constantly faced with newly added custom features that consumed more additional development time.
We soon realized that frameworks was not the right thing for us.
Session 2 – Introduction to Atomic design system.
Extracting inspiration from physics of nature and making it as a methodology for interface design thats Atomic design, a solution proposed by Brad Frost a web designer from Pittsburgh, USA.
To simplify things its like an empty canvas where you can define and organize your in components within a design system with a simple and basic categorization of : atoms, molecules, organisms, templates and pages.
Lets look at them in detail.
Atoms: The most basic building blocks. Individual lego bricks. Anything from basic checkbox, text blocks, buttons etc. These elements cannot be broken down to any more granular level.
Molecules: Two or more atoms put-together makes up a molecule. Input fields with labels, hero banners with text, cards with buttons or text, notification toasts. Molecules could be functional elements usually seen inside an organisms.
Organisms: functional bits of the page that are made up of groups of atoms and molecules. Organisms are usually autonomous functional components. Organisms can get quite sophisticated with mini organisms inside a super organism.
Templates or ecosystems: We being a democratic team, introduced a tweak to make the design system work for React and .Js (Angular, Node) frameworks. Templates are empty state pages without content. Ecosystems are container components which are composed of multiple organism components. In React, we can use these container components to organize, manage, and delegate messages to organism components.
Pages or environments: You add content to a template that becomes a page. So in theory you can generate multiple pages with the same template. Ecosystems should semantically represent the major core components and ideas the layout, you can define any number or ecosystems inside an environment or even break an existing one to an atom level.
How did we make it work for us?
Session 3: Making it work – design&code documentation.
When the team agreed to try out Atomic approach both designers and developers had long hour sessions locked up inside a conference room, analysing the existing designs and working out a methodology thats close to our natural workflow.
Now, being an ambitious team we wanted to make the design system work two ways – for both designers and product development teams.
As a digital design team we use Sketch and invision in day to day work with Avacode and invision inspect for dev teams to inspect the designs and get measurements or artifacts. With all these components and artifacts been created we needed a online inventory where we cold document atomic components created, this led to introduction of a tool called Brand ai or invision DSM.
Brand ai. or Invision DSM – design documentation
Instead of traditional approach of documentation that comes after a design is crafted, we figured out the most efficient way is to document progressively as we design. This ensured the designers to use Brand.ai as a first step to look for components in the design documentation.
We established two subset of documentation one for native and one for web, native would cover all native app product and web the desktop sites and both documents inheriting components from each other. Meaning a ‘ basic card’ in native is the same ‘basic card’ in web, but a different dimension.
With Brand.ai offering sketch plugins, design documentation served as a shared dictionary for designers while designing a new layout. This became a process – Where one designer would update the design system on brand.ai and other would find it in the ‘sketch’ library instantly. This methodology not only reduced the creation of new components but instead pushed our designer to think of various possibilities to reuse the existing components form library.
Not only for designer but brand.ai also served as a presentation of components for dev team, every time a new component was introduced it was sent as an update notifying the dev team on the changes. This was all possible with a well planned naming structure, every component had a unique name that defined its atomic structure and context of component itself. e.g. Atom-buttons —- consisted all buttons inside it (button-primary, button-secondary, etc…)
Molecule -cards —— consisted all cards inside it (Card-mini, card-promo-small, card-highlight etc…) eventually the names stuck in the minds and designers – developers started communicating in a new vocabulary – I call it ‘component language’.
With brand.ai our ‘watering hole’ was half way through, we had designers using it actively in their design process. To complete the ‘watering hole’ and have all members in organization and to benefit from it we had to take it a step further and fill life into these components.
How we did it?
- Brand.ai offered style data export of any component that was documented, anything from CSS, Sass, Less etc. Developer could instantly pull the values of a specific component from Brand.ai.
- We also had detailed labels for every component that was documented, which served as the base communication channel.
- Using Pattern lab ( Pattern lab is built around the base principles of Atomic principles) and Story book.js for React, we ensured support to product development teams without restricting the technology stack they had chosen.
Pattern Lab and Story Book.js – Code documentation.
As a first step we started documenting Sass library of components on KSS node making its as a style-guide kit and distributed it within development teams using NPM inventory. By doing so we endured that the entire organization was consuming a common style guide aligned with design documentation.
Tip: Styleguide being common for both pattern lab and React this ensured continuous development on style guide and reusability.
With starter kits available to connect with Brand.ai we were able to link back the components to the original design on Brand.ai. Check this out for details on implementation. Once the same series of atomic components was established on story book and Pattern lab the communication became be more fluent between designers, this should also help clear the air between designer and developers once the documentation with same labels is established on both ends.
Currently we are still in transition of documenting components on story book and pattern lab, with these in place in theory the time it take from design to shippable product should be cut short by a huge margin. I’ll talk about the challenges and share our experience in part 2 of the article.
Session 4: Benefits of ‘having a design system’.
The advantages are huge no matter which angle you look at it from. Here are some highlights from my personal experience.
- Design consistency for end users. Although the design documentation was more a process to improve efficiency of the process the benefits were pretty obvious in the end result. Customer experience was clean and sophisticated.
- Clear communication between Designers and Developers with a good naming structure and giving each component a unique name for what it stands for, we had established a new vocabulary ‘a component language’ where designers and developer spoke in one voice and with the Brand.ai all components were visually available for anyone to view.
- Code documentation with pattern lab and story book the atomic structure came to life. Designers and product owners could finally see the interactive component which was documented and use them in reference of discussion while brainstorming. These components also served as well organized lego bricks.
Conclusion
Design system is not just a fancy terminology thats trending in contemporary world. Yes, it does take some time for teams to get onboard and gain momentum. But once you are onboard benefits are huge.
Ultimately why create a page when you can create a system thats capable of producing multiple websites and apps or a ‘watering hole’ where designers, developers and product teams feeding from the same pond.
Tic Talk 