How to: Create a Typographic Hierarchy

Having a strong typographic hierarchy is a fundamental piece of the design equation for any digital product. Typography is kind of the like the tires on a car. When everything is working well, you don’t really think about it too much. But if something is wrong, then your whole car is at risk of falling apart.

So how do you create a typographic hierarchy that can go the distance? Here are three important things to consider.


Selecting which font or fonts you will use to create your hierarchy is something that can be agonizing if you let it get to you. But there are a few simple things you can do to help make sure you pick the “right” one. I put “right” in quotes there because there is no perfect font for all instances. Different contexts should have different fonts.


User ability to read text is the primary concern when selecting your fonts. Some font choices were designed specifically to be legible on screens (Georgia, Open Sans, Verdana, etc). If you’re designing for a screen, grab a screen friendly font.

Sometimes, it’s okay to veer away from pure legibility for accent text or for branding style purposes (Think “Disney” logo) but you want to build the meat of your typography around legibility.


Selecting a pair of fonts is another great way to build out your hierarchy. A combination you’ll see used often is a more stylized Serif font being used for headers and a more legibility focused Sans-Serif used for body text. It’s also okay to just stick to one font family. But if you do, using styling and size will be of higher importance when distinguishing between levels of your hierarchy.


There are a lot of fonts out there. And they convey wildly different tones. You should select a font or fonts that match the tone of what you are building. You probably don’t want to use a cursive, hand lettering style for a high efficiency digital tool. But that would be great as an accent header for a cozy bed and breakfast website. The best way to test out if your font is working for your tone is to try a handful out until you land in the right place.


The best place to start with sizing a typographic hierarchy is by selecting a base “paragraph” size for text. The most common size you’ll find for this is typically 16px, but depending on what you are applying your typography to, you could scale this up or down.

For instance, if you are building a complex application with lots of moving parts, using a 16px or even 14px can be nice to give your self the most bang for your buck when it comes to screen real estate. On the flipside, if your interface is simpler or less efficiency focused, bumping up your base paragraph size to something like 18px or 20px can really make a difference for your users.

Either way, you will want to start at the paragraph and build your sequence up and down from there. The best way to do this is with a type scale. A type scale acts as formula for you to move up and down in size with your hierarchy without having to spend too much time splitting hairs. Some font scales include:

  • 1.200 – Minor Third
  • 1.250 – Major Third (My personal favorite)
  • 1.333 – Perfect Fourth
  • 1.500 – Perfect Fifth
  • 1.618 – Golden Ratio

To apply your type scale, you would take one your formula (ex: 1.250 Major Third) and multiply your base paragraph size by that number (16px x 1.250 = 20px) You would then do this to your next number (20px x 1.250 = 25px) and so on and so forth. To move down your scale, instead of multiplying your base by your scale number you divide it. (16px / 1.25 = 12.8px)

💡 A great part of using type scales is that they will help define how your font should be set up in CSS if you are using rems.

So using the 1.250 Major third type scale above, we get this nice scale up and down of font sizes we can pick from:


Finally, applying different styles to your type can make a huge difference when it comes to having a solid typographic hierarchy. Some areas where you can tweak the style of your typography are:

  • Color
  • Weight (Medium, Bold, Extra Bold, etc)
  • Italics
  • Capitalization
  • Letter Spacing
  • Line Height

Small tweaks to these styles can go a long way in creating differentiation in your hierarchy. A rule of thumb with style is that you typically don’t need more than one differentiator to make an impact.

Dont: H2 - Extra bold weight, italic, all-caps and with 7% letter spacing
Do: H2 - Medium weight

Lessons Applied – Updating BriteCore’s Typographic Hierarchy

When building BriteCore, our initial pass at typographic hierarchy for the application did not provide much differentiation between different levels but also had lots of variation. This created inconsistency across the experience as far as type was concerned and needed to be addressed.

When reevaluating our typography, I had a few goals in mind:

  • Create differentiation between levels of the hierarchy
  • Clearly define the typography to prevent variation
  • Accommodate the typographic needs of the full, interconnected application

To create differentiation in our hierarchy, I leaned hard into tweaking the styles of each of our levels of the hierarchy. Here are a few of the edits made:

  • H1 – Upped its size and also gave it a lighter weight. This made it the most distinct styling as the only lightweight font, which works great as an H1.
  • H3 – Kept the same size, but given a medium font weight and a lighter recommended coloring. This allows it to keep a heavier weight on the page but remain distinct from the H2 and H4 around it.
  • H4 – Reduced its size to be closer to the size of our paragraph size but instead bumped up the letter spacing to 4% which helped it stand out when being used above paragraph text.
  • Small Text Size – Added a class for small text (14px) and gave this smaller text a 1% letter spacing. Upping the letter spacing of this smaller text allows it to be more legible.

Another element we wanted to focus on with our update to the hierarchy was simplification. Previously, our typography included 6 header styles, and then a handful of editing classes for each of those headers. With this setup, each level of the hierarchy could have a light, regular and medium font weight. Meaning that we ultimately had around 18 different header styles live around the system. 😳

This created a massive amount of variation throughout the product. By removing much of that variation, it allowed our typography to remain more consistent and easier to implement.

Ultimately, our typography went from a gradual slide from top to bottom to something that has much more definition and clarity:

Left: Before, Right: Updated

Case Study: BriteClaims – Tasks


With an emphasis on generative user research and collaborative design techniques, designed a task list system (think, Todoist, Asana, etc.) inside a SAAS claims processing tool. Served as the sole designer responsible for research and UI / UX design. Timeline: 1.5 months

Methods & Techniques

Assumption declaration, hypothesis creation, survey, focus groups, user interviews, wireframing, prototyping, first click testing

The Problem to be Solved

Discussions with claims adjusters (our target users) over the course of building v1 of the BriteClaims system revealed that one of the most important things for them to do their job effectively is the ability to keep track of the different tasks they needed to complete to work on the insurance claims their customers would submit.

Incorporating task tracking functionality directly into the BriteClaims system would empower our users to do their jobs more efficiently and with less error.

Assumption Declaration

To kick off the project, I got our product team (consisting of product owner, engineers and designer -me) together to do an assumption declaration session. This helped our team move forward on the same page about the definition of our fledgling feature and gave us a baseline of ideas to validate with users.

Hypothesis Creation

Once all our assumptions were declared, we collaboratively distilled those assumptions into a hypothesis statement.

After using stickies on Miro to collaborate on the hypothesis creation, our hypothesis was distilled into:

We believe claims adjusters need a way to track tasks so that they can ensure proper protocol has been followed and claims get closed

To support this need, we will build task tracking functionality into the claims system with features like:
- The ability to add tasks
- A filterable list of tasks

We will know this hypothesis is correct if end users workflow is enhanced by this feature and made more efficient and less error prone


With hypothesis in hand, we wanted to validate these ideas with users.

We sent out a survey to target users with a focus on laying out the assumptions we had declared collaboratively and seeing if users agreed that those were things they were interested in seeing in a future task management feature or not.

This survey gave us a view into which of our assumed functionality would be most important to potential users (Due dates, tagging tasks, task priority) which would be extremely helpful for me in knowing what to prioritize when moving into the design phase.


While collecting survey responses we were simultaneously conducting user interviews. With the interviews, we were focused on understanding how users currently tracked the tasks associated with their work, what pain points they were experiencing and what they desired out of a future task tracking solution.

From these interviews, we had a handful of participants mention how helpful it would be to have a calendar integrated into a future task solution. This would inform a large focus of how we would end up designing the feature.

"I'd like to be able select a task on my calendar and drill down directly into the claim." 

"I want a task list with a calendar to live entirely in the claims sytem. If it overlaps with my Outlook / Gmail, then that's ok, but mostly I want it in the claims system." 


When beginning wireframing, I invited the product owner and engineers into some collaborative wireframing sessions. These sessions were great because they allowed us as a team to continue building shared understanding on how we wanted to build this feature.

A technique I used for these sessions was to encourage my team to use screenshots of other tools / software to build out their rough wireframes for what our tasks feature could be. For example, in the screenshot below a team member was playing with the idea of having a task list alongside a calendar so they just screenshotted Google Calendar and put it alongside another roughed out task list.


After going back and forth on some wireframes for a while, we got our ideas to a point where we were ready to polish them and start looking into how some interactions might work with our tasks feature.

I used Figma to build out some higher fidelity mockups for how this feature could operate as well as using Figma’s built in prototyping tools to illustrate how the software should interact and behave.

You can see this prototype for yourself here.

Our final design for the tasks feature was made up of three main parts:

  • Search bar / header
  • Task list
  • Filter menu

The task feature itself lives inside a right sidebar that slides over to reveal itself when the tasks icon is clicked. This allowed the tasks function to be accessible anywhere inside a claim file without the user having to lose context of where they were when accessing the tasks list.


Our final phase before feeling ready to start developing our design into live software was to evaluate the polished designs with our end users. For this, we took our design back to our focus group and gave each participant a link to the prototype and asked them some questions about it’s design and if it included all the elements needed to allow them to successfully track their tasks.

Following this we had some tweaks that needed to be made. we reworked our calendar component to be more focused on ranges of dates as opposed to a calendar and also were able to clarify some logic around the completion and cloning of a task.

We also prepped a first click test which was sent out to the same audience as our initial survey to further evaluate the usability and discoverability of the design we created. In one of our first click tasks with users, we asked them to click where they believed would complete an open task. We had ~30% of our users click on the batch selection item, which led us to incorporating a batch completion feature into the design that wasn’t there initially.

Following these evaluations, our team felt ready to start building out our first development version of this feature. I wrote up the stories needed to support its development and put it into our backlog.


Following our design process we had:

  • Strong shared understanding across a product team on what we assumed an integrated task tracking functionality needed to be.
  • A testable hypothesis to deliver functionality against.
  • Validation of our hypothesis from direct conversations and data collected from users.
  • A prototype that had been evaluated by users for usability.
  • Stories written for development to build the feature.

Case Study: BriteClaims – Vendor Management


Using a collaborative design approach and a focus group based validation method, built out a vendor management tool inside a SAAS claims processing application.

Methods & Techniques

Assumption declaration, wireframing, prototyping, focus groups

The Problem to be Solved

When claims adjusters are working on an insurance claim, one of their primary responsibilities is managing contacts that are associated with a claim. These contacts can be insureds, claimants or vendors. Collectively, these contacts are often called ‘parties’ in a claims system.

Vendors represent contacts that provide a service for a claim (auto repair, property inspection, consultation, etc.) and require payment. Since vendors act as points of contact and potential payees on a claim, their management inside a claim file needs to be handled carefully.

Continue reading “Case Study: BriteClaims – Vendor Management”

How to: Start a User Research Practice From Scratch

It’s your first day as a user experience designer at a new company. You’re excited not only to design and prototype and pretend you’re more font savvy than your more experienced peers, but also to dig in and start doing some user research. You ask the rest of the team what kind of user research they do. You are met with some waffling around the topic but the answer makes itself clear to you. There is no user research being done.

I’m assuming I’m not the only one this has happened to. You’re hired on as a user experience designer and the existing team or business does everything but talk to the end user. Instead of being discouraged, take this as an opportunity. You are going to build a user research offering. The question is, how?

Continue reading “How to: Start a User Research Practice From Scratch”

Bad Design Trends to Leave Behind

It’s a more exciting time than ever to be designing the digital frontier. And why shouldn’t it be? Americans on average are spending upwards of 10 hours of time looking at digital content on screens a day. For better or for worse, digital design is the future.

It’s fitting then to focus on bringing digital design into the future. Namely, by looking at what we need to leave behind.

Continue reading “Bad Design Trends to Leave Behind”

Case Study: Addiction Services Center (Full Site Design)


Did a full site design and branding refresh for an addiction services center

Methods & Techniques

User story mapping, wireframing, prototyping, logo and asset design

The Problem to be Solved

eXclusive Services provides a handful of vital services to those struggling with addiction in the Cincinnati area. They are also the only group in the Cinci area providing primary care medical services alongside addiction services. The eXs team was wonderful and when they cited their need for a UI/UX designer, I was happy to jump headfirst into helping them build a solution. eXs needed a new, modern website to help communicate the services they offered to their potential clients.

The site would need to be easy to update as the eXs team had no easy way to update their old site in its current state.

The eXs team was also looking to update some of their branding to be more versatile.


The solution we landed on was to create the eXs team a new WordPress site. WordPress would afford us the flexibility to quickly design and develop a solution that was powerful enough to encompass the full scope of the new site we were designing but also give the eXs team a simplistic CMS to make any changes to the site going forward.


Building a full site in a weekend certainly creates a challenge. Every second is vital when running on such a tight timeframe. Our small team size, while advantageous for shared understanding, also required our skill sets to be stretched to create the needed solution.


Having such a delightful and talented team made the pressure of delivering a great solution in the timeframe of a weekend not only possible, but a lot of fun too.

Mac (Myself) – Design

Beverly & Suraj – Developers

Markku – Project Manager

Lakshmi, Erin & Ron – Forms & Additional Dev

Tracy & Sean – eXs Team

L-R: Sean, Tracy, Erin, Beverly, Mac, Suraj, Markku, Lakshmi, Ron

Activities Responsible

Getting a whole site off of the ground in the span of a weekend gives an excellent opportunity as a designer to build upon a variety of skills.

My first role as a designer on the project was to work with the eXs team and Markku, the project manager, on understanding the scope of what we were building. The eXs team came to SWOGC prepared and with already validated assumptions of their user base’s needs which helped us quickly get an idea of what exactly we would need to build and (more importantly) what we could put aside and not spend time building. This involved drawing out rough sketches of UI possibilities and charting out a site map.

After turning our story mapping session into a Scrum board, my next task consisted of creating rough wireframes of each view we were looking for. I took these wireframes and turned them into a clickable prototype using Marvel which allowed our team to get a really solid visualization of the solution and get fully aligned before we even wrote a line of code. These wireframes would continue to be tweaked as we revised our solution.

As our developers began working on setting up the backend of the site, I began working with the eXs team on developing some new branding for the site. I am not a logo designer, but I have an eye for consistency and decided to spin up a very simple text based logo using Roboto Slab from Google Fonts. Add in a couple of lines on top and bottom of the text and you’ve got yourself a versatile logo system.


We also determined the site would use the Roboto Slab font for headers and Open Sans for body text. Nothing beats a FREE serif / sans-serif font pairing right? After we grabbed some colors that the eXs team had already been using, we felt we had a solid branding put together. I then pivoted back into working on translating our wireframes into high fidelity mockups.

I built our high fidelity mockups directly on top of the wireframes that had already been made. This allowed me to update our clickable prototype on Marvel in real time. This was my first time using Marvel as prototyping tool and it won’t be the last. I love the snappiness and speed of Marvel’s editor and it’s Sketch plugin works wonderfully.

Hi-Fi Mock of eXs landing page

With high fidelity mockups in hand, the developers went to work coding them into reality. Some difficulties here were encountered in battling our selected WordPress theme, but with all hands on deck testing the site as it came together our team was able to quickly and efficiently tackle bugs and fixes. Getting a refresher on the joys and terrors of WordPress development is always fun.

We also worked with the eXs team to find content to fill the site. The eXs team is working to get a photographer into their facility to get some personalized content onto the site. But until then, we decided upon some great, royalty free stock photography. Thanks Pexels!

With the final hours of our weekend long race to the finish, we squashed bugs, optimized for speed and tested, tested, tested.

Lessons Learned

A website is never technically finished, but we are very proud of the solution we delivered to the eXs team and I’m grateful for the experience of getting to work with them and the lessons I was able to learn.

Givecamp was a crash course in just how valuable time is to the delivery of a digital product. When you have only a few days to deliver a solution, every second matters. However, I am astounded at how much time we saved by NOT cutting any corners.

You would think that when time is so tight, skipping wireframes and going straight to hi-fi mockups would have been the way to go. However, I can’t imagine our team would have landed on as solid of a solution as we did as fast as we did had we not followed a design process that involved low fidelity mockups first.

I was also again reminded that a UX designer’s role involves wearing many hats. It’s just as important to be able to ideate and clarify the scope of a project as it is to be able to build out prototypes at a rapid pace.

Check out our finished site at! I’m excited to return to the SWOGC next year and I highly recommend you check it out as well!

Design Principles Learned From Playing Halo

I have recently been playing a lot of Halo studying the design of the Halo series and have been struck with how the elements at play in a game like Halo can inform user centered design in any field.

The ultimate goal of any video game is that its users are enjoying themselves. This is what determines whether a game is good and if it sells any copies.

Imagine if everything we designed had this same goal? What if we designed everything with the mindset that if it wasn’t enjoyable to use, it would not be a success? As simple as it sounds, it’s deceptively hard to do.

Continue reading “Design Principles Learned From Playing Halo”

Case Study: Designing a Better Mobile Navigation

I was reminded during last week’s Apple Keynote reveal extravaganza of one of the more obscure features of iOS.

It was on the slide where they were discussing the iPhone’s home button where there was a brief mention made of “Reachability”.

With two taps to the iPhone’s TouchID sensor (See: Home button), the bottom part of your screen is folded down, giving you easier access to the top part of your screen. This was implemented in 2014 with the iPhone 6 and has quietly existed inside iOS ever since.

Continue reading “Case Study: Designing a Better Mobile Navigation”