# How to let a user know a number in the UI is rounded, and not an exact figure?

We've got a property in our user interface that can range from fractional (0.01 or so) to potentially millions. It's usually over 1.

Before displaying it, we simply rounded it to the nearest digit and used K, M, B etc to show thousands, millions to keep it small and the level of precision sensible. So we'd display 2.3m instead of 2,324,499. 0.8 would just show 1.

The actual value isn't too important in terms of precision (say, like a monetary value is) to the user - but it is important to the system to have a lot of precision as it determines the order of items. But the user isn't going to mind if one value is 0.8 and another is 1.1.

However, we've added a search functionality, and someone brought up that if the user sees "23" in the UI, then do a search on this field for "=23", it wouldn't actually return the value they can see - as it's actually 23.1149274829172892382 or whatever meaningless decimals.

How should we 'telegraph' to the user the number is rounded? Should we show the number in all it's hideous precision on hover?

It depends on your audience. More tech-savvy audiences might understand a tilde (~) as "approximately". Less savvy audiences might need a word like "about" or "approximately" by values, or "(Approx.)" in the header if it's a table.

With values being fuzzy and approximated, search queries should be, too. Your engineers should let a search for '23' return results that approximate 23. Perhaps you don't want to show "equals" as the operator in the search UI - something softer like "is" or "is about" might be more accurate.

• The wavy thing is dependent on the level of maths education ( not tech,). math.stackexchange.com/questions/864606/… Feb 19, 2021 at 16:48
• Our search uses a 'lucene' like query language, so they can search ranges like `property:[20 to 25]`, or in the the simple view a UI search box for property put `20 to 25`, I could support them giving a 'fuzzy' search like `~23`, but that's something else for them to discover how to do!
– Joe
Feb 19, 2021 at 16:58

If your users understand the dimension you’re quantifying (i.e., they recognize that it’s a continuous variable, rather than discrete), then I think they’ll assume that 63K means “rounded to the nearest 1000.” Are users in fact confused? Have you tested it?

If you feel you must represent approximation, then there’s these options:

~63 (Short and simple, but doesn’t show the level of precision; users may think it means “60 to 65”. Words like "about" and "approximately" have the same problem.)

62-63 (Here, you don’t round, but classify the value if it’s indeed between 62. and 63. Downside: hard to read at a glance.)

62.5 to 63.5 (Takes more space than above, but represents true rounding and users won’t confuse the dash for minus sign.)

63ish (A colloquialism that I think implies rounded-to-63, but your users may vary. Suitable only if you want an informal feel.)

63 (rounded) (When in doubt, just say it. If you have a whole column of such numbers, put "(rounded)" only in the header to limit clutter.)

Which one is best depends on your users.

That said, the real solution is as given by Izquierdo: support fuzzy searching if you’re going to display fuzzy numbers.

Showing the number at full precision on mouseover may be a good idea for those rare cases when users do want an exact number. Maybe sometimes they want to search for instances that are exactly (or relatively closer to) the value of a case, so they need a more precise value. However, don't rely on mouseover effects to telegraph that the numbers are rounded. What if users never mouse-over?

You’re effectively asking how to communicate to the user that search won’t work the way they expect it to. That puts the burden on the user instead of the UX.

The better solution would be to make the search results match the user’s expectation: if they search for 23 then it should return what they see displayed to them as 23. Index your search against the rounded values instead of against long decimal strings the user won’t ever see or care about.