Vyond Design System
How might we better enable Designer, Engineers and Product owners in building more consistent Vyond products?
Working in Vyond (formerly GoAnimate), I worked with one other UI designer to create a universal design system and documentation that enable the teams to collaborate more effectively together and to ensure design consistencies.
Head of Design
When I joined GoAnimate in 2012, it was still a startup, there was no style guides, Sketch files, guideline, nothing. I realised I had to start from scratch. I created a style guide to maintain the consistency of the website and revamped the Video Maker's look and feel so that at least it looked more professional; However, as the product grew and we built more features, we realized we needed more than a style guide.
In 2017, we started to rebuild the Flash-based Video Maker to HTML5. While designing the Video Maker, we become aware of some internal problems:
01 Designs were custom built and not reusable
02 UI lacked consistency
03 UI, UX designers and Engineers had their own versions of UI components
04 Video Maker and Vyond.com website followed two different set of styles
With the help of one other UI designer, Queenie, we worked on defining a design system together. I started to capture every UI element in the Video Maker as well as the video listing page, then we grouped them into categories.
The structure of the design system is based on the Atomic Design principle by Brad Frost. The Design System and its components are build with a hierarchy in mind like it is used in chemistry.
Basic building blocks in a UI
Componenents are created by combining the Elements
They define the look. Examples are typography, colour palette, illustrations, icons.
Generic page layouts put together by elements and components
Each component was clearly defined with all “states” in the system. For example, a form input had a placeholder, hover, focus, filled out, error and disabled state. This saved a lot of time when designing wire-framing and prototypes.
Ideally my goal was to create a live website that documented all the patterns, usage guidelines, examples and centralized codes; However, due to limitation of time and resources, what I did was simply start with Google drive, pdf and XD prototypes.
One of the goals of the design system was to get designers, engineers and product managers to speak the same language. We held workshops and tried to come up with a consistent naming conventions that could be applied to both design and code.
At the beginning, there was some resistance in creating a design system, since we have to take extra time to build the system.
Over time the benefits started to show. With a design system, I noticed I was able to create hi-fi mockups faster. UX Designers also focused more on the user experience, problem solving and not on re-designing the UI over and over. It also helps to improve communication with engineers .
Being a UI designer means being a gatekeeper to the product's Design System. There were times when designers needed to be creative and experiment with new interactions and patterns; However, most of the time we should use what the Design System offers and reduce the amount of unnecessary design debts created. Failing to do so means either the system failed or the team not understanding the rules of the game. This is changlleging, as a designer myself I value creativity and uniqueness; yet we need to strike a balance in the world of product development.
It is always a challenge to try to connect the product team with the design system.
How to get other teams informed and excited about the design system? How to get design and code in sync? How to update changes made in the components? When to summit component changes in the sprint?
I think that a practical design system cannot just live in a vacuum, it requires both designers and developers to work on it together.