There's a major difference between how we approach design systems at Amplitude and how I've approached them on previous teams I've worked on.

In the past, teams I've worked on focused on the number of components we shipped as the primary indicator of success. This meant that we invested the vast majority of our time on building new components. We then expected product engineers to take time out of their sprints to use those components in application code.

At Amplitude, we focus on adoption as the most important success metric. This means that we spend a significant amount of time doing what we call "integration" work.

Integration work is when members of the DS team replace existing application code with design systems components. We then check on our adoption rates every week to track how we're doing against our stated adoption goals.

An important part of design systems work is creating positive feedback loops. By integrating the components themselves, a design systems team can:

a) increase the % of adopted components and therefore prove the team's value to stakeholders,

b) put example code in place that application engineers can copy when they inevitably need to reuse the component,

c) build trust with their teammates and consumers, and

d) dogfood their own code.

--

If you like this newsletter it would really help me if you shared it with your friends. Tweet about it, post on LinkedIn, and share in slack channels. Building this community can lead all of us to more job opportunities, guest posts, and connections.

Talk soon,

Mae