Overview

In the past three years I’ve been in Peerspace, I’ve seen the design team grow from one, myself, to four designers (three product designers and one visual designer) on a team. As our team grew, so did the velocity of features we’ve pushed out. Since there was now three product designers on the team, it was harder to be consistent with current patterns and component we had or even know what the rules are for each specific one. Aside from working on platform features, I’ve spearheaded the creation of the design systems for our product.

Why do we need it?

Since our team has been working on plenty of big complex features, we ran into multiple issues where we created an inconsistency in the product and only found out after the feature has already been released.

Pain point

The biggest pain points I’ve experienced and also heard from my team is:

· Not knowing the rules within components, patterns, and styles.
· Not having a UI kit handy for us made it twice as long to do detail designs and created inconsistency.

Goals

Based on these pain points, these are the goals that I wanted to tackle:

· Create a UI kit for the internal team to use.
· Create a documentation of the most frequently used component currently in the product and define them.

Phase 1

UI Kit

The first thing I wanted to tackle was to create a UI kit that is synced with everyone on the team so that we will have one single source of truth and anyone can make changes or add any new component created.

DSM by Invision in Sketch

I’ve set up the team on Design System Manger by Invision with all of our components and styles. This was a great complement to Sketch and can easily drag in the symbols.

Documentation to set up DSM on Sketch

Since DSM was a brand new tool and was still on beta, I put together a documentation for my team on how set up DSM on their Sketch and how to use it. This will help future designers that will join our team to have a UI kit ready.

Phase 2

Documentation

An important part of putting together the design system is definitely the documentation part. Not only will it benefit our team but also the engineering team. The whole design team had a workshop day just to define which components we frequently used in the product and divided them all up to start documenting. We ended up documenting ten components from that workshop.

Here are some of them:

Conclusion

We have a long way to go compared to other companies out there but I’m glad we started early on even when we had a small design team. Being able to tackle this as a MVP gave us the satisfaction of having it out and ready to use by other designers on the team.

View another case study

Boards

A tool that allows guests to create a collection of spaces for planning and collaboration.

Read Case Study

Feedback System: Toast Redesign

Peerspace Design Systems

Boards