Lying to the User: An Ounce of Inaccuracy is Worth a Pound of Explanation

Truth and honesty are much overrated. If user interface designers decide that users should always be given all relevant information that is available then we will probably flood them with data that they can not decipher.

Engineers like precision. They go to great lengths to select the most accurate sensors and then design calibration systems to iron out any inaccuracy introduced by manufacturing variability. They sometimes expect the user to appreciate that precision too.

I have seen many cases where a system at rest displays a measurement of 0.01, which leaves the user baffled when a reading of 0.0 would have made perfect sense. Users do not want a precise reading. They want to be reassured that the device is working normally. Sometimes a gentle lie is the easiest way to give that reassurance. The interface could display any reading below 0.05 as 0.00. An alternative would be to reduce the resolution to one decimal place, but there may be reasons for showing both decimal places at larger values.

Constantly changing signals can also be difficult to interpret. One of our designs had a lightbar made of LEDs that showed the pressure being controlled in a pneumatic system.

Because we had more LEDs than the product’s predecessor, the bar could show a variation of 0.5cmH2O, while previous systems only had a resolution of 1.0cmH2O. We received complaints that our system was not as good at controlling pressure than the older alternatives. We investigated and found that while our pressure control was just as good as the older devices, small variations in pressure were reflected in the bar. These variations are not visible with a lower resolution bar. So the older system was not more stable, but it looked more stable because small variations were not visible on the lightbar.

It was too late in the design to reduce the resolution of the bar. Instead we filtered the pressure signal to make it look more stable than it actually was. By hiding some of the true picture from the user, we made them more comfortable with the system, and this avoided having to spend time during training explaining to the customer the principles of our control system in order to explain the small variations in pressure. If the target users had been engineers then providing that accuracy on the ledbar, and providing an accurate explanation might have been appreciated by the users, but with less technical users, an ounce of inaccuracy is often worth a pound of explanation.

One of my client’s designed software for specialized mobile phones. They have a small market and designing the complete phone is not feasible. They buy in sub-assemblies but run their own software these phones. One of their customers complained that a competitor got a far better signal, for a specific distance from the cell tower. This surprised my client since they were using exactly the same electronic components, bought from the same suppliers. It turned out that the customer’s measurement of signal strength was based on the number of bars appearing on the LCD. My client's software reflected the signal strength by lighting up the bars on the LCD in proportion to signal strength. The competitor was lighting up more bars for the same signal. My client resolved the matter by using an algorithm that did not light up the bars in proportion to the signal, but weighted it to always light more than its fair share of bars. The engineer would have assumed that the amount of the bar that was illuminated should be proportional the signal available, but the customer was happier to be given an indication that was as optimistic as the competitor’s indicator. In this case it could be claimed that both competitors ended up lying to the user in equal amounts.