- Right now at ConvertKit
we're working on a new design system
for our marketing website, convertkit.com.
And this right here is the start
of a brand new video series
where I'm gonna be taking you along on this journey
as we bring this design system to life,
and share the progress with you along the way.
Now, something you should know is
that we are a very small team
of people working on this design system.
There is just three of us, two designers, one developer.
I know at some larger companies, they have whole teams
and like designers whose whole role is
to work on developing, and maintaining,
and documenting the design system.
That is just not the case for us at ConvertKit.
We all have other responsibilities and other priorities.
And so hopefully this video series is gonna end up being
a really good look at how a small team can get
a super solid design system in place
while maintaining their focus on all of the other work
that's going on.
In this first video I'm gonna give you an overview
of our approach to the system, some details
on why we're working on it and why now is the right time,
and then a look at where we're at with it so far
in these very early stages.
So let's jump in.
(upbeat music)
I thought it might be best to start
by talking about what our goals are for this design system.
Creating one is a lot of work.
It requires a lot of energy, and time, and focus.
And so it's important to know why you're doing it
and what you're looking to get out of it.
And for this bit, I'm gonna bring in David,
our senior marketing designer to talk
about what we're hoping for as a result of this process.
So, David, what are some
of the goals we have for our design system?
- I mean, there's a couple, but the one that comes
to mind for me is a lot of the time we'll get requests
about different pages on the site that already exist.
- Hm
- So if we've got components and things already created
in the design system, we don't have to think too much
about like a redesign or setting something new.
So it's just about a little bit
of a faster workflow, really.
- Yeah, and also I think that's changing our mindset
or at least mine
in the way that I used to approach pages was,
like every time we did one, it was a redesign.
Whereas now
- Yeah
- It'll be updating components rather
than updating pages, which I think is good.
- You start thinking
about like the knock on effect of something.
So if you're gonna change a component now,
how is it gonna affect things later?
And you start planning ahead a bit.
- Yeah, yeah, yeah.
We're future proofing things
a little bit better, aren't we?
I also think like obviously now we're
a team working on the website together,
whereas it used to just be me thinking about it.
And so think our design system, you know,
didn't have to do quite as much
but this is really helping us get alignment
as a marketing design team, right?
- Yeah, definitely.
And you're so right.
Like having a design system for one person,
you almost, it's very hard to sell that idea to other people
in the organization because you're like, "Well,
you're the only one using it," so.
- You should know what you're doing. (laughs)
- Yeah, exactly.
It's a tough sell but it's another thing, your teams grow
and teams change.
So if you've got systems set up,
having people join and then just start using the system
from day one is a huge help.
- I also think, because right now we're going through
some visual design language changes, right?
So we're like using the creation of the design system
as our platform for making those decisions
about what we want to bring with us.
And like, I dunno
we're Marie Kondo-ing our whole design language, aren't we?
We're like, "We'd wanna take this with us
in this part over here, we're gonna say, 'Thank you,'
and we're gonna move on from it
and do something different." (laughs)
- Yeah, that's so true.
The other thing is,
especially when we are fortunate enough to work
with the developer in our team,
So having parity with the code base is also another factor
that helps the workflow.
So if I know that I'm gonna be using something over
and over again,
rather than having Corey, our front end developer,
build it new every single time,
he can create something that we've set up
in the design system.
We know that there might be a few variants of that,
and it's gonna get used on different pages,
and just having components and things that are
in a Figma file in a design system, and then replicated
in the code base, whether you're using React
or whatever kind of library for your components,
it just, it makes everybody's workflow better, not just ours
but also the development.
- Yeah, so I guess to sum up our goals
for our system are around getting alignment
so that we're working from the same like set of options
and making decisions together,
and having alignment with the code base as well,
but also making things more efficient
for us because we are a small team.
So we gotta do a lot with a little. (chuckles)
If you've been subscribed to my channel for a while,
like we're talking a good long while,
you might have seen this video here that I made
in 2019 talking you through the very first version
of a design system for the convert marketing site.
Now, looking back on this,
I see now that this wasn't really a design system,
it was more of a component library
that allowed me to build mockups faster
because it didn't relate to the code base.
It didn't have any documentation.
And I think those two factors are really important
for making something an actual design system.
Now, recently we've been making a bunch
of changes to the way that our marketing site is coded.
It's gonna allow for us to have better parity
between what's in Figma and what's in the code base.
And so I thought I'd bring on Corey,
our senior front end developer,
to talk a little more about these changes.
Corey, can you explain how the code that we're creating
for site 2.0 is gonna allow us to have a system
that matches the design system
in Figma a little better than our current site does?
What are we making changes to?
- So two of the biggest challenges that we've had
on our team for a really long time, I think is twofold,
is speaking the same language when it comes
to taking static designs from Figma
and translating them into code for the browser, right?
So you can't just say hey here, you know in the olden days
you would have a Photoshop file
and you just cut it out, and they would all be images,
and you'd just stick it on the internet.
And that's how it worked
but that's not how things work anymore.
So speaking the same language and saying, "Hey,
this is what we want from the design.
And then this is how we want it to appear.
So that I, as a developer, can take your vision
and your design and translate that as best as I can
to as many people as I can
with all of their different devices and so on."
So that's the first challenge.
And then the second challenge is efficiently adding
or updating components, whether in style or functionality.
And, and so that's been the main thing
that we've tried to tackle over the years and not very well,
at least from a development point of view.
So moving forward, we're using a library called React
which many developers will be familiar with,
which is, at its core, the JavaScript library
for composable user interfaces is how it's defined.
The overall concept is that you build an interface out
by saying, "Hey, I've got component one component two,
component three," just like in Figma,
designers will know this, and you say,
'Hey, I wanna take an instance of this button or this card
and just reference it over here.
So if I make changes to the main one,
it changes over here as well."
In the past kinda the ways
that we've done this have been kinda hacky
and not really ideal from a user experience point of view.
And so in our case, we wanna just say, "Hey,
here's a component.
Charlie has designed this out,
or whomever has designed this out.
We feed it some data from a development point of view.
And then every single time it's rendered on the site,
it has the exact same design that we want for it."
- Yes.
- So that's kinda what we're aiming to do
with the current site rebuild on that, I guess.
- Yeah, and what we had previously,
is we'd of course use the same classes
to style things around the site
- Yup
to try and get a similar look,
but it kinda, because it wasn't built
the same from an HTML perspective,
we really had to check each individual page
that a thing was on each time
if we wanted to make an update, which is
- Right.
- Why it couldn't happen very often.
- Yeah. And if we ever wanted to update
something at its core
of how it looked or behaved, or if we wanted to change kind
of our methodology for rendering something on the page,
we would have to go find every instance
- Yes
- And change that.
So, as an example, one of the things we use
at the ConvertKit website is a system called Tailwind
which is a utility based CSS classes.
And we hadn't always used that.
We had used Bootstrap before.
And so whenever we wanted to update anything
on the site to Tailwind,
now I have to go into however many 100s of pages,
or posts, or whatever,
and update how, which classes those elements are using.
And it's a giant pain, it's the worst.
So having something like a component where you say, "Hey,
we wanna update this base methodology of the code."
You just go over there and you say, "Hey,
we're gonna do this instead."
And then it changes everywhere.
It's magic.
- So it's basically just like what we can do in Figma
with our component library and with variance things.
- Exactly - Very cool.
- Exactly, yeah.
- Okay, so now you've heard what our goals are
with this system, our approach to making it happen
between taking things from Figma
and getting them to the code base,
and also keeping them aligned.
Let's jump in and I'll show you where we're at so far.
So we have three different main libraries in ConvertKit
that we split up.
The overarching design system between one is this shared
system that is things that both us marketing designers
and the product designers will use.
Things like logos, things like our icons, and our colors.
This little like dev notes tool that we can all use.
These things are in a shared library
so that we can all access them
and all be pulling from the same place.
But we keep everything else fairly separate.
We use slightly different button styling
in the app, slightly different typography.
And we just felt like it was best
for marketing and product to have their own design systems.
So this currently very messy file is
the marketing design system.
And as you can see at the side here,
we're using these emoji to indicate the status
of certain parts of the system.
So all these bits
that are green are ones we're fairly happy with right now,
at least in Figma.
They still have some work to be done
with being implemented into the code base.
Yellow ones that we're started on
and like are getting close to.
And then red is like, well, the mess
that you see here. (chuckles)
Let's start by looking at the spacing
because this is kind of like the base of the whole system
and was actually one of the things that pointed us
towards needing to have a shared understanding
between design and dev in the first place.
So as you heard Corey talk about, he's using Tailwind
on the site as utility classes
and we're using a Tailwind style spacing system.
I got this file from the Figma community.
I'll leave a link to it in the description
but it's basically a component
that has all of the spacing units set up as variants.
So you can just drag it in from the Asset panel
and then use it as a spacer in your designs.
So that little component's gonna come
in handy when we are laying things out to make sure
that it's clear exactly
what space should be between elements,
but this also informed the like spacing unit
and system we're using across typography,
and corner radii, and things as well.
So we're using the standard base of one REM is 16 pixels.
And then, yeah, we have things moving up from there.
Sometimes we have halves, like we have 4 1/2
so that we can get 18 pixels
which we need for some font sizes.
But yeah, this is our base.
And using REM is really important
because it is better for accessibility.
If someone with lower vision has their settings such
that they need the type to be bigger, if we use REM,
then it'll scale really well with that.
Whereas if you use pixels,
then things can stay really small
depending on how they've set up that low vision access.
It also helps to create like a bit of flow and balance
in our design to have everything be like multiples of eight,
essentially like this
and Tailwind uses a naming function.
So as you can see here,
one REM is actually four as a Tailwind spacing unit.
So this is an important piece
of like a shared language between us as design and dev
for us to be able to say tail and spacing unit four.
And it means one REM, which means 16 pixels
if you're set at the base, like zoom size.
Hopefully that was okay to follow.
But yeah, we just felt like a spacing system
was gonna be really important foundation for everything.
We then applied it to our typography.
As you can see here, we have it documented
in the system as well with exactly how it is set up.
And all of these are set up as styles.
We have a different set of styles
for desktop compared to mobile,
where things get a little bit smaller,
but again everything is based on REM.
So if a user has their zoom settings differently,
then all the type would be larger for them.
Typography was something really important
for us to get sorted straight away.
We didn't make a lot
of changes compared to what existed previously.
Like we haven't changed our fonts
but what we did do was a bunch
of refining and making sure that the font sizes fit
within this system that we had set up.
Next, we also have these website frames set up.
So these are our like break points essentially
that we pay attention to.
And that we can target easily
with CSS when we wanna make a change to something, you know,
for a certain screen size.
These are a little bit different
from the like standard ones that come in Tailwind.
So if you are familiar with Tailwind
and you're seeing these look different, don't worry,
we're just sort of like doing our own thing
based on what we know works best for us.
These are all set up as well
with a very handy grid that we can align to.
And David has created these boxes here
to document what we're seeing below as well.
These website frames are set up, we're using Figma variants.
So we have this mobile screen size as our base
but then you can pick
to, you know, design with a larger screen size, if you like.
And all we do is drag it in and then detach the instance.
And this becomes the like frame
that we're working from for our design.
We have also set up buttons.
I think I'm gonna do a whole separate video
on exactly the like decisions
that went into making this button component.
Cause I did, I mean, I created like three
of them before I got to this point. (chuckles)
Sometimes things take a trial and error, you know?
Yeah, we have our different button sizes
and it's all set up as variants as well
to be able to control certain things.
Then more recently,
David started working on this beautiful system of shadows
with a bunch of different depths and colors to it.
So that'll be the next thing
that I think that gets marked as green.
David's also been working on the navigation recently
as well, and I think once those things are settled,
the shadows and the navigation,
we will have our like base completed
and be ready to start working on different page elements.
So far, really the only other component
that I've made is this call out bubble one
that you'll see around the ConvertKit site.
I set it up with a bunch of different variants
with, yeah, different options for the arrow direction
and things like that.
But since creating this,
I've learned some like better ways to go about it.
So I think I'm gonna be making some changes
to this component coming up.
This is gonna be the new button
that I end up making this component three times
until it's right.
But the reason
that we haven't jumped straight into like making
a bunch of different things that we would use
to lay out a page is because we are building the system
as we go.
For example, I'm currently working on designing
a new product overview page
and through this, we're kind of establishing
the design patterns that we then want to live in our system.
I personally believe in this approach
to building a design system
because this way you're designing the components
in context of real copy, real content
in like a real situation where they would end up being used.
I think if you design components in a silo,
like say for example,
you design a really nice looking carousel
and then you go to use it
and you realize it doesn't fit the type of content
that your team wants to use for it,
or it doesn't quite fit
the like way you thought it would go on the page,
or maybe you end up like not even using a carousel at all
and that wasn't a component that you needed.
I think those things can be avoided
if you build components based on them being used in a page.
So yeah, this is just the approach we are choosing to take.
I know there are many different ways to go about it
but next I need to like refine the spacing
of these text elements, for example,
and start building these outer components
because clearly an h2 with large paragraph
underneath is gonna be something that we want in our system.
We've also so far noticed a need for David and I
to get better aligned with Corey in terms of reviewing
the code that he's implementing based on our Figma designs.
In our normal process, we're reviewing a full page
Whereas now we need
to sort of like review each particular part,
'cause if we make sure that we get the bones right,
they'll be right when they're applied to the page.
So it's kind of the opposite approach that we're taking
with developing the design of the system in the first place.
But I think it's what makes sense.
I'm sure I will end up sharing more about that
in future episodes of the series as we figure it out.
But I hope you enjoyed this look
at where we're at right now,
and that you're gonna subscribe
and stick around to see the system develop.
I'll be making these videos every so often
whenever I feel like we're at a good point
where it's worth updating you on the progress,
but you can actually follow along
as I'm working on the system through my live streams,
"The Co-Working Club," that happen every so often,
usually on Fridays right here on this YouTube channel.
So subscribe and you'll be notified about them as well.
If you are currently working on a design system yourself,
maybe that's why you clicked on this video,
please let me know where you're at in your process
down below in the comments.
I would love to hear where you're at
and what hurdles you've hit so far .
For us, honestly, it's just been really overwhelming
to even think about everything that's needed for the system
which is why I think our approach
of building components based on the pages
that we're designing will be the best one.
Anyway, thanks watching, stick around
and I'll see you in the future video.
Bye.
(upbeat music)
(upbeat music continues)