How to: Create a Typographic Hierarchy

Having a strong typographic hierarchy is one of the most fundamental pieces 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.

Pairing (or not)

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 important 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 was weak. It was one font, with the only difference across levels of the hierarchy being size. And those differences were subtle at best.

When deciding to reevaluate 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.

For our H1, I upped it’s size and also gave it a medium weight. For H4, I reduced it’s 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.

Another element we wanted to focus on with our update to the hierarchy was simplification. Previously, our typography included 13 (!!!) header styles. We knew we wanted to simplify that and make it easier for designers and developers to select a style. So we reduced our header count to 5 and then captured additional styles in a “Miscellaneous” category

Ultimately, our typography went from a gradual slide from top to bottom to something that has much more differentiation 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.

Methods & Techniques

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

The Problem to be Solved

In discussions with claims adjusters (our target users) over the course of building v1 of the BriteClaims system, we were made aware that one of the most important things for them to do their job effectively is the ability to keep track of the different tasks associated with all of their claim files.

When building out the BriteClaims system, we knew we wanted to incorporate functionality for claims adjusters to create and track tasks directly inside their claim files in a way that rivaled best in class task tracking tools like Todoist and Asana.

Assumption Declaration

To kick off the project, I got our project team (consisting of product owner, engineers and designer -me) together to do an assumption declaration session. I love kicking off projects with this exercise because it puts all of our collective ideas about what this feature should be out in the open so we can all understand each other’s headspace. It’s also great because it helps lay out the gaps as well.

Perhaps the best part of this exercise is that it forces the team to reframe what they think the feature should be into an assumption. We assume this is what we should build, but we won’t be certain until we validate it.

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 validate that this fits their needs and expectations for a claims system

It’s great to go into a project with a hypothesis like this because it pushes a team to think about what they are building as a potential solution to a user problem that shouldn’t be actively considered for development until it is validated.

Generative Research

With hypothesis in hand, we went full tilt into a generative research phase. This phase included a survey, user interviews and a focus group.


Our survey was taken by 10 of our target users (Claims adjusters, claims managers etc.) Something that drove our line of questioning in the survey was laying out some of our assumptions we had declared and seeing if users agreed that those were things they were interested in seeing in a task management feature.


While collecting survey responses we were simultaneously conducting user interviews (5 participants). With the interviews, we were focused on understanding how users currently tracked their tasks on their open claims and understanding the pain points in their current processes and listening for opportunities for how a new task feature could alleviate those pain points.

I used Google Sheets to track our interview findings which made it easy to take notes in one cohesive spot for each interview and then see the data collectively across the board.

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." 
Focus Group

Another aspect of our generative research was facilitating a discussion with a focus group of our claims users on what a potential task solution should look like. For this session, we asked mainly the same questions as we were asking in the interviews but the focus group nature allowed our participants to bounce ideas off of each other which led to some interesting insights. I would highly recommend to any researcher to pair 1:1 interviewing alongside some focus groups to maximize insights and understanding.


Our generative research phase proved to be incredibly productive in validating some of our assumptions and giving us direction on what to build. From here, I started doing some wireframing and invited the product owner and engineers into some collaborative wireframing as well. These collaborative wireframing 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. Enter, protyping.

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. The design performed well in this test, but again had some difficulty as far as the calendar was concerned which further led us to want to rework that piece.

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.

Lessons Learned

Designing for this feature was an absolute joy because of how much we honored the idea of treating the design like a hypothesis. I worked hard with this design process to create a sense of shared understanding across the team that paid off in a design that met user needs and looked and interacted in a delightful manner as well.

If I could do anything different, I would have spent some more time doing dedicated usability testing alongside our focus group and first click testing for the prototype. I think it could have revealed a few more insights that could have aided in the design. I decided against this because usability testing on a prototype usually has it’s fair share of caveats unless the prototype is incredibly thorough, which is something I tend to shy away from in the spirit of moving a little faster into development.

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

A large element of the claims module in BriteCore is managing contacts that are associated with a claim. These contacts can be insureds, claimants, witnesses and 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”