When I first joined ViSenze, I was told that there were many different web applications in the machine-learning lifecycle (from data sourcing, data cleaning, training to models evaluation). Each of this application has its own feature but the majority of the building blocks are vastly similar.
There was no formalized design team to oversee all applications which caused different teams to build their own systems to speed up their own operational efficiencies. New and existing applications became inconsistent and confusing due to different interaction behaviours, layout and aesthetics.
I initiated and led the building of the design system with my team of designers.
First and foremost, I worked with the engineers to prioritise UI components by evaluating all web applications and identify commonalities. Group UI components into P0, P1 and P2 (P0 being most important and commonly used in most use cases and P2 being least important for the time being until more use cases are found).
A weekly checkpoint between designers and engineers are scheduled to review the progress of the component design and finalise the interaction behaviours and visual design.
Once a component is implemented, designers will conduct Design QC to validate against the design specifications. When a component is ready to be used, it is applied to actual project to identify technical gaps and design changes required. This process is iterative and enhancements were raised as we design more UI screens.
I always remind my team that:
For a Design System, I broke it down into two key parts: Component Library and Design Pattern
An organised UI library with clear behaviours and specifications help designers to quickly locate component and speed up the design work such as prototyping or visual design of UI screens.
Design Pattern documents the common interaction behaviours across all applications. This acts as a source of truth to fall back to when questions arise on design problems that have been discussed before.
Building a design system is an iterative process. Just like technology keeps advancing based on trend changes and usage behaviours. Here, design system improvements are also driven by the same factors.
At ViSenze, I worked with the lead engineer of Vix to derive something that is optimal to suit the company’s process, people and culture:
When validating an application, there might be a design system bug found. I came up with this process to help developers and designers know what to do:
The Vix Design System was eventually launched as a software development kit that engineers can refer with component demonstration and code base. Engineers and Product Managers could also handle simple design concept prototype on their own with guidance from Design Pattern. A great Design System is one that empowers users of the system to use and create great design concepts. At ViSenze, I believe this has been achieved during my tenure.