12.05
Can a number be so precise that it actually hinders users rather than assists them?
Take search results for example. It is common practice to indicate the total number of results found for a given query. Google tells me that there are 221,000 web pages about “rubber duckies,” while a recipe site indicates that there are 113 salads and 7 desserts with “avocado.”
I can think of two good reasons for why showing the number of search results has become a standard. First of all, it provides a sanity check. If “Barack Obamaaa” only returns 3 results, it is an indicator that I’ve made a mistake in my search query. Second, it helps me compare one collection with another. The fact that there are twice as many two bedroom flats as one bedroom flats in Greenwich informs me about the area.
The problem: big numbers
Knowing that there are 324,768 results is no more helpful to me than knowing that there are about 324,700, which is really no more helpful than knowing that “there are a bunch of results.” And when comparing collections, knowing that there are 41,327 species of vertebrates and 1,589,583 species of invertebrates isn’t nearly as useful as knowing that there are 38 times as many invertebrates as vertebrates.
Perhaps I’ve convinced you that the utility of precise numbers decrees as the size of numbers increase, but can they actually harm the user experience? The danger comes with the added cognitive burden of processing precise numbers of results into something that is meaningful. Result counts themselves are a step removed from what we’re actually after, and it’s the mental cost of translating the abstract to the practical where the problem with precise numbers lies.
The solution: be less precise
The answer to the problem is simple: make big numbers less precise. A less precise number, such as “3 million,” is less taxing to comprehend than a precise one like “3,185,391.”
In TwigKit, we decided to precisely render numbers 999 and below. For 1000 and up, we felt like 2 digits of accuracy struck the right balance between precision and low cognitive burden. We also decided to provide numbers in units of thousands, millions, billions, and so forth. Thus 2,239 would become 2.2k, 723,826 would be 720k, and 12,296,148 would just be 12m.
Not only does this system of two-digit precision make the meaning of numbers more accessible, but it also allows us to fit big numbers into compact spaces.
Tyler Tate
Tyler is a user experience designer at TwigKit. He has been designing websites and web applications for 9 years and is the creator of The 1KB CSS Grid. You can keep up with Tyler on Twitter.
Agreed. I did a bit of usability consultancy for the recent JustGiving redesign (http://www.justgiving.com). One thing that I thought was quite important was the precision of the numbers at the top: “Over 8 million of you have helped raise £550m for 8,382 charities.” Classic social proof, but the original wireframes had these numbers in full. We put forward the idea of rounding them to aid quick comprehension & recall, and to save some layout space. I think the results work well, although of course I’d need to usability test it to know for sure.
I love your site
Well said Tyler, will use this method in the future for large numbers. Maybe could add the actual result number as a title tag over the number too.
Nice blog, perhaps the unit could be styled with different shade/color as it stills takes time to digest.
Good idea Morris, I think shading could help – we’re also experimenting with turning the capsule around the count into a bar chart of sorts (where the capsules have proportional width according to frequencies).
:D, I have to say this whole site and idea is really good, beautiful design. I haven’t really seen anyone out their try and simplify search in terms of deployment and UI like the way you guys have. I’m definitely betting you guys to be leaders within this space :)
I don’t agree. When I look at that list of numbers, I actually have to read them to see which number is greater. Looking at 324,768 I will not read the number, just compare it’s physical size to 23,745 and 100. In your example, 24K looks smaller than 9.3K. You should also decimal-aling the numbers to facilitate scanning and comparison. “9.3K” is user-hostile tech-speak, shame on you.
ALIGN, not aling of course. Shame on me
Jon brings up a really good point. I completely agree that it’s a significant problem that, in this case, 24K looks smaller than 9.3K. Ideally larger numbers would always appear visually larger than small numbers. While there isn’t a straightforward method of doing decimal-aligning in HTML, we are working on turning the grey capsules surrounding the numbers into a sort of bar chart, where we programmatically manipulate the width of each capsule. This way, there will always be a visual indicator that instantly communicates the proportionality of one item to another.
Thanks Jon for the thoughtful feedback!