When I first entered Kalibrr, most of the older designers had moved on leaving a lot of legacy code and UI behind them. As Kalibrr grew and grew fast, documenting and making sure things we're scalable became the least of our priorities leaving a lot of UI and UX debt. Though there was an internal sketch design library, it did not reflect the current state of the product which still used out of box bootstrap UI. To make sure that we can scale the design team and design operations I needed to make sure we had a sustainable design system working.
To make sure we had buy-in across the entire organization and ensure scalability across the organization I brought in representatives from Marketing, C-level executives, Engineering and Product to join me on a discussion on Design principles. Using the Maslow's hierarchy of needs we we're able rank our design principles from which we can make sure our design decisions are always aligned even if we we're working in different teams.
The principles we've set as follows:
From previous experience I knew that without multi-disciplinary team committed to the cause. The push for a design system coincided with our desire to update our system to the latest version angular which made it easier start our efforts. We we're able to gather a set of engineers who specifically enjoyed working on the frontend to help us organize and build our design system. This group became the Design System Guild, individuals from different packs in the product engineering group who we're focused on interested on our frontend, UI and UX.
Every time a specific component or element is initially designed by the designers, we'd gather the guild to discuss and gather feedback within the group. This helped make the process more inclusive and faster to develop as engineers are able to give their thoughts early in the process and are very aligned with the goals of the design.
Not all components come out perfect at the start. What we've all learned throughout our creation of our design system is that design system components can be iterated and evolve over time. A good example of this was our buttons.
Our initial buttons we'r every much based on the material design specification but after discussions with our marketing designers, our engineers and testing it out with my dyslexic nephew we realized that our buttons could be more accessible, inclusive and malleable.
We changed the type setting to take out the all-caps, made the weight more bold to separate it from normal hyperlinks and creating variations of how it would look with an icon on the left-side and right-side.