Is this information really needed in the design?

If not, try to cut it down.

In UX design, this principle has a catchy name — progressive disclosure. It’s about showing only what’s necessary upfront, and revealing more details when needed. Components like dropdowns, accordions, tabs.

Expandable cards are all examples of progressive disclosure in action. They share many similarities with accordions, but with a more flexible, card-based structure that fits certain layouts better.

What is a card? Expandable card vs accordion

Let’s address the elephant in the room. We use card a lot in user interface, we see them everyday. But, what is a card? Like many other design elements, there is no clear definition of it. Each design system has a different way to use and to define things.

But if we boil it down, it is simply:

A card is a UI container that visually groups related information into a compact, scannable block.

The idea comes from real life—business cards, credit cards. These objects organize information into neat pieces you can quickly read and compare. Digital cards do the same thing on screen.

So what makes a card different from an accordion or other expandable components? A card must:

• It must group different types of information into a bite-sized container.
• It must also resemble a physical card, meaning it should have a visually distinct border, such as a line, color, or shadow.

In fact, an accordion can be designed as a stack of cards—but the concept of a card always starts with how it looks, not how it acts.

The Anatomy of an Expandable Card

1. Visual divider

After all, what truly defines a card is its visual divider. Whether it’s a border, a background, or a shadow, a card needs that boundary to be recognized as a card.

2. Trigger Indicator

An expandable card without a trigger indicator feels like a regular card. Users won’t expect it to expand, which can catch them by surprise and lead to confusion.

As an old saying goes:

Good UX is predictable.

We need some gestures, unmistakable, to tell users that there is something more here. We have arrow icons, plus/minus signs, and finally: caret icons.

Recommendation: A caret is the most reliable choice. While a plus icon is popular, it may be confused with an “add” function. An arrow, on the other hand, can be mistaken for a “jump to” or “open” action.

In some cases, when the revealed information is not secondary and is simply an extension of the original content—like a list or text—you should use a “More” label instead.

3. Summary Information

This is the part users see first, so it must give them the key details they need at a glance.

The summary should be scannable and self-explanatory, allowing users to understand the context without expanding the card. Most users won’t expand the card, so the summary needs to include the essential information they rely on most.

But what counts as “essential”?

Only your users can tell you. Talk to them. Observe them. See whether they frequently expand the card or rarely touch it. Their behavior will show you exactly what needs to live in the summary and what can safely remain hidden.

A tip for designing summary information: you should have a hook—such as an icon, image, or short title—helps anchor their attention and quickly communicate what the card is about.

4. Additional Information (Expanded Content)

Reveals related or secondary details connected to the main summary.

Keep it short and relevant. If the expanded content is too long, you should consider using other type of progressive disclosure like popup or guide users to another page.

Layout

There are two common ways for design expandable cards to behave: overlay expansion and inline (non-overlay) expansion.

An inline expandable card grows in place, pushing the surrounding layout downward as more content appears. This approach is more common for it’s easier for responsive design.

An overlay expandable card, on the other hand, reveals additional content on top of the original card while keeping its footprint fixed. This prevents the layout from shifting, which is useful in dense grids or dashboard views where expanding one card would disrupt the entire structure.

When You Should Use an Expandable Card

When users need only a few pieces of information on the page, they will likely skip most of the content. Hiding most of the content on the page helps users spend their time more efficiently by focusing on the few topics that matter.

1. Most users don’t want or don’t need the content

Use it when most users only need the summary, and only some need the full details.

Good examples:

• A product card that expands to show technical specs
  
• A task card that expands to show subtasks or notes
  
• A profile card that expands to show contact methods
  

2. When you want to keep the user on the same page

If switching to a detail page breaks flow, expanding the card can preserve context.

Examples:

• Reviewing multiple small profiles
  
• Comparing metrics across several items
  
• Browsing items where depth is shallow
  

Inline access helps the user evaluate multiple items quickly.

When Not to Use Expandable Cards

Expandable cards can easily break your UI if used carelessly.
They take up space when expanded and can disrupt scrolling or layout consistency.

Avoid using them when:

• Most users will expand every card anyway (use a list or table instead).
  
• The expanded content is large, complex (you need to make interaction with the expanded content).
  
• The layout depends on consistent card sizes (e.g., gallery or dashboard).
  

Alternatives:

• Accordion (for structured content lists).
  
• Modal or drawer (for more complex interactions).
  
• Tooltip or hover card (for lightweight context).

Conclusion

Expandable cards are a useful way to keep your interface clean while still offering more details when needed. They work well when most users only need a quick summary and only a few need the full information. But they also require careful design—because expanding a card can affect layout, content flow, and how users move through the page.

Use expandable cards when they help users focus and stay on the same page. Avoid them when the hidden content is too long, too complex, or when every card will be expanded anyway.

In the end, good design is about showing the right amount of information at the right time. Expandable cards are just one option—choose them only when they truly make the experience simpler, not more complicated.

Good design hygiene is often overlooked, but it highlights your attention to detail. It’s one of the qualities that defines a great UX designer, shows that you care and are a professional in your field. 

Some may think it takes time and does not add value to your workflow. Does it really matter?

A simple project can become messy over time, especially if multiple people contribute and team members change. While it may be tempting to skip naming conventions for quick, small projects, it’s important to establish them for larger projects that involve multiple designers or require ongoing maintenance.

Even for smaller projects, adopting naming conventions can help reinforce design best practices.

Disclaimer: There is no right or wrong way to name things in Figma. The naming convention depends on who you work with and your team’s naming guide. What’s right is what works best. 

How you should name your design also depends on which stage of designing you are in. In the beginning state, where you just play around with ideas, you don’t even have to name anything. 

The bigger and the more mature your system is, the more you have to take notice of the naming. There are 1000 ways to name things, but we can definitely start somewhere, this is it. 

Who will use your design? 

The most suitable naming convention depends on who will use your design. In my experience, developers do not care much about how you name things. They only see and copy the parameters, not the components’ names. So naming layers according to BEM (a CSS naming convention) is not making any sense. 

I’ve noticed many users name components in Figma using formats like “.something__like–this” or “$just-like-this.” These styles are not practical for Figma’s current system. If needed, it’s best to mention this in the component description.

Most of the time, its users will be you and others who will maintain it, like other designers in a team.

You have to name it in a way that helps you find and maintain it later. 

Many people forget that Figma is primarily a design tool, meant for designers who use it most often. It’s not a coding tool. Tools like Storybook and the “Design API” are there to help convert what Figma creates into code with proper naming conventions.

My approach 

If your team does not have a naming convention, you can start with this. Without any standard, these are my internal rules for the design file. 

Each frame on a page is named based on its most general purpose. For example, all buttons are labeled simply as “Button,” Text elements are named according to their function, such as “Title” or “Description.”

When elements have varying properties influenced by their parent elements, I ensure that my naming is more specific. For instance, a title may be labeled as “Card Title,” “Section Title,” or “Accordion Title,” depending on its context. 

The key is to be as descriptive as possible also try to be simple and consistent. 

For outer frames that primarily function for layout, I use simple labels such as “Container,” “Row,” “Column,” “List,” or a plural noun. When a frame is designed to resemble a card, I just label it as “Card.”

If the container comprises only two types of elements, I try to be more descriptive by naming them as element 1 + element 2. In this case, because the autolayout contains only icons and text, I name them ‘Icons + Input Text.’

I take a similar approach with components. Since we all use variants, most components should just have simple names, like “Button” for buttons.

This makes it easy for your team to find what they need and helps our engineers understand the designs quickly.

Camel case, title case or sentence case

From my experience with design systems, usability is the most important aspect, especially when creating something in Figma. Camel case just isn’t as easy to read as title case.

Camel case is helpful for naming variables and functions in coding as they don’t allow space or tabs in identifiers.  If the people who work with layers most of the time are the designers, why do you want to name it for the developers? 

When it comes to using title case or sentence case, there aren’t any studies that clearly show which one is better for readability. Personally, I prefer title case because it looks more professional, has a nice visual flow, and stands out better. It makes sense to use title case for short, descriptive titles.

On the other hand, sentence case feels more casual and works well for longer text. You can go with either style, but just make sure to stay consistent!

See more about the comparison between title case and sentence case in this article

Talk to your developers!

There’s a common belief that designers can create a perfect handoff for developers by organizing everything in Figma and naming layers well. But that’s not really how it works.

Every developer has their own way of interpreting designs, and each project is different. To really get it right, you need to talk with your developers. Ask them how they like things organized and named. Find out if your efforts are helpful and whether your naming aligns with front-end standards. Learn how they turn Figma designs into code and what kind of documentation they need. 

Basically, at the start of every project, the best practice is to talk to your developers before doing anything else. This is all about having a conversation. It’s important to understand what developers want and adjust your approach accordingly.

If you’re practicing for a handoff without working with developers, you might be setting yourself up for failure. Naming conventions and processes need input from the development team.

If you deliver a well-organized design, like UntitledUI, without talking to your developers first, you could be wasting your time. The best way to learn how to work with developers is to collaborate with them, not just focus on naming layers.

You’re doing the right things, but you need to change the order. Start with conversations before getting into the details.

The best way to create a smooth developer handoff is to step away from the internet and talk to your team directly.

Conclusion

There are no strict rules for naming layers in Figma. It’s important to talk with your team to understand their preferred naming practices. Your naming approach can vary based on the project’s size and stage. If you’re just experimenting or working on a small, personal project that won’t scale, you might skip detailed naming.

However, in my experience, getting it right from the start can save you trouble later. If your team doesn’t have any naming practices, you can begin with the suggestions in this article and tweak them to fit your needs.

Typography system

Break points

Spacings and font sizes

PC (1700px)

Tablet (835px)

Mobile (393px)

Spacings & Text sizes

So, how do we make things user-friendly? Presenting a design to users is like introducing yourself; you need to communicate who you are and set the right expectations. We as UX designers need to help users understand where they are and what they need to do next. 

Toggle switches are efficient, they save space by controlling two mutually exclusive options with a single control. Despite their popularity, toggle switches usually fail to fulfill the first rule: to inform users of its current state. 

Where did GUI (Graphical User Interfaces) toggle switches come from?

GUI toggle switches come from physical switches like light switches that we use at home. These light switches operate with two mutually exclusive states, such as “On” and “Off.” 

When computers started using pictures and graphics, designers wanted to make something similar to those light switches for software. They created digital toggle switches that work just like real switches, letting people easily turn things on or off in apps. This makes it simple for everyone to understand and use.

Digital switches also adopt the physical switch characteristics that their interaction is instantaneous. 

One significant advantage of light switches is their visual indication of the current state, which is determined by the room’s brightness rather than the switch’s position. For instance, flipping the switch in a dark room turns the lights on, while flipping it in a lit room turns the lights off. This surrounding environment provides immediate feedback, making it clear whether the lights are on or off.

While some software toggles, like the Dark Mode toggle, offer similar cues, many others lack immediate feedback regarding their enabled or disabled states, which can lead to confusion.

I have noticed that there are two types of toggle that usually cause challenges for users when not used right: toggle switches and toggle icons. 

1. Toggle Switches

Toggle switches let users toggle between “On” and “Off” states, just like regular light switches do in real life.

One challenge with these switches is clearly conveying their current state. One common solution has been to place labels inside the switches, but it’s clear that this hasn’t been very effective.

With this design, can you tell which state the switch is currently in? Is “ON” an action or a state? If “ON” is a state, why is it displayed at the switch’s off position? For those of you familiar with this design pattern, it might seem like an easy question. However, for others, it can be quite confusing. You can only figure it out correctly because of the switch’s color, which indicates that it’s in an active state.

How about this situation? Where there is no color as an indicator, the question becomes incredibly more tricky. 

This physical switch is no exception. Its state is still not clear and the label inside the switch also doesn’t help. We still do not know if the on is a state or go-to action. reading “on” next to a toggle could mean “this toggle is turned on” or “click here to turn it on” there” .

So what can we do to deliver a better switch without ambiguity?

No On Off label at all

You can simply use a brightly colored switch to indicate when it’s on. If the label inside the switch only serves to confuse users, why include it at all? 

However, this design choice could pose challenges for individuals with Achromatopsia, a form of color blindness where people see only shades of gray. While this condition affects approximately 0.0033% of the population, it’s important to consider it if you aim to create an inclusive product.

Adding tooltip/ toast message 

Adding tooltips is a great way to clarify toggle switches. However, if the product is a website or intended for mobile use, this may not be the best approach since tooltips typically require a hover action.

In this case, a toast notification could be more effective. It provides immediate feedback upon interaction, informing users about the switch’s state while remaining unobtrusive enough to ignore if they choose.

Showing both label outside

Displaying labels outside the toggle switch is an effective way to clarify its function without relying on color. By placing the labels outside, there’s no chance for confusion. The switch’s state is clear, whether ‘On’ and ‘Off’ are used as adjectives or adverbs. OS X has successfully employed this design and eliminated any ambiguity. 

Change state label position

Microsoft has recognized this issue and moved the label outside the toggle switch.

However, the labeling remains ambiguous: since the ‘Off’ label is on the right and the toggle dot is on the left, users might mistakenly interpret the switch as being ‘On’ (moving away from the ‘Off’ label).

According to Gestalt Principles of proximity, we tend to perceive elements that are close together as belonging to the same group. To improve clarity, we can position the ‘On/Off’ labels closer to the switch description, as shown in this example:

Here, the ‘Off’ label is associated with the switch description rather than the switch itself, allowing ‘Off’ to function strictly as an adjective rather than an adverb.

A better approach is to change the phrasing. In this example, instead of using the standard ‘On’ and ‘Off’ labels, the alarm app utilizes ‘Tomorrow’ and ‘Not Scheduled’ to eliminate any confusion regarding the state or action.”

2. Toggle icon 

Products frequently utilize toggle icons to switch between options beyond just ‘On’ and ‘Off.’

Toggle icons, such as a plus sign (+), chevron, play, or pause, signify interactive elements that can toggle between two states. When clicked or tapped, these icons typically change in appearance, such as expanding or collapsing a section, revealing or hiding additional information, or switching between different views or modes.

However, toggle icons can sometimes cause confusion. Some icons indicate the current state, while others represent an action. For instance, the play/pause icon reflects the action that will occur, while the dark mode/light mode icon shows the current screen state.

Another common example is the eye icon, which is often used to toggle the visibility of elements like passwords. Different systems may have varying conventions for these icons, adding to the complexity. Generally, the eye icon indicates the action ‘show,’ as seen on platforms like X.

You can still find other systems that use the eye icon as an the current state indicator, like on the Adobe Cloud login page.

Such ambiguity is the bane of many UX designers’ lives. What’s the best choice? Does it impact how effectively users complete the form?

I think the eye icon poses more of a challenge for designers than for users. The reason is simple: much like a light switch, the cues indicating whether it’s on or off come from the surrounding context, not the icon itself.

For instance, do you ever check the position of a switch before turning on a light? Probably not. People typically assume the switch is off when the room is dark, so there’s no need to check. This can lead to confusion in tasks like turning on a light in another room or adjusting the water heater, as we don’t see immediate effects.

When you see dots in a password field, you can tell that the password is hidden without relying on the eye icon. The same logic applies to light/dark mode toggle icons.

State indicators can extend beyond visual cues. For instance, with the play/pause icon, the state is represented by the music or sound from your device. You can determine whether the audio is playing simply by listening, without needing to rely on the design itself.

Action or state? 

If the toggle represents an action, such as Play/Pause, it should indicate what will happen next. For example, while paused, it should display “Play,” and when playing, it should show “Pause.”

Conversely, if the toggle represents an option, like Shuffle/Linear, it should reflect the current state.

Using segmented control

If the toggle icon represents an option, consider using segmented controls. Segmented controls are ideal when all options need to be visible simultaneously for easy comparison. 

On the other hand, use toggle icons when space is limited and you want to offer a compact way for users to switch between states.

Adding label 

If the toggle icon isn’t immediately clear or could be ambiguous for users, adding a label can provide essential context and help them understand its purpose. For example, on Mailchimp’s login page, the eye icon is accompanied by the label “show,” indicating that it represents an action.

Using checkbox instead

Many of you may be familiar with the guideline that checkboxes require a second confirmation and do not take immediate effect like toggle elements. However, in certain situations where clarity is a priority, you can still use a standalone checkbox. This approach is also referenced in the M3 design system. A standalone checkbox can be used to execute an immediate action.

Conclusion

Toggle switches or icons in products need to be clear about what they do and what state they are in. 

To achieve this, we must consider various design strategies, such as eliminating ambiguous labels, utilizing color cues, and providing contextual feedback through tooltips or notifications. The distinction between action-oriented and state-oriented toggles is crucial.

But remember, whether a toggle element shows an action or a state can be a personal choice, as there is still conflict among designers and many design systems have different approaches. I am not trying to dictate what you must or must not do. As long as the buttons work well, apps can create their own rules for how they look. What’s most important is that they are consistent in their design.

Design is all about questioning the usual ways of doing things and seeking better solutions to both new and old challenges. Without this challenge, there is no progress.

Without it, we would still be painting the same shapes on the same cave walls, not daring to think it can be done differently.

Crafting a well-designed piece with good readability is nuanced, skillful, yet straightforward. Despite this, many designers still struggle with it. Have you ever visited a website and felt frustrated by its tiny font, inadequate contrast, or poor font choice?

How can you improve readability so your message gets across clearly?

What type of design are you going to make?

Before we dive into how to ensure your design’s readability, it’s crucial to determine if your design is text-heavy or interaction-heavy.

Text-heavy design (such as articles, blogs, and news) focuses primarily on reading.

Interaction-heavy design (like apps, feeds, and forms) prioritizes user interaction or quick skimming instead of deep reading.

For example, a blog post falls under the text-heavy category, while a contact form or dashboard is considered interaction-heavy.

In text-heavy designs, the primary aim is to ensure that the text is comfortable to read for extended periods.

Conversely, interaction-heavy designs focus on presenting information clearly and efficiently, allowing users to easily view and understand the relationships between text elements.

If you design for long-form content, such as blog posts, you have to take into account eye fatigue and much more about readability.

When you design for interaction-heavy design, you need to make the text easy to scan, have a good design hierarchy, be concise, and be quickly understood. 

Typically, this means that text-heavy pages end up with slightly larger font sizes than interaction-heavy pages. 

How we read text-heavy design

According to the Nielsen Norman group, people read in 3 ways: Casually, scan with purpose, and in an engaged manner.

Casual Reading: This is when readers skim through the text, picking out words and sentences to get a general idea of what it’s about. They spent time on the product image, read the first few sentences, and quickly scanned the bullet points. 

Purposeful Scanning: In this style, readers are looking for specific information. They jump from one section to another, sometimes just reading a word or the first few letters.

Engaged Reading: Finally, when readers find something they like, they slow down and read the entire text, often getting lost in it. Their eye movements are more steady, with more time spent on the text and less jumping around.

Micro typography and macro typography

Micro and macro typography is crucial for creating effective, engaging, and visually appealing designs that communicate effectively.

Micro typography refers to the fine details of typography that enhance readability and overall visual appeal, such as font choice, letter spacing (kerning), line spacing (leading), and font size. It focuses on the arrangement and treatment of individual characters and words.

Macro typography, on the other hand, deals with the larger structural aspects of typography. This includes the choice of layout, white space, hierarchy of text elements (such as headings and body copy), and overall composition of a page or screen. It emphasizes the broader context in which text is presented, impacting how information is organized and perceived.

Micro typography

Font family

Tip: choose a popular font with multiple varieties. You can not go wrong with it. There are some fonts are created for readability, to name a few: 

• EB Garamond
• Montserrat
• Inter
• Work Sans
• Lato
• Times New Roman
• Calibri
• Noto Sans
• Open Sans
• Roboto
• Arial
• Merriweather
• Helvetica
• Georgia

You need to prioritize fonts that have clear and distinct letterforms. Avoid highly stylized or decorative fonts that may sacrifice legibility for aesthetics.

There is no single best font for all users. Some studies show there are clearly groups of fonts that perform better than others. But to pinpoint the best font – the holy grail of readability is impossible. 

Each person with a different reading behavior and age will have a different most suitable font. The only solution for this problem is personalization to present individual users with text in the font that’s best for them.  Of course, this is just a fun suggestion as presenting users with ever-changing fonts will cause many other problems to arise. But who knows? The future is full of possibilities, maybe one day we will have an answer to this problem

Serif or Sans-serif?

Sans-serif fonts like Arial, Helvetica, and Verdana are often preferred for their clean and modern look, especially in smaller sizes and on screens. Serif fonts like Times News Roman, Bodoni, and Garamond are famous for their professional look.

Apart from differences in the mood that they create, as I have stated above, there is almost no difference in readability between them.

Countless studies have been conducted to shed light on this comparison. However, the results are about the same: either the differences turn out to be statistically insignificant, or the Sans-serif font is slightly ahead of the serif.

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4612630

The small advantage of San Serif is they may be a little easier to read for some people with dyslexia.

Font Size

As always, you want to start by knowing whether you’re designing a text-heavy or interaction-heavy page. The minimum font size is not fixed, it depends on the context and devices. For example, when designing for smart TVs, of course, the minimum font size will be much much bigger because the distance between the user and the screen is so far. 

The further the device is from your view, the bigger the minimum font size has to be. 

Bellow are minimum font sizes for desktop

• For interaction-heavy designs, your minimum font size should be 12px
• For text-heavy designs, your minimum font size should be 16px

Bellow are minimum font sizes for mobile

• For interaction-heavy designs, your minimum font size should be 10px
• For text-heavy designs, your minimum font size should be 14px

Choose a font size that is large enough for comfortable reading. For body text, a font size of around 14-16 pixels (or equivalent) is the minimum requirement.  You should avoid using font sizes that are smaller than 12px. In some rare situations, you can use 10px for small labels that only have 1-5 characters if the hierarchy of the text is not important. 

Letter Spacing

Opt for fonts with adequate letter spacing (also known as tracking) to ensure that individual characters are distinguishable and do not blend together. Avoid fonts with excessive or overly tight letter spacing.

If you are not accustomed to adjusting letter spacing, it is best not to change the default settings. Instead, choose a font with good letter spacing as the default.

Font weight

Generally, avoid using light or bold weights for long-form content. For larger and shorter text (i.e., headlines), lighter weights are easier to read. For longer and smaller text, it is better to use regular weights and reserve heavier weights for emphasis. 

This approach also falls in line with studies that show people don’t read, they scan copy online.

Stay away from all Cap text

All cap texts have bad legibility because their forms are too similar. We can quickly recognize text thanks to its shape. Mixed-case text has a variety of shape forms, which help us better identify each word. 

There are still cases where all-cap fonts are acceptable. Such as when you use it for short labels, only 1-3 words. And you want it to stand out to other texts. 

Color contrast

Black and white are the best for readability. However, a white background sometimes can cause eye fatigue for users when reading for a long time. In this situation, you can consider using dark mode with white text on a black background or using a more subtle background like off-white.

See more on this article

Macro typography

Be generous with white space

I spend a lot of time iterating to adjust the design’s white space. When used appropriately, it can create flow, and balance, and guide users through the design in alignment with the designer’s intent.

More precisely, white space helps attract users’ attention to the content within it, whether it be cards, text, or images and creates a visual divider between sections.

As designers, our job is to guide users’ eyes through our design with minimal effort. The more important a design element is, the more white space it should have around it. Conversely, the more closely related the elements are, the closer they should be positioned to each other.

You can find more in-depth information on this topic in this article.

When optimizing your text content, it’s crucial to consider heading margins, paragraph margins, and line spacing (the gap between each line).

Common values for heading margins, paragraph margins, and line spacing can vary depending on the design and style of a document or website. However, some typical values are:

Heading Margins: Heading margins are often larger than paragraph margins to visually separate headings from the content below. Common values can range from 10px to 40px or more, depending on the design.

Paragraph Margins: Paragraph margins help create space between paragraphs for better readability. Common paragraph margin values range from 10px to 20px.

Line Spacing: Line spacing, also known as line height, refers to the vertical space between lines of text. The rule of thumb is that for long-form content, the line height should be 150% of the font size. Too little line height will make content mingle together. Too much line height will make the lines floating apart from each other.

Consistent formatting

Maintaining consistent formatting is crucial for enhancing readability and improving user experience. Here are some key points to consider:

Font Styles: Use a limited number of font styles (typically one or two) to create a harmonious visual identity. Mixing too many fonts can lead to confusion and distract the reader.

Color Schemes: Stick to a cohesive color palette for text and backgrounds. Avoid using too many colors, as this can create visual clutter. For text color,

Spacing and Alignment: Consistent use of spacing (margins, padding, and line height) helps create a clean layout. Proper alignment of text (left, center, or justified) can also impact readability and visual flow.

Clear visual hierarchy

Font Sizes: Establish a clear hierarchy by using different font sizes for headings, subheadings, and body text. For example, headings should be larger and bolder to draw attention, while body text should remain smaller and easy to read.

Use bullet points and lists: When presenting information that can be easily structured into lists or bullet points, use them to enhance readability and make content easier to scan.

Clear and concise paragraphs

Break up large blocks of text into smaller paragraphs to improve readability. Aim for concise and focused paragraphs that convey a single idea.

Body text should have 50-75 characters per line

For text-heavy designs, if you know how large your main column of text is, that can help you figure out the best font size to use. Simply put, you want 50-75 characters per line. Why? It all has to do with “tracking from the end of one line to the beginning of the next”.

If you have fewer than 50 characters per line, readers can spend too much time tracking and not enough time reading

If you have more than 75 characters per line, readers can find it difficult to track from one line to the next

Responsive design

Design layouts that adapt well to different screen sizes and devices, ensuring readability is maintained across various platforms.

Based on this article, here are some items you may include in a readability checklist:

1. Design Type

• Identify if your design is text-heavy (e.g., articles, blogs) or interaction-heavy (e.g., apps, forms).

2. Font Selection

• Choose a legible font family with clear letterforms.
• Consider popular fonts known for readability (e.g., Arial, Helvetica, Georgia).
• Avoid overly stylized or decorative fonts.

3. Serif vs. Sans-serif

• Decide between serif (e.g., Times New Roman) and sans-serif (e.g., Arial) based on context and audience.
• Be aware that while sans-serif may be easier for some, both can be equally readable.

4. Font Size

Minimum font sizes:

• Desktop: Interaction-heavy (12px), Text-heavy (16px)
• Mobile: Interaction-heavy (10px), Text-heavy (14px)
• Ensure body text is comfortable to read, typically 14-16px.

5. Letter Spacing

• Use adequate letter spacing to enhance readability.
• Avoid excessively tight or loose letter spacing.

6. Font Weight

• Use regular weights for long-form text and lighter or bolder weights for headings.

7. Case Usage

• Prefer mixed-case text for better legibility; restrict all-cap text to short labels.

8. Color Contrast

• Ensure sufficient contrast between text and background (black on white is ideal).
• Consider alternatives like dark mode for extended reading.

9. White Space

• Use generous white space to create balance and guide the reader’s eye.
• Adjust headings and paragraph margins for clarity.

10. Consistent Formatting

• Limit font styles to one or two for visual consistency.
• Maintain a cohesive color scheme and proper alignment.

11. Visual Hierarchy

• Use varying font sizes for headings, subheadings, and body text to establish hierarchy.
• Utilize bullet points and lists for easy scanning.

12. Paragraph Structure

• Break text into concise paragraphs of 50-75 characters per line for optimal readability.
• Avoid large blocks of text.

13. Responsive Design

• Ensure your design adapts well across different devices and screen sizes.

Before exploring the optimal color combination for UI design, we must familiarize ourselves with some key terms.

What is color luminance contrast?

Luminance contrast is all about the difference in brightness between visual elements. Our eyes are highly skilled at detecting and differentiating these variations in brightness.

When it comes to human perception, luminance contrast holds more significance than hue differences. This is crucial because luminance contrast allows us to create content that is visible even to users with color blindness.

Vision fatigue versus readability

Vision fatigue and readability are not exactly the same thing. They are related concepts, but distinct in important ways.

Readability refers to how easily and comfortably text can be perceived and understood by readers. Elements like font size, typeface, contrast between text and background, and overall layout impact readability. It focuses on ensuring that text is clear and legible for users.

On the other hand, vision fatigue refers to the strain and discomfort experienced by our eyes during prolonged visual tasks, such as reading text on a screen. Factors like screen brightness, glare, text size, and color combinations can contribute to vision fatigue over time.

Although high readability is crucial for minimizing vision fatigue, they are not interchangeable terms. Text can technically be readable but still cause significant eyestrain if the visual presentation is poor.

Therefore, you need to take into account both readability and eye fatigue-reducing aspects of the color combination in the design. 

Colors and readability

When it comes to readability, the luminance contrast between the text and the background is key, rather than the specific color combination.

There are no specific maximum thresholds for color contrast when it comes to readability. The higher the contrast between the text and background, the better the readability becomes.

This means that using pure white text on a pure black background or pure black text on a pure white background will achieve the best results in terms of readability. These extreme contrasts provide optimal legibility and ensure that the text stands out clearly against the background.

There is still debate surrounding the use of pure black text on a pure white background, as well as the reverse. Some argue that such extreme contrast can lead to eye fatigue and create an unbalanced design. While there are valid points to consider, studies have shown that higher text contrast actually improves user accessibility. It is only in specific situations that text contrast should be reduced, which I will discuss below.

Colors and vision fatigue

A recent study published in Behaviour & Information Technology examined the effects of various text-background color schemes on important outcomes. You can find the study here:

https://ieeexplore.ieee.org/document/9363189

Once again, the study demonstrates that higher contrast levels are more effective in reducing user eye fatigue.

Now, let’s address the concerns about pure black text on a white background. Some argue that this combination can cause eye strain and make it difficult for users to read for extended periods. The argument stems from the fact that white is 100% brightness while black is 0, creating a significant difference in color brightness that can lead to intense light levels overpowering the reader. Additionally, when scrolling, the eyes have to work harder to adjust.

My take is they are completely wrong about this.

Using lighter text is generally acceptable for younger individuals. However, as people reach middle age and beyond, their ability to adjust focus from far to near distances diminishes, and the lens of the eye undergoes a gradual hardening process that can lead to cataracts later in life. In this context, reading gray text for extended periods can cause eyestrain among older individuals, contrary to the experience of younger ones.

Not to mention, many eye conditions will cause problems when reading low-contrast text. 

Of course, there is nothing wrong if the grey text has enough contrast according to APCA. However, reducing text contrast to increase accessibility is misleading and should not be encouraged. 

Is high contrast ever the problem?

No, the issue lies not with high contrast itself, but rather with the poor design of many interfaces.

One common problem is the choice of fonts used for texts. Often, these fonts are not suitable for screens. The font size may be too small or its design is bad for readability. Increasing the font size is generally a good solution, but some fonts do not scale well.

Another issue is insufficient white space. When using high contrast, it is essential to increase the spacing between features such as borders, decorations, and icons.

The mentioned study also supports these points, highlighting that higher contrast leads to better results. On the other hand, low-contrast text can significantly contribute to eye fatigue. This is because low contrast requires the pupils to dilate more to perceive the text clearly, leading to visual strain over time. Moreover, low contrast makes it harder to focus on and resolve the text, reducing visual acuity and increasing the cognitive load, thus contributing to visual fatigue.

On the other hand, the high-contrast text allows the visual system to operate more efficiently, reducing strain on the eyes and visual processing, and minimizing visual fatigue. Therefore, maximizing the contrast between text and background is an important design consideration for displays with negative polarity, aiming to minimize visual fatigue for users.

The truth for “high contrast” and “light mode” cause eye fatigue

The debate between light on dark versus dark on light is not definitively settled in the scientific community. There are advantages and personal preferences associated with both options and ambient conditions also play a significant role. Exploring this topic in depth would require a more comprehensive article.

Furthermore, it is worth noting that many issues often attributed to “excessive contrast” are actually related to “excessive luminance.” You can read more about the problem in this study. 

https://www.thinkmind.org/articles/achi_2024_3_150_20069.pdf

In summary, the main finding is that dark mode on smartphones can help reduce eye fatigue, but this benefit is primarily observed in bright ambient lighting environments. The display polarity (dark vs. light mode) did not have a significant impact on eye fatigue in dim lighting conditions.

While the sample in this study is small and may need larger-scale tests to produce more trustworthy results, it’s still consistent with some of the studies in the literature on how reducing excessive luminance will reduce eye fatigue such as: 

T. Sethi and M. Ziat, “Dark mode vogue: Do light-on-dark displays have measurable benefits to users?” Ergonomics, vol. 66, no. 12, pp. 1814–1828, Dec. 2023.

X. Xie, F. Song, Y. Liu, S. Wang, and D. Yu, “Study on the effects of display color mode and luminance contrast on visual fatigue,” IEEE Access, vol. 9, pp. 35 915–35 923, 2021, publisher: IEEE.

The reason for low contrast design

While it’s not desirable but low low-contrast text still exists in many designs nowadays for some reasons: 

Aesthetics

Low-contrast text designs may be used for aesthetic purposes, even if they are less optimal from a visual fatigue perspective. Some designers may prioritize a certain visual style or mood over maximizing contrast.

Easing the eyes

Another potential reason is the idea that low-contrast text could be “easier on the eyes” in some situations. While the research indicates high contrast is better for reducing fatigue, there may be a perception that softer, lower-contrast designs are more soothing or comfortable to look at.

Take note that users may prefer some color contrast but that doesn’t mean that the contrast is optimal for them. 

Establish visual hierarchy

When it comes to labels or other short-form content that doesn’t require much attention or reading time, designers often de-emphasize it by using a smaller font size or reducing the color contrast.

Other contextual factors

There may be other contextual factors, beyond just aesthetics and eye strain, that influence the choice of low-contrast text designs in certain applications. For example, following brand guidelines or stakeholder’s preferences,…

Working as a designer, you must compromise between options. In other words, you have to balance between business goals and user goals. 

For people with dyslexia

Some people with dyslexia have reported seeing unstable or “jumpy” letters when using high-contrast settings. And that is the only valid reason for having low contrast mode. However, we don’t fully understand the specific impact of this phenomenon, and there is variation among individuals, source: https://www.sciencedirect.com/science/article/pii/S0042698900000419

So we can say it is still difficult to establish a direct link between contrast sensitivity and dyslexic reading performance.

Moreover, reducing text contrast may enhance the reading experience for individuals with dyslexia by reducing visual strain, this approach comes at the cost of diminishing the reading experience for those without dyslexia. 

My suggestion is to set high contrast as the default option. To assist users, we can provide a function that allows them to reduce text contrast. This can be achieved by offering alternative themes or incorporating a slider to adjust the contrast level.

Solution

There is nothing wrong with pure black text on a pure white background. I recommend starting with a high-contrast design as default. If you want to have a low-contrast mode, you can give users the option to change to that from a high-contrast mode. 

Always use minimum contrast according to APCA. 

When users have to use the product for a long time, for many hours, you can consider providing the ability to switch to dark mode. 

In the case where text is not the main point in the design, for example, when you have other elements, you can reduce the contrast to make the design more balanced. 

What color combination is best for accessibility? 

When it comes to accessibility, the best color combination is typically black text on a white background. This high-contrast pairing ensures clear visibility and readability for most individuals. This combination is preferred by both people with and without dyslexia. 

However, if you want to reduce screen luminance, there are alternative options. Instead of using pure white, you can consider using off-white, light yellow, and creme as the background color. These alternatives can help lower the overall brightness while still maintaining a sufficient level of contrast for readability.

As one of the most successful elements, buttons have made their way into user interfaces. Since then, numerous studies have been conducted to determine the best practices for button design. This article will focus on the best practices and techniques for designing button groups.

About button hierarchy

First, it is essential to understand the different types of buttons and their proper usage.

Button hierarchy involves categorizing buttons based on their level of importance. Depending on the design system being used, different names may be assigned to each level of importance.

In most cases, a three-level hierarchy suffices. According to M3 (Google’s design system), these levels are high, medium, and low emphasis. Alternatively, in some other design systems, they may be called primary, secondary, and tertiary.

There are four main types of buttons: filled buttons, toned buttons, outline buttons, and text buttons.

Filled buttons have a strong visual impact. They should be used for important actions that complete a flow, such as “Save,” “Join now,” or “Confirm.”

Toned buttons provide a middle ground between filled and outlined buttons. They are useful when a lower-priority button requires slightly more emphasis than an outline can provide, for example, “Next” in an onboarding flow. Or use it when you want to de-emphasize a filled destructive button. Some design kits avoid toned buttons because other types already provide sufficient hierarchy.

Outlined buttons are of medium emphasis and represent important actions that are not the primary focus of the app. They pair well with filled buttons to indicate alternative or secondary actions.

Text buttons are used for the lowest priority actions, especially when presenting multiple options. They are often embedded in components like cards, dialogs, and snack bars. Text buttons do not have a visible container in their default state, ensuring they do not distract from nearby content.

1. Button group orientation

A button group can be either horizontal or vertical in its orientation. You should only use the vertical option when horizontal space is limited. 

For example, when designing on mobile. Otherwise, it’ll create a lot of unnecessary white space. 

On mobile, where users tend to use horizontal scrolling, you can stack multiple buttons vertically and stretch them.

2. Button order – The primary button should stay in in the corner

Where do you place the primary button in a button group? left? right? top? bottom?

There is no right or wrong answer to this. It is more about making a call and sticking to it. Having worked in multiple design systems, this is my take. 

Button groups can be left-aligned or right-aligned depending on the context or preferences. However, whatever alignment you choose the primary button should be in the corner.

Imagine it’s like this, when there is only one primary button, it’s in the corner. 

So, to be consistent, the primary button – the most important button should stay where they are when adding other buttons. 

If the buttons are fluid (extend to fill their parent container), the primary button should be on the left. 

When buttons are arranged vertically, there are two scenarios: they can either scroll along with the content or remain fixed at the bottom. Regardless of the number of buttons (1, 2, or 3), applying the previous rule, the primary button should remain in the same position when adding other buttons. Can you guess where it is?

If the buttons are scrollable, the primary button should be placed at the top. However, if the buttons are fixed to the bottom, the primary button should be positioned at the bottom.

When the button group is vertically aligned in the middle, the primary button can be placed on either the left or right side. However, I prefer it to be on the left.

. 

Note: There is no evidence of which kind of button alignment performs best in bring-in conversion. There are still feuds among designers that argue whether you should place the primary button on the right or left. You can read more in this article:

https://www.lukew.com/ff/entry.asp?571

Different design systems may have varying conventions regarding button placement, with some placing the primary button on the right and others on the left.

Regardless of the chosen convention, it is crucial to maintain consistency throughout the interface. If you opt for placing the primary button on the right in a modal, it is important to stick to this arrangement consistently.

The reason behind this alignment choice is to achieve visual balance. By positioning the most important button where users expect it to be, you enhance the user experience and facilitate seamless interaction.

3. Button group alignment

Button groups are aligned contextually. In general, button groups are left-aligned to follow content such as a block of text. They are center-aligned in the context of an empty state. And, they should be right-aligned inside container components such as dialogs, popovers, or cards.

The order of button priority should match the alignment of the surrounding text. When text is left-aligned, buttons should be arranged so that the leftmost button is the most critical. When text is right- or center-aligned, the most critical action should be the furthest right.

4. Number of primary buttons in one view

The primary button conveys a high level of emphasis and should be used for actions that are crucial to the user experience.

There is a debate in some circles regarding the usage of multiple primary buttons in a single view. However, this argument is applicable only in ideal situations where there is only one main action we want users to take.

It is possible to use more than one primary button in the same view, but I recommend a maximum of three. Multiple primary buttons can draw attention to important actions and establish a clear hierarchy.

In situations where you have more than three actions of similar importance, it can become challenging to display them all as primary buttons. In such cases, you should consider using multi-secondary or tertiary buttons to prevent overcrowding in the design.

5. Button group style

When arranging multiple buttons together, it is crucial to ensure that users can easily differentiate between them. This means there should be a clear contrast between a filled button and a filled-tone button if you decide to combine the two.

All buttons should have a cohesive look as a group, which means they should share the same color scheme and design style. It is best to avoid mixing round pill buttons with box-shaped buttons.

6. Button group spacing

It is important to provide adequate spacing between the buttons to prevent users from mistakenly selecting the wrong one. As a rule of thumb, I usually recommend using a spacing of 16pt to ensure clarity and minimize any potential confusion.

7. Button matching

Following are some of the most common ways that you can match between primary, secondary, and tertiary buttons. 

Primary with secondary

The combination of primary and secondary buttons is the most common. It is used when you have two actions for users to choose from, with one being more important than the other.

Primary with primary

This combination is less common but might still be necessary when you have two equally important actions. In such cases, you can choose to use two or more primary buttons.

But it’s not a good idea to use multiple primary buttons. When designing a system, you need to consider not only the current screen but also anticipate future scenarios. Will you need to add any additional buttons that require more emphasis? If not, using two or more primary buttons side by side can be a viable option.

For example, in the scenario mentioned above, the login buttons have similar levels of importance. The solution would be to design them as multiple primary buttons or multiple secondary buttons.

In cases where there are only two or three primary buttons, you can use different colors for each button to make it easier for users to distinguish between them.

In Figma design software, it is the same way. There are two equally important actions: creating a Figma file and creating a Figjam file. In this case, these two actions are represented by two primary buttons placed side by side, accompanied by a secondary button next to them.

Since the “Create Figma file” button is used more frequently, it is positioned on the edge.

Secondary with secondary

This is a more common choice compared to using primary buttons together. If you have multiple actions with equal importance, using multiple secondary buttons is the most appropriate option.

Using primary buttons together may create too many focal points and potentially disrupt the design balance.

Primary, secondary and tertiary

As the name suggests, if you have multiple actions to display, and they are ranked in order of importance from top to bottom, you can use this group of buttons.

Primary and tertiary

There is one important action and one less important action.

Secondary with tertiary

Two actions that are not very important, but one action is more important than the other.

8. Make it harder to find destructive buttons

You may have encountered this abomination if you are an HP Probook user. 

The power button on the keyboard is positioned in the middle and is too close in proximity to other function buttons like delete and print screen. Many people have accidentally pressed this button and unintentionally shut down their computer screen while working.

The destructive button should be placed further away from the group of function buttons to prevent accidental clicks.

If you do need to include destructive buttons, it is important to make them less prominent than the primary action button. For example, you can make them appear less like buttons, smaller in size, or even present them as links. This way, users who intend to cancel or perform negative actions will actively search for them, while users who are focused on their tasks won’t be prone to making serious errors.

Hide buttons when there is too much action

According to Hick’s law, the time required to make a decision increases as the number and complexity of choices available grow. Therefore, it is important not to overwhelm users with too many options.

To address this, we can employ a technique called progressive disclosure in UI design. This involves gradually revealing information and options to users, allowing them to focus on the most relevant choices . You can do so by using:

Overflowing actions

In cases where you have tight spaces and multiple actions, you can overflow actions into a menu triggered by a button.

Action grouping

You can group similar actions into a menu button or a split button. A menu button with a designated, primary action is a split button.

Limit the group of actions to 7 or less. Remember to place the less frequently used actions in the form menu.

Conclusion

When it comes to arranging buttons, there isn’t one “best” way. But whatever way you choose, it’s important to stick with it and be consistent. One way to be consistent is by lining up buttons in a way that fits with what’s around them and putting the most important button in the corner where it stands out.

You also need to think about what users need to do and which actions are the most important for them. Some actions might be less important or even harmful, so you can make those buttons look different or put them further away to guide users.

If you have a lot of buttons and you don’t want to confuse people, you can use a trick called “progressive disclosure.” This means you show only a few buttons at first and then reveal more as people need them. It helps prevent people from feeling overwhelmed and lets them focus on what they need to do.

WCAG 2 is designed to be user-friendly and easily understandable for everyone. However, its simplicity is also its major drawback. It only considers the luminance contrast of colors, disregarding how humans perceive them. In other words, WCAG 2’s mathematical approach lacks perceptual accuracy and fails to align with human perception.

This method can lead to issues for readers in certain situations. It is unsurprising, considering that WCAG has been around for over 15 years. While it has served its purpose well, it’s now time to embrace a more effective approach.

How does the WCAG 2 ratio work?

WCAG 2 provides guidelines for contrast ratios to ensure sufficient visual accessibility. The contrast ratio measures the difference in luminance between text or images and their background. WCAG 2 specifies minimum contrast ratios for different levels of accessibility compliance.

For normal text and images, the minimum contrast ratio requirement is 4.5:1 against the background. This ensures that the content is easily readable for most users. However, for larger text or images, such as headings or captions, a lower contrast ratio of 3:1 is acceptable.

WCAG 2 also considers contrast for user interface components and graphical objects. These elements should have a contrast ratio of at least 3:1 against adjacent colors to ensure they stand out and are distinguishable.

To sum up, the higher the contrast point is, the easier it is to read content. 

However, the contrast issue is more nuanced and complex than what can be captured by a single ratio. While WCAG 2 provides guidelines for contrast ratios, there may be situations where these ratios do not adequately address the accessibility needs of all users.

Failure of WCAG 2: The notorious orange button and others

Which button has a higher contrast point according to WCAG? 

For most people, the button on the right is more readable. So if you guessed the button on the right has a higher contrast point, you are not alone. Still, in reality, the button on the left is more “accessible” according to WCAG.

This is a common issue with orange buttons or other colors that have vibrant hues. 

It’s crucial to recognize that not everyone will find white text on a black background easier to read. Different individuals have varying vision abilities and preferences, influenced by factors such as age, conditions, impairments, equipment, environments, and personal perceptions of what is considered normal.

Nevertheless, studies have indicated that a significant majority of users prefer and experience less difficulty when reading white text on an orange background compared to black text. 

Ericka O’Connor has conducted a throughout test on this problem. About 60% of the participants found it easier to read white text on an orange background and 40% preferred black text.  While we can not confidently say that white text on orange is always better, we can say that the math in WCAG2 is flawed.

There are numerous other instances where WCAG contrast ratings appear to fall short of meeting our needs:

During an independent study conducted by a PhD researcher at Cambridge in the UK, around 5,000 colors were analyzed as part of the peer-review process.

It was discovered that approximately 47% of the colors that passed the WCAG 2 criteria should have actually been rejected due to their lack of readability. 

Conversely, about 23% of the colors deemed non-compliant were found to be perfectly readable and even more suitable for individuals with color vision impairments.

How is the WCAG contrast ratio calculated?

The WCAG contrast ratio is determined by a mathematical calculation based on the relative luminance of two colors.

To calculate the WCAG contrast ratio, we use the relative luminance, which represents the light output and is typically expressed as a number between 0 and 1.0. A value of 1.0 represents the intensity of white.

The term “relative” is used because it measures the light intensity in comparison to white.

The contrast ratio is calculated using the following formula:

Contrast Ratio = (L1 + 0.05) / (L2 + 0.05)

In this formula:

L1 represents the relative luminance of the lighter color.

L2 represents the relative luminance of the darker color.

The relative luminance (L) of a color is determined by the following formula:

L = 0.2126 * R + 0.7152 * G + 0.0722 * B

In this formula:

R, G, and B are the red, green, and blue values of the color, respectively, normalized within a range of 0 to 1.

The resulting contrast ratio value falls within the range of 1 to 21. A higher contrast ratio indicates better distinguishability of text or content for individuals with visual impairments.

For example, if a green color has a coefficient of 0.7152, it means that the green is 71.34% as intense as white at the same level of stimulus. The same principle applies to the red and blue colors.

What’s the problem?

We don’t linearly perceive light to its intensity.

Instead, some sources refer to the human perception of light as “lightness.” This perception is not linear but rather perceptually weighted. Under low light conditions, our vision is more sensitive to small changes in light compared to higher light conditions.

WCAG is limited in its ability to take these factors into account. The suggested calculations by W3C make certain assumptions and weight red, green, and blue color values differently in terms of brightness. These weights are only approximations and represent colors at full saturation, which may not accurately represent the full range of colors encountered in practice.

Furthermore, different screens may display your orange color as brighter or darker, but the formula used by WCAG can only provide a single number for contrast calculations. For example, this formula would not be suitable for printed documents as “bright” colors like white do not have the same luminosity they do on digital screens.

Traditionally, green appears disproportionately brighter on most screens, leading to a higher weighting. Since your orange color contains a significant amount of green, reducing it slightly can help meet the AA contrast requirement without significantly altering the color. This difference may even be imperceptible to you and your users.

How we perceive color contrast

Our eyes can perceive colors thanks to light-sensitive cells in our eyes, which are called cones. 

65% of the cones are sensitive to yellow/ green, but they also respond to red. Around 30% of cones are sensitive to green, while only 5% are sensitive to blue. Even though there are fewer blue-sensitive cones compared to the other types, they are highly sensitive, which helps compensate for their lower numbers.

But how do we translate color to contrast? 

The key here is luminance. When it comes to reading, luminance is crucial.

Luminance refers to the lightness or darkness of a color without considering its specific hue. Interestingly, most of what we see is not focused on color. Our vision system primarily relies on luminance to capture fine details and detect edges. It’s like having a dedicated black and white channel in our brain called luminance, which processes information first.

Color, on the other hand, is processed a bit later, with a delay of about 70 milliseconds. That’s almost like a two-frame delay in a film. As a fun fact, it takes around one-fifth of a second (200 milliseconds) from the moment light reaches your eyes to the point where your brain perceives it as an image. So, what you see at this very moment actually happened a fraction of a second ago.

What is the better way?

Exciting news! WCAG 3 is on its way to replace the current guidelines. It will bring a better algorithm called the Accessible Perceptual Contrast Algorithm (APCA), created by Andrew Somers. APCA is based on research about how humans perceive visual information, so it provides more accurate recommendations. Sometimes, APCA may suggest using opposite colors for text (like white instead of black) compared to what WCAG 2 AA has recommended.

The problem with WCAG 2 guidelines is that they oversimplify things by giving pass or fail ratings. However, contrast is a complex subject, and one approach doesn’t fit everyone’s needs, especially when it comes to font size.

How is APCA different from WCAG2?

One main problem is that the numbers produced by WCAG 2’s contrast calculations don’t match how humans perceive contrast for optimal readability. On the other hand, APCA is designed to be more accurate under human perception, providing consistent contrast predictions across the entire visible range. WCAG 2 sometimes artificially inflates contrast values to compensate for these limitations. APCA, however, doesn’t require such adjustments and offers precise contrast predictions, allowing designers to choose from a wider range of colors.

APCA guidelines are better suited for different scenarios and sizes of elements. For instance, when it comes to body text, higher contrast is necessary for better readability, and APCA takes that into account. Body text has a higher spatial frequency and demands the highest contrast level. 

But what about other elements like buttons? WCAG 2 enforces similar contrast requirements for all elements, which can be challenging for designers. In contrast, APCA, being perceptually accurate, recognizes that larger elements like buttons can still maintain readability with lower contrast, such as Lc45 or even as low as Lc30. This provides designers with more flexibility while ensuring that the content remains easy to read.

Another different aspect is unlike WCAG 2, when you exchange the colors of the text and background, it has an impact on the outcome.

This is logical if you consider it – since text occupies a smaller visual area, it naturally has lower contrast.

If you want to dive more into the mathematical aspect, check out this post. 

How to apply APCA in your design

For starter, you can access this website to calculate contrast point.

Unlike WCAG, APCA doesn’t categorize contrast ratings as pass or fail. Instead, APCA uses a sliding scale that varies across the visual range and takes different use cases into account, as different uses have different contrast requirements.

These general levels are sufficient on their own, without the need for a lookup table. APCA measures contrast using an Lc value (lightness contrast) ranging from Lc 0 to Lc 105+. When it comes to accessibility, Lc 15 is considered the point where many users may find text invisible, especially for thin lines, and Lc 90 is the preferred contrast level for body text.

Here are some specific levels for different types of text:

Lc 90: Recommended for smooth text and columns of body text with a font size of at least 14px/weight 400 (normal).

Lc 75: The minimum level for columns of body text with a font size of at least 18px/400. Lc 75 should be considered the minimum for text where readability is important.

Lc 60: The minimum level recommended for content text that is not body, column, or block text. In other words, text that you want people to read. The minimum values are based on the reference font Helvetica: 24px normal weight (400) or 16px/700 (bold).

Lc 45: The minimum for larger, heavier text such as headlines (36px normal weight or 24px bold). This is also the minimum for pictograms with fine details.

Lc 30: The absolute minimum for any text not mentioned above. This includes placeholder text and disabled element text. This is also the minimum for large/solid non-text elements that are semantically meaningful and understandable.

Lc 15: The absolute minimum for any non-text element that needs to be discernible and distinguishable, and is at least 5px in its smallest dimension. This may include disabled large buttons. Designers should treat anything below this level as invisible, as it will not be visible to many users. This minimum level should be avoided for any items that are important for the use, understanding, or interaction of the website.

These are the basic minimum levels, similar to the A/AA levels in the old WCAG 2. To achieve the equivalent of AAA, simply increase the contrast values by Lc 15. Keep the contrast below Lc 90 for large fonts in dark mode.

In a nutshell: 

15 – 🚫 Minimum for non-text elements

30 – ⚠️ Absolute minimum for any text

45 – ‼️ Minimum for large text (the old 3:1)

60 – ❗Min for body text (the old 4.5:1)

75 – ✅ Preferred level for body text

Is it essential to change?

Implementing a new standard can be challenging and complicated, especially when dealing with a complex system like APCA that has no clear pass or fail indicator.

From what I can observe, we are likely to have a lengthy transition period ahead of us. This wouldn’t be a problem if WCAG 2 was universally understood and consistently applied as a baseline, but unfortunately, that’s not the case. Most websites currently do not even meet WCAG standards, and I believe this situation will persist in the foreseeable future, even with the introduction of a new standard.

Considering this, I believe WCAG still holds its place in the design world for its simplicity and ease of application, particularly regarding contrast requirements. However, once you grasp the concept of contrast and have the opportunity to enhance the user experience further, I recommend considering a switch to APCA.

In the meantime, I suggest approaching the current WCAG contrast calculations with some caution. While it’s important to comply with them if necessary, I also encourage you to test your color combinations using APCA for a more assured level of accessibility.

While you can improvise along the way, having a streamlined method for auditing design work is often helpful. That’s where a UI audit checklist comes in.

The UI audit checklist serves multiple purposes. Firstly, it helps identify areas for improvement, bugs, and potential issues. Secondly, it ensures that the designs meet the user’s needs. And lastly, it plays a crucial role in ensuring the design is aesthetically pleasing.

In this article, I’ll share my personal UI audit checklist, which you can easily adapt to your design project. So, feel free to use it as a starting point and customize it to suit your specific needs.

1. Identify the audit goal

The first step in conducting a UI audit is to identify your specific goal or goals. Here are a few examples:

• Business/Interaction-related Goal: This focuses on specific user actions or behaviors directly impacting your business objectives. For example, you might want to increase the percentage of visitors who sign up with their email address by 10% or improve the conversion rate for a specific interaction.

• Brand-related Goal: This revolves around your brand’s overall perception and personality. You may want users to feel that your brand is casual, friendly, knowledgeable, or professional. 

• Visual-related Goal: This relates to the visual aesthetics and style of your UI design. You may want to make your design more modern or adopt a minimalist approach, aligning with current design trends.

• Other Goals: There may be additional goals specific to your project, such as enhancing usability, improving accessibility, optimizing performance, or addressing specific user needs.

By clearly defining your UI audit goals, you can focus your evaluation on areas that directly contribute to achieving those objectives. This will help you conduct a more targeted and effective audit.

2. Understand the users’ needs and goals

Every product you make, you make it for users. So it’s important to align your decision-making with users’ goals. 

Before you start auditing the UI, it’s essential to truly understand your users—their needs, their goals, and what drives them. To gain this understanding, consider the user/customer journey as your guide. Take a close look at each step they go through and identify areas where you can make improvements.

As you delve into the user/customer journey, keep an eye out for opportunities to add or tweak elements and UX content that can enhance their experience. Think about how you can provide helpful cues, streamline processes, or optimize the design and content to make their journey smoother and more enjoyable.

3. Ask what’s truly necessary/needs to be changed, and cut the rest

The next crucial step is identifying what is truly necessary and requires changes while eliminating anything unnecessary. This step helps streamline and refine the UI design to ensure it aligns with the desired goals and objectives.

To begin, carefully evaluate each aspect of the UI design. Ask yourself if it serves a clear purpose or if it contributes to the overall user experience. If certain elements or features are not essential or do not add value, consider removing them to reduce complexity. Or you can consider using progressive disclosure. 

By cutting out unnecessary elements, you can declutter the UI and improve its clarity, simplicity, and functionality. 

4. UX Writing Audit

UX writing MUST come first to avoid crafting a beautiful package unable to respond to customers’ real expectations. After all, it’s not a good idea to stuff writing in an existing design. In the worst-case scenario, you have to change the entire design to fit with the content. 

Here’s an audit checklist for reviewing UX writing:

Clarity and Conciseness

• Is the UX writing clear, concise, and scanable? (Do you provide users with more information than necessary? In most situations, you should aim to cut down on information instead of adding them)
• Does the text effectively communicate the necessary information to the user? (You should use words that users are already familiar with, like “cancel”, “confirm”,..)
• Are complex terms and jargon avoided or adequately explained?

Taylor Dykes from NNGroup has explained how to write more concisely in this article.

Consistency and Tone

• Is there consistency in the tone and voice used across the user interface?
• Does the tone align with the brand’s personality and the target audience?
• Are there any inconsistencies in terminology or language choices?

User Guidance and Instruction

• Does the UX writing provide clear instructions and guidance to users?
• Do tooltips, hints, and onboarding messages effectively assist users in understanding the interface and its features?

Microcopy and Call-to-Actions (CTAs)

• Are microcopy elements clear and actionable, such as button labels and form field placeholders?
• Do CTAs use persuasive and meaningful language to encourage desired user actions?
• Are CTAs consistently styled and positioned throughout the interface?

Error Handling and Feedback

• Are error messages clear, and specific?
• Do they provide actionable steps to resolve the issue?
• Does the UX writing provide feedback to users after completing actions or tasks?
• Are success messages or confirmation dialogs appropriately displayed to provide a sense of completion?

Localization

• Have localization considerations been taken into account, ensuring that translations maintain the intended meaning and tone?

5. Colors Audit

Color Consistency

• Are the colors used consistently throughout the UI?
• Do the colors align with the brand’s color palette and guidelines?

Color Psychology and Meaning

• Do the chosen colors align with the intended message or emotions of the UI?
• Are the colors appropriate for the target audience and purpose of the UI?
• Are there any conflicting or confusing color associations?

Contrast and Readability

• Is there sufficient contrast between text and background colors for easy readability?
• Do the color choices meet accessibility standards and guidelines?

Visual Hierarchy and Focus

• Are important elements appropriately emphasized through color choices?
• Do the colors guide the user’s attention to key actions or information?

Color Combinations and Harmony

• Do the color combinations create a visually pleasing and harmonious UI? (By following 60-30-10 rule)
• Are there any clashes or conflicts between different colors used?

Color Usage for Feedback and Alerts

• Are colors effectively used to provide feedback or indicate status changes?
• Do error messages, warnings, and success indicators use appropriate colors?

Color in Different UI States

• Are colors consistent across different states of UI elements, such as hover, active, and selected?
• Do the color changes effectively communicate interactivity and user actions?
• Are there any visual issues or inconsistencies in color transitions?

6. Typography and Readability Audit

Font Choice and Legibility

• Is the chosen font easy to read and legible in different sizes?
• Does the font style align with the intended tone and purpose of the UI?
• Are there any issues with font clarity or readability, especially for long passages of text?

Font Size and Hierarchy

• Are headings, subheadings, and body text appropriately sized to guide the user’s attention?
• Are font sizes consistent and balanced throughout the UI?

Line Length and Spacing

• Is the line length of text optimized for readability?
• Is there adequate spacing between lines and paragraphs to enhance legibility and comprehension?

Contrast and Accessibility

• Are there any readability issues due to low contrast or poor color choices?
• Do the color combinations meet accessibility guidelines, specifically for users with visual impairments?

Text Formatting and Emphasis

• Are text formatting options, such as bold, italics, and underline, used appropriately for emphasis?
• Do these formatting choices enhance or detract from the overall readability and user experience?
• Are there any inconsistencies or overuse of text formatting?

Alignment and Consistency

• Is the alignment of text consistent and visually pleasing?
• Are text elements properly aligned with other UI components?

7. White Space Audit

Consistency and Balance

• Is white space consistently applied throughout the UI design? (You should adhere to the 8px spacing rule, more information in this article)
• Do elements within the same category or type share consistent margins and padding?

Breathing Room and Clutter

• Is there enough white space around elements to provide breathing room and avoid visual clutter?

Proximity and Grouping

• Are related elements visually grouped through appropriate spacing?
• Is there enough space between unrelated elements to clearly distinguish them?

Margins and Padding for Interactive Elements

• Do interactive elements (e.g., buttons, links) have sufficient padding for comfortable interaction?
• Is there enough spacing around interactive elements to minimize accidental clicks or taps?

Responsiveness and Screen Sizes

• Does the spacing adapt well to different screen sizes and orientations?
• Are there any issues with overlapping or excessive spacing on smaller or larger screens?

Responsive Design

• Does the UI work well across different devices and screen sizes?
• Is the content and layout adjusted appropriately for smaller screens?
• Are touch targets and interactive elements appropriately sized for mobile use?

8. UI Layout Audit

Consistency

• Is there a consistent visual style and layout throughout the UI design?
• Do elements align and maintain consistent spacing across different screens and sections?

Hierarchy and Organization

• Is the content hierarchy communicated through layout and visual cues?
• Are related elements grouped logically for easy comprehension?

Alignment and Grid

• Do elements align properly based on a defined grid system or alignment guidelines?
• Are there any instances of misaligned or unevenly spaced elements?

Readability and Scannability

• Is the content presented in a way that is easy to read and scan?

Responsiveness

• Does the layout adapt well to different screen sizes and orientations?
• Are there any issues with content overlapping or becoming too cramped on smaller screens?

9. UI Elements Audit

Consistency

• Do UI elements follow established design patterns and guidelines?
• Are the visual styles, colors, and typography consistent across all elements?
• Are any deviations from the design system intentional and well-justified?

Alignment and Spacing

• Are UI elements aligned properly, maintaining a consistent grid or layout?
• Is there sufficient spacing between elements to avoid visual clutter and confusion?
• Do elements align with other interface elements for a cohesive design?

Responsive Design

• Do UI elements adapt well to different screen sizes and devices?
• Are elements appropriately sized and positioned for mobile, tablet, and desktop views?
• Is the responsiveness of elements tested across various devices and resolutions?

Interactivity and Feedback

• Do UI elements duly respond to user interactions?
• Are hover, focus, and active states properly implemented for interactive elements?
• Do elements provide clear visual feedback to indicate interaction or completion?

Accessibility

• Do UI elements meet accessibility standards and guidelines?
• Is there sufficient color contrast for users with visual impairments?
• Are interactive elements keyboard accessible and provide proper focus indication?

User-Friendly Interaction

• Are interactive elements appropriately labeled and provide clear instructions?

Error Handling and Messaging

• Are error messages and validation feedback clear and helpful?
• Do elements indicate when there are errors or issues with user input?
• Are error messages displayed consistently and noticeably?

Performance and Loading

• Do UI elements load quickly and efficiently?
• Is there an appropriate loading state or progress indication for elements with delays?
• Are large or complex elements optimized for performance to ensure a smooth user experience?

Remember to check popular design systems and trusted sources for specific best practices relevant to your project or design system. By incorporating and adapting these practices for UI components, you can improve the user-friendliness as well as the aesthetic of your design.