About the blog
This blog will talk about the journey of creating a design system which brought a uniformity in all our designs and helped in productivity.
What is a Design System
Working in software development and design, we are often required to ship one-off solutions. In some cases we're working inside time limitations and here and there we simply haven't yet settled upon a way ahead. These one-off solutions are not always bad, but if they are not made on some strategy or foundation we may end up in technical and design debts.
Design Systems have been characterized numerous ways: an assortment of visual resources, an example library, and a CSS Framework are the most widely recognized. However it’s defined as a collection of related yet independent components that can improve product-development efficiencies and help enable a great customer experience.
Design has always been largely about systems, and how to create products in a scalable and repeatable way. A universal Design framework is fundamental for building better and quicker; better in creating a cohesive user experience and quicker on the grounds that it's anything but a typical language to work with.
Why we need Design Systems
1. Faster time to market
A Design System dispenses reinvent the wheel every time a designer or developer sits down to work on a frontend element. Either the library of assets will have a component that can be promptly utilized or the available guidelines will take care of some of the brainstorming. Also, since debates are more averse to happen, organizations can deliver products a lot quicker than without a design system.
Besides, the Design System evolves with time. So if some team comes across a problem during advancement, they modify the design system accordingly. This prevents different teams from running into comparative issues later on.
2. Enhanced Collaboration
In the absence of a regulated set of guidelines, designers and frontend developers often find it difficult to agree on multiple grounds. Designers, on occasion, would design something without contemplating the functionality and implementation perspectives and basically hand over the plans to designers. And afterward now and then, engineers may present a couple of changes in the plan to deal with functionality. With a design system, you get to leave all these issues behind. The Design System deals with aesthetics just as functionality and guarantees designers and engineers run after a shared objective.
3. Reduced costs and fewer errors
With a faster turnaround time and fewer elements to create from scratch we can save some valuable design and development hours which can be otherwise used for productive tasks. And since a design system is constantly used by multiple teams and individuals, it’s much easier to isolate errors at an early stage. And with every error isolation, the design system leaves lesser room for errors and streamlines frontend development.
Getting Started
To work through these challenges and keep our decision making process fast, I was teamed up with some front-end developers at ChaosNative who explained to me how react-theming works and all sorts of programming constraints. We cleared our calendars and for around three weeks looking through all the designs of each product we jotted down the common elements, the coloring schemes and then planned in creating the design system.
1. Laying Foundation
While looking through the designs of each product I became aware that in designs various things are common like buttons, input fields, only they look different due to their colors, or the icons used and many other things. So we needed to bring a common ground for all these things and created a color system, shadows and iconography.
2. Creating the components
There can be many components and developers may be creating the same components with different coding styles. So after discussing with the front-end developers they suggested to use a common JS library package and we decided on Material Design , and after reading through its component style guide , it became easy to know which components we definitely needed to create and assign the properties and make variants.
3. Compiling the library
While creating these components, we collected them in a master file called the Litmus Component Library, which we referred to throughout the design process. After a week or two we began to see huge leaps in productivity by using the library when iterating on designs. It has also become a guidance for upcoming design of products.
Conclusion
We knew that this was a challenging project. It meant re-designing and rebuilding the majority of the views in our software. As with any project, there are things we wish we would have done differently. While this was a monumental task that ended up requiring efforts from many of our product teams, we found that creating our Design Language System was worth the investment and a huge leap forward. Since the design language and code are often shared, we can now build and release features on all native platforms at roughly the same time. Development is generally faster, since product engineers can focus more on writing the feature logic rather than the view code. Additionally, engineers and designers now share a common language. I believe that aided with these systems we were able to focus more on actual user experiences and concepts we want to create in the future.
Resources
To view the design file with components and guidelines :
LitmusChaos Community
Are you an SRE or a Kubernetes enthusiast? Does Chaos Engineering excite you?
Join Our Community On Slack For Detailed Discussion, Feedback & Regular Updates On Chaos Engineering For Kubernetes:
https://kubernetes.slack.com/messages/CNXNB0ZTN
(#litmus channel on the Kubernetes workspace)
Check out the Litmus Chaos GitHub repo and do share your feedback: https://github.com/litmuschaos/litmus
Submit a pull request if you identify any necessary changes.
Don't forget to share these resources with someone who you think might benefit from them. Peace out. ✌🏼
Top comments (0)