We've all heard about information overload, and the paradox of choice.

Don't you love those thai menus with every type of sauce, noodle, and protein, all written out as separate dishes? "I'll have item D132 with no water chestnuts....no, I mean the one with chicken on page 12....yeah, that one."

There's a ton of data on that menu, but not a lot of information about what tastes good.

Over the years, I've worked on some very data-intense software applications, with the IT software for data center hardware (storage arrays, networking, computing hardware) probably being the most data-rich.  Many of the management interfaces I helped redesign started out as "where should we display all the metrics we're collecting on all these objects the software is managing?" Tons of index/list screens, with the occasional hub/spoke information architecture breaking up massive numbers of metrics into categories. A step better, but much of it was raw data desperate to be informative to somebody.

Ironically, some of the dashboards for these products tended to be information deserts. A few pie charts, desperately trying to convey an overall score of the entire system, but failing miserably. Or worse, a list of "every resource that is yellow or red" sorted in some table, trying to be a to-do list for the poor IT support staff that had to manage one of these resources. Ouch.

Ironically, the issue with both situations was information underload, not overload.  You can learn more about assessing information overload (underload?) in your design with my free guide.