Journey to deliver consistency and flexibility through Blibli design system (Blue)
A story about design system development from the beginning until today â¨
Let me start this article with a quote from Alla Khomatova, the author of Design System: A practical guide to creating design languages for digital products.
âDesign Systems is about how to approach your design process more systematically, and ensure your design system helps to achieve the purpose of your product and fits with the culture of your team.â
â Alla Kholmatova. âDesign Systemsâ.
Hi everyone đ Iâm Vanessa, one of the UX Engineer at Blibli and a member of Blue Team. I start my journey here since 15 June 2020 as an intern and have been witnessing how Blue grow. We start crafting Blue in the beginning of 2019, and around Q2 2020 there are 8 of us (3 designers and 5 UX Engineers). At that point, Blibli UX team was in the middle of scaling-up and there was a tremendous pressure to achieve consistent design in all products. So, our responsibility is more inclined towards crafting components and socialize our design system, Blue.
Today there are 11 members in the Blue team (4 designers and 7 UX Engineers) and most of us are also dedicated to at least one squad, working on design realization. Until now, Blue has been used by over 70% squads đ
What is Blue?
Let me introduce you to Blue (Blibli Unifying Elements), the home of Blibli Design philosophy, creative vision, and guidelines. Built to optimize design process, Blue is a living source of truth that evolves constantly with the product we design.
Our design system is a crucial tool to help scale the quality, consistency, and efficiency of a design output. At its best, Blue allows designers and developers to rapidly and repeatedly leverage quality design solutions, freeing them up to spend time-solving unnecessary problems. For example, instead of creating a new button every time designing or developing a product, our designers can instead spend that time optimizing design and development process.
However, as we get to know the business, many requirements and new use cases emerged. We also need to adapt to current business conditions to meet user needs.
But how? đ¤
How do we keep maintaining Blue, scaling good design solutions and creating consistency, while also providing flexibility needed to support innovation and improvement?
This was, and continues to be a question as we develop our design system đŤ
However, to help guide our Blue team in the development, we (implicitly) stick to the following concepts:
1. The core
Core contains elements that are universally used by our product and appear in most areas of our product. Thereâs a simple, generic component like button, card, text field, as well as our styling guide like colors, tone and voice, font, etc. These core elements require much more stable and consistent application. A button interaction in one project needs to behave in the same manner as a button in another project. With consistency, we implicitly force users to learn what experience should feel like.
Any proposed modification will go through several stages of consideration and testing before making any changes. Because itâs widely used for our companyâs product, any slightest change can provoke unintended consequences in a project. Therefore, we aim to ensure all the core element meet high quality, interactions, and has basic features that meet any requirements. Some experiences that seem more complex will be treated as cases.
2. The case
There are some product experiences that are often repetitive, but not universally. Cases might be more complex than the core component. In every project, each component may be slightly modified to meet some specific needs but still stick to the basic guidelines that already exist in the core component. Most of the components in our design system come from the outer shell of specific case (furthermore we refer them as âthe templatesâ) which then get picked up by one or two other projects to be used in their product.
Components at this level are maintaining their flexibility. Some sections may be combined or replaced with other components, some sections may be added or omitted. But, each change is still bound by Blue guidelines (tokens and styling guide) that provide consistency to our product.
As an example here I attached one of our core components, text field. Some projects that I have been participated in use a text field with autocomplete feature. Therefore, we treat autocomplete as one of the cases in text field and develop it with text field combined with list.
3. The templates (slicing)
For certain specific cases â intentionally made for a single, specific need â it doesnât make sense for us to develop it due to differences in the concept and purpose of Blue which provides a generic design solution. In other words, if our product wouldnât benefit broadly, we donât include it in Blue. But for some cases, we initiate to provide it and explicitly label them as templates in our Blue documentation. Each template is also bound by Blue guidelines that provide consistency to our product (such as tokens, color, font, etc).
We always encourage our designers and developers to never hesitate to contact UX Engineer to discuss and help provide specific cases component đ
Last but not least,
Due to its nature as a living document, weâre always updating our design system at Blibli. This is just one of the story in our journey. Make sure to look forward to our next stories. Kudos to all Blue members who keep composing Blue until this far! đđ
If youâre interested in applying for a full-time position or intern, Blibli is currently hiring! Send your resume to recruitment@blibli.com and get the chance to work with our PM and UX team and our own unique stories.
