DBS Design Systems

Building tokens, components and patterns into design systems is just one part of the responsibilities of a centralized team. As the system and teams grow, so does the roles the central team has to take on.

Some of my first tasks was to build the entire web library and standardize the color ramps that would be used across each platform - that is only the first of many roles we have to take on. In fact there are six key areas (in no particular order) I see as a lead design on the design systems team, including building the design systems.

Communication

One of the most important aspects of being on a design system team is standardizing the way designers communicate. These means understanding how we should hand-off designs to developers and unifying terminology across teams; for example, developers may use one term for a component, while designers use another.

Leading by example was my mantra. As we handed off more components with great documentation to developers, developers would then request this type of documentation from product, and eventually we had a strong hand-off process that was organically adopted.

Collaboration

Related to communication, one of my goals was to set up workshops to help keep everyone on the same page. One of the challenges we saw was that product managers were not communicating the full message, or details got lost in translation.

Before covid hit, we ran a few workshops where we had everyone in one room discussing, wire framing and planning the product together. Questions that came up were clarified and discussed immediately, and the amount of work completed in a two hour workshop was by far more and of higher quality than everyone going their separate ways.

During user testing, we also encouraged product managers and developers to view from the screen room in order to build a stronger understanding of the challenges users faced, or see how ideas we came up with together were falling flat on their face.

This not only allowed team members of different roles to see directly the product issues, but also it created more empathy and overall a stronger team bond.

Training

This covers a wide variety of aspects, but I will cover a few simple items we launched to the team. The first was onboarding.

My goal here was to have the onboarding as seamless as possible and have it easily accessible for future reference. What better place to put it then Figma itself? I created these tiles as way to share some basic details about our design system, how we work and link to more documentation and resources that may get lost in the weeds.

Another major improvement we did to help the team was creating simple decision trees that had questionaires. These would help designers decide which component they should use should they come across a gray area they are not so familiar with.

Governance

We had two different ways to allow designers to contribute and review components. This allowed us to manage components at different stages of the process without taking too much of everyones time.

On the SME team, I had one design review with each group each week. This meeting was joined by product managers and on occasion developers. Allowing for open review, it allowed for the designer to communicate their intentions, but also allowed those of us on the central design team to communicate and support designers, but also hear the feedback and intentions of product managers or concerns of developers directly.

The second method was an open review, once the component is in a strong position and well positioned, the designer would setup a review meeting with the rest of the central design team. This meeting was open to anyone in the company to join and allowed different perspectives.

In some cases, a component can be cleared for the purpose of the original designer, but use cases may come up that we as the central design system team would implement into the component before publishing to the design system.

Exploration

One final aspect of the central design team is future explorations. This allows the design systems team to try their hand at the product, redesign areas that are not yet using the design system and see how it all falls in to place.

This not only allows the rest of the team to see exemplary examples of where the product could go, but it also allows us on the design system team to use our components first hand and find issues or use cases that may not have been covered yet.