Design leadership

Key Design Leadership Initiatives at Chartbeat

In 2016 I joined Chartbeat as a Sr. Product Designer. Previously, I had been leading the Product Design team at General Assembly. I had found leading a team to be challenging and rewarding but I realized I missed designing and wanted to continue to develop as a designer while working in a new domain.

I spent my first 2 years at Chartbeat as an individual contributor. I got to work on large projects like the launch of Chartbeat’s first historical dashboard. I learned about statistics, data viz, enterprise software, and the world of digital publishing. In addition to my individual contributor work, I found myself gravitating towards problems related to how we worked as a team. I often suggested changes to our tools and processes, applying the lessons I learned building the Product Design team at General Assembly.

When my manager at Chartbeat left, I was offered the Director role and I accepted. Over the next 3 years I undertook projects related to hiring, career ladders, implementing a design system, collaborating with cross functional peers on overhauling our product development process, and creating design principles.

Below are some of the details of those projects.

Standardized Hiring Process

Upon becoming director my first mandate was to backfill my role. At the time Chartbeat didn’t have a structured interview process. I saw this as an opportunity to create a process that was efficient, reduced the chance of bias, and most importantly, would lead to us making great hires then and in the future.

At the time, Chartbeat hadn’t formally documented what the expectations for Product Designers were at different levels. This was a problem for a few reasons.

First, if we didn’t know who we were looking for we were unlikely to make a successful hire. By writing down what the competencies were, and what good looked like for each competency at each level, we were increasing the chances that the person we hired would succeed in the role.

It also created alignment across the design team, with my boss, and with our outside recruiters. We were aligned on what we were looking for at each stage of the interview from phone screen and portfolio review to final round 1:1s. This helped us figure out which questions to ask, and we used it to evaluate candidates, attempting to remove as much personal bias as we could.

Rather than starting from scratch, I leveraged open source skills matrices including Buzzfeed’s design team role descriptions. I referenced theirs and others as we evolved our skills matrix to become career ladders for the team.

Design System

During my tenure as Director proposed and oversaw the creation of a design system. A Design System is, simply put, a set of design patterns and guidelines for when and how to use them.

I chose to focus on this project because during my experience as an individual contributor I witnessed frustration across the Design team, as well as Product and Engineering, due to the lack of design standards. At the time, Chartbeat had just turned 10 years old and, like most startups, in an effort to move quickly, hadn’t prioritized defining and implementing consistent patterns across our product. As a result, whenever we needed to add or change anything in the UI, there was a lot of discussion and debate about which, if any, existing patterns we should be using. We did the best we could to create a consistent experience, but it was often unnecessarily painful to get there.

There were many challenges along the way, including:

• We lacked tools and processes to keep our design files and code in sync.

• Existing components didn’t meet teams needs, and getting consensus on updates was time consuming.

• There was a culture that celebrated reinventing the wheel.

• It was treated as a side project without clear owners.

I set out to solve these problems.

First, in terms of design tooling, I moved the team to use Abstract, a version control tool for Sketch files. It was both a big change in terms of culture and process. Previously, we saved our files in Google Drive, but designers would often have personal copies on their local machines. This setup made it difficult to easily share styles and components across files, or even to find versions of the files you needed. Moving to Abstract had an even bigger effect on the team than I anticipated. It not only solved our logistical problems of being able to share styles and having a single source of truth, but it also reinforced a value I felt was missing from the team—collaboration. Working on the same file reinforced that we were all working on the same product, and encouraged consistency across our product surfaces.

Next, I advocated that we adopt an OKR to be co-owned by myself and our Director of Front-End. Shortly after I advocated for us having two project leads, one Product Designer and one Front-End Engineer. These two changes had a huge impact. After months of making very slow progress we began to get traction. The project evolved to being a side project that we worked on when we had time (which happened rarely), to being a project that had goals visible to the company, as well as resources attached to it. Assigning project leads to own the design and technical decisions helped move much more quickly than when it was everyone’s responsibility.

Our first big test of whether our design system would in fact allow us to develop high quality design work quickly came early in 2021. A team was working on a prototype for an entirely new product which required many new screens and flows. The team used our design system and was able to develop the MVP in just a couple of weeks. Previous similarly scoped efforts had taken months.

Product Development Process

Another key initiative I took on was revamping our Product Development process.

In 2019 it was clear that our product development process was leading to dissatisfaction across teams and wasn’t leading to good results. I facilitated a series of conversations with my peers on product and engineering to document the root causes of the issues we were seeing.

Over the course of the next couple of months I advocated for and help lead a major overhaul of our product development process. We shifted from having permanent teams working on ½ year goals, to working on six weeks cycles. Every six weeks PMs and project owners would write pitch documents that outlined projects estimated to take 2-6 weeks to complete. The documents described what we hoped to accomplish and how they supported company wide goals. The projects also described how big of a team was needed, and the breakdown of skills.

This resulted in a complete shift in how we were working and resulted in many positive outcomes, including:

Better velocity
Up front planning for cycles meant that teams had ambitious yet achievable goal, and the right number and mix of people to achieve it

Less knowledge silos
Working in six weeks cycles where we could reevaluate team assignments every 6 weeks allowed for people to move more easily onto projects based on need or interest. This allowed designers and engineers to learn about parts of our product or code they otherwise wouldn’t have had the opportunity to have worked on.

More transparency
As part of our six week cycle process we created project proposals which clearly laid out what we were intending to accomplish. This allowed stakeholders and other teams to have more visibility, leading to us catching misalignments on goals, or potential points of conflict in our product experience early.

After implementing the new process, I led our effort to get feedback from the Design, Product, and Engineering teams, as well as our stakeholders including the Exec team. The results showed that our new process, though not without issues, was an improvement over our previous process. We used this process to successfully bring to market Image various features including Image Testing and SSO.

Design Principles

As my team grew to include newer employees, we realized that aligning on Design Principles would help us collaborate more effectively. I facilitate a series of workshops where we looked at existing company and product principles and came up with more specific design principles that we could use in our day-to-day work.

Consider each customer’s journey
We want Chartbeat to feel like a knowledgeable partner who understands you and how we fit into your life.

• Start by identifying your target customer(s)

• Create holistic solutions that span the tools and channels they need to.

• Leverage our product suite and other channels like emails and our support site.

• Understand when a single solution is appropriate and when we need multiple solutions for different use cases.
  
  

Bring focus and clarity
We don’t want to overwhelm customers with mountains of data. We want to help them focus on what’s important so they can easily find what they need.

• Strive for simplicity. Be diligent about editing out all but what is essential.

• Look for opportunities to highlight what’s important, rather than making users look for it themselves.

• Look for opportunities to use progressive disclosure to bring focus and allow for deeper dives.

• Help users understand how to think about their data, and when possible, what they can do next.
  
  

Be forward-looking
We want to create solutions that can evolve easily along with our customers’ needs. We aim to create patterns that are modular and can be reused in various solutions by any team.

• Start by referring to our Design System and try to use existing styles and patterns.

• Help evolve our Design System when something is missing or needs to be more flexible.

• When designing a solution, think about how it could scale to accommodate more data or functionality.

• Look for opportunities to combine multiple similar solutions into a singular one.
  
  

Design for emotion
Our goal is to present data in a way that resonates with our audience of storytellers. We use craft, from micro-interactions to copy, to add a human touch that evokes emotion and inspires confidence.

• Strive for the highest level of craft that inspires confidence in our brand.

• Use language that is familiar to our audience.

• Look for opportunities to infuse delight, while recognizing situations where it’d be inappropriate.

• When designing dynamic real-time tools, avoid making them feel frenetic or stressful.

• Aim to make Chartbeat feel friendly and easy to use, and more like a consumer app than

Career Ladders

Another of my early projects at Chartbeat was creating the team’s first formal career ladders. This was an important project for hiring and onboarding, retention, and because we owed it to the team to set clear expectations around their roles, and to envision possible career pathways at Chartbeat.

Given my previous work on a skills matrix as part of our structured interview process, we had a good foundation. We knew which competencies were important and what good looked like for our current roles. Building on this I set out to implement a dual track ladder that created a senior individual contributor track. I also advocated for and created a new, more senior individual contributor role of Staff Designer. This enabled us to create opportunities for a couple of the more senior designers on the team, and positioned Design to play an increasingly pivotal role at Chartbeat.

Like our hiring skills matrix, we leveraged many open source projects including Buzzfeed’s role descriptions and the career ladder developed by Peter Merholz at Snagajob.