oVERVIEW

Salesloft is a very fast-growing revenue orchestration platform. User configurations and settings accompany the countless features shipped out to users each week. Most often, much time is spent on getting these features into tip-top shape with little thought given to their settings.

I take on the challenge of developing a framework that sets up the “control panel” within the “winning machine” for long-term success.

Join me on the journey to build Salesloft’s first framework: The Settings Framework.

GOALS

• Deliver cohesive experience and interaction patterns across Platform Settings

• Reduce the time product designers spend building elements for Settings pages

• Create a Figma component library for product designers to use in daily workflows

• Increase overall efficiency of product development organization by increasing the usage of reusable components

• Support Angular deprecation and React implementation across the tech stack

ROLE

• Lead Product Designer

• Product and Framework Owner

I joined Salesloft as a Product Designer in late 2018. As I began to onboard and ramp up on the Salesloft platform, one of the first areas that struck me as an area for improvement was Salesloft’s Platform Settings.

At this point, the company was a startup of about 300 employees. Product Development teams were small and nimble. Almost anything that could be a project would be a project if it added value to our customers and internal teams. I decided to go for it.

Platform consistency.

Simple and intuitive end-to-end workflows.

Attention to detail.

These are things that I enjoy focusing on. I value the details. It’s one of my superpowers. I’m often told that I have “good eyes” because I usually spot inconsistencies or areas for improvement in spaces that others overlook.

I believe that consistency is at the core of predictability and predictability plays a big part in delivering intuitive experiences to users.

When intuitiveness is a driving principle across a platform, users tend to know what to expect when exploring different areas of an application. This principle sets the stage for building reusable code and components, streamlining work for development teams. Having a framework to build on to support specific use cases or design solutions, also makes work easier for designers.

There are huge benefits all around.

I asked around to learn more about why our Settings were so — “all over the place.” There wasn’t a real reason, as I suspected, but everyone expressed that this part of the application left a lot to be desired. The company was growing super quickly, shipping large amounts of features, and the Settings experience just became the essential messy drawer — disorganized but holding everything that you need, for whenever you need it.

process

milestone 1: Side HUSTLE

I first performed an audit of the Platform Settings. Since this was a side project that I was pursuing, low efforts and high returns improvements were my focus I wanted to be mindful of existing teams’ roadmaps yet create an easy opportunity for teams to improve the settings pages they owned.

I settled on the following goals:

1. Establish a clear visual hierarchy using current typography and components

2. Create templates that encompass the needs of the various page layouts

3. Provide design recommendations for current pages to enable quick page redesigns

The aim was to get buy-in on this work without throwing off product roadmaps.

I created and delivered design templates for product designers to leverage when creating new pages.

I also handed off recommendations and design guides for all existing settings pages in the application.

I presented these resources at the Product Design All Hands meeting and asked teammates to update settings pages in their respective surface areas using the created guides.

Phase 1? Complete.

milestone 2: tiger team

It turns out that the templates, recommendations, and guides were a win.

Product Managers were asking questions about where the patterns for new settings pages came from. Product Designers were happy that there were design guides to follow - as consistency was also important to them.

My side project started to gain some momentum. I kept receiving requests to review newly created settings page designs, questions about how to tackle specific configuration implementation, and recommendations for how we could update the templates to account for different development needs.

To continue to push progress, I continued to work on these improvements outside of the main feature work on my two development teams.

This landed well, but I also felt a bigger initiative coming.

What’s Next? I spun up a Settings Squad to help push the efforts further across the Salesloft application.

milestone 3: bUY-in

Time for the team kickoff!

As a Settings Squad, we primarily focused on solidifying interaction patterns and designing components specific to the Platform Settings surface area.

Designing components was important to us because until now, Settings pages were created without the use of components. Engineers had to implement all facets of the pages from scratch which wasn’t the most effective use of time. The lack of components also made things more complex to tackle when a page was just redesigned but an aspect of that design needed to be updated a few months later. At that point, the “redesign this settings page” ship would have sailed for a development team and that update would be left undone. Building one-off pages also created small inconsistencies that could potentially lead to a larger issue in the future.

After a few weeks of dividing and conquering - we wanted to get buy-in from the engineering organization.

We hosted a “lunch and learn” and presented options to engineers.

Much of what we proposed was very feasible and worked for our engineering counterparts.

Design. Set. Go!

Oh, wait. A plan is great but someone has to prioritize the work.

Milestone 3b: Prioritization

The timing worked in our favor when it was time to get the Settings Squad work prioritized.

Engineering had a goal to update the tech stack by deprecating Angular and implementing React. I viewed this as a perfect opportunity to kick off the component creation work across my CRM teams. So that’s where we started - CRM Admin, CRM User, and CRM Sync settings page. My team did not have a dedicated UI Engineer at the time so I worked with a new junior designer on this as their capstone project for promotion. Across the Settings Squad, each designer also started to work with their team to do the same after my UI engineer and I completed the first few pages.

Safe to say that the passion project became a movement? I think so.

After working to get prioritization in our respective surfaces, the Settings Squad was no longer, but I continued to own the Settings Framework.

milestone 4: Rebrand

In efforts to modernize the application, Salesloft’s marketing team sought to complete a Salesloft rebrand in 2021. One of the biggest shifts was going from blue to green (sidenote: users strongly disliked the color change) but that wasn’t the only change. With this effort, the framework changed as well. The goal was to modernize all components across the application. This ultimately took the form of less line usage and more rounded corners - which can be seen in the version of the framework that is live today.

Outcome

The Settings Framework is out in the wild and lives as a part of Starlight. Starlight is Salesloft’s Design System that we created over the last year or two.

It currently serves both designers and developers across the Product Development organization at Salesloft.

The quality of enterprise software can be determined directly by the settings that govern it.

REFLECTION

Going back to late 2018 when I first logged into the Salesloft app while looking forward to today in late 2024, the Settings Framework is one contribution I am most proud of. 

This work started as a passion project, where I believed that my strengths could provide value, and grew into something great. 

When building and designing large and complex SaaS software, I believe it’s important to simplify configurations when possible. If a user cannot configure or self-manage a feature, that user cannot seamlessly adopt the feature. If a user cannot adopt a feature, it can be argued that the feature is not of much use. 

Through shifting priorities, new product offerings, sunsetting products, and product acquisitions The Settings Framework continued.

Simplicity, consistency, and intuitive system workflows are things that I enjoy providing to users.

I’m happy that past, present, and future Salesloft customers and employees will benefit from the framework that lives today. 

Takeaways:

1. Block by block - it will surely get done.

2. Side projects turn into a movements - with the right momentum.