Research
Planning
Team collaboration
Interaction design
Design quality assurance
Web application
1x Product designer (me)
1x Front-end developer
1x Quality assurance engineer
Creating a design system helped the team have a cohesive understanding of what we are building, how to get it right and deliver solutions at a better pace.
I led the process of setting up the design system, got the whole team on board and created a single source of truth that product owners, designers and developers will refer to during every product implementation cycle.
I was part of a startup that offered a B2B product – CMMS tool that companies used to track machine health and plan out work on a daily basis.
We were picking up pace as more clients were getting onboarded with the goal of digitizing and optimizing their work flow. This meant that the product will be maturing fast to provide better solutions for the new use cases.
The web application was expanding to have more features and flows. With this demand for rapid growth, we faced challenges that will become harder to tackle as time passes.
The initial style guide had only a few guidelines, elements and components to start off. It limited the creation of design for broader design explorations and product functionality.
I had to design interaction experiences that were specific for single scenarios without considering their use somewhere else in the app.
At every design stage, more time was spent on deciding on a new style, element or flow instead of the actual problem. I had to go back and forth between design files and the live application to confirm a design choice and imagine how it will effect the structure moving forward.
The same problem arose in code. Similar functioning sections, actionable items or granular elements had unique styles and names even though they could have had the same rules and categorization to optimize code.
Having different versions of elements like buttons, links, colors or tables was common. Similar type of pages were designed with varying layout styles.
The product also had many instances of design not translated properly in code. The main reason for this was not having a dedicated front-end developer in the team and so implementation of UI design was pushed towards the end of a full-stack developer’s work priorities.
In light of the challenges faced, it was important to make structural changes to how work was getting done. I, along with the quality assurance engineer, discussed our concerns with the product owners to streamline the design implementation process.
We decided to dedicate efforts in designing and implementing a design system which will help us achieve these goals:
I collected data from existing design files, product requirements and the live application to get an idea of design patterns in use.
This activity helped me take notes of design inconsistencies, commonly used elements and focus on what needs to be prioritized to create a unified design language.
Before starting to define a design system, I wanted to re-evaluate what the product aims to achieve. I had a detailed conversation with the product owners discussing the vision of the product and how we can build a process that is efficient, and an experience that is delightful to use.
We discussed the needs of the product’s primary users. Feedback from clients suggested that they would like to have larger font sizes that are easy to read and primary call to actions that are easily recognizable and interactable.
A user should be able to quickly and easily navigate through the web application without spending a lot of time on the system.
For the product’s design to be sustainable in the long run, it should have these core design principles:
I researched design systems of well established digital products for insights and gathered best practices to put in use.
Since the web application was intended to be used only on desktop screens, I didn’t consider designing for smaller sizes. We had tablet and mobile apps in the pipeline to be launched soon.
Deconstructing everything to atomic size, I started drafting standards for colors, font, icons and spacing. The process for some of these are mentioned below:
The first thing I did to improve textual content was iterate on a few styles to ensure type modularity. Keeping the base font size as 16pt, I revised all other sizes to be in ratio of the base size. This ensured scalability in the type system and easy translation of points/pixel sizes to em and rem used in CSS. At any time, we can experiment with changing textual sizes for specific use cases without breaking content hierarchies and layout styles.
The heading sizes were revised to be larger and spaced out to help users easily scan important information.
Initially, a bunch of colors were already in use so it was not required to introduce a whole new color system. My main focus for colors was to ensure that the existing and new colors follow the color accessibility standards to a greater extent, have enough contrast and are consistent in every place.
It was important to keep the colors look true to their older versions so that the user is not confused with the change in color and what it signals.
A few new colors were also introduced that had similar tones to gel in with the accent family. I was careful to avoid introducing too many accent colors and apply them all in the same place to ensure users do not face a cognitive load or have to remember what color means what.
For every accent color, I introduced a lighter and darker shade that can be created by changing color opacity or darkness in front-end design. The tints and shades were used to give user interaction feedbacks on hover and in-active states.
This technique worked well for the product at that time. However, if there were no constraints, then I would have tried to create a new system of colors with multiple tonal variations for each accent color.
In order to standardize the use of icons across the app, I adjusted the size, style and visual weight of all icons currently in use along with creating some new icons.
After a discussion with the (recently hired) front-end developer on how to optimize the use of icons across different platforms (web app + mobile apps launching soon), we created a font file with the help of icomoon.io. It was intended to be regularly updated with every new icon addition. Each icon had a name, a letter and a unique code that can be referred from the sheet exported with the font file.
This approach ensured that the development team always had the latest icons in use without waiting for the designer to share the asset files with them. All they would need is to update the latest version of the font file to gain access to the icons in the 24-point-grid.
Colors, strokes, shadows and sizes were now easy to change according to the design.
Referring to all previous design files and features in the web app, I made a collection of reusable components and UI patterns in one place. This rigorous activity greatly helped me in picturing the product’s current and future design potential.
I documented and wrote guides for UI patterns and their usage, a task that will never end.
Moving forward, every new design decision was considered in light of what was available in the product and how I can make newer elements in line with the existing design language.
Now that I had a set of design standards in place, I created new symbols and components in Sketch app to optimize and speed up my work flow. Then I zealously updated older design files in accordance to the design system.
To have it accessible for the rest of the team, I uploaded the design system documentation to InVision app where the development team can go through and inspect each component's style properties.
Having a single source of truth in the design files was great. Now came the part of updating the web application accordingly and keeping it up-to-date.
To start implementing the design system in code, a dedicated front-end developer was hired. Once we had our design saviour on board, I collaborated with him to audit the complete web application and come up with a prioritized plan of action.
We started off with the basics first like colors, fonts etc. Then we moved to the collective UI elements, tables, cards and so on... The UI adjustments were incrementally tested by the quality assurance engineer and reviewed by me before they were released on the live app.
Even though the process involved a lot of cleaning and rework in the beginning, we were able to considerably reduce design inconsistencies and speed up the design implementation process in the longer run.
The process of creating and iteratively having the design system implemented was a huge step for the web app’s design maturity.
I was now able to focus more on identifying and solving the real user problems instead of dwelling on secondary UI decisions. It became easier to quickly iterate and test design prototypes with potential clients.
The design system helped the product owners systematically plan for new feature requirements.
The engineering team were able to code more efficiently and ensure consistency of design across the product. The detailed documentation and guide made it easy for them to translate design to code and figure out problems they needed to solve.
If I had to do a similar project again, I may have done it a bit differently.
It would have been interesting to explore data visualizations, charts and tables as part of the design system.
I would consider naming and categorizations earlier in the process and would also do more research of the front-end frameworks available and how to make use of components that could be incorporated in the product’s design style.
If a color system had to be created from scratch, I would make decisions that were more in line with color standards and contrast ratios to ensure maximum readability and accessibility. I would also add more than 2 variations for each color to ensure flexibility and scalability of the color system.
I understood that there could be no ‘one perfect design system’ as it is destined to evolve and change with the product’s growth. Creating the MVP of the design system that effectively served its purpose was nonetheless fulfilling.
