TLDR:

• Most icons are meant to be small – try not to blow them up

• Instead, give icons more weight by putting them in a circle

• Pick between giving the circle a background or a border – see which one you like best

Before:

After:

This issue is sponsored by Design Hacks, a newsletter run by incredible designer Erik D. Kennedy! Design Hacks helps you create better designs. It features short, original UI/UX tips & tactics. It’s read by over 50,000 people from Apple, Google, Stripe, and more. Check it out here!

I was creating an onboarding flow for my new app, which includes a step where the user picks the kind of element (I call them “tiles”) they want.

The design for this felt pretty straightforward – I had a square for each of the tiles and, inside, I had:

• an icon representing the kind of tile it was

• the name of the tile type

Pretty simple, right?

Here’s the wireframe:

What do you think?

To me, it looks ok, but something about it feels off. There’s something about the tiles that’s just not working for me, but I’m not sure what.

Fortunately for us, there aren’t too many elements involved, so dissecting this problem shouldn’t take too long.

Here are the elements we can play with:

• Border of the tiles (color, thickness, and radius)

• Sizing (title + icon)

• Icons

The easiest thing to play with is the border, so let’s start there.

Border

Here are the original elements of my border:

• Color: gray (#D9D9D9)

• Width: 1px

• Border radius: 8px

There are tons of variations of these three variables and it’s tough to know which direction I want to go in, but let’s see if we can define our goals and decide what variables will help us get there.

I want the whole onboarding flow to feel approachable and the emphasis to be on the content within each rectangle. With those goals in mind, I’m going to:

• Use a lighter gray for the border color

• Make the border radius rounder, to make it feel more friendly (maybe 16px?)

• Thicken the border

Note: I’m making the border thicker because I’m making it lighter. Making a border a lighter gray generally makes it harder to see and thickening it gives it more weight, and, therefore, more presence.

Let’s see if that improves the look and feel of this section and gets rid of that “off” feeling I’m getting.

I think it does look a bit friendlier, but that “off” feeling is still there for me.

Also, in lightening the border, I created a new dilemma. Can you spot it?

The border color is very close to the modal’s border color. That makes it a bit harder for my individual tiles to stand out the way I want them to. I want more visual separation between the modal and the tiles, so I’m going to go back to my original color and border width.

I do think the more rounded corners make it look more approachable, so I’m going to keep those.

Here’s the updated design:

With borders out of the way, one variable down, two more to go!

Next, let’s look at the sizing.

Sizing

One thing I struggled with on this design is figuring out how to size the title and its icon.

I’ve read that icons should generally be a bit bigger than the text, but are mine too big? Should they be closer to the same size? Should my title be bigger?

Let’s play and find out!

I don’t think my icons should be bigger than what they are now, so let’s try going the opposite way – let’s bring the two sizes closer together by bumping up the size of my text.

Oof, I do not like that at all. Look at that “product page” element – the icon and text take up so much space! It’s too tight and feels crowded.

However, I do like the size relationship between the icon and the text – they feel a bit more cohesive. So let’s bring the text back down to its original value and make the icons a bit smaller and see how that feels.

I like this so much better. I feel like each text and icon combo has the breathing room it needs to sit comfortably in its little box. Padding feels right, sizing feels better, but I still haven’t gotten rid of that “off” feeling.

We’ve got one more thing left to try: playing with the icons.

Let’s do it!

Icons

To be honest, I do not want to mess with my icons. I don’t know about you, but I find images and icons to be a little overwhelming. First I have to pick the library, of which there are so many to choose from, and then I have to decide what looks good? Oof, too much pressure!

When it’s time for me to pick an icon, I start with two free libraries I like:

• Feather

• Heroicons

Feather is a collection of simple, beautiful, open source icons with a solid range of options. Heroicons look very similar, are also free, and are from the makers of Tailwind.

They both have Figma plugins, and between the two of them, I can usually find what I need. To keep styles consistent throughout your app, it’s ideal to use a single library for all your icon needs, but sometimes the library won’t have what you're looking for.

In that case, I use a paid option called the Noun Project. They have both icons and photos and their library is huge! There are tons of options to pick from so you can find the style that best fits your app. I pay $39/year for it and I think it’s an absolute steal.

I think the actual icons themselves do their job well and I really don’t want to go through the process of replacing them. So what else can I do?

At this point I felt stuck and so I reached out to Erik Kennedy, a design educator whose course I was taking. He immediately said, “Your icons are too big. I have a tweet about that.”

He sent me the following tweet.

I had a feeling he was right. It wasn’t that I’d picked bad icons, it’s that I was misusing them.

Icons are generally meant to be small. They’re designed that way. I was blowing them up past their intended size.

At the same time, I needed them to be bigger. Having a small icon next to 18px text just doesn’t make sense. Here, let’s try it and see for ourselves.

Oof, that’s just not right.

Luckily for us, it looks like we’ve got an easy fix! All we have to do is place our small, correctly sized icon into something bigger to give it more presence. We can put it in a circle with either a border or a background color.

Let’s try both and see which we like better! I’m going to start with a circle with a simple border.

I like it a lot! I could make the borders a bit darker since they feel a bit too light right now, but it definitely gets rid of the “off” feeling I was getting.

Now let’s try it with no border and just a background color.

I don’t know about you, but this is my favorite so far. It looks so clean and intentional. I think the light gray background makes the icons pop. Even at a smaller size, they hold their own and take up space, which is great!

This feels like a huge improvement in the design of this onboarding stage. I might consider adding some color in a later draft, but we’ll do a whole thing on colors in a different issue. I’m happy with how this looks for now.

Key takeaways:

• Icons are generally meant to be small – don’t blow them up!

• Give icons more weight by putting them in a circle

• Pick between a circle with a background or a circle with a border – see which one you like best

If you end up using this icon styling tip in your next project, I’d love to know about it!

Happy designing! 🤗
Saron

PS. I’d love to learn more about what made you subscribe. Help me out and take this poll?

Hello!

One of the things I always struggle with in writing this newsletter is length. I write a lot. I’ve averaged over 1.7K words per issue!

I really want to walk you through the process of how design decisions are made, and walk-throughs take more explanation and detail, and, therefore, more words. But I want to make it easier to grab the key takeaways when you don’t have time to read the whole thing.

Introducing a new TLDR section that, when applicable, will include a helpful graphic or cheatsheet! The walkthroughs will still be there so you can join me in the learning process, but if you just want the punchline, I got you.

Enjoy!

TLDR

Question: How do we style text?

Answer:

1. Determine priority of the text.

2. Assuming your text is a regular font weight, pick one:

   • Emphasizing high priority text? -> Increase font weight

   • Deemphasizing lower priority text? -> Make it gray

   • Deemphasizing lower priority text AND it’s small? -> Make it gray AND increase the font weight

Important things to know:

• You rarely want to decrease the font weight lighter than “regular” – usually makes it hard to read and, therefore, inaccessible.

• Colored text is tempting, but rarely works. Usually just ends up being distracting, not looking very good, and being harder to read.

Cheatsheet:

When I think about design, my mind goes to colors, shapes, and fun fonts. But when I’m actually designing, especially when I’m designing an app, I find that I’m usually sticking to one font, maybe one or two colors, and, outside of icons, very few shapes. In fact, most of what I’m doing is styling text.

But how do you style text?

Styling text starts with understanding its role and prioritizing it.

How important is the particular text we’re working with? Do we want it to be loud and stand out, or do we want it to take a back seat?

Throughout this newsletter, I’ve frequently referred to the idea of the canvas as a stage. Some elements take center stage, others are supporting characters, and still others are merely background actors.

When I’m designing something, I find it helpful to think of my elements as actors and assign them a role – is this piece of text the main character, or should it take more of a backseat? Who’s the star?

Let’s explore this concept further by continuing on with designing our personal site.

Styling projects

To make sure we’re all on the same page, here’s where we left off:

We’re designing a personal site and using all the tools we’ve learned to build it piece by piece. Using an 8px scale, an 8px grid, and 12-column layout, we’ve laid out the projects section of my personal site.

I’m making a grid out of the different projects that I’ve done, and here’s what the first project element looks like.

Last issue, we focused on spacing and I feel good about how that turned out. We also discussed font sizes, which I also feel good about.

But even with those two things covered, it still looks like basic, unstyled text. Let’s figure out how to make it feel more polished.

We said that the most important thing about styling text is prioritizing it, so let’s do that now.

In this case, my prioritization is pretty simple – in fact, it’s already organized by priority!

The star of the show? The name of the project, “Not A Designer.” The supporting actor is the description and the background actors are the tags.

So where do we go from here?

From here, we need to think about what, stylistically, conveys importance.

What does priority look like in the design world?

Playing with weight

One way we can convey priority is to play with weight.

The most obvious definition of this is the literal font weight of the text. The thicker and bolder the text, the more important it feels. That’s because it’s taking up more pixels on the page and the more pixels something has, the more space it takes up, and so the more it draws our attention.

Let’s add some font weight to the title of this project and see how that feels. In Figma, I’m going to select “bold.”

That looks pretty good! It clearly calls attention to the top priority text and creates more differentiation between the title and the rest of the content.

But now I’m looking at the tags and feeling like they’re drawing a little too much attention to themselves. They’re not quite falling to the back like the background actors they are.

So what do I do now?

Should I keep playing with font weight, decreasing it to make it more subtle?

That’s certainly an option. The font I’m using, Inter, has a “light,” “extra light,” and “thin” font weight that I could try.

Let’s try the lightest weight and see how that would look.

Sheesh, that is really hard to read!

It’s tempting and logical to think that going down in font weight is a good way to de-prioritize text, but we usually end up with text that’s hard to read, especially for something like tags that are already a small font. When we style our text, we always want to check for readability. After all, our products need to be accessible.

So what else can we do?

There is one more thing we can do.

Bring in some gray

We’re going to go back to our original font weight but make the text gray.

Gray is simply a lighter shade of black, and by using gray for the text, we’re avoiding the distracting result of introducing a true color, but, at the same time, toning down the loudness of the text.

Let’s pick a medium gray and see how that feels.

I think I like it. It moves the tag to the background like I want, and there’s a clear visual representation of its priority level. The big bold text is most important, the regular text is next, and the small gray text is last.

But because the text is small, I’m worried I still have a bit of a readability problem.

What can I do to keep that background feel but increase readability?

One thing we can do is increase the font weight.

Let’s try that and see how that feels. I’m going to give it a small bump, from “regular” to “semi-bold.”

I like it! Keeping the text gray deemphasizes the content and increasing the font weight increases its readability. Great!

Here’s a summary to capture the process we just went through:

• To emphasize high priority text, increase font weight

• To deemphasize lower priority text, make it gray

• To deemphasize lower priority text that’s also small, make it gray AND increase the font weight

A prettier version of this summary can be found in the following flow chart I made for you. Feel free to use it in your next project.

Happy designing!

Saron

Today, we’re finding our rhythm — our vertical rhythm — while pulling together a few other tools we’ve explored up to this point. We’re going to dig into how to use a scale to space elements systematically on the page — no guessing (and second guessing) here!

This issue of Not A Designer is brought to you by Erik Kennedy of LearnUI, a REAL designer who used to be an engineer, has created design courses taken by thousands of students, and has his own newsletter, Design Hacks. Make sure to check out his stuff! 🤗

While researching grids and layouts, an interesting term kept on popping up: vertical rhythm. It refers to how the site feels as you move down the page. Like music, does it have a good rhythm, a visual pattern that moves you smoothly and harmoniously downward? Or is it off-beat, with a jump here and a jolt over there?

You can tell when the vertical rhythm is off because your eyes tend to get stuck at different parts of the page. The elements are harder to take in, text is tougher to read, and it just feels bumpy. We want that smooth ride.

Here’s an example of a page with poor vertical rhythm:

It’s not the worst page in the world, but something about it feels just a little off. The subheading feels like it’s floating away from the heading. Its spacing is too wide. The main body text feels too tight. If you feel the same bit of discomfort I feel looking at this page, that’s a sign of poor vertical rhythm.

Let’s see this same example after fixing that vertical rhythm:

That’s much better. I feel like my eyes are flying down the page, not a bump in sight!

So what changed? What’s responsible for that rhythm?

It’s not the font, font weight, and other more obvious styling choices. It’s actually the one thing that’s kind of invisible – the spacing.

If you think about what it takes to lay out a page, there are so many spacing-related decisions we have to make.

Line height? That’s a spacing decision. We’re deciding the height of the space where the text is going to be, which determines how far apart lines of text are from each other.

Margin below that heading? That’s a spacing decision. That determines how far away our subheading is going to be.

The height of that nav bar? Another spacing decision. That decides how much room our title and nav items have to themselves before they go up against a different element.

We’ve tackled line height in a previous issue, so in this drop, we’re going to focus on other forms of spacing.

More specifically, we’re going to continue on our #notadesignernewyear challenge by working through the spacing of a particular part of my personal site redesign – the Projects section.

Getting set up

To start, we’re going to pull together everything we’ve learned so far about layouts and wireframes. In Figma, we’re going to start with our 8px grid and our 12-column layout.

Let’s see what that looks like.

Great! Now we have a structure we can use to help make our first placement decisions.

I’ve got six projects I want to highlight on my personal site. Remember that the first step of wireframing is gathering our content so we know what we’re working with.

For each of my projects, I’m going to have an image, the title of the project, a short description (1-2 lines), and some related stats.

I’m going to start working on my design by simply blocking off each project as a rectangle on the page. I like giving it a red outline so it stands out.

Because I want three projects on each row, each project will take up four columns. The gutter between the columns on my grid gives me built-in margins, so I don’t have to worry about figuring out how far apart my projects should be as we move across the page. That means my first spacing decision is out of the way. Nice!

You’ll notice there are two rows of projects and there’s space between them. Since I don’t yet have a system for spacing those apart, I’ve just eyeballed them for now. We’ll revisit that with a more intentional strategy a bit later.

For this issue, I’m going to focus on laying out only the first project. Then I can copy and paste that style to all the other projects.

Putting things in rows

You might remember from the wireframe issue that we talked about a very helpful idea in laying out content – every row should represent an idea.

So the next thing I’m going to do is represent the different pieces of content as different rows in my project. I’m not going to worry too much about their precise size for now – I’ll approximate that the two lines of the description are bigger than my title and the stats will probably be pretty small.

If we give each piece of content its own row, we end up with this:

Now it’s time to fill in those rows.

The first time I did this, I left the borders red and the background gray, but this actually made it really hard to see what looked good. After I’d finished spacing things out, I removed the border and the background, and things were way too spaced out! Because the borders add their own weight to the layout, they’re hard to design around, so it’s best to get rid of them first.

In fact, it’s a good idea to create a rectangle that’s close to what you actually want it to look like.

I know that I want a light border for my project with some slightly rounded corners and a white background, so let’s get rid of the borders and background and replace them with those style choices. I also made the grid a lighter pink so you can see the gray border better.

Now we’re ready to start placing actual text.

Placing the title

We’re going to start with our title. The first thing we have to do is determine its font size. Luckily, we have a typographic scale we’ve already come up with! We can use the values here to pick our font sizes instead of just making up numbers.

Here it is:

To pick the font size for my title I need to consider two things:

1. What heading level makes sense for something like a project title?

2. What’s going to fit all the letters into that small box?

As far as heading levels, the project title isn’t the most important thing on the page. It’s not the heading of the hero, which is usually our biggest font size and would therefore be a Heading 1, and it’s not the title of a section, which might be a Heading 2. So I would put it maybe in the middle, a Heading 3.

Let’s try that and see if that works.

Yikes, that’s too tight! Let’s go down one level.

That’s much better. That gives us some room to breathe.

Now I will note that this is a relatively short title. If my titles go on for three lines, I might come back and reconsider the font size, or try to make the title shorter. But this is a good starting point for now. Once we place all my other content, we’ll learn and iterate from there.

Now the question is, where in that little box should we put it? 

Right now, it’s flush against the image and the rectangle’s border and has no breathing room. Not good. We definitely want some margin there. The question is, how much margin?

You could just eyeball it and see what feels right, but let’s see if we can be more intentional.

Is there a system or tool we can use to help us with spacing?

Yes, there is!

We’re going to use the 8px scale to create a set of predetermined blocks that we can use to pick our spacing.

Let’s do a quick recap of the 8px scale.

The 8px Scale

The scale will provide us with spacing guidelines that start at 8px and adds 8px at each step. Since we’re using the scale for spacing, we’re going to create a series of squares with dimensions that are multiples of eight. To save space and make our squares a bit easier to use, after 64px, I’m using multiples of 16. We’re going to use these squares in our design shortly.

Here’s the first half of that scale so you get the idea:

You can keep going as high as you’d like. Tailwind’s spacing scale goes up to 384px!

Now that we’ve got this scale, we can start using it to help speed up our spacing decisions and create that vertical rhythm.

But first, a design break!

I’m super excited about Not A Designer’s January sponsor, Design Hacks, a newsletter run by incredible designer Erik D. Kennedy. Design Hacks helps you create better designs. It features short, original UI/UX tips & tactics. It’s read by over 50,000 people from Apple, Google, Stripe, and more. Check it out here.

Spacing the title

I know I need to add some cushioning around the title – I need to give it space both from the border and from the image.

So how much space should I give it?

Instead of picking a random number, I’m going to pick a number from my scale. I want a healthy amount of space, so I’m going to start with 24px from my scale. That means I’m going to grab my 24px box and put it in all the places where I want that spacing.

Here’s what that looks like:

That looks better, but it’s hard to tell with the boxes and the grid visible. So in Figma, I’m going to hide those tools so I can see how the spacing feels on its own.

Here’s what that looks like:

That actually looks pretty good! In one go, we’re done placing our title!

Now let’s place that description.

Placing the description

Let’s start by picking its font size, once again using my handy dandy typographic scale. This is going to be one of my body texts, so I have only three options (16px, 20px, 24px). I’m going to go with 20px and see how that fits in that box.

That fits pretty well! Once again, having only three predetermined options to choose from for font size made that an easy decision.

Now let’s figure out where to put it.

We want to align the description with the title so we know the spacing between the border and the description will be 24px. Great! All we have to decide is how far away from the title I want it to be.

This is where the proximity design principle comes into play.

Proximity tells us that the closer things are to each other, the more related we believe them to be. So if we want to convey the idea that title and description are related, we need to place them relatively close together. Since we already have them 24px away from the border, I’m going to pick a value less than 24px. Let’s go with 16px and see how that feels.

Here’s what that looks like:

Now let’s get rid of all our tools:

Hm, that feels too far away from the title. Let’s go down one and see how 8px feels.

And here’s without our tools:

Much better! Another spacing decision done!

Now let’s add in our stats.

Placing my stats

I have two stats I want to include for Not A Designer: my subscriber total and my open rate.

Let’s add those in at the bottom:

For our stats, I want to add a bit more styling to them first since that will impact my spacing. I’m going to style them like tags. I’m not going to worry about color for now (that’ll be covered in its own issue), but instead, I’m going to give them a light gray rounded border.

Now the question is, how much padding should I have around each stat? That’s a spacing question that can be solved with our 8px scale!

My tags are pretty small, so I’m going to use the smallest unit I have and go with 8px.

Let’s see what that looks like.

And here’s without my tools:

Hm. That’s ok, but feels too tall. I want that narrow, pill look.

This is where we introduce a new tool to our 8px scale – the 4px block. We’re going to make a square that’s just 4px big that can really come in handy when we’re dealing with smaller elements like labels, icons, and, in our case, tags.

Here’s what our tag looks like with that new 4px spacing.

And here’s without our tools:

Much better!

Now how far apart should the two stats be from each other?

Again, if we use our proximity principle, we want them pretty close together since they’re both conveying the same type of information. So I’m going to pick a conservative 8px and see how that feels.

Here it is:

And here’s without our tools:

Looks good!

Now we have to figure out where to put our tags in relation to our description. How far below it do we want it to be?

Let’s think for a moment. The proximity principle tells us we should be fairly close because they’re related content. However, I would argue that title and description are more closely related to each other than stats – stats are like bonus content. Title and description are the main thing. So I think it’s reasonable to have a bit more space between the description and stats.

The spacing between the title and description was 8px, so let’s make the space between the description and stats 16px and see how that feels.

Here it is:

And without our tools:

That looks pretty good!

Now there’s one spacing decision left – the space between the stats and the bottom border.

Luckily for me, I can use a previous decision and apply it here. I already decided that the spacing between my top border and my title was going to be 24px and it makes sense to have the spacing surrounding all of my text be consistent. When I code this up, that’ll end up being the value of my padding.

So let’s add 24px of space below my stats and see how that feels. This means increasing the height of my box, which is totally fine – it was an arbitrary height to start with anyway.

Here it is:

And here it is without our tools:

Now that’s got some rhythm!

It looks clean, well-balanced, and, best of all, we didn’t really have to think too hard or rely on our own creativity to lay it out. By using a scale and moving around some boxes, we were able to use predetermined numbers to quickly and easily pick values that create a great looking element.

If you want to use the 8px scale for spacing in your design and are using Figma, no need to create those boxes from scratch – you can use mine right here!

Writing this walk-through took quite some time because I’m breaking down each and every decision, but the process of actually using the scale and then making the spacing decisions took maybe a minute or two.

Using a scale like this is very new to me – I’m used to just eyeballing things and seeing what looks good and feeling very uncertain about my decisions. But picking from that predetermined list made the process so much easier and faster and also came with the added benefit of making me feel confident about my decision. I wasn’t just making things up — I was using a spacing system that is widely used in design by real designers. There’s a huge comfort in doing things the official way.

What do you think of the 8px scale for spacing? Reply and let me know!

Happy designing!

Saron

Today, we’re talking all about font sizes. We’re going to dig into how designers use systems to make their process easier, faster, and more cohesive and we can too! This is an introductory look at picking font sizes, but if you want to dig in deeper, you should check out this amazing resource by Erik Kennedy called, “Font Sizes in UI Design: The Complete Guide.”

This issue of Not A Designer is brought to you by Erik Kennedy of LearnUI, a REAL designer who used to be an engineer, has created design courses taken by thousands of students, and has his own newsletter, Design Hacks. Make sure to check out his stuff! 🤗

To determine where to place all of our elements and how far away from each other they should be spaced out, we used a scale.

But what about the size of our text? How do we determine that?

Your font size could be anything, and, having an unlimited number of options, it can be overwhelming to stare at a piece of copy and figure out how big to make it. And because our screens are usually filled with far more text than images, this becomes a super important decision.

One strategy is to just pick as you go. You’re working on the header? Pick a font size that “feels right.” You’re deciding on a paragraph? Pick a font size that “looks good.”

I’m personally not a fan of the pick-as-you-go option. I know that, in general, a safe paragraph font size is 16px or 18px, but beyond that, I have no idea how big things should be.

Instead, I want a system – something with a limited number of options that have already been decided for me ahead of time that I can just pick from. Picking from a set of, say, 10 font sizes is much easier than coming up with them on the fly.

To help us with that, we’re going to use what’s called a typographic scale.

But first let’s define what a scale is in this context.

What’s a scale, anyway?

A scale is essentially a set of predetermined sizes, in our case, font sizes, based on a single number.

To create that set, you first start with a base font size. Usually, that’s 16px since that’s the base font size for most browsers.

Then you pick what’s called a scale factor or scaling ratio. That’s a number that can technically be anything, but usually has a value between 1 and 2.

You take that scale factor and you multiply it by your base font size. The value you get is the next font size you can use for your text.

Then you multiply that font size by your scale factor again to generate the next font size you can use. Then you multiply that font size by your scale factor again to generate the next font size in your set. And you keep multiplying by your scale factor as many times as you like until you get a set of font sizes that cover your needs.

So how many font sizes do I need?

You can generate as many font sizes as you’d like by continuing to multiply by the scale factor and, to cover all your use cases in a user interface, you need quite a few. In general, you want font size options for your headings (usually six) and a set for your body (usually three).

If you think you might want some super large, funky text in your interface, you can create a set of display font sizes that are bigger than your six headings. And if you’ve got a lot of little labels and icons, you can create a set of font sizes just for your labels (usually three is enough).

How do I decide the number for my scale factor?

You can pick any number you’d like, but the good news is, you don’t have to! Luckily for us, there are popular typographic scales with their own scale factors that we can use.

There’s a great site called Modular Scale that lets you pick different scales and see the resulting font sizes. It’s created by Scott Kellum and Tim Brown. If you’re into music, you might appreciate some of their names.

The popular ones I came across include:

• Minor Second (scale factor: 1.067)

• Major Second (scale factor: 1.125)

• Minor Third (scale factor: 1.2)

• Major Third (scale factor: 1.25)

• Perfect Fourth (scale factor: 1.333)

• Augmented Fourth (scale factor: 1.414)

• Perfect Fifth (scale factor: 1.5)

• Golden Ratio (scale factor: 1.618)

The difference between these scale factors seem minuscule, but they actually do make a difference.

To illustrate, let’s look at Minor Second (scale factor of 1.067) vs. Minor Third (scale factor or 1.2). That’s a difference of just .133, not even half a decimal! What does that do to our font size options?

Let’s calculate them and see!

Here is the set of font sizes for Minor Second (1.067):

The smallest size is 13.17px and the largest is 30.6px.

Now let’s look at Minor Third (1.2):

Oh my goodness, look at that jump in size! For Minor Third, my font sizes start at 9.26px and end at a whopping 99.07px! Compared to Minor Second, going up one level is a major jump.

Just for fun, let’s look at the Golden Ratio, the one with our biggest scale factor (1.618):

We start at a value of 3.78px and by the time we’ve reached Heading 5, we’re already at over 100px! Sheesh!

So even though the differences in the scale factors are small and seem insignificant, they actually make a big impact on the font size choices you end up with. The smaller the scale, the smaller the incremental changes from one level to the next. The bigger, the more noticeable the differences will be.

Now for a design break!

Want to go in depth on your design skills with an experience designer? Check out Learn UI Design. It’s a complete video course in visual design. Learn to confidently create beautiful user interfaces for any site or app.

• 53 lessons

• dozens of assignments

• student community

Join thousands of students from around the world, including from top companies like Google, Meta, Apple, Stripe, and more.

I’m actually planning on taking the course myself, and no, I’m not getting it for free — paying full price. Join me!

So how do you pick which scale to use?

Picking the right typographic scale really comes down to what your interface needs. The higher the scale factor, the more dramatic the font size changes, which means if your interface comes with big, splashy headers, strong editorial, or creative flexibility, you might prefer the dramatic range of something like a Golden Ratio.

But let’s say, instead, you're designing the interface of a medical dashboard and it’s got tons of little displays, buttons, icons, and labels. You’ve got a lot of information that needs to stand out and font size is one of the tools in your tool belt. So you don't need big, dramatic changes – you need a nice selection of relatively small font sizes for all that information you need to display.

So when deciding on the scale, think about the kind of content you're displaying and what range would be the most appropriate.

If you feel like you have an “average” interface with some range but maybe not too much, a safe scale to go with is Major Second.

I picked that scale by watching this really great video of a designer, Tim Hoon Lee, who studied 45 top design systems of popular products and places including AirTable, Figma, Shopify, Uber, and Material Design. He wanted to understand what they had in common and extract insights and patterns from some of the most widely used ones.

One of the things he looked at was which typographic scale these systems used. Number one on the list was Major Second, with 75% of his selected design systems using it. It has a scale factor of 1.125. So if you’re not sure where to start, this seems to be a safe choice.

If we start with a base font size of 16px, let’s see what our set of font sizes would be for Major Second. To give us a nice range for our interface, we’ll go a few sizes lower than our base for our labels and add a few display font sizes too.

Here’s what we get:

This gives us a nicely balanced set of font sizes with enough of a difference between font sizes without there being a huge leap between them.

Now, I don’t know about you, but something about these values make me a bit … uncomfortable. All those decimals. While there might be some beautiful harmonies happening by using some simple but sleek math to come up with font sizes, decimal font sizes feel very awkward and unintuitive.

That’s not a problem specific to Major Second – all eight of those scales will give you decimal font size values. So what do you do?

I did some research to find out.

I checked out a few popular design systems from designsystems.com to see what they did with their decimals and I saw that they didn’t have any at all! There wasn’t a decimal insight!

I was confused – there’s so much information out there about all these typographic scales and how they give you these beautifully harmonious values with just the right font sizes – were these design systems just not using them?

I reached out to a designer friend to get to the bottom of this.

It turns out that theory and real world application are two different things, and the world is not as rigid as these scales. Rather than the guide being the definitive source for all font sizes, they’re often used as a starting point that you then tweak and perfect.

The easiest way to tweak it is to simply round all the numbers to the nearest whole number. That would certainly make me feel better. Then we have values that feel more natural and are easier to remember and reference, too.

In fact, that’s exactly how designer Priyanka Godbole picked her font sizes for her company, an electronic health record company. Her process was beautifully described in this great article featured in Figma’s design systems blog.

Her process was to round off in a particular way. Because her design system used a 4pt grid system, she rounded off to the nearest multiple of 4 so that it would be easier to work with. So the grid system you’re using might be another helpful consideration when dealing with those decimal values.

In the real world, these typographic scales are meant to give you a starting point, not be the destination. Depending on your comfort level, your expertise, and your own opinions, you can always switch things up and pick your own final values.

That’s pretty much what Tailwind did.

Instead of using a scale, they used their years of design and front end experience to pick a set of font values that seems to work well across different projects and interfaces and comes in a nice range. And because they picked their own numbers, they don’t have to deal with strange decimal values.

I’ve recreated the Tailwind scale here, categorizing it into the different types of text we might use.

Compared to the mathematical Major Second scale, you’ll notice that Tailwind’s set of font sizes has fewer options.

Because we used our scale factor to go as high (or low) as we want, our Major Second scale allows us to create as many font sizes as we want. We stopped at 14, but could’ve kept going. Tailwind is limited to just 11. Depending on how many styles you think your content needs, you might want more options than what Tailwind gives you.

Applying it to my personal site

Looking at my personal site, I don’t have a ton of information that needs to be laid out. My site is a bit lighter and more fun, so I’m going to go for a little more ‘drama’ in my scale, but not too much!

I want a noticeable jump between my text styles, so I’m going to go with our Minor Third guide. But I don’t like all those decimals, so I’m going to round everything off by multiples of four as well. That gives me numbers that I feel comfortable working in.

The only exception is in my Label 1. I’m going to pick 14px for that one since I’m limited by how small I can make my font sizes to remain readable and accessible. Just because a scale gives you a value of 6px, for example, doesn’t mean you should actually use it in your interface. You gotta think about accessibility as well!

Here’s what that gets me:

I’ve got my scale, now what?

Having a scale is a great starting point, but you still have to try things out, use your judgment, and see what makes sense. Let’s try applying my scale to the hero of my personal site.

My personal site has two pieces of text: the heading and the subheading.

The heading is going to be the biggest text on the page, so I’m tempted to use the Heading 1 value. But 68px seems pretty big. Let’s try it and see.

And then for my subheading, I want some nice contrast between that and the heading, so I’m going to try a Heading 4 and see how that feels. For my typeface, I’m going to keep it simple and stick with Inter for now.

Here’s my wireframe with those sizes:

That’s actually pretty good! It’s not so big that it needs a bunch of line breaks – the heading fits on one line and the subheading fits on two lines, which is what I want.

I was expecting to need a few iterations to pick the right font, but having that scale ahead of time and putting a little thought into the kind of content I’m working with made it super easy. Done in one go!

So how do you plan to approach font sizes in your next project? Reply and let me know! And make sure to let me know what you think of this issue :)

Happy designing!

Saron

We’re continuing our #notadesignernewyear challenge by exploring grids and spacing.

So far, we’ve:

• Picked our project

• Gathered and prioritized our content

• Laid out the main pieces of our design into rows

• Laid out our hero

I’m working on redoing my personal site. You can check out the journey so far, but if you’re just tuning in, no worries! You can jump in here.

In today’s issue, we’re digging into grids to help us figure out precisely where to put our elements. We’ll dig into rows and columns and a whole spacing system based on an 8px scale that’s going to be really helpful in making design decisions easier.

This issue of Not A Designer is brought to you by Erik Kennedy of LearnUI, a REAL designer who used to be an engineer, has created design courses taken by thousands of students, and has his own newsletter, Design Hacks. Make sure to check out his stuff! 🤗

Let’s begin!

So I’ve decided on a two-column layout for my hero. But where exactly do I put each element on the page? Where in my column does my heading go? How far away is the subheading? And how far away from that are my links?

For a lot of seasoned designers, this placement process is intuitive. They eyeball the spacing and go with what looks right for them. Indeed, the exact placement of elements is pretty subjective, but I still wish I had some guidelines to help me out. Luckily, there’s a tool that I’ve found really helpful in figuring out where to put things: the 8-px grid*.

*Note: You might also see this referred to as the 8pt grid. It’s the same thing, only we’re using pixels since we’re working with screens.

Intro to grids

Grids can be a really helpful way to bring structure to a page, and they aren’t just used in interfaces. They’re a common tool for all kinds of visual design – posters, graphics, paintings, you name it.

A grid has four key elements: columns, rows, gutter, and margin (note: this margin is not the same as the margin attribute in CSS. I’ll explain shortly).

Theoretically, you can pick whatever sizes you want for these elements, but because we’re using an 8px grid system for our interface, that comes with some standards.

Columns

We start by picking how many columns we want in our layout. We generally want 12 columns. Twelve is a great number for columns because it’s divisible by so many numbers – 1, 2, 3, 4, 6 – which means we can group them in many different ways.

If you have a collage of items, you can have them each take up two columns and fit six in one row. If you’re working with a two-column layout, like what I’m doing for our hero, that’s fine too! We can have each one be six columns wide. If we want a nice wide image but a more narrow text area, we can have the image take up nine columns and the text take up just three columns. So much flexibility!

Your column width is the one thing that we actually don’t want to set to a fixed number. As the window size changes from screen to screen, we want the width of our content to be able to accommodate those changes. Instead, we want to set our spacing, the white space outside of our content, according to our 8px scale.

So we’ll we set our column width to “auto” so that it scales with the size of the frame. One less size to worry about!

Gutter and Margin

But what about the gutter and the margin?

Our gutter is the space in between our columns or rows. For our columns, our margin is the left and right space between the edge of the screen and our set of columns. For our rows, our margin is the top and bottom space between the edge of the screen and our set of rows.

Here’s a diagram to illustrate:

Setting the gutter and margin is the first place where the number 8 comes into play.

8px scale

In an 8px system, everything spacing related is on the 8px scale. That means that your smallest unit will start with 8px, the next will be 16px, then 24px, and you keep going up by 8.

Here’s what the scale looks like:

On occasion, you’ll need something a bit smaller, like when dealing with icons, and you can go down to 4px for those scenarios. But in general, you’ll stick to 8px.

That means that when it comes to picking my gutter and margin values, I don’t have to make up a number – I can refer to this scale.

I don’t know about you, but this gives me a huge sigh of relief.

When you’re still pretty new to design, being given constraints to work within can, ironically, make you freer. It gives you a starting point and reduces decision fatigue. Making decisions becomes easier. Being forced to pick values from that 8px scale helps narrow down your options significantly.

So for our gutters and our margin, we’re going to pick a value from our 8px scale. But which do we pick?

Margin

Let’s start with the margin.

This is where we need to consider the content we’re working with.

For example, let’s say I’m designing something like the Dribbble interface with its grid of images. I want to fill my screen with as many images as possible. I need all the width I can get! That means that my margins are going to be more narrow.

If we measure the margins of this design, they’re about 72px on each side.

But if we’re designing something more narrow, like the hero of my personal site, there’s not a ton of things I need to make space for. I’ve got my photo on one side and my text on the other. To make sure my text is readable, I don’t want it to be too wide. So with all that in mind, I’m going to choose a bigger margin, something like 320px.

Gutter

Now for my gutters. We want something that lets the columns breathe, but just a bit.

For a bigger screen like a desktop, 24px is a value that came up a ton in my research, so let’s go with that. As our screen gets a bit narrower and we’re a bit more pressed for space, we can drop that down to 16px.

With 12 columns, a 24px gutter, and a 320px margin, here’s what my layout looks like so far on Figma’s Macbook Pro 16” frame, which has a screen width of 1728px.

Making this in Figma, a great, collaborative design tool I use for all my design work, is super easy. Let me show you how.

In the right panel, click the “+” icon under “Layout grid.” When you do, Figma defaults it to “Grid 10px.”

Click on the grid icon on the left and select “Columns” from the drop down.

Then fill in your values for count, margin, and gutter.

This is great because it gives us guidelines on where to place things moving across the screen.

But we’re not just laying things across the screen, we’re also laying them down the screen.

But before we dig into that, let’s take a quick design break!

I’m super excited about Not A Designer’s January sponsor, Design Hacks, a newsletter run by incredible designer Erik D. Kennedy. Design Hacks helps you create better designs. It features short, original UI/UX tips & tactics. It’s read by over 50,000 people from Apple, Google, Stripe, and more. Check it out here.

So how do we know where to place things as we move downwards?

You might think we need rows, but rows aren’t exactly the right tool here.

The problem with rows is that we’ll need to specify how many we need and we’ll need to give them a margin and a gutter too. These rows might be a helpful way to lay out large sections of our page, but that might change so I don’t want to hardcode that number just yet.

Instead, I want something that will help me place all the tiny rows of elements that make up each section. What we want are guidelines with a lot of flexibility.

Sometimes, we’ll deal with elements that we want spaced close enough together and only need a teeny bit of breathing room, like between our heading and subheading. Other times, we’re spacing out two sections that might need a bigger break from each other.

So how do we get a system that gives us that flexibility?

This is where the “grid” part of the 8px grid system comes in.

When you set up your columns in Figma, you may have noticed that it actually gave you three options of what to add: grid, column, and rows. In CSS, we use the term “grid” even when we’re just adding columns without the rows. To figure out how to space things moving down, instead of adding rows, we’re going to add a grid that has lines for both columns and rows.

By adding a grid, we’ll get guidelines for both rows and columns spaced a certain number of pixels apart going all the way down and all the way across. We don’t really need the column guidelines since we already specified our columns, so will just use the row guidelines.

Since we’re using our 8px spacing system, we’ll space the guidelines exactly 8px apart.

Let’s add that now.

With this grid, I know that the smallest amount of space between two elements is going to be 8px but it can get as large as I want! Wonderful. That gives me both constraints to get going in addition to that flexibility that I need.

But I’ve still got quite a few values to pick from. How do I choose the right one?

This is where we introduce an important design principle that can help us out: proximity. This principle states that when two elements are close together, we assume they are related. The further apart, the less related we think they are.

Let’s use an example to illustrate.

In my hero for my personal site, I’ve decided on a two-column layout: one for my text and the other for my image. In the first column, I have my name, the subheading, and my social links.

How do I use the proximity principle to determine their spacing?

Well, I know that the content of those three elements are pretty tightly related, so I want them to be visually close to each other. So on my 8px spacing scale, I want to pick something on the small end. Let’s pick 16px and see how that feels.

Here’s what that looks like with the columns and grid.

And here’s what it looks like without the columns and grid.

Not bad, but I think we can do better.

We’ve determined that the three elements are all related to each other, but they’re not equally related. I would say that the heading and subheading are more closely related to each other than they are to the social links.

So if I use the principle of proximity to inform my spacing further, I would keep the spacing between the heading and subheading at 16px and increase the spacing between my subheading and my social links. That way, my heading and subheading will feel like a little group, separate from the links. Let’s try that and see how it feels.

Here’s the version with the columns and grid.

And here’s the version without the columns and grid.

I like this better. It feels like a small change that packs a punch. It’s more organized, more intentional. The difference in spacing allows me to communicate the way the different elements are related. Doing it on an 8px scale made picking the spacing easier. Are two items more related? Go lower on that scale. Are they less related? Go up.

Now it’s your turn. Try laying out the hero of your project using an 8px grid system.

Do that by going into Figma and:

• Setting up your columns: Go for 12 columns, a 24px gutter if you’re on desktop (16px for mobile), and determine your margin (still on our 8px scale) based on your content

• Set up your 8px grid so you have guidelines for the vertical spacing

• Use the principle of proximity to determine your spacing between elements, still using the 8px scale

I will say that using a grid or a column system isn’t mandatory. In fact, Erik Kennedy isn’t a big fan of them. He thinks of grids as a tool that helps with alignment more than anything else. But I find that when I don’t know where to place things, columns and grids give me a starting point by narrowing down my choices and making the decision a lot easier.

So if you end up using a grid system for your design, let me know how it goes!

Happy designing <3

Saron

If you know what song the subject line is from without looking it up, good for you! It was one of my favs growing up 🙂

We’re continuing on our #notadesignernewyear challenge by redesigning a site of our choosing.

So far we’ve:

• Picked our project

• Gathered and prioritized our content

• Laid out the main pieces of our design into rows

In today’s issue, we’re laying out our hero, the section under the nav bar, arguably the most important part of our website. We’ll walk through three common layout options for the hero (with examples, of course), discuss their pros and cons, and walk through a real life example from a recent project I launched.

This issue of Not A Designer is brought to you by Erik Kennedy of LearnUI, a REAL designer who used to be an engineer, has created design courses taken by thousands of students, and has his own newsletter, Design Hacks. Make sure to check out his stuff! 🤗

Alrighty, let’s get started!

I recently had to design a hero, that first row of content below our nav bar, for my newly launched project, Big Cash Money 2024. The hero is the introduction to the whole site; It’s the first thing the user sees and can get them to either stick around or leave.

Big Cash Money 2024 is all about reaching big financial goals this year and I wanted the hero to be bold and attention grabbing. But I gotta admit, it was a struggle.

I didn’t really have a process. Instead, I had a vague idea in my head and put pixel to canvas and just started placing things. I freestyled it; something I do not recommend. Since we’re still early in our design journey, it’s much easier to start with more structure and a plan.

The first attempt looked ok, but not great. I kept iterating and, eventually, got it to a place I was proud of, but it took a while.

Let’s break down what was wrong with it, how we can make it better, and what process you can use to design a great hero.

Attempt #1: The Freestyle

I started by gathering my elements. Our hero generally has four elements: an image, a heading, a subheading, and a call to action (CTA).

Here were mine:

• Image: I found a great image of a pig rockin’ some cool shades

• Heading: The title of the project, “Big Cash Money 2024”

• Subheading: “This will be your biggest financial year yet.”

• CTA: A button that said “Apply to join”

Here’s what my first attempt looked like:

It’s ok, but it’s not great. Let’s see what we can learn from it.

A good way to sharpen our design eye is to critique the work of others. So before we keep going, take a moment to examine this design and reflect on what doesn’t feel right about it.

Thought about it? Great! Here’s my analysis:

• Is it the typeface?

  At first, I was stumped by the typeface. I wanted the Big Cash Money 2024 part to feel as loud and bold and fun as the words themselves, so I started with one of my favorites, Cabin Sketch. But I wasn’t sure it was the right pick.

  
  I knew I wanted a simpler typeface for the subheading, something that was super readable, so I went with the classic Inter for that, but I wasn’t convinced that it went well with my Cabin Sketch selection.
  

• Is it the layout?

  In this freestyle, I was mixing layouts. I kinda had a two-column thing going on by positioning my image and heading next to each other, but the subheading and the call to action were both centered. This mixing of layouts wasn’t intentional – it just kinda happened. And I wasn’t sure it was working.

Instead of trying to freestyle my layout, I decided to research a few commonly used layout options and choose one of those.

The Center layout

Here’s a simple, but beautiful example of a landing page for a portfolio site with a centered hero.

This was created by designer Yassine on Dribbble, a marketplace for designers to showcase their work and get hired.

Let’s break it down. As we consider its different elements, I added some questions I ended up asking myself to help me process what I was seeing. Take a moment to use them to reflect on your own #notadesignernewyear project as well.

• Photo

  In this center layout, the photo plays a relatively small role. While it’s the first thing you see on the page, its actual size isn’t very big. It’s pretty easy to set aside and ignore as your eyes keep scanning.

  
  Reflection: What role do you want your photo to play? Is it a big, bold photo that you want to call attention to, or do you want it to play a more secondary role? If the answer is secondary, the centered layout with the top rounded photo might be a good option.
  

• Heading 

  We talked about our typical hero having four pieces – heading, subheading, image, and call to action – and in this layout, the star of the show is definitely that heading. In fact, it’s more of a full-on sentence than the few short, punchy words that usually make up a heading.

  
  Reflection: When it comes to your content, what kind of heading do you have? If you have a bold statement or a powerful thought you want to grab your users with, maybe a center layout makes sense.
  

• Height

  Another consideration is height – how does this layout affect the length of your page? Because the atoms are stacked on top of each other with every atom taking up its own row, the hero ends up being rather tall.

  
  Reflection: If you have just three of four sections on your page, maybe that’s not a big deal. But if you have more than six, that’s going to end up being a ton of scrolling for your users. If conserving space is important to you, this might not be the right layout. How many things are you stacking in your website?

So what do you think?

Left-align, background photo

This is another hero from Dribbble designed by the team Nija Works.

While I’m generally not a fan of putting the call to action on the opposite side of where you’re reading since it breaks up the flow, I think this is a great example of what effect a full-image layout can have on a site.

Let’s unpack it.

• Photo: Using a photo as the background really makes you focus on the image. It’s not just that it’s a big photo, it’s that it takes up 100% of the space. That means that the subject of the photo captures your attention while the rest of the photo sets the tone for the whole site.

  
  While I’m looking at the woman, the fields of grass in the background are also putting in work – they set the color scheme rooted in green and natural colors and give me a whimsical feel.
  

  Reflection: Is center stage the role you want your photo to play? Is the subject worthy of that kind of focus and attention? Do you want the rest of the photo to set the visual tone for the site?
  

• Heading: Because of all of the attention the photo takes, the heading feels like more of a caption to the photo than its own idea. It feels more secondary, far less important than in our center layout. If you want to draw attention to your photo and treat the words as supplementary, making it the background might make a ton of sense.

  
  Reflection: What role do you want your heading to play in relation to the photo? Is it more of a caption or should it be the main focus?
  

• Call to action: Such a heavy emphasis on the photo means deemphasizing everything else on the page, including the call to action.

  
  With such a gorgeous photo, I feel like I’m looking at a magazine more than a website, and the way I interact with magazines isn’t by clicking – it’s by browsing. As the user, this layout makes me more inclined to keep scrolling and take everything in. I feel less ready to click on the call to action.
  
  Reflection: How important is the call to action to you? Is it ok if you end up encouraging people to browse instead of click?

So what do you think about this left-align, background photo layout?

Two-column classic

Lastly, we have the classic SaaS hero. This one in particular was designed by Ahmad Fawaid. You’ve got two columns, one for your text and the other for your image. It’s simple, it’s clean, it gets the job done.

Let’s break it down.

• Heading

  In this layout, it’s the heading that gets your attention first. But unlike the center-aligned layout, I don’t feel the pressure to fill the space with a long, thoughtful sentence. There’s less room, so I can paste something short, like a title, and it still works.

  
  Reflection: What kind of heading are you working with? Long and flowy, or short and sweet?
  

• Graphic

  The image feels like less of a focus and, instead, serves to balance out the space – you give the reader some work to do by offering text to read, then you treat their eyes to a nice image. The image should still be good, but it’s more secondary.

  
  Reflection: What role does your image play? Is it the star of the show, or more complementary?
  

• Height

  Because I’m utilizing two columns, I don’t have to worry too much about a height that’s too big. My elements are placed side by side, which means a shorter height and valuable space saved.

  
  Reflection: Is space saving important to you or do you have more flexibility in that department?

For more hero inspo, go to Dribbble and search “hero section.” You’ll find tons of great examples from really talented designers, and you’ll see that most heroes are some variation of the three layouts we discussed above.

Think about your goals for your site, what you plan on using for your heading and image, and pick the best layout for your hero.

Before we get back to our project, a quick break!

I’m super excited about Not A Designer’s January sponsor, Design Hacks, a newsletter run by incredible designer Erik D. Kennedy. Design Hacks helps you create better designs. It features short, original UI/UX tips & tactics. It’s read by over 50,000 people from Apple, Google, Stripe, and more. Check it out here.

Back to Big Cash Money 2024. Which of these layouts should we try?

Attempt #2: The Two-Column Classic

I’m going to go with the two-column classic and see how that feels.

Hm, let’s dissect it piece by piece.

• CTA: The call to action is pretty standard – slightly rounded border, bold text, good contrast. That looks just fine.

• The image: The pig looks great and it’s sized at the same height as the copy on the right so everything aligns well. No issues there.

• Text: The juxtaposition of that heading and subheading are really bothering me. The problem we identified earlier about the typefaces is super obvious now that we put them right next to each other. Those typefaces don’t go together at all!

But it’s not just the typefaces, it’s the font sizes too.

If we look at the previous examples of the three layout styles, we’ll notice that there is a drastic size difference between the heading and the subheading. The heading is pretty large, drawing all the focus, and the subheading is closer to a paragraph-styled 18px.

Here, we’re using 64px for the heading and 32px for the subheading. That might sound like a big difference, but it’s not different enough, creating competition between the two. It’s not clear what you’re supposed to pay attention to – they’re both pretty loud.

This is where we take a step back and ask a deeper question, a content question – what is the most important thing to communicate to the user, “Big Cash Money 2024” or “This will be your biggest financial year yet”?

I would say that, since the url is bigcashmoney2024.com, they already know the name of the project. By the time they get to the page, the name isn’t actually all that important.

But that subheading? That’s the message I want you to remember. That big, bold declaration of how great this year is going to be. It gets you to think big. It gets you excited, hopefully excited enough to apply. That’s the good stuff.

So what do we do with that?

One thing we can do is get rid of Big Cash Money 2024 entirely and just make it part of the header and promote the subheading to be the new heading of the hero.

Let’s try that and see how it looks.

I don’t know about you, but I think that looks so much better. It’s cleaner, more focused.

That Cabin Sketch typeface for the title definitely doesn’t work for small font sizes, so we’ll need to change that, but since that’s now part of the header, we don’t have to worry about that right now.

So let’s assess where we are.

We’ve decided that we want to focus the user’s attention on the new heading – that big, bold statement that hopefully will entice people to apply. That’s the most important thing.

If we’ve determined that message is top priority, is the two-column layout the best way to bring that message home?

Based on our earlier analysis of the three layouts, the center layout is best suited for when we want the heading to really stand out.

Let’s give that a try.

Attempt #3: The Center Layout

That center layout helps us focus on our message by deemphasizing our image, and while I love that pig, it did feel like it was taking up a bit too much space and attention in our two-column layout. I want it to play a more supplemental role.

Let’s try a center layout and see how that looks.

Ahhhh, much better. That big, bold message commands your attention, and the pig adds a touch of personality without drawing too much focus.

But the one thing I want to change is the heading’s typeface. It’s just too bland compared to the personality and fun of the pig. We need to bring some funk to the mix, but still make it readable.

Luckily for me, I’ve already researched and picked six typefaces that have a touch of flare without sacrificing readability.

My favorite in that list is Anek Bangla. Let’s see how that would look.

Perfect. That touch of flare really goes a long way!

This final hero design looks much better, but it took a while to get here.

How could we have shortened the process?

Instead of freestyling my design, here’s what I can do next time instead:

1. Gather all the content I wanted to include in the hero

2. Determine what the most important element was (for me, it was the new heading)

3. Decide which of the three layouts best caters to that element (the center layout emphasizes the heading the most)

4. Try it out and see if it works

5. Iterate from there

And just like that, you have a step-by-step process for approaching your next hero section. If you want a hero section that spices things up a bit, check out Erik’s twitter thread of ideas for making it really stand out.

I hope this breakdown and analysis of the hero was helpful. Let me know what you think!

So, what does your hero look like? If you’re taking on this challenge, send me your wireframes, I’d love to see them!

And if you’re interested in applying for Big Cash Money, make sure to apply before it closes this Friday, Jan 12.

Next time, we’ll look at laying out the rest of the page and maybe get into grids and spacing. 👀

Happy designing!

❤️ Saron

I’m excited to continue the #notadesignernewyear challenge with you! 

If you’re new to the challenge (or to this whole newsletter), welcome! Let’s get you caught up:

So far we’ve:

1. Picked our redesign project – for me, it’s redesigning my personal site (yikes)

2. Gathered our content – at the bottom of the last issue, I made a list of all the content I want to include. I organized them based on the Atomic Design framework – I’ve got my atoms (the most basic element on the page, like a label), my molecules (a collection of atoms, ex: a form), and my organisms (a collection of molecules, ex: a newsletter signup call out)

In today’s issue, we’re going to dig into laying out content and beginning to wireframe.

When you’re done reading, take the poll and let me know if it was helpful!

I’m also excited to announce that this issue of Not A Designer is brought to you by Erik Kennedy of Learn UI Design. He’s a REAL designer who used to be an engineer, has created design courses taken by thousands of students, and has his own newsletter, Design Hacks. Check it out!

Ok, let’s dive in 🙂

You’ve got your content. Now you’ve gotta decide where to put everything.

That’s where a wireframe comes in.

Wireframes can be super detailed or as chill as a marker and some sticky notes. You can use software that specializes in it, like Balsamiq, or just grab some Post-It goodness.

But watching tutorials on how to wireframe, it feels like people just intuitively know where to put things. With little thought or explanation, boom, a section is perfectly laid out and they move on.

I don’t know about you, but I need more structure than that.

So we’re going to break down our wireframing into three steps:

1. Ordering the content

2. Laying out the rows

3. Laying out the organisms

Ordering the content – does this go next?

Websites are generally laid out from top to bottom. So before we can start on a wireframe, we need to first lay out the order of our content.

For this, we need to answer two key questions:

1. What are our goals?

2. What action do we want users to take?

In thinking about my site, I have three goals I’m trying to achieve. Here’s how they break down in order of priority:

Goal #1: Read about my background
User Action: Sign up for my newsletter

My primary goals are to introduce myself, tell people about my background, and build a mailing list of folks I can update on what’s going on in my professional life. This means my bio and personal newsletter are top priority, so after I get my hero out of the way, I’ll start the meat of the site with that.

Goal #2: Get people to understand my work
User Action: Reach out

After that, I want a place to really showcase the things I’ve built and give people a chance to know my work better, so next up are my projects. I’m trying to take my speaking career more seriously this year and I’m hoping that reading all these cool projects will make people want to book me as a speaker, so the speaking section will come next.

Goal #3: Impress people
User Action: Consider working with me

To provide some external validation to my work, next I’m going to show the logos of companies I’ve partnered with. Then finally, I have a list of fun facts about myself I want to include, which are interesting and hopefully leave a good impression, but are not super important. I’m hoping these will seal the deal on wanting to work with me.

Great, I’ve got an order ready to lay out! Now it’s your turn.

Activity: Go through the list of content you want to include for your site and put it in order, optimizing for your goals and what actions you want visitors to take.

Done? Great! Let’s keep going. But, first, a quick break.

I’m excited to introduce you to Not A Designer’s very first sponsor, Design Hacks, a newsletter run by incredible designer Erik D. Kennedy. Design Hacks helps you create better designs. It features short, original UI/UX tips & tactics. It’s read by over 50,000 people from Apple, Google, Stripe, and more. Check it out here.

Laying out the rows

Of everything I learned on how to wireframe and lay out content, I still felt like I didn’t know where to begin. I was staring at that blank canvas wondering where to put that first pixel.

But there was one video that gave me what I needed most – a starting point.

It began with a very simple proclamation:

Everything is a row and each row should contain a single idea.

What a powerful way to simplify things and give us an entry point!

We can use this proclamation to look at our freshly ordered list of content in a whole new way.

You see, your list isn’t just a collection of content about you – each top-level item is actually a single idea, which can be visually represented in a single row.

So to start laying things out, I can map each top-level item to a single row in my wireframe. That row will take up the whole width of my site (I’m not going to worry about how many pixels yet), so I can start wireframing my website by blocking out rows for each top-level item.

Based on what kind of elements are contained in each top-level content, I’m going to estimate how much space I need for each row – sections with tons of content will be taller and sections with less content, like a nav bar, will be shorter.

I’ll end up with something like this:

Activity: Now it’s your turn. What do your rows look like?

Laying out the organisms

Last issue, we talked about the pieces of our content in terms of Atomic Design and how each top-level item can be thought of as an organism. So when we lay out our wireframe, each row actually contains an organism, and organisms are made of molecules (ex: a form) which are made of atoms (the smallest units like a label, input field, or heading).

So the next thing I’m going to do is take my content list and place the molecules and atoms into their corresponding rows in my wireframe, representing them as rectangles.

I’m going to guess how much space I’ll need based on how long each piece of content is likely to be, and I’ll size the rectangles on my wireframe accordingly.

For sections with repeating molecules, I’m just going to place one molecule. I’m not going to worry about spacing or exact sizes (we’ll do an issue on columns and grids soon), I’m just getting all the content down on the page.

Here’s what I end up with:

This isn’t the final placement of the content.

It’s just a way to gather all the pieces and see what we’re working with. It’s a helpful intermediate step before finding a final place for each piece.

Take a moment to reflect on this layout.

What are some things that stand out to you? What’s drawing your attention?

Just by seeing all the pieces laid out in front of me, I’m starting to form some ideas of where I might put some text, how different pieces might work next to each other, noticing their estimated sizes and how much space I have available.

Instead of doing all that work in my head, I can see what I’m dealing with and start to make connections. If you’re just beginning to learn wireframing, this can be a really helpful step. It certainly was for me.

Next, we’ll move into proper wireframing territory.

Let’s decide on some structure for each organism. We need to find a good place for all of our little elements. We’ll begin at the top and work our way down, starting with our nav bar.

Nav bar

The most common way to lay out your nav bar is to put your logo or site title on the left and all nav items on the right. You make sure your nav items are evenly spaced (we’ll get into spacing in a different issue) and call it a day. Easy!

But here’s the problem – I don’t really have a logo for my personal site.

And while I could just put my name there instead, I was already planning on using my name as the heading of my hero and I don’t want it there twice. So the left-right nav bar isn’t a great solution for me.

If all I have are the nav items and no logo or title, the other option is to simply center align my nav bar. I think I like that idea! Let’s go with that for now and we might revisit it later.

Let’s go ahead and center align our nav bar items.

Perfect! One row of our wireframe is done.

Activity: It’s time to lay out your nav bar. What will you go with? If you’re taking on this challenge, reply and let me know!

Now that we’ve got one down, next issue we’ll move into something a bit more complex – the hero.

In the meantime, check out this popular twitter thread on laying out content from Erik. It’s a great breakdown with tons of examples of how a simple rule of thumb can make your designs so much stronger.

What to take away from this issue:

• When you’re new, really break it down – start with a bulleted list, then order it, then lay out the rows, then wireframe each row at a time. Take it one step at a time. You don’t have to do it all in your head.

• Put all the pieces in front of you – the more you can gather all the parts and see them laid out, the easier it is to see how things should be put together and where they ought to go. Things become so much clearer that way.

Hopefully this breakdown was helpful to you! Let me know what you think 🙂

Next week, we’ll look at laying out the hero, the centerpiece of our whole site.

See you then and happy designing!

❤️ Saron

PS. I just launched a new project called Big Cash Money 2024 👀. If you have big plans to maximize your money through different revenue streams this year, check it out and apply by Jan 12 :)

The first step of a site redesign is figuring out what’s going to be on the site. Which means that before we can think about design and style, we have to first think about content – the star of the show.

If you’re working on a portfolio or personal site for your New Year's redesign, that means reflecting on your background and experience.

I’ve been in tech for over a decade and have done a fair bit in that time. I’ve worked as a developer, bootstrapped a business to acquisition, launched a VC-backed startup, produced podcasts, done a ton of speaking – there’s a lot of stuff I could potentially add to my personal site.

I find the whole thing a bit overwhelming. I’m not really sure where to start.

So instead of brainstorming from a blank page, I’m going to reference websites of awesome tech people to get my juices flowing.

Here are the five people I chose:

• Cassidy Williams

• Kent C. Dodds

• Jason Lengstorf

• James Quick

• Ankita Kulkarni

A quick glance at these websites might be enough to give you some ideas of what you might want to include in your site, but let’s go deeper.

I’m going to break down these reference sites through the lens of atomic design, a framework popularized by Internet-famous designer, Brad Frost.

He offers a way of looking at interface design that I really love. Here’s the breakdown.

Atoms

At the most granular level, interface designs can be broken down to their bare elements, which he calls atoms. Taking inspiration from chemistry, atoms are the smallest unit you can find on a website. I’m talking buttons, headings, paragraphs, labels, inputs, etc.

Molecules

A step up from atoms are molecules, which are a few atoms put together. In the world of user interface, that’s what we get when we collect a few elements to create a functional unit. A label, an input, and a button brought together to make a form are a great example of a molecule.

Organisms

Put a bunch of molecules together and you get an organism. For us, that means taking that form and adding a heading and a paragraph to create a callout to sign up for your newsletter.

Templates

Going up another level, we get to templates. This is where our organisms have order and organization. We think about columns, different sized widths, and prioritization. We’re not just connecting our organisms, we’re creating relationships that tell a story and bring users on a journey.

Page

This is where we fill in the templates with real content and start to bring our site to life. We paint the picture adding real photos and real copy, even if it’s a first draft. This helps us see how everything works with a higher fidelity. We get to test out our design with real information, seeing it in action.

We mentioned how three of the above items come from the world of chemistry. The benefit of using these particular chemistry concepts is that there is a known relationship between them. We all know that atoms make up molecules that make up organisms. There’s hierarchy built in. That helps us understand how the items on our page are connected to each other. There’s an inherent organization.

So how do we implement this atomic design? What do we do with this information?

That brings us to our first activity.

Activity 1: Red Box Breakdown

In this activity, we’re going to slice up our reference sites and identify their atomic units. To do this at home, follow these steps:

1. Make a list of 3-5 personal sites you want to reference.
   
   It’s more helpful if you pick people with a similar background or at least those who are in the same industry so that their content is relevant to you. I recommend picking at least three so you have options to choose from.

2. Take screenshots of the reference sites.

3. Open Figma (it’s free!) and create a frame. Make it huge. Then copy and paste the screenshots into the frame.

4. Use a red box to outline the different organisms you see on the site. Feel free to pick just the organisms that are most relevant to you.

5. Use a green box to outline the molecules.

6. Use a yellow box to outline the atoms.

When you’re done with steps 4-6, you should end up with something like this. This is James’s site.

7. In a document (I just use Google Docs), make a list of the different organisms with their corresponding molecules and atoms. Here’s what my list for James’s site looks like.

• Header

  • Name

  • Nav bar

    • About, Blog, Speaking, Courses, Podcast, Discord

• Hero

  • Copy

    • Intro

    • Tagline

    • Buttons

      • “Get to know me”

      • “Work with me”

  • Photo

• Socials

  • Social info

    • Handle

    • # of followers

  • Links

    • YouTube icon

    • Twitter icon

    • TikTok icon

    • Discord icon

• About

  • Header

    • Section heading (“About me”)

    • Tagline

  • Copy

    • Bio (multiple paragraphs)

    • Button (“Learn more about me”)

  • Graphic

• Work experience

  • Section heading (“Work experience”)

  • Company logos

    • FedEx

    • Microsoft

    • Auth0

    • PlanetScale

• Speaking

  • Copy

    • Section heading (“Speaking”)

    • Heading

    • Description (1 paragraph)

    • Buttons

      • “Previous talks”

      • “Invite me to speak”

  • Testimonial

    • Quote

    • Photo

    • Name of recommender

• Newsletter

  • Copy

    • Logo

    • Heading

    • Description (1 paragraph)

  • Sign up form

    • Input field

    • Button (“Sign me up!”)

8. Review your list and cross off anything that doesn’t apply to you or that you’re not interested in including. Highlight anything that you’d like to include.

At the end of this activity, you should have your juices flowing with things you might want to include in your site.

I love this activity because it removes all the intimidation of creating something well designed. As non-designers, fancy designs look great but can feel inaccessible.

But turning that pretty screenshot into a simple list of organisms, molecules, and atoms is a great reminder that these are just pieces that we are capable of putting together too. The building blocks are familiar. Nothing here is new or innovative. We just need to figure out how to assemble the pieces.

Even the prettiest portfolios and the fanciest websites are just made up of atoms – elements that are mixed and matched to tell a story and share some information. If they can mix and match a bunch of elements to make them look good, so can we!

Now that you’re properly inspired, you’re ready to come up with your own list.

Activity 2: Organism Brainstorm

It’s time to brainstorm.

In that same document, start writing a list of organisms you want to include in your app. Take the best ones from the previous activity, add new ones that come to mind, review and refine. Don’t worry about order just yet.

This is the list we’re going to work from. Now fill in those organisms with molecules and atoms you might want to include. Again, use your reference screenshots as inspo and add your own ideas.

Here’s what mine looks like:

• Nav bar:

  • Newsletter, bio, speaking, projects, work together

• Hero

  • Name

  • Description (1 paragraph)

  • Socials (row of logos)

  • Photo

• How to pronounce my name: 

  • Heading

  • Description (1 paragraph)

• Bio

  • Heading

  • Bio (multiple paragraphs)

• Newsletter:

  • Heading

  • Description (1 paragraph)

  • Form

• Projects

  • Not A Designer

    • Graphic

    • Description (1 paragraph)

    • Key stats

  • CodeNewbie Podcast

    • Graphic

    • Description (1 paragraph)

    • Key stats

  • Codeland

    • Graphic

    • Description (1 paragraph)

    • Key stats

  • Command Line Heroes Podcast

    • Graphic

    • Description (1 paragraph)

    • Key stats

  • Basecs Podcast

    • Graphic

    • Description (1 paragraph)

    • Key stats

  • CodeNewbie Challenge

    • Graphic

    • Description (1 paragraph)

    • Key stats

  • Dear Flatiron

    • Graphic

    • Description (1 paragraph)

• Speaking

  • Heading

  • Photo

  • Description (1 paragraph)

  • List of past conferences

  • Button (“Book me”)

• Companies I’ve partnered with

  • Heading

  • Logos:

    • Microsoft

    • GitHub

    • Flatiron School

    • MongoDB

    • Flatiron Health

    • Red Hat

    • Qualcomm

• Let’s work together

  • Heading

  • Description (1 paragraph)

• What people have said about my work (testimonials)

  • Heading

  • Screenshots of tweets + LinkedIn posts

• Fun facts

  • Bulleted list

    • Born in Ethiopia, proud immigrant

    • Based in San Diego and absolutely loving it

    • Tried to raise $500K and ended up raising over $2M in venture capital in two months 

    • Was a biochemistry researcher and a published author on DNA detection methodologies

    • Wrote the foreword of the 20th anniversary edition of the iconic Pragmatic Programmer

    • Worked at NPR and booked Boyz II Men and got a private concern for our team

    • Once auditioned for Debbie Allen for her production of Annie

This is a solid starting point for gathering the content that we’ll design later. Next, we’ll need to organize this information and lay it out in a template, finally dipping a toe into our design pool.

This is where we talk about layout and information architecture – that’s coming up in the next issue.

How to apply what we learned:

• When you’re struggling to find a starting point on a new design, it’s helpful to reference other apps and sites for inspiration.

• When studying a site for inspiration, try breaking it down through the lens of atomic design. It’s a helpful way of understanding how to put different pieces together. That means starting by identifying the atoms, molecules, and organisms.

• Before designing anything, make a list of your own organisms to include and their corresponding atoms and molecules so you can get a good sense of content before thinking about style.

If you’re participating in #notadesignernewyear, share the results of your activities with me, I’d love to see them! You can either post on social with the hashtag or reply to this email. And if you want feedback, let me know :)

Happy designing!

Saron

I don’t know how your personal site looks, but mine is a hot mess.

It’s painfully out of date and does a terrible job of showcasing who I am and what I’m currently up to. I’m hoping to do some consulting work and book more speaking engagements next year, and I need a site that reflects that.

So it’s time for a redesign!

But this time around, I want to do it more thoughtfully and with intention. I want to create a cohesive and consistent design and use it as a learning opportunity.

So instead of just picking a template or selecting pieces from a component library, I’m going to create one of those design systems I hear so much about.

Which means I should probably learn what a design system is and how to use one.

I’ve been reading posts and watching videos about design systems and the information I’ve come across makes the whole thing sound more complex than I’d hoped.

Let’s break it down and simplify it together, starting with a definition.

What’s a design system?

A design system is a playbook for how an interface should look and work. It generally contains (at least) two key categories of information: components and guidelines.

The components section explicitly lays out what the elements should look like. This is usually a document or set of pages that shows every color, type of heading, button, input field, and every other element the site might use, laid out with examples and sometimes a description explaining what you’re seeing.

Here’s a screenshot of the Material 3 design system that shows you the range of button styles used in that system.

The buttons represent one of the many components in the system, but to use them properly, you need guidelines.

A great analogy that I read was that using the guidelines is like putting together a piece of furniture: the components are the parts of the furniture, but you still need the instruction manual to know how to put it all together.

Sometimes these guidelines are full-on documentation, like the following screenshot from the button guidelines of the Material design system.

The button guidelines break down things like the anatomy of a button, decomposing it to its tiny bits, leaving little room for ambiguity.

It provides tons of examples of different types of buttons – elevated, filled, filled tonal, outlined, and text buttons.

Just as importantly, it shows you when to use each one. It’s one thing to know what an outlined button looks like, but how do you know that it’s the correct button to use? What’s the right context for an outlined button?

We can use the guidelines to find out.

Based on this, we should ask ourselves how important the action we’re asking the user to take is, and use that to determine the type of button to use.

If it’s a primary action, then we should use something else. But if it’s a secondary action, like the “back” button shown in the screenshot, then an outlined button is likely the right pick.

But design isn’t static – it moves and breathes with every click and scroll, and our guidelines can help us know what to do when the screen changes.

There’s a helpful section in the Material guidelines called “Responsive layout” that tells us how our buttons change with our screen.

Take a look at this excerpt.

It tells us how our buttons should behave in the context of a card or dialog, giving us one less decision to worry about.

But design systems don’t just stop at components. Many of them encompass brand identity, content guidelines, writing style guides, and much more, with the goal of creating a consistent and cohesive user experience. They even offer coding documentation and show you how to implement these styles on the front end.

For a look at other examples of design systems from popular companies, check out this incredible repo from Figma.

The Material design system is extremely thorough and, to be honest, a little overwhelming. It’s very well organized, but you need to know what’s going on your page for it to be useful. Before you decide which type of button to use, you need to first decide that you need a button at all.

Design systems are great at telling you how something should look once you’ve determined the overall structure, but you have to start with the structure.

But first, content structure

I was reading the book Atomic Design by the popular designer and teacher Brad Frost, and he included a helpful quote from designer Mark Boulton that made a ton of sense to me:

Mark said, “You can create good experiences without knowing the content. What you can’t do is create good experiences without knowing your content structure.”

Intuitively, I get that. Before I style the form, I need to first decide that I need a form. For experience purposes, what the form is about doesn’t matter so much. What matters most is the fact that I need one. Same thing with headings and paragraphs – before I can pick a typeface, I need to first determine that I need a heading and paragraphs. What the heading and paragraphs say are secondary.

This is great because it means we can use a lot of placeholder content and still design a great experience. That helps us determine the structure without needing to gather all the graphics and final copy just yet. We can worry about filling in the structure later.

When you’re designing an app with tons of components and dozens of types of pages, designing a system that’s all-encompassing and covers all the elements probably makes sense. You can make all the design decisions up front and reference them (and tweak them as needed) as they come up.

But when I’m building my little SaaS app, or in this case, my portfolio, creating a full design system like that feels like overkill. In fact, I don’t think it makes sense to start with a design system at all.

Instead, I want to start with deciding what my content structure should look like.

So what I’m going to do before I think about design is figure out what I want my portfolio website to include.

But I don’t want to do this exercise alone – it would be way more fun to do this with a friend.

That’s where you come in.

Not A Designer New Year Challenge

To kick off the New Year, I want you to pick something you want to design and, through this newsletter, we’ll go on a design journey together.

You can pick a portfolio site like me, or you can pick something else. But for our learning purposes, I recommend picking something that can be contained to a few simple pages. Though we’ll be working on different projects, we’ll learn best practices and walk through the steps together.

If you’re down, here’s your first assignment: decide what’s going on your site.

If you’re building a portfolio too, take a few minutes to browse the personal sites of people you admire in tech, maybe other designers or developers, and check out what they’ve included. Is there a headline? A bio? An image of the person? A contact section?

Then do the following three things:

1. Take screenshots of what you see to reference later

2. Make a list of the different sections and components you see

3. Determine what sections you want to include in your site

This will be the start of our content structure.

If you’re on social media, let me know what you’re going to work on by using the hashtag #notadesignernewyear. Feel free to tag me @saronyitbarek or the NAD account @notadesignerrrr.

Excited to go on this design journey with you!

<3
Saron

PS. If you want more content on design systems, check out this incredible library of design system videos from Josh Harwood.

When I’m designing a hero section (that first section that users see right below the navbar and logo), I always struggle to pick a typeface for the heading. The heading in this context is that main line of copy that usually describes the product or declares its value proposition.

In the Stripe example below, the heading is the line that reads, “Financial infrastructure for the internet.”

It’s often the first thing that users see on the page, usually conveys an important message, and can set the overall tone for the page. It’s a good idea to put some thought into that typeface and see if you can find a way to make that heading stand out just a bit, complimenting the message and helping the product make a good impression.

So, to find a great typeface, I google something like “fun fonts for headings.”

What I end up with are typefaces that are gorgeous, but usually have too much going on. They’re great for something more graphical, like an artist’s website or a movie poster, but not for my SaaS app.

What I really want are fonts with just a touch of personality, but that still fit into the more straightforward aesthetic of my product site.

So I did a bunch of research and found six typefaces that work really well for the kind of products I’m usually building websites for – primarily, SaaS products.

If you don’t like the typefaces I picked, that’s totally fine! Picking a typeface, especially for a heading, is as much about personal taste as it is anything else. But if you’re browsing typefaces on your own, there are a few things you should consider to create a great design for your users.

Let’s go through the three rules I used to come up with my typeface choices.

Ensure readability

When styling the heading, your font size is going to be pretty big. That means you have some flexibility in how readable your typeface needs to be.

Remember how in an earlier issue we talked about the importance of picking a typeface with a large x-height (the height of the lowercase letters compared to the capital letters) so that it’s readable in small font sizes like buttons and labels? You don’t have to worry about x-height much for headings. You have more freedom.

But not too much freedom.

Although you can get away with smaller x-heights, headings for SaaS products still have quite a few words, making readability an important consideration.

Take this example from Tailwind, where they use Inter for the heading (Pro tip: to find the typeface on any website, check out the WhatFont? browser extension :).

That heading is pretty wordy! Even at a bigger size, the heading still has to be readable, and the funkier the font, the harder it is to read.

Let me show you what I mean.

One of my favorite typefaces that I came across was called Nineties (this site’s a little sketchy, but if you ignore the pop up and click the “download” button near the bottom next to nineties-font.zip, you’ll be fine).

It looks like this:

It’s got a retro vibe, it’s super round, and a little off, but in a fun way.

Sounds great! But how does it look when we use it in our heading?

Yikes, that’s pretty tough to read. I really have to work to make out those words!

We need something much more pragmatic.

A better place for something as fun as Nineties is one where we only need to read one or two words, like in a logo. Now if we wanted to give the Tailwind logo a funky update, this typeface would be a great option.

Here’s what that might look like (check the logo on the top left):

Since it’s just one word, using a funky typeface is just fine. It still feels readable and gives the product some personality.

It can be hard to look at a typeface and put it in the context of your app, so when in doubt, download the typeface and see for yourself! But if you’re trying to eyeball it, look out for “decorative,” “handwritten”, or “display” typefaces. Those are usually better for one or two words, not a full heading.

Avoid condensed fonts

I love condensed fonts. There’s something about the sleek, long strokes that feels bold and regal. They work really well for social media posts when you’re often working with narrow widths, but they usually look awkward in headings.

That’s because when it comes to designing SaaS apps, we’re usually designing our headings in terms of desktop, and that tight narrow typeface in the sprawling width of a browser just looks awkward.

Let me show you what I mean.

Here’s the Tailwind site again as is.

And here’s how it looks in one of my favorite condensed fonts, Bebas Neue.

The entire width of the heading shrunk considerably, leaving a ton of awkward space and a general feel of compression.

To offset this, I might be tempted to make my line length longer so I can get rid of all the spacing.

Let’s see what that does:

Now we have a new problem: too many words in one line! With all those words jam-packed into that first line, my readability goes down and the heading ends up looking overwhelming.

So as a general rule of thumb, I tend to avoid condensed fonts for headings.

Distinct from your subheading

While we don’t want our heading typeface to be too funky, we do want it to be distinct from the subheading, the second line of copy right below my heading.

When the two typefaces are too similar, it creates a different kind of awkwardness – your user will detect that something is different, but because the two typefaces aren’t different enough, it will end up just feeling off.

For example, here’s what the Tailwind site would look like if I used two sans serif typefaces with similar x-heights: Inter and Roboto.

Best case scenario, the users can’t tell the difference, in which case there was no point in using two different fonts. Worst case scenario, it looks awkward.

If you pick a unique typeface for the heading, it should be done with purpose.

A few things to consider when trying to create that distinction are:

1. X-height: Is one typeface’s lowercase letters significantly shorter than the other one?

2. Body or character width: Is one typeface’s letters more narrow than the other one?

3. Shapes of bowls, loops, and shoulders (these are the curves of the letters like an “h”, “p”, or “g”): How does one typeface’s curves compare to the other? Is one significantly rounder?

Looking at these specific typographical elements can be a good starting point for identifying differences between typefaces and making sure they’re different enough.

Pro tip: An easy way to create that distinction between the heading and subheading is to pick a sans serif for one and a serif for the other.

Six Great Typefaces

So now that we’ve covered how to pick a typeface for your heading, let’s see examples of six great typefaces you can use.

For these examples, we’re going to use GitHub’s landing page to experiment.

Here’s the original, where they use a great sans serif font called Mona Sans for their heading:

As we look at these typefaces, think about, not only whether you like the look, but how the look impacts the website overall. What impression are you left with? Knowing what GitHub is, does it fit? What vibe does it give this brand and, more specifically, the message of the heading?

Let’s begin.

League Spartan

Our first typeface is League Spartan, a typeface with a much smaller x-height, giving it a slightly different, more playful aesthetic.

For me, this means it gives GitHub a younger, more playful vibe. I like this vibe, it makes enterprise software look a bit more grounded and relatable.

It also offers a different interpretation to the word “build.” In the original typeface, I imagine building as something big and challenging. With this font, my idea of building turns to something more fun and less serious. A different impression indeed.

Rubik

This next one’s called Rubik and is a thick, slightly rounded typeface. It gives me stationery, thick-marker vibes.

When thinking about what I could build here, the images that come to mind are more woodworking and manual – I’m about to build with my bare hands, which is pretty cool! I could be building a labor of love or a fun hobby project. DIY is the impression I’m left with.

What about you?

Roboto Slab

To switch things up, let’s check out Roboto Slab, a slab serif font that looks like an old-school typewriter.

This feels more professional, but also reminds me of publishing. When thinking about what I could use GitHub to build in this context, I’m thinking of sleek websites and rich content. It feels more media and less apps to me.

What do you think?

Lora

For a more classical look, check out the very elegant Lora. Chic, sophisticated, but still very readable.

This feels similar to Roboto Slab in giving me that publishing look, but it also leans a bit more physical goods and products. I can see myself building a jewelry or fashion site with this tool.

Anek Bangla

A subtly fun typeface is Anek Bangla. On the surface, it looks like a heavy sans serif font with a decent x-height. But if you look at the curve in the b and the d (called the bowl) and the curve in the f (the hook), they’re just a little quirky. There’s that touch of personality that we were looking for.

As far as what I’m building with it, this feels the most open ended and creative. It makes the tool feel like I could build anything I can think of, the limits are my own imagination, which is great! The quirky curves might lean a bit more artistic, but definitely feel boundless to me.

How do you feel looking at this heading?

Nunito

And finally we have the smooth, round edges of Nunito, helping it stand out, but not too much.

I don’t know about you, but I think this one fits really nicely with the space theme of the landing page. There’s a nice contrast between the sharp edges of science and technology and the soft, roundness of the letters. It’s a great reminder that we can be both hardcore builders and still have fun and engage in play at the same time.

What to take away from this issue:

When you’re picking a typeface for your heading, make sure to pick one that’s the right balance of fun and readability. You can do that by:

• Avoiding typefaces that are so funky that they’re unreadable past a few words (when in doubt, download and try it out!)

• Steering clear of condensed typefaces

• Making sure your heading typeface and subheading typefaces are either exactly the same or distinct enough from each other. To be safe, try a sans serif and serif combo.

That’s what I got for today, hope this was helpful 🙂

Happy designing!

Saron

As far as defaults go, the default checkbox actually doesn’t look too bad.

Default checklist

It’s clean, has cute little rounded corners, a fun bright blue color – not too shabby!

But with just a few changes, we can upgrade our humble checkbox and make it look a little more elevated.

After reading about styling checkboxes and looking at tons of examples, I found that there were three things most styled checkboxes had in common.

Here’s what designers seem to be doing:

1. Increasing the size of the checkbox

2. Giving the checkbox room to breathe

3. Playing with gray

Let’s do a walkthrough and break it down.

Here’s a screenshot of the kind of settings you might find in an application with default checkboxes.

I’ve done some minimal styling to make this a little more organized. Namely, I:

• gave the descriptions a margin-left so that they’re inline with their label

• gave each checkbox item a padding-bottom to create separation between the options

Now let’s start elevating.

When bigger is better

One of the techniques I saw over and over was making the actual checkbox bigger. Right now, it’s the same height as the line height of the label, but we want our checkboxes to go beyond that.

So how much bigger should our checkboxes be? For text that’s 18px, it seems like a good size is about 25px. If you’re using Tailwind, you can use the classes h-6 and w-6 to get it to 24px, which is close enough.

When we do this, we want to make sure we center our labels to our checkboxes. Here’s what that looks like:

What I like about making the checkboxes bigger is that it draws the user’s attention to the main activity on the page – checking those boxes! We’re highlighting the primary action on the page, which brings focus to the interface.

Let me breathe!

But now I’m feeling a little claustrophobic. With those boxes taking up more space, it feels like they’re bumping up against everything and could use some more room.

This is probably why so many examples I saw of these larger boxes also came with more padding, giving them a little breathing room. Let’s add some right padding to the checkboxes and see how that feels.

Ah, that feels so much better.

Playing with grays

So far we’ve implemented two out of the three techniques: size of checkbox and spacing. The last one we mentioned was “playing with grays.” Where does that fit in?

That’s referring to the color of my text.

The problem we’re trying to solve is readability. Right now, there’s not a clear delineation between the label and the description. Because they’re the same size, font-weight, and color, skimming just the labels to easily find what you’re looking for is tough.

We could change the font size and make the descriptions a little smaller. We’ve explored the effect of changing font size in previous issues and we found that the change often is more subtle than we need it to be. To really feel the effects of a font size change, the difference between the font sizes needs to be dramatic, and at those levels, it can end up looking a bit obnoxious. So we’re not going to do that here.

The other option is adjusting the font-weight. I could increase the font-weight of my labels and that would certainly help them stand out. Let’s try that and see how it feels.

This definitely helps our readability, but there’s something that’s bothering me.

Increasing the font weight helps the labels stand out by giving them more real estate on the page, but they feel a little too loud, a bit too bold. If I really think about it, it’s not that I want the labels to be louder, it’s that I want the descriptions to be quieter. I want to turn the volume on the descriptions down so they don’t call as much attention to themselves. That’s where color comes in.

Instead of increasing the font weight, I’m going to change the color of my descriptions to a gray and see how that feels.

I like it! By turning down the volume on the description, we make our labels stand out by comparison, making them easier to scan and read.

But before we pick this design, we need to check something super important – our color contrast. This gray looks good to me, but is it accessible to someone with low vision? I’m going to use the Able plugin in Figma that I talked about in my color contrast issue to check.

This gray fails the small text guideline, but because my text is bigger, I’m in the clear. Great, I think I’m all done!

Let’s do a quick before and after.

What do you think?

What I like about these changes is that they’re relatively small and subtle, but the result is a sleeker, more polished looking checklist.

There’s more we could do – we could get fancy and change the color of the checkbox, give it a fun border, maybe even add an animation when it’s clicked. But even without doing all of that, we’ve created something that’s a bit more thoughtful and easy to incorporate in your next project.

Checkboxes IRL

Here are some examples of checkboxes in the wild that use similar techniques but are slightly different.

This one is from GitHub’s profile page where there’s a long list of settings, options, and lists.

Checkboxes in GitHub

The biggest differences are that they went with increasing the font weight and not much spacing. I don’t know about you, but I think we could use a bit more spacing in this one.

This is from Gmail’s settings.

Checkbox in Gmail

Here we see that bigger checkbox with another example of increased font weight. What’s also interesting about this one is that they put the description inline with the label instead of beneath it. Interesting choice!

This one is from Instagram’s settings.

Checkbox in Instagram

We see the use of the larger box and the grays, but the description isn’t flush with the label, which I found a bit surprising.

So how can you elevate your checklists?

1. Make the checkbox bigger than your label’s line height. If your label is 18px, pick a checkbox that’s at least 25px tall.

2. Add right padding. Give that big checkbox room to breathe.

3. Use a gray for the description. This makes your list more readable, but make sure the gray you pick is accessible by using a tool to check the contrast.

Happy designing!

Saron

Not A Designer Newsletter Shoutouts

It’s super validating to hear your thoughts on the newsletter. Thanks for the shoutout, Dan ❤️

My least favorite thing to do online might be filling out forms. So when it’s my turn to design a form, especially one with more than just a few fields, I’m always thinking about ways I can make it less painful for my user.

So what can we do to create a better experience? How can we better design our forms?

There are a lot of parts to a form – the placeholders, the labels, the fields, the sections. So when we’re dealing with a longer form, one strategy you might consider is breaking it up into columns.

At first glance, a multi-column form, like this one from Walmart’s 2021 checkout flow, feels easier on the eyes.

Shorter’s usually better, isn’t it? It’s less intimidating and looks more compact, like there’s less work to do. But research has actually shown that multi-column layouts in forms are generally a bad idea.

Let me explain.

The Baymard Institute, an independent web UX research institute that’s conducted over 130K hours of research on a number of usability topics, released a report a few weeks ago revealing that although multi-column forms might look more aesthetically pleasing, they’re actually a terrible user experience.

Where do I go?

When you only have one column, it’s pretty clear what direction you need to go in – you start at the top and you work your way down. Simple!

But when you have multiple columns, that direction is gone. Let’s revisit that Walmart form. Here it is again:

Which way do you go? Reading in the English language tells you to move from left to right, but if we did that, we’d go from “First Name” to “Street address” down to “Last name.” That doesn’t make any sense.

So I guess you should finish one column first then go back up to the second? This lack of clear direction can throw users off and create confusion.

But why does this matter?

Oopsie daisy!

When users get confused about which direction to go and where to look, there’s a higher chance they’ll miss something entirely and get a frustrating error when they thought they were done. Or, they’ll fill something out incorrectly, mistaking it for a different field, and get an error message that way.

Filling out a form is already a chore. You don’t want to add pain to the process. Forms that are multi-column are more prone to user error, making it a less pleasant experience for your users.

But isn’t there autocomplete or other tools to help fill out the form for you?

Good point! When considering a checkout flow like Walmart’s, users often have the help of password managers or autocomplete to make filling out the form easier, but as designers, we can’t rely on users having these tools. To be safe, we have to assume these aren’t in play.

What about related fields?

There is one exception to the one-column layout that Baymard found, and it’s that fields where the concepts are related can be placed in-line with no usability issues. Fields like “first name” and “last name” are perfectly fine to put next to each other, as are “zip code” and “city”, along with “cvv” and “expiration date.”

But these in-line exceptions should be used sparingly for just a few fields so that the overall layout is still a single-column layout.

Let’s look at Walmart’s checkout flow as it is today as an example of a tempting option that you should still avoid. Here it is below:

To be fair, this two-column layout is a big improvement to their 2021 version.

Rather than creating two columns where you go down one column and then back up the next, they created a two-column layout where the two fields next to each other are actually related. You’ve got your first and last name in the same row. Makes sense. Then street address and apt or suite number. Fair enough. And then you’ve got city, state, and zip together. Sure thing.

The natural inclination to read left to right is honored by grouping related fields next to each other while creating an experience that visually feels like less work because it’s shorter. Seems like a win-win!

But Baymard’s research shows otherwise – that even when fields are grouped together in relatable ways, the two-column layout can still be confusing and prone to error.

The problem is that, at first glance, it’s still not visually obvious which direction I should go in, at least not as clear as a one-column layout.

Instead, I have to read each field to realize that the correct flow is left to right, and in my scanning, I might make an error of skipping a field by accident.

Because of that, Baymard recommends doing the occasional inline fields while keeping the overall layout single column.

So if we shouldn’t use a two-column layout, what can we do to make our forms more approachable?

Break it up

There is one thing that Walmart does well with their form experience – they don’t just break up the form into different sections with headers – they actually hide most of the form until you’ve finished with a section.

Take a look at the following screenshot:

This form has three sections: Shipping, Payment, and Mobile contact. But they don’t show you all three. They’ve actually collapsed and grayed out the Payment and Mobile contact sections, making it feel much more approachable.

In fact, when I complete the Shipping section and hit “continue,” I feel good about making progress on what would’ve otherwise felt like an endless column of fields. It’s a more satisfying experience than seeing the sections and fields upfront.

So consider not just using sections and headers to break up your form, but actually hiding parts of the form from your user, until you’re ready for them to fill it out.

Give it constraints

If I were building a long form from scratch, I might start with something basic like this.

The default for our form fields is for them to take up the whole width of our container.

Instead of placing them directly on the body, another way to make it feel more manageable is to offer them a home on a card or panel with a max-width and some padding, like this:

That makes them feel a lot more contained and organized, a little more approachable.

Another strategy is to have a two-column layout, not for the form, but for the page. You’ll have one column for the form and a second for some additional content. On a checkout page, it makes sense for that second column to be a summary of what the person is buying.

It’s good context and a helpful way for them to confirm what they’re about the purchase, but the other benefit is that it balances out the form. And if your summary includes a photo of what they’re purchasing, that provides a nice visual to offset the column of fields, like this.

If you’re building a form where some type of summary doesn’t make sense, another option is to include some supporting text thanking them for filling out the form. It might be a reminder of what the form is about or why it’s important, plus a fun emoji or small graphic to brighten the page. It’s easy to ignore as a user while I fill out the form, but still brings a lightness to the experience.

When you’re designing your long, single-column form, it might look like a lot, but take comfort in the fact that as a user, you’re providing a single flow – one direction that’s easier to follow than a multi-column alternative. And with the ideas in this issue, hopefully you found ways to make your long form more friendly.

Happy designing!

Saron

Not A Designer Newsletter Shoutouts

It’s super validating to hear your thoughts on the newsletter. Thanks for the shoutout, Julia ❤️

📢 Quick announcement!

I want to make sure these issues are super high quality and want to incorporate more feedback into my writing process so I’m announcing a new Beta Readers program.

As a Beta Reader, you’ll get a first look at all my issues via Google Doc with the humble request that you provide feedback within 24 hrs.

Besides getting a preview of the Not A Designer drops, I’ll also send you swag as a thank you. So if you like mugs, t-shirts, stickers, and want to help make this newsletter even better, reply telling me a bit about yourself and let me know you’re interested!

Back to the show…

As someone without web accessibility needs, I must admit that accessibility isn’t something that’s top of mind during my design process. I do a gut check that things look contrasting enough and I try to use alt-text when I remember (yikes), but I haven’t done a good job of making sure my work is accessible to everyone.

I know it’s something I should do, I know it’s the right thing to do, but for reasons I can’t explain, it’s never been a priority. I want to change that.

I’m going to do a better job of educating myself on accessibility issues and try to incorporate them into the Not A Designer newsletter so we can all be a little more inclusive.

Let’s make a better Internet for everyone, together.

Today’s topic is color contrast.

It’s something I hear a lot about in accessibility conversations, and, since picking colors is a big part of design, it felt like a great topic to start with.

On a high level, I know that contrast is important for people with low vision, but I never knew exactly how to define contrast that’s good enough. I use my own uninformed opinion to eyeball how contrasting two colors seem to me, which is a terrible way of approaching the topic and, after learning more about it for this issue, is something I do not recommend.

But before we talk about the solution, let’s take a moment to understand the problem.

What is “low vision”?

Having low vision means that a person experiences a loss of sight that’s not correctable by glasses, medicine, or surgery. It’s more common as we get older but can happen at any age.

Low vision isn’t tied to one particular visual impairment and isn’t experienced the same way. Visual impairments that can result in low vision include, but are not limited to, diabetic retinopathy, age-related macular degeneration (AMD), and glaucoma. Having low vision can impact your sight in a number of ways, and one of them is having a harder time telling the difference between low contrast elements.

While that information is helpful, I still find it hard to wrap my head around what that means for my design process. What I really want to know is: how hard is it really for people with low vision to experience my designs? What does my product look like to them?

How do low contrast elements look?

To better appreciate this problem, I tried to find a simulator that would help me see first-hand what poor design choices look like for people with low vision.

There are a number of tools that work in different ways, including downloadable apps, Figma plugins, and browser extensions. Some of them are unfortunately defunct, but, with the help of amazing people on Twitter, I was able to find two ways to simulate low contrast vision that are built right into my dev tools!

Firefox Devtools: The first is in Firefox. Shoutout to Konnor Rogers and Todd Libby for sharing this with me.

All you do is:

1. Open dev tools

2. Click “Accessibility”

3. Select “Contrast loss” from the “Simulate” drop down

Screenshot of Mozilla DevTools “Contrast loss” option

Here’s an example of what a landing page looks like using this simulator.

Social media management landing page through Firefox low-contrast simulator

Chrome DevTools: You can also use Chrome’s built-in visual simulator for the same thing.

1. Open Chrome Dev Tools

2. Press Ctrl + Shift + P

3. Search for "rendering"

4. Click on "show rendering"

5. Scroll down until you see an “emulate vision deficiencies” section

6. Select “Reduced contrast.”

Here’s what my landing page looks like according to this simulator:

Social media management landing page through Chrome low-contrast simulator

You’ll notice these two simulators gave me very different results.

Firefox makes everything darker, which is the kind of low contrast often experienced by people with something like cataracts, which can reduce the amount of light that enters the eye, making everything look a little darker.

Chrome simulates the experience that people with conditions like glaucoma would have, which makes them more sensitive to light and hard to distinguish elements on brighter backgrounds.

Low contrast looks different for different people, and using both of these built-in tools gives us an appreciation for how our designs can look depending on the type of low contrast the user is experiencing.

Big green button

The contrast on our example landing page isn’t great (it actually fails our accessibility requirement, more on the requirement later!), but it’s not the worst. To illustrate this problem better, let’s look at a button we’ve probably seen a lot in the wild, a “Get started” button.

If I were designing a “get started” button from scratch, a color I would intuitively reach for is green. Green means “go!” and feels active, but it can be a tricky color to work with. For those of us who don’t experience low vision, a bright green color like the one below can feel like a great choice!

Green “get started” button

It’s eye-catching, it’s fun, it screams “action!” But what does this look like to our low vision users?

Green “get started” buttons through Firefox and Chrome low-contrast simulators

Neither of those is great, but the bright one is particularly bad. I can barely make out those letters!

The dev tool simulators are a great way to help us understand the problem and empathize with our users with low vision.

But how do we quantify this problem? How do we know what our contrast should be?

What are the requirements?

To answer this question, we turn to the WCAG, which stands for Web Content Accessibility Guidelines. It’s the go-to source for web accessibility. It has helpful, straightforward guidelines for tons of stuff, including contrast. You can read the contrast guidelines here and here.

There are two levels of guidelines, the minimum, called Level AA, and the enhanced, Level AAA. The enhanced level tends to have more stringent requirements.

The contrast guidelines specify a particular contrast ratio that our text and our background should meet for both small and large text.

Here they are:

Table of Level AA and Level AAA contrast ratios for small and large text.

Wait, what’s a contrast ratio?

For a guideline to be usable, it’s best if it’s measurable, and luckily, contrast is!

Contrast is quantified by our contrast ratio, which tells us how bright and dark two colors look on a screen. The ratio comes from comparing the luminance of the two colors. There’s a whole scientific formula on how to do this, which takes into account what the RGB values are, but all we need to know for our purposes is that we want that first number to be high – the higher it is, the bigger our contrast.

The range of contrast isn’t that big – we’re talking under 21. But a single point can make a big difference.

That bright green that was fun but inaccessible? It had a contrast ratio of 2.01:1. Ouch, not good.

Let’s see if we can increase that ratio and make it accessible by using a darker green.

Here are the before and after:

A before and after of the green button

As a non-low-vision-experiencing-person, that definitely looks more contrasting!

I used Figma to make these buttons and Figma has a bunch of plugins to incorporate accessibility into our design. I tried a few and the one that I really liked is called Able created by Sondre Kvam.

You pick two layers and it will:

1. tell you the color ratio

2. state whether it passes WCAG level AA and level AAA

3. simulate how it looks for different vision impairments.

It’s a free plugin that’s super easy to use.

Let’s run the Able plugin on my new button and see how well we did. Here are the results:

Screenshot of Able tool on green button

Failed on all fronts!

Let’s see how this button looks with our dev tools simulators.

Darker green button through Firefox and Chrome simulators

Oof, that’s tough.

What’s amazing to me is how high contrast this felt as a person who doesn’t experience low vision, but how completely wrong my instincts were. This taught me how important it is to rely on easy-to-use tools instead of my gut to make sure I build accessible products.

When it comes to contrast, my gut is not very reliable.

Let’s pick a darker green and see if we can get that contrast up to code.

Darker green “Get started” button

Let’s check with our Able plugin. 

Much better! Let’s see what this looks like with our simulators.

Darker green button under low-contrast simulators

More readable for sure. From looking at my simulator, I feel like we could still go a little darker and improve what that Chrome output looks like, but we made a lot of progress.

Let’s compare all three buttons and their contrast ratios side by side.

Three green “get started” buttons and their contrast ratios

Let’s look at another example.

Another button I see a lot in products is a big red “Delete” button. The question is, what color red do we pick?

Without checking my contrast ratio, here’s one that I might start with.

Red “delete” button

If I use my gut to assess this, it looks great! Nice, bold red, I’m sure this will pass … won’t it?

Let’s run Able and see.

Screenshot of Able result for red “delete” button

Womp, womp, we were wrong. It passes on large text, but fails on small, and, since this is a button, I want it to pass that small text guideline.

So how much darker do we need to go to pass?

Luckily, not much! Here’s a red that passes the contrast guideline.

Darker red “delete” button

Let’s put them side by side to compare.

There’s definitely a difference, but not one that would change a design dramatically. I’m still within my range and likely within my color scheme, but to our users with low-vision, we’ve made a big difference.

Fixing contrast issues IRL

Having accessible colors is important for every product, regardless of size, and the more popular the product, the more low-vision users you’re likely to have.

Unfortunately, not all products get this right the first time, but it’s great when they learn and fix their mistakes.

My favorite example of this comes from a blog post by Rachele Detullio about YNAB updating their UI elements to increase the contrast and make it more accessible. Her post is full of goodies you should definitely check out, but in the meantime, here are the before and after of YNAB’s elements.

The before and after of YNAB’s balance fields

What I love about this is, not only is the “after” more accessible, it’s also prettier to look at. Double win!

How to incorporate contrast into your design process

There are a lot of tools to help make your product more accessible, but without an easy way to incorporate them into your workflow, you just won’t do it.

So here are three ways you can incorporate accessible colors into your workflow.

1. Start with an accessible palette
   There are accessible palette generators you can use to help you pick colors with great contrast ratios. Check out this one by Venngage. You can start with one color you like and it’ll build palettes for you based on that color. That way, you know every color you use is safe.
   

   

2. “Pick and check” with a plug-in 
   The easiest way to include accessibility as you design is to do a “pick and check” throughout the process. Use Able in Figma to check elements as you build them. Even if you have an accessible palette to get you started, there might be a random color you need to add to make your design work. Use this plugin to do a quick check as you work before committing to the color.
   

3. Do a browser check
   As a final check, use the simulators in your dev tools to see how your page comes together and appreciate what your low-vision users experience. Make sure to do it in both Firefox and Chrome so you can get the range of low-contrast experience.

Hopefully, this issue gave you a solid introduction on how to think about contrast.

Key takeaway

For me, the biggest takeaway was that eyeballing what looks good to me as someone without low vision is not a reliable way of making my designs accessible. There are lots of tools that do a much better job. Let’s use those tools to create a better web for us all.

In the meantime, there are wonderful people on the internet who do great work on accessibility that I want to shout out. Make sure to give them a follow and check out their work!

• Africa Kenya: She calls herself the A11y Baddie, and she is! To learn from her, check out her accessibility study group and her web accessibility trainings on YouTube.

• Todd Libby: Todd is a breath of fresh air on social and always willing to lend a hand, especially on accessibility topics. You can check him out on his site here and listen to his Front End Nerdery podcast.
  

• GrahamTheDev: Graham was so helpful in tipping me off to accessibility tools for this issue and he’s turned this passion into a great service that helps SaaS businesses become more accessible, called Toa11y (clever!).
  

• Sara Souiden: A huge name in web dev and accessibility, Sara has a great course teaching application accessibility to the rest of us, called Practical Accessibility.
  

• Rachele DiTullio: Besides writing that excellent YNAB post, she’s written tons about accessibility. For a solid intro to accessibility testing, check out her resources here.

My goal with this issue is to make it easy to incorporate more accessible color choices in your product. How did we do?

Happy designing!

Saron

We did a few detailed design walkthroughs last week, so I thought I’d pick a simpler topic for today’s issue: line height. One value, one little concept – should be easy right?

Boy, was I wrong.

I ended up reading a ton about the topic and even bought a book on typography that went into detail about it. Turns out, there’s a lot of art that goes into picking line height.

I’m not a designer, so I find relying on art pretty unhelpful when I’m working on a page, so let’s see if we can use rules and a bit of science to set our line heights responsibly.

Let’s begin!

PS. Apologies in advance for some of the spacing and line break issues. I fought Beehiiv forever trying to fix them and lost quite a few battles :(

What exactly is line height?

Let’s start with a simple definition of line height.

Line height is the height of the line box (the part of the box model that contains the text) plus the space above and below it.

Line height vs. leading

You might have heard of another related term, “leading.” Conceptually, it describes the same result (space between lines of text), but there’s a slight difference. While line height measures space above and below a line of text, leading measures the space from the baseline of one line of text to the baseline of the next.

Here’s an illustration, courtesy of CSS-Tricks:

Leading is generally used in print and graphic design, but the two concepts collide in our world, thanks to Tailwind.

Tailwind uses a class called “leading” to set the CSS property “line-height.” Spicy.

Why is line height important?

Line height might not feel very important on the list of design things you have to worry about, but setting a good line height can make a big difference when it comes to 1) readability and 2) usability.

Let’s tackle readability first.

• Readability
  
  As we read text, we’re putting our eyes to work. The longer we read, the more tired our eyes get. When we reach the end of a line, our eyes get a nice little break before getting back to work again.
  
  If our line height is too small or too big, we make it hard for the user to find the next line easily, making the text more difficult to read.

  
  Check out this example, with a line height that’s a bit too tight. How does it feel to read?

  

  
  It was pretty hard for me. We need more space!

  
  And here’s an example on the other end of the spectrum – too loose. How does this feel to read?
  

  

  
  That’s a bit too much space for me! With that line height, things start to feel too messy and disconnected.

But there’s also the issue of usability.

• Usability
   
  When you look at a block of text on a screen, you have to decide: do I read it or do I skip it? In other words, do I want to use it or not?

  
  Text with a line height that’s too short feels packed, dense, and overwhelming. It’s too intimidating to read.

  
  Text with a line height that’s too tall feels loose and disorganized. It’s too messy and difficult to read.

  
  A line height that’s well set makes the text approachable and invites the reader in.

How do you measure line height?

Before we get into picking line height, we need to know how to measure it.

I’m used to seeing line heights with no units at all, so I was surprised to learn that line height can actually be measured in a range of units!

Here they are:

body {
   line-height: normal;
   line-height: 2;
   line-height: 1em;
   line-height: 1rem;
   line-height: 200%;
   line-height: 20px;
}

I’m going to do a dedicated issue on units in CSS (with the help of the incredible Kevin Powell!), so for now, we’re going to stick to the option that has no units at all.

That option is a multiplier – whatever it’s set to, you multiply by the font-size of that text and that’s the value of your line height.

Ex: If your font-size is 16px and your line-height is 2, then your line-height for that text is 32px. Nice and simple.

But don’t I get a default line height? Can’t I just use that?

You sure do and you totally can! If you don’t manually set a line height, your browser will set one for you, and it’s usually 1.2. If you’re using Tailwind, the default line height is 1.5, although it changes based on the size of your text.

That’s not bad, but we can often do better. We’re going to unpack how to pick a better value along with some shortcuts to help you make good design decisions.

Great, so what value should I pick?

Now that we have some background on line height, let’s dig into actually picking a value. We’ll start by asking some questions about our text.

1. What kind of text is it?
   
   Text that needs a line height is usually a header or body text. Buttons and nav items are usually just a word or two, so I don’t really have to think about line height when it comes to my UI elements.
   

   There’s a simple rule you can follow when it comes to how we can think about text and line height:
   

   • Bigger text = smaller line height

   • Smaller text = bigger line height
     

   In other words:

   • Headers = smaller line height

   • Body text = bigger line height

   
   Let’s look at examples of this in action and see what we think.
   
   Headers
   
   Here are headers with Tailwind’s different line-height values.

   
   

   
   
   
   
   
   

   
   For headers, a line height that’s smaller usually works better. In fact, if you’re using Tailwind and pick a bigger font-size from their predefined classes, it’ll automatically reduce the line height for you.

   
   To practice sharpening your design eye, take a moment to look at the above and see which one feels most 1) readable and 2) usable to you. Which feels most approachable? Which feels most organized?

I personally find myself drawn to “leading-tight” for bigger headers. Large text takes up real estate and can feel like they’re floating in space. Decreasing the line height can pull them back together again and make them feel nice and cohesive. When in doubt, this is a safe choice for larger text.

Body text

And what does body text look like at my different line height values? Here are some examples:

Let’s take a moment to pause and reflect: Which of these feels most 1) readable and 2) usable to you? Which feels most approachable? Which feels most organized?

I find myself pulled towards the “.leading-relaxed” example the most, but let’s see if we can put some science behind that feeling.

2. Calculating your line-height
   Line height sounds like one simple value, but in my research, I was most surprised at how dependent it is on three other elements: typeface, font-size, and line length.

   
   This is where the art comes in – you start with a typeface, you pick a font size, you play with the line-height, you adjust the line length, then you go back to fix the font size, then modify the line-height, and on and on until it “feels right.”

   
   I don’t know about you, but a process like that is lost on me. I need some rules to follow. Let’s see if we can come up with a framework to get us a great line height.

   
   1. Pick your typeface

   
   Since we’re designing for a screen, we’re going to pick a typeface that 1) is sans serif and 2) has a big x-height (ideally, 70% or greater). For more info, I wrote an issue on x-height and picking a typeface here.

   
   Short cut: When in doubt, Inter is always a safe choice. For alternatives, Work Sans, Open Sans, San Francisco, and Roboto are all good options.

   2.Pick your font size
   
   Since we’re talking about body text, this one is fairly straightforward. There’s a small range to pick from, but these seem to be the agreed upon best practices:

   • Mobile: 16px

   • Desktop: 18px
     

   So far, so good! Next, we’ll pick our line length.
   
   3. Determine your content width

   
   Content width is determined by line length. Line length can be measured by 1) how many characters are in a line or 2) how many pixels (or other fixed unit) long it is. Since we’re optimizing for readability, we’re going to start with the number of characters.

   
   I did a bunch of research on this, and it looks like the most agreed upon line length for body text is between 50-75 characters.

   
   But as developers, we don’t size content based on characters. So what is 50 - 75 characters in pixels?

   
   That depends on your typeface and font size. Let me illustrate.

   
   If we picked a font size of 16px, here are the different widths for 5 different typefaces at 50 characters.

   

   
   At a font size of 18 px, here are the different widths for 5 different typefaces at 75 characters.
   

   

   As you can see, there’s some range here, but our screen friendly options, predictably, take up around the same amount of space compared to our serif font, Times New Roman, and our low x-height sans serif option, Futura.

   
   It’s important not to make your text too wide, since that will make it hard to read and feel unusable. To make it easier, here’s a reference of suggested widths for your future projects, assuming you pick one of our screen-friendly sans serif fonts:
   

   

   
   And finally, we can get to line height.
   

   3.Calculate your line height

   Now that we have typeface, font-size, and content width, all that’s left is determining the line height.

   
   It was harder than expected to find a straight forward rule on line height. The answers seem to be either a blanket statement like 1.5 for everything (ok, but not great) or a frustrating “it depends.”

   
   But I did find one resource that I’m excited to share with you. It takes your font size, typeface, and content width and uses the golden ratio to calculate a good line height.

   
   It’s called the Golden Ratio Typography and I offer it with a grain of salt: there’s a lot of controversy behind the legitimacy of the golden ratio as it applies to graphic design (and in general). I’ll cover that topic in a different issue.

   
   But regardless of its legitimacy, it serves as a helpful starting point for those of us who are still sharpening our design eye. Let’s dig in.

   
   For easy reference, here’s a table of suggested line height values I calculated for Open Sans and Roboto (those were the only two of our five typefaces they had, sorry!).

   

   If you want to use Tailwind’s predefined line height values to implement this, you’ll have to use “leading-relaxed” which is 1.625. After that, it jumps to “leading-loose” which is 2 and way too big. Otherwise, you can always define your own.

   
   As you can see, the line heights aren’t widely different.
   
   But how do our calculated line heights compare with the 1.2 browser default and our 1.5 Tailwind default? Let’s see.

   
   
   
   

   
   Let’s take a moment to reflect on these options compared to our two defaults and see how it performs in terms of 1) readability and 2) usability.
   
   

   
   For me, I see a pretty big difference between our browser defaults and our calculated line heights, and I like the results of our calculated line heights much better.

   Going from the Tailwind 1.5 default to our calculated line heights is more subtle, but I can still feel the difference. I think the extra room gives it just a bit more readability and usability and really serves the user.

   What about you? What impact did this exploration have on your future line height decisions?

Whatever you do, it’s important to take a moment to think about the 1) readability and 2) usability of the text on your page and make sure your line height helps your users do their jobs as easily and quickly as possible.

Here are today’s takeaways on line heights:

• Headers should have a smaller line height

• Body text should have a bigger line height

• Determine typeface and content width first, then figure out the line height

• Content width should be based on a target line length of 50-75 characters for body text

• If you’re using Tailwind classes and want to give your body text more space, go with “leading-relaxed”

This was a bit more of a tactical issue than my usual breakdowns and walk throughs. Which do you prefer?

Happy designing!

❤️ Saron

I received a comment on a previous issue that made me a little sad.

The comment read, “I love this. This seems so easy as I read along with the explanations and changes you made after the fact. But wonder if it's something I can do myself and I think the answer is no.”

I’m glad she loved the issue, but I really want the answer to that question to be “yes”. I want you to feel empowered and capable of going through the design process on your own.

So I’m going to approach this issue a little differently.

We’re going to do the same change-by-change breakdown we always do, but this time, I’m going to see if I can bring it back to one guiding question, a question you can ask yourself for your own design sessions.

Let’s go!

When we styled Open AI’s documentation last issue, we removed a key element from the docs – the tags.

In this issue, we’re going to bring them back and style them. Let’s pick up where we left off with the addition of our unstyled tags.

Here’s our starting point:

By “tags,” we’re referring to the unstyled, second line in each list item.

Before we begin some fun styling, let’s cover the basics with a simple, starter question.

Is my content even readable?

As far as readability, I’d say “no.” The way the tags are laid out, I can’t tell if “number or null” is one idea or three. We need better spacing. Let’s add some margin to make our tags more readable.

Here’s the before and after:

Before

After

Much better!

Now we get to the fun stuff 🙂

What’s the job?

First, let’s establish the role these tags play on the page.

Their job is to help the user better understand how to use the param. They’re secondary, supporting information, which means that they shouldn’t compete with our param for our attention – the param is the star of the show. Instead, they should fall into the background, waiting to be called on.

Remember that guiding question we started this issue with? Let’s introduce it.

“Does my design help the tags do their job?”

This is the question we’re going to keep coming back to, and that you can keep coming back to, as we walk through this together.

In its current state, I would answer: “No.”

Why not? What looks off?

To that, I’d answer: “The tags are competing too much with the param. They should take up less space. They should feel smaller.”

Great! How about literally making them smaller?

Revisiting font size

Let’s play with font size and add the class “text-xs” from Tailwind to our tags.

Great. Now that we’ve updated our design, let’s go back to our question:

“Does my design help the tags do their job?”

Hm, sort of?

Okay, what looks off?

The tags’ job is to support the param, but visually, they take up a whole line by themselves, making them feel more important and independent than they are. It makes sense that the description would take up its own line since it’s distinct, but the tags don’t feel quite important enough to take up that much space.

Playing with positioning

This sounds like a good opportunity to play with layout and positioning. If the param feels like it’s more of an augmentation of the param than its own distinct element, how about we literally move it closer to the param?

Let’s try putting them on the same line.

I love this change. By having the tags follow the param, it gives our user permission to ignore them unless they become relevant. As our eye travels down the page, we’re drawn to the param and, once we find the right one, we can keep reading and see its supporting information.

Let’s add “make it inline” to our toolkit of things to try for future design projects.

Back to our guiding question: Does my design help the tags do their job?

I would say this design helps the tag play their role, but I think we can help it even more.

Let’s get tag-y

Tags are a very common design element. We see them everywhere across screens. But our tags here don’t look very “tag-y.” But do they need to?

I would argue “yes.” It’s easier to communicate the purpose of an element when it looks the way you expect. Users know what a tag does and what it’s supposed to look like. By showing them an element that looks like one, we’re making it easier to understand its purpose.

So in order to help our tags do their job, I’m going to try to make them look more “tag-like.”

This is where we cheat – shhhhh, don’t tell 🤫

Because tags are everywhere, we don’t need to start from scratch to figure out how to design them. Let’s find some inspo.

To do this, log in to the products that you use and see how they approach the same element. If you can’t think of where to look, Dribbble is a great source of inspiration for a wide range of UI elements. Just search for “tag” and filter by “web design” or “product design.”

Here are a few I found from products that I use.

Notion

Gmail

The StoryGraph

DEV.to

Although these are all tags, their context is different from ours, so the style might not work for our purposes. Let’s look at our collection and see what might makes sense for us.

Instead of trying out each option, let’s try to rule out some options by just talking through them.

Let’s update our guiding question from, “Does my design help the tags do their job?”, to “Would this design help the tags do their job?”.

Let’s look at the first one:

Notion

So let me ask you:

Aesthetically speaking, I like the look of the colored background and the colored text, but given that the tags would be the only colored things in our documentation, I think that would make it stand out just a bit too much. I think we can do better.

Gmail

What do you think of this one?

I must admit that this isn’t the most exciting styling for tags I’ve seen, but it feels very functional. For our purposes, we would remove the “x” meant to delete the tag since the user isn’t interacting with the documentation. But I can see how gray text on a light gray background would keep our tags in their supporting, secondary role but still help them look like tags.

Let’s look at the next one:

The StoryGraph

Hm, maybe? To be honest, I’m not quite sure. There is some color, which could be distracting, but it’s just the text and not the whole background, so maybe it would be okay. We could also try the gray border and keep the font color gray too. Definitely something to consider.

Last one!

DEV.to

These tags don’t feel right. They remind me a lot of social media tags, which is a different context than the one we’re in. I think we can do better.

We haven’t picked a final style, but we did narrow it down. By asking one key question, the same question we’ve been asking this whole time, we ruled out options and made our process a little faster.

Instead of an endless list of CSS attributes to test and fiddle with, we have two styles to pick between. Much easier!

Let’s implement the first one. We can break down this style to its key components:

• Light gray background

• Dark gray text

• A bit of padding

• Rounded corners

Easy enough! Let’s implement this using Tailwind.

Here’s the sample code:

<span class=”mr-4 text-xs bg-gray-200 text-gray-700 rounded px-2 py-1”>number or null</span>

And here’s the result:

Let’s revisit our guiding question.

The good news is that our tags are looking very tag-like, but they feel a little too prominent for me. I want them to settle into the background a bit more.

Let’s try the second option and see how we feel.

For our second option, we’re going to do the following:

• Add light gray border

• Round the corners

• Change the text color to dark gray

Here’s the sample code:

<span class="mr-2 text-xs border border-gray-200 rounded text-gray-500 rounded px-2">number or null</span>

And here’s the result:

Looking good!

But let’s remember – it’s not about looking good, it’s about doing the job. So let’s revisit our question: “Does this design help the tags do their job?”

The answer to the question for me is “yes.”

In this design, our tags:

• look like proper tags, which makes their job clearer to the user

• fall into the background more easily since we only added a subtle border

• lean into their secondary, supporting role by being inline next to the param

But how did OpenAI style it? Let’s compare our final design with what’s live on the site:

Our final design

OpenAI’s version

They’re pretty similar, but OpenAI made a few different decisions. They decided to:

1. keep the tags as simple words with minimal styling

2. use a different typeface instead of font weight to draw the eye to the param.

Which ever you like better, I’d say they both help our tags, and our documentation in general, do their job well. And now you’ve got two different approaches in your tool belt for a future documentation project!

Let’s end with some key takeaways for your next design project:

How to use this in your next project:

1. Use the guiding question
   Throughout this process, we kept coming back to one key question you can ask yourself: “Does this design help the element do its job?”
   
   If the answer is “no” or maybe “not all the way,” try and spend some time thinking critically about the job of the element and what feels off to you about the current design.
   
   Thinking is just as important as pushing pixels.
   

2. Don’t forget about positioning
   My favorite decision in this design process was placing the tags next to the params.
   
   Positioning and layout may not be the first things you think of when it comes to design, but they’re super helpful tools that can create order and organization. Make sure to keep these tools in mind.

Hopefully this issue gave you a few more tools in your design tool belt and a powerful new question to help you get to the next step in your design process.

Sneak peek 👀

I’m working on an issue dedicated to the very popular, and often default, typeface, Inter.

I want to understand what makes this typeface so special, where it came from, and how it became so widespread.

So I reached out to the creator of Inter for an interview and he said yes! It means creating some of our first video content, which I’m a little nervous but excited about! Stay tuned 🥳

Happy designing!

❤️ Saron

When it comes to lists, particularly text-based lists (ex: documentation or bullets in a blog post), I don’t think much about how they’re designed.

They feel like just another piece of content. I might give the bullets a color, but besides that, they don’t scream out as elements that need much design attention.

What about you?

But every once in a while, I’ll notice a list that doesn’t look like a hastily thrown together <ul> element that I would create.

The list looks … good.

In fact, it doesn’t look like a list at all. It looks like a thoughtful component intentionally laid out on the page. Nothing wild or over-the-top, but just a touch of style that makes it appealing but still highly functional.

I want to learn how to make my lists look like that.

So let’s dig in and see if we can figure out how to style our lists together.

Let’s start with a basic HTML list.

Here’s some unstyled documentation from OpenAI. For simplicity’s sake, I’ve removed the group of words that look like tags meant to describe the param (like “number or null, Optional, Defaults to 1”) that are found in the real docs.

Now, I don’t know about you but, without styling, this list is hard to navigate, if not overwhelming. I’ve only picked three items, but imagine scrolling through a whole page of these – that would be a lot!

So how can we style this list to make it easier for our users?

Remember, we’re not striving for design per se – we’re striving for organization and trusting that good design will come from that.

So let me start by asking you – what about this list makes it feel disorganized?

For me, one thing is the fact that I can’t easily tell each item apart. They all kinda run together as one long, ongoing list instead of a list with distinct items.

How can we fix that?

I have two ideas. Let’s see which one we like best.

Good spacing

Idea #1 is playing with spacing.

The reason why the items flow together is because the space between the lines and the space between the items is the same. Let’s change that.

Let’s make the space between the items bigger. There are several ways you can do this. Since I’m using Tailwind, I’m just going to add the class “mb-8” to the first two <li> items.

Here’s how it looks:

Ahh, that feels so much better!

But I want to try one more thing to see if I can double down on that separation.

Drawing lines

Let’s try idea #2: adding a line between each item, a literal separator.

I’ll do that by adding a bottom border to each <li> element and adding some margin and padding to let the border breathe.

The code looks like this:

<li class=”mb-8 border-b-2 border-gray pb-8”>

Here’s the result:

I like it!

Each item feels like its own, individual entity, increasing the organization of the page.

That’s a great start, but where do we go from here?

Let’s revisit our goal.

The point of better organizing our page isn’t just because we like things neat and tidy – it’s because we want to help our users accomplish their goal.

For documentation, the goal of the user is to quickly understand how to use OpenAI’s API. In order to do that, they have to easily find what they’re looking for, understand how to use it, then get back to their editor and try it out.

In other words, we want to make our documentation “skimmable.”

How do we do that?

The first step is understanding what content we’re working with. We’ve got our list items, but what’s in them?

When our users are busy skimming, what are they hunting for?

Let’s break it down.

Our list items are made of two parts:

1. Param

2. Description of the param

Of these two, the param is the most important one – that’s the thing the user is hunting for. Positioning the param as the first thing you see in a list item is helpful, but besides that, as it stands, we’re not giving our star of the show its deserved spotlight.

Let’s change that and help our params stand out.

Here are three things we could do to our param elements:

• Change the color to make it pop

• Make the font size bigger

• Increase the weight

Let’s try all three and see what we think!

Playing with color

Since one of OpenAI’s accent colors is green, let’s start with that.

This does create that separation between the param and the rest of the information – “temperature” looks distinct from the rest of the content – but changing the color to something bright while keeping the rest of the content black comes with a problem.

While green and black are obviously different, the black is darker, which means it carries more weight. So while we’ve created separation, I don’t think we’ve called attention to the right piece of content, which doesn’t help us achieve “skimmability” in the way we’d like.

Changing the font color to a bright accent color is always a tempting first choice but doesn’t often work out the way we think. If we’re using black for our body, we end up with a colorful header that competes for attention and looks more washed out than distinct.

What if we change the font-size instead? What would that look like?

Go big or go home

Let’s try a bigger text size.

Hm, I guess this kinda works? The params do look distinct, but they don’t stand out as much as I want them to. But if I made them any bigger, they’d look obnoxious.

I’ve found that when I’m trying to emphasize something, increasing the font size rarely works out the way I hope either. I choose going home over going big for this one.

What about you?

And finally, we’ll try our last tool in our toolbelt: font weight.

Go thick or go home?

What would increasing font weight look like? Let’s try it and see!

That looks much better! The params stand out and are much more skimmable. I choose going thick!

But there’s one thing that’s bothering me – those bullet points.

When we started, those bullet points were an important way of letting us know that we were starting a new list item. They helped us organize our list.

But now that we’ve added the border and we’ve increased the font weight on the params, we don’t really need those bullets. In fact, I would argue that they detract from our “skimmability” goal by starting each item exactly the same way. (Fun fact: Tailwind by default actually gets rid of the bullets for you. To illustrate the default <ul> styling for our example, I had to add the class “list-disc” to my <ul> class!)

So let’s remove them.

That looks a lot cleaner. Your eye goes straight to the params, which is what we want.

Final results

Let’s compare the list we started with to where we ended up and take in all that we did.

Before

After

What an improvement! We made a ton of progress with just a few thoughtful design choices. There’s more we could do, but this feels like a good stopping point. If you want to see the code, here’s a link to the gist.

So how do you apply this to your next project?

There’s a lot that went into our final result so I want to highlight some of the big takeaways to bring to your next project, whether it has a list or not:

• You can do a lot with black and gray. 
  We were able to create a lot of organization without reaching for any bright colors. Keep this in mind when designing.
  
  Colors can be a fun and helpful tool, but they can quickly get overwhelming. See if you can make things work with grayscale first.
  

• Understand the user’s job. 
  All the design decisions we made required us to first understand what purpose the list served. We’re writing documentation for an API and the goal is to quickly understand how to use it.
  
  We determined that “skimmability” was the name of the game and we made decisions based on that goal. In the end, optimizing for the job the user is trying to accomplish helped us end up with a design that looks way better than what we started with.
  

• Don’t be afraid to experiment. 
  When I look at great design, I always assume the designer just knew what to do. I personally don’t have the experience to simply know what’s going to work, so I need to try things and assess the results. Initially, this takes time. But eventually, it gets faster.
  
  When I first designed, I used to always reach for color to improve my screens. Now I know to try other tools first and usually end up with better results.
  
  But when you’re not sure, just try it out and see whether it works.

Sneak peek …

Now you might recall that we removed those tags from OpenAI’s documentation to simplify this example. What would the list look like if we added them back in? That’s coming up in the next issue 👀

I know this was a long post, but hopefully it was helpful! Was the length ok or should I try to make it shorter in the future? Let me know what you think! 🙂

Happy designing <3

Saron

I don’t know about you, but I get super overwhelmed when it comes to fonts.

It feels like everything is either Inter or some wacky, bold display font that I’m too scared to use in my own projects.

There’s an ever-growing variety of fonts to pick from and I don’t know what I’m supposed to care about. After a while, all the options in Google Web Font start to look the same.

Luckily, there are some basic principles we can apply to picking a font that doesn’t require us to have good taste, or any taste at all.

So how do you pick? What elements of a font should we care about?

First, it’s important to think about where we’ll use this font. Text is everywhere in our products, but there are three categories that stand out.

The first is headers. This is where we can have some fun. Because headers are generally bigger and used sparingly, we don’t have to worry as much about readability. We can get away with something interesting and funky.

The second is in a body of text. This might be something like an article or documentation. When we’re asking users to consume a large amount of text in one go, readability becomes more important.

The third is in our UI elements. This might include our buttons, icons, navigation, labels, and other secondary information. These tend to be the smallest elements in our apps, so it’s really important to make sure they are readable. When we talk about a font being good for screens, we’re usually referring to this category.

Our products generally include more of the second and third category than the first, so we’re going to focus our exploration of fonts on those two.

But first, let’s start with some basic definitions. We’ve been calling them “fonts” so far, but what about typefaces? And how do these relate to the property “font-family” in CSS?

Let’s break it down.

Font vs. Typeface vs. Font-family

When you go to Google Web Fonts and pick “Inter,” you’re actually selecting a typeface. That typeface dictates the way the characters look, but within that typeface are different styles, like different weights and whether the text is italicized or not. “Font” refers to the individual style. So while “Inter” is the typeface, “Inter 400 italics” is the font.

But in CSS, we don’t have a property for typeface or font – what we have is “font-family.” That property allows us to list the different typefaces our application can use. Although it’s called a “font-family,” it doesn’t actually specify a particular font, only the typeface. Other properties like “font-weight” help us choose a particular style of the typeface.

“Look how tall I am!” The importance of the x-height

There’s a lot that goes into a typeface. Check out this breakdown of the anatomy of a typeface, courtesy of AE2S Communications.

Anatomy of a typeface

That’s a lot of pieces!

Don’t worry, you don’t have to know them all to pick a good font. But there is one that’s pretty important: x-height (can you spot it in the graphic above?). That’s what today’s issue will focus on.

The x-height of a typeface tells you how tall the lowercase letters are compared to the capital letters (the height of the capital letters is called the cap height). It comes from measuring how tall the lowercase “x” is for that particular typeface, hence the name “x-height.”

The x-height is super important for app-building purposes. The larger the x-height, the easier it is to read the text in smaller sizes.

Let’s look at an example.

Let’s compare Futura, a sans serif typeface with a relatively small x-height, to Inter, a typeface with a relatively large x-height.

This visualization shows how x-heights compare, but it’s a pretty contrived example.

Does going from a 59% to a 75% x-height actually make a difference in the context of your app?

Let’s find out. Let’s look at the screen of a mobile app and compare the two typefaces. Here are two versions of the design for The StoryGraph app, one for each typeface.

The tricky part here is accounting for the different font weights. I’ve tried to make them as comparable as possible, but because they come with a different set of styles, some of the text might feel heavier in Futura than in Inter.

But overall, which do you think is more readable? Did the x-heights make a difference to you?

I find that at the smaller sizes, having a slightly heavier weight can increase readability, but where the font weights are the same, the bigger x-height helped me a bunch.

So what are some good x-height typefaces to use for your app? 

There’s a really great video from designer and entrepreneur Mizko called “The Only 8 Fonts UI Designers Need.” While any list like this is pretty subjective, he focuses on elements like uniqueness, x-height, and screen readability to make his recommendations, and they’re pretty solid (although I will note that the correct x-height for Inter is 75%, not 69%).

I picked my favorite three typefaces and implemented them in our mobile app to see how they would look:

All three typefaces are solid choices and you really can’t go wrong with any of them.

Time for a reading break shout out!

If you’re still unsure of what typeface to pick, you can always pick the system defaults. For Apple, that’s the typeface San Francisco (often titled simple “SF”), and for Android, it’s the typeface Roboto. They’re familiar to your users, something they’re already used to seeing, which makes them a safe pick.

Let’s see how those would look:

If you’re not feeling any of these typefaces and want to go with something different, that’s ok too! Whatever you pick, make sure that it’s readable in those tiny sizes and pick a large enough x-height.

But what exactly is a large enough x-height?

The answer to that was harder to find than I expected. Tons of resources tell you to pick a larger x-height, but they don’t actually quantify it.

But from measuring the x-heights myself of the fonts that are considered optimal for a screen, a safe number seems to be 70% or higher.

There are a few other things to consider that can help us narrow down typeface choices, but we’ll get into those in a future issue. For now, let’s focus on those big, juicy x-heights to help keep our interfaces nice and readable.

Happy designing!

Saron

As a non-designer, I always assumed that design was about making things look good. And when it comes to looking good, I think of picking colors, fonts, and layouts that are aesthetically pleasing.

But one lesson from Adam Watham and Steve Schoger’s Refactoring UI that really stood out to me was how “looking good” isn’t all about subjective aesthetic choices. Instead, it’s about organization.

When items on a page look structured, organized, and positioned with intention, they give us a sense of calm and order, and it’s that sense that “looks good.”

How does that make you feel?

Personally, I find this incredibly reassuring. Understanding how to organize information feels much more learnable than having good taste and knowing which font is hot right now.

Instead of trying to make design decisions based on what we think looks good, what happens if we instead base it on what best organizes the information on the page? What would that do for our products? How much easier would design choices be?

To illustrate, let’s style some info on a banking dashboard.

Before you apply any styling, you might start with some simple HTML that results in this:

A row of information surrounded by a light gray border. Simple.

Now let’s do an exercise: before reading onward, think about how you would describe this data to a friend.

What would you say?

You’d probably say something like this: “The balance is $120,103.10”

Did you notice that you basically read the dashboard as is?

This exercise illustrates one of the tendencies of us non-designers – we lay out information the way we would describe it – linearly.

We would say, “The balance is X” so in our app, we write “Balance: X.” Makes sense! But is that the best way to communicate to the user that the balance is x? How else can we do it?

Let’s break it down.

“Balance: X” contains two pieces of information: 1) the label and 2) the data. If you’re the user, which piece of information do you care more about? What is more pertinent?

Hint: It’s not the label.

But by putting the label first in the same row with no other styling, we’re implying that it’s more important than the data. We’re giving it primary status.

So what can we do to better organize this information and make it look good?

The first thing we can do is play with positioning. The fact that the label appears ahead of the data in the same row isn’t helping our organization.

What if we just moved it?

Here are two options:

Putting “Balance” to the right of the data feels a bit funny at first glance, but with a bit more styling, we can probably get it to look right.

But I think I like the “Balance” on top more. It feels like a label but, because it’s in a different row, the data gets more weight. Let’s pick that and keep going.

Another element we can play with is size. Why don’t we try making the label smaller?

That feels better. The label is looking much more like the secondary information it is.

But here’s the thing about font size – the smaller it is, the harder it can be to read. I think it’s still legible here, but I’m going to try uppercase-ing the label to make it a bit easier on the eyes. And because the label and data are on separate lines, I’m going to lose the colon as well.

Let’s see how that looks.

Not bad! I get the hierarchical separation of the label from the data by using a smaller font size but I keep the readability by making it uppercase.

This is looking better, but I want the eye to be pulled to that data, to make it really stand out in a busy dashboard.

What if we introduce some color to help it pop? Since we’re talking about money, green sounds like a great option to play with. Let’s try it out!

Poll time!

For me, changing that color actually had the opposite effect than what I was going for – although the green is brighter, it’s also lighter than the black of the label. So instead of standing out the way I’d hoped, it actually feels a bit more washed out to me.

How can we keep that pop of color but give it more weight? Well, we can literally give it more weight!

Let’s see what that does.

That feels much better.

But I think we can help that data stand out juuuuuuust a bit more. There are two things we can keep playing with: font color and font size.

What if we made the label a bit lighter by using a dark gray instead of the deep black? What would that do?

I like that! It takes the edge off of the label and helps it ease into its supporting role.

The last thing I want to try is to increase the size difference between the label and the data a bit more. I don’t want to make the label smaller because then it won’t be readable, but I can make my data bigger.

Let’s try that.

Now that looks good.

Let’s compare this to what we started with.

Much better.

Now, here’s the thing: we didn’t do anything wild. We changed four things:

• position

• font color

• font size

• font weight

But it’s not the number of things we changed that’s important, it’s the logic we used to make those changes.

What led each decision wasn’t a subjective desire to have it look good — it was a desire to make the information more organized. We optimized for creating a design that helped the user get the data they were looking for quickly and, in that process, ended up with something that looks so much better.

We didn’t try to make it look good – we tried to make it look better organized.

So what do balances on dashboards look like IRL? Here’s how some popular finance companies display this information:

You’ll notice that apart from some dark gray, the IRL examples don’t use colors. What do you think about that?

So next time you’re trying to design something with data, don’t think of designing aesthetically – ask yourself how you can organize the information better, and see if designing gets a bit easier.

What other changes would you try to make it even better?

Let me know!

Saron

PS. Don’t be shy about replying, I love hearing from you! Click “reply” and let me know what you think of this issue :)

PPS. Were you forwarded this email? Feel free to subscribe below to get future posts!

Was I the only one surprised to see gradients make a comeback in a bold new way?

The early Internet had gradients everywhere – a quintessential design element found in backgrounds, fonts, and every place in between.

Check out gradients making an appearance on some famous websites in the 90s:

The boldness of gradients was eventually swapped out in favor of flat design – solid colors and simple lines – in the early 2010s.

Now, gradients are back in full force and they’re louder and bolder than ever.

But to be fair, they never completely went away. What’s changed is the way we use them.

A good way to illustrate the evolution of gradients is to look at two popular logos over the years.

Let’s start with iTunes (now Apple Music).

If we look at the iTunes logo from 2006-2010, we see a preference for skeuomorphism, or the literal representation of objects in our design.

iTunes was all about music, so the logo includes a realistic looking CD.

But in 2010, Apple replaced the CD entirely and introduced a circle with a gradient (it’s probably safe to assume the circle represents that original CD, but it’s not a literal interpretation).

But here’s the thing about this new gradient – it’s not a gradient full of colors the way we see in design today.

Instead, it’s a gradient used to create a 3D effect. The blue circle looks like it bulges out and has a subtle reflection that suggests it’s made of glass. It’s not a literal CD, but it still takes cues from the reflective 3D nature of a CD in the real world.

The 2012 logo is a variation of the same principles – shiny, glass surface with a gradient used to lift the logo off the page.

But in 2014, we see a complete shift.

They’re still using a gradient, but, this time, it doesn’t create that same 3D effect. Instead, this logo is grounded in flat design principles of minimal colors and simpler elements and the gradient is there for aesthetic enhancement.

The 3D note has been flattened to a simple, white graphic and the circle has lost its glassy reflection.

The gradient gives it a touch of personality but it’s pretty subtle – it’s the red-pink color that catches our eye.

But look at what happens in 2015 – the gradient isn’t playing a supporting role. It’s bringing the heat!

By adding multiple colors (we’ve got three packed in a small space – blue, purple, and pink), the gradient is at the forefront, bringing life to an otherwise very simple design.

It’s the smooth blending and melding of the three colors that makes the logo come to life.

Let’s look at the Facebook Messenger logo as another example.

All four logos are very similar and all use a gradient, but they use it differently.

That first logo from 2011 uses a gradient to create that 3D effect. Going from that darker blue to a lighter blue combined with that drop shadow gives the sense that the speech bubble is floating off the page.

But the gradient from 2013 is different – the gradient doesn’t feel like it’s going simply from dark to light – it goes from one blue to a different blue.

We can see this by looking at the HSL values for the two gradients.

HSL stands for hue (the type of color), saturation (the intensity of the color), and lighting (how dark or light the color is).

If you compare the hue values for the two ends of the gradient of the 2011 logo, you’ll see that they’re basically the same (221 vs. 220).

The main difference is the lighting (58 vs. 31).

That tells us that it’s the same color, just a lighter and darker version of it, which is what happens when light bounces off different parts of a 3D surface, suggesting that, here, the gradient is meant to create dimension.

But for the 2013 logo, the lighting is about the same (51 vs. 50). Instead, the difference is in the hue (194 vs. 212). The gradient is made up of two different types of blue, which tells us that it’s not about creating dimension, but more about creating a pleasing aesthetic.

I like the look better, but the blues are still both pretty blue. The gradient looks good, but it’s subtle, giving it a nice effect but still playing a supporting role.

It’s in the 2020 logo where the gradient takes the lead.

It’s another example of using multiple colors (blue, purple, pink) to create a beautiful blend that pops and becomes the dominant aesthetic in the graphic.

It’s tempting to say that gradients are back, but they’ve actually always been here. The difference is that, these days, they’re stepping into the limelight and owning the stage.

Inspo

Want to give gradients a try in your own projects? Here are a few inspired by some popular sites:

Implementing in Tailwind

Tailwind makes it really simple to implement background gradients. Here’s how you’d do that for one of our inspo gradients.

1. Declare your colors
   All of our gradients use three custom colors, called color stops, that are not predefined by Tailwind, so we need to extend our Tailwind config to include them.
   
   If we’re implementing our Stripe gradient, here’s what that would look like:

// tailwind.config.js
module.exports = {
  theme: {
    extend: {
      gradientColorStops: {
        'custom-red': '#F23F56',
        'custom-yellow': '#FFC657',
        'custom-blue': '#90E0FE',
      }
    }
  }
}

2. Use Tailwind classes
   Pick the div you want to have the gradient. If you want to give your whole landing page a gradient, you might want to pick the body tag.
   

   Then apply the following code:

<body class="bg-gradient-to-r from-custom-red via-custom-yellow to-custom-blue"></body>

The “r” in “bg-gradient-to-r” tells us what direction we’re moving in, in this case, to the right. The “from-”, “via-”, and “to-” tell us the order of colors we’re moving through. There’s more you can do with gradients in Tailwind, check it out here.

What do you think of gradients? Are you a fan of the multi-color blends or do you prefer a more subtle application?

Reply and let me know! I’d love to hear your thoughts :)

Saron

PS. If you enjoyed this email, I’d love for you to share it with a friend! And if they like it, they can subscribe here:

Thanks for your help :)