While working as a Senior Product Designer at Vancity Credit Union, I led and owned the creation and sustainment of the Vancity Design System. The creation of this was a long (roughly 9 month) process, but the result was a more collaborative design team that was able to build designs and products much more efficiently.
We used a designer first approach, focusing on their creativity and existing work rather than on specific components. At all times the design system was led by the ideal of being a collaborative living system, rather than led by the design system team. This required building a culture of systematic thinking and collaboration.
The result of this project is an evolving design system which is still the foundation to all new digital product designs at Vancity.
The first stage of building a design system was to create a foundation for it to sit on. This was both a software and an organisational foundation.
Over many projects Vancity had begun to evolve a new design style that was being used inconsistently across digital products. This evolution was organic, meaning that all new products had a similar look and feel but with key differences that made them feel disjointed.
To work with this, a large scale design audit was done across all digital products. This audit encompassed everything from colours, layouts, components and interactions. While the bulk of the focus was to audit the visual elements, we also took an audit of UX practices such as form labelling and behaviour (for example, are buttons horizontal or vertical).
Once we had this audit we began migrating the entire Design Team onto Figma. We saw that Figma had the best opportunity for us to build a strong design system that wouldn't degrade over time.
With the team's transition to Figma and the audit complete, we began working on the new baseline by tackling core brand elements such as colour and font. As is to be expected, outside the primary brand colour there were dozens of colour variations being used, often only once. These variations were undocumented, and seemed to serve only a visual purpose.
Specifically with colours, we began by finding the most common themes. For example, we saw that most products used a darker red, often for a similar reason, but rarely did the reds match.
With this knowledge we started creating many iterations of the colour scale. However, unlike previous approaches we tackled this as holistically as possible. Not only did we make sure colours worked in their specific instances, we also had to make sure the colours worked as a set and met the accessibility needs required of them.
Accessibility became a primary driver of not only our colour choices, but all design system decisions. This was expressed throughout the design system, all the way down to how components were named and organized for the design team's use.
We began transitioning the designers onto it as soon as we could. At first we did this by creating new files both from and in the design system. Because projects were already underway, this gave us a great chance to let designers begin streamlining the components they were already using.
The design system team then began taking those individual components and working with designers to really understand how, where and why they were being used. We would then create the components in the design system with a focus on flexibility and product agnosticism.
This let us quickly iterate and test on techniques for creating components, such as flexibility, layer ordering, component naming, etc. After a short time we sat down with the design team as a whole and began discussing these techniques, to find what was working best. It was critical for the design system to work for designers in a way they wanted, rather than have it dictated to them.
We did this through many exercises, from design critiques to card sorting to help us understand what designers were expecting of a component and where to find it as intuitively as possible.
It only took a few months to have enough component coverage that designers could comfortably build the majority of their pages from the design system. This became version 1.0 of the Vancity Design System.
With an internal 1.0 release, our next steps were to document and distribute it. A subdomain was set up where we could upload the components and document their best practices, both for internal designers and external vendors.
At the 1.0 release, the entire design system was being kept in a Core file owned and maintained by the design system team. Adding components to Core was a very manual process, whereby designers would create new components in their files, then meet with the design system team regularly to discuss them. The team would then build those components into the system, using the rules and standards defined in 1.0.
This quickly became a bottleneck for designers, and a lot of work for the design system team. We found that designers were becoming disengaged with the system, as it often felt like a blocker. For example, if a component wasn't working how they needed, they would have to discuss with us and then wait for the next release. This would often take up to two weeks, which was too slow in an Agile environment.
We explored many ways of working with the team. The outcome was migrating to digital channel based design systems. These channel design systems would reference Core for all brand components (colours, fonts, buttons, etc), but then house the unique components for the products within that channel.
The three channels chosen were website, platform (mostly internal systems) and apps (mobile, tablet, etc). Each project could only use one of these three, to help us all manage workload and keep track of usage. Unlike Core, these three systems could be added to or changed by the project team designers as and when they needed.
By giving individual teams their own systems, we helped teach them how to build great components, while also giving them personal investment in the design system as a whole. This significantly increased engagement with the design system, while drastically reducing the slowdown caused by a single system.
With 4 design systems, it became important to create workflows that could help designers understand when a component should live in Core or elsewhere. We began testing and documenting different processes to explain this.
The result was a flow that included creating Trello tickets when designers felt components were useful to other teams. This had the added benefit of getting designers to think more about other projects and how they could help one another.
This workflow was accompanied by monthly meetings where the entire design department would discuss their work on the design system. This was an opportunity for everyone to see what others were working on, and then leverage the work of other teams to help their own projects.
For the design system team this was a crucial meeting, as it helped us identify and priorities items for the backlog for each monthly release.
With these processes in place, the design system is still growing and being used on a daily basis. It helps the designers build pages and applications a lot faster, which in turn makes their role within an Agile team easier. This has given the team a significant boost in efficiency, and let the designers work more closely with front end developers.
However, despite these efficiencies, the true impact of the design system has been on team culture. At the start of the project a conscious decision was made to build a design system that didn't tell designers how to work, but instead gave them the foundations to build on. This now means that everyone comes together to build and evolve the designs over time. The personal investment everyone has with the design system helped build a team that is collaborative and engaged, in a way we did not anticipate.For the design system team this was a crucial meeting, as it helped us identify and priorities items for the backlog for each monthly release.
Lead Product Designer
Reinventing the Dugout product, to bring fans the best experience of their favourite clubs.
View case study