Quickbase—
Bebop design system

● Background

As the lead on the Quickbase design system and being part of the team to re-design Quickbase's dated navigation, I saw a chance for us to both revamp the design system library and make sure that the navigation project would put our best foot forward with regards to design. This gave us the opportunity to re-evaluate our processes, from documentation to how to get developer buy-in on updating our components, something that we've historically struggled with.

I settled on three tenets to establish what this design system would strive for:

• Approachable: the design system should be easy to understand for non-technical users and we'd stick to more conventional styling.
• Flexible: the design system should adapt to the wide-range of Quickbase product areas and use cases for our app builders and end-users.
• Concise: data and data density is at the core of Quickbase and customer needs and the components should reflect that, from how they look and function to the content.

● Research

From being one of the designers working on our design system, I knew that it wasn't a flashy, fun project that other designers typically enjoy contributing to. Especially on our end, updates and processes are hard to implement.

I set up design systems meetings for the whole team to jumpstart the initiative. To make these meetings meaningful, I did a few things:

• Make sure that an agenda was provided and keep meetings short with just 1 or 2 topics per session.
• Other designers could be “guest” speakers and make sure everyone wasn’t only listening to me week after week.
• Each week would have clear action items.

One of the first undertakings I did was to run retros about how we organized files to make sure the team worked in a consistent manner.

The retros brought up issues like files being inconsistent and difficult to read from one file to the next, missing certain features that helped our file organization, and in other parts, too many unnecessary features like unused pages.

● Rebuilding the component library

While I was running retros, I took the liberty of building a new library so that designers could use the current design system uninterrupted. This also allowed me to rebuild older components to address longstanding issues, build with best practices in mind, and implement the use of Figmas' latest features like variables.

Once the retros on file organization were completed, I made several updates:

• The base design file template had extra, often unused pages before and was trimmed down to what designers most frequently used.
• I added specific places for designers to copy component instances from so that they didn't accidentally copy and update the main components.
• I pulled in other designers that had more experience with design systems for feedback on better ways to build and organize things.
• While the content team continues to refine their content library and how they with with their teams and Figma, I worked with one of our content designers to make sure that commonly repeated content patterns could be easily used by designers as a starting point for their work.
• I moved documentation into one place for single source of truth until other stakeholders need to consume the design system information again.

● Working with developers

On the engineering side, at least one developer was frustrated on needing to define CSS each time they added text to the UI. I updated the type styling and scaling and worked with the engineer to add our type styles to the React library that other teams could start using.

And to get the process started on implementing updates to the components, I worked with the lead designer and developers on the navigation project to figure out when it made sense to bundle some of the work with this project or other projects.

● Next steps

We're starting to ramp up our usage of the new design system as more designers and teams get onboarded, continuing to update documentation, and work with developers to bundle design system updates into the navigation project.