A formula for defining maximum character lengths

Update: This formula is now available as a web app! 

If you’re designing digital products, at some point in your career you’ll cross paths with the need to define the maximum character length for a component. My turn came when I was in the design system team at one of my previous employers.

Buttons are usually the components for which this need arises first, because they can’t generally expand in width or height.

The common approach is to try and fit as many capital Ws as you can into the component— because capital W is the widest character in a character set—and that will be your maximum length.

I was never fond of this approach—I considered it superficial, especially for mobile experiences, where the real estate is so tight that every pixel counts. So I started thinking about how could I get a more personalized outcome using real data.

The approach

If not Ws, what’s a more realistic sample of characters to calculate the maximum length?

This very simple question made something click, because it led to the realization that I had a wealth of information readily available to me:

• The font used for buttons
• The width of the widest button
• The content of existing buttons

With this information, I knew I could reach a more precise number than using the Ws so, with the help of AI, I devised a formula:

MAX LENGTH = [BUTTON WIDTH – (PADDING + MARGIN)] / AVERAGE CHARACTER WIDTH

This formula is everything that matters. I wanted to place it at the beginning because I acknowledge that we all have busy lives, so that you could just stop reading here and move on with your day if you want. 😈

For us, writing isn’t the challenge — we know how to write error messages and success messages and the like. We want to upskill so that we might be design partners rather than consultants.

I was sure that the formula would work, so I set off to retrieve the information I needed. While the data for the divisor (button width, padding, and margin) was relatively easy to collect, things got really juicy for the average character width, because it required digging into the data and doing some maths (which I stopped doing in high school—that was 20 years ago 🧓)

The process

1. Determine the Average Character Width (ACW)
   • • Obtain the width of each character in the font you’re using
     • Multiply each character’s width by its frequency in the English language
     • Sum all these values
     • Divide by the total number of characters (taking into account their frequencies)
2. Calculate the Available Space
   • • Measure the width of the button where the text will be placed
     • Subtract any padding or margin that you want to maintain within the button
3. Estimate the Number of Characters
   • Divide the available space by the ACW to get an estimate of the maximum number of characters that can fit in the button

Let’s delve into each section with more detail.

The approach

Talking to one of our product designers, they explained to me that I should use a mobile button as the basis for the calculation. It’s the most constrained compared to other variants of the button:

• It cannot resize
• It sits within the narrowest screen width available
• It has the biggest font
• It has the most generous padding

So I popped into Figma, created a frame with our smallest mobile size, and then dropped a button component into it.

I also kept in mind how the text box sat within the component, and subtracted margin and padding. Something else to keep in mind is whether leading or trailing icons can appear in your button.

The examples in the article use sample iOS material, default Figma fonts, and made-up button content, but you get the picture…

Average character width

There were many moving pieces to calculate this one, so let’s look at them one by one.

Character width

For this, I pulled the font that we used for buttons, I created text boxes for each letter of the alphabet, and noted their width. The average width for them was 7,99px.

Character frequency

For this one, I had access to the repository where we stored localization keys, so I filtered every key that contained the word button and exported them as a JSON file.

Calculating the frequency manually seemed like too much hassle, especially because I wanted to ignore capitalization (not all languages have capital letters, but more on localization later…), punctuation, and spaces. If you can’t code, AI can certainly do it for you.

Here’s a table that compares the frequency of characters in my data versus a generic sample based of 40.000 English words. If you don’t have access to your translation keys, using a generic sample is already enough. The results looked really promising and made me want to dig further.

Running the equation

Now we have all the info to calculate the equation:

MAX LENGTH = [BUTTON WIDTH – (PADDING + MARGIN)] / AVERAGE CHARACTER WIDTH

Which would be: 375 / 7.99 = 46.93

Rounded down, the maximum character length is 46. In 46 characters you can fit something like “Sign In to Access Your Personalized Dashboard” (not that you should want that 😅).

Localization

Software is often localized into many languages and the maximum character length must account for text expansion caused by localization. There are generic calculations and expansion rates out there, but again, I wanted to have real numbers based on my data set. After talking to my localization specialist, I identified our 5 “most expanding” languages and wrote some code to give me text expansion rate by language, with English acting as the baseline.

In my case, the results were:

1. Bulgarian
2. Ukranian
3. Russian
4. Italian
5. Spanish

With this data I additionally adjusted the formula so that it accounted for the maximum expansion.

ADJUSTED LENGTH = MAX LENGTH OF MAIN LANGUAGE + (MAX LENGTH OF MAIN LANGUAGE * HIGHEST EXPANSION IN DECIMALS)

ADJUSTED LENGTH = X + (X * 0.35) = 46

X = 46 / 1.35 = 34 (ROUNDED DOWN FROM 34,07)

Conclusions

Comparing the results of this approach to the approach that uses only capital Ws, we’re talking about 26 more characters, or about 20 more if we adjust it by the highest localized langauge expansion.

I don’t know about you, but I can make great things happen with all those characters so, in conclusion, this is definitely worth the trouble.

I don’t consider this approach perfect and I recognize it still has many gaps, but it’s definitely a great improvement from the generic approach.

Here are some shortcomings I spotted. The formula:

• Doesn’t account for kerning
• Doesn’t account for capitals
• Doesn’t account for non-latin alphabets
• Doesn’t account for possible punctuation
• Doesn’t account for space characters

Defining this number is just the start, now you can start auditing your buttons, see whether there are any that exceed this count and adjust them, but also give your translators better guidelines to ensure no wonky buttons ever make it to your product again.

Do you see other shortcomings or advantages in using this method? If you decide to follow it, I’d love to hear your thoughts about whether this improved your day-to-day work in any way.

Stefano Romanelli is a Senior Technical Writer at Deel. Connect with Stefano on LinkedIn.