This is something that has bothered me a lot on how to approach.

I like to use "ugly data" in my wireframes since my goal isn't to have pretty wireframes, but functional ones. Using simple single-line words is easy and pretty, but it's not real.

Here are some ways I can think of to handle longer text in a preview before selecting an item: A list of ways to handle long text in previews But then what if you have a nefarious user who exploits Unicode to overflow these fields? Various ways of exploiting unicode

The first example is the user using either or to create new lines, making a simple character count inaccurate.

The second example is the user using a long Unicode character to abuse a character counting method.

The third example is using a whitespace rendering character to create an ellipsis out of seemingly nowhere.

You'd need to somehow not only measure the width of a piece of text, but also make sure it doesn't flow vertically. Or sanitize inputs so this doesn't happen in the first place. But these precautions aren't always technically feasible.

In addition, you need to display the full text somewhere anyways, and it starts getting ridiculous with the longer Unicode characters. As an example, longer title that ends in an ellipsis is 37 characters, below is an example of a 20 character string, if you were to use newlines it would only take 17 characters to completely overflow the screen at that font size.

Too long of strings

With all that in mind, how would you handle this? Do you scroll-overflow the text after a certain height? What if it's composed of newlines? Do you decrease font size?

I've been told that it doesn't matter because it would be ridiculous to have a user input such long text. I don't like this response since it does and will happen, and it should be my task to figure out the best way to display these edge-cases.

  • 2
    If a pernicious actor contrives obstructive input designed specifically to render poorly, the blame for the imbalance in the resultant UI is placed justly on said actor. Perhaps on a case-by-case basis, you might make the decision to truncate with ellipsis, but I don't see why any further responsibility should be placed on the designer to ensure the UI remain proportional after such deliberate sabotage. Sep 20, 2019 at 15:01
  • The examples I showed are merely what happens when you take potential issues to extremes. These issues can still prop up under legitimate user interaction. Such as writing in Urdu, using a keyboard that just happens to insert new-lines when it shouldn't be possible, and even when pulling content from another source, such in the case of really long book titles. That said they probably won't end up having as large of an impact as the extremes I showed, but they still definitely do.
    – nine
    Sep 21, 2019 at 1:03
  • As a UX designer, these things are not really your problem. You should consult your content strategist to determine how much room you need to allow for text in each instance and then leave it up to the content team to police standards and ensure text is laid out correctly Sep 23, 2019 at 8:15

1 Answer 1


While I do applaud you for using wireframes to effectively explore different scenarios and test edge cases, I don't think you should be trying to solve this problem in a silo as it is the job of the UX designer to advocate for the user's point of view in various requirements and design considerations as part of a bigger product team.

To answer the question, if you can understand the various motivations why a user would want to type in more text than you can comfortably display in a line of text, the best course of action for resolving this issue will hopefully become more apparent.

The two main groups of users that you describe appear to be A) users that unintentionally create the overflow and B) users that deliberately create the overflow, and there are a number of strategies that would apply equally to both groups:

  1. Creating a physical character limit and enforcing it through UI validation
  2. Redesigning the user interface to prevent the overflow (e.g. truncate)
  3. Redesigning the interaction to reveal the overflow text (e.g. using hover-over)

But the exact combination of design strategies may depend on other factors, which is why a better understanding of the users and the context of usage within the team will help guide you to the right approach.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.