I'm working at a company where the operations team uses a dashboard to manage/monitor logistical operations. Not to make this problem specific to operations or logistics, I want to ask it in generic terms: This is what the dashboard looks like at a high level (blurring intentional for confidentiality): enter image description here

The problem is that now the page is having way too much information, yet every time I ask someone if they need all the information on that page, they respond yes! every last bit of it.

My question is: can someone point me out to literature/terminology/case studies etc in how to deal with this situation? keep in mind I'm not a UX professional but I've worked in areas that overlaps with UX for most of my life.

  • Could you clarify if the question is about the cognitive load or the memory/cpu load? Because substantially more complex applications can run in the browser.
    – simonlh
    Feb 26, 2019 at 11:29
  • Could you use browser's developer tools to profile this page loading time?
    – Serg
    Feb 26, 2019 at 17:53
  • It's both.. I've used the profiler and have a lot of data but that's all technical stuff.. I'm more interested in the ux/cognitive aspect of it
    – abbood
    Feb 26, 2019 at 21:17
  • There is a technical problem (site is not fast enough on old machines), yet you're looking for a UX solution. Suppose that you simplify the UX, but the site is still slow on low-end machines, what then? As a software engineer, I would advise you to find the bottlenecks before investing efforts into changes. Once you know what makes it slow, you can focus on that. Maybe the problem is not in the shown data, but in the state of the program itself (it is too complex and a lot of things are re-computed, but could be cached).
    – ralien
    Feb 27, 2019 at 11:58
  • guys i know all about the technical problems and i have a lot of experience in optimizing and fixing them.. but i'd ask those questions on stackoverflow not here. I'm only interested in the UX aspect of things. i'll reword the question
    – abbood
    Feb 27, 2019 at 12:38

3 Answers 3


I've divided my response in 2 sections to hopefully make it a bit easier to digest.

Section 1: Don't ask users what they need

I think in your case you might have already figured out what the issue is here. Hint: Never ask your users what they need. Why? Because majority of the time you'll get the response you've already received - that they want everything - no matter if it solves their main goal/task or if it's just nice to have. It's in our nature, if we can have more then why not? But more is not always better. It can lead to dangers of building an unusable, overcomplicated and cluttered interface with watered-focus on solving a specific objective.

As mentioned by Jacob Nielsen,

It's dangerous to make big design changes because "users didn't like this" or "users asked for that."

A better approach to follow that will solve lots of time and frustration for you is to not ask your users directly of what they need. Instead, ask the right questions and observe them. Interview them and focus your questions on how they behave currently:

  • How do they manage logistical operations currently? (What are the main tasks and processes? How do they do certain tasks currently?)
  • How does a typical day look like in their role?
  • What's the most frustrating aspect of their day when it comes to managing logistical operations?
  • What do they do currently to overcome those frustrations? Why do they take that approach?
  • Why do they need a product and dashboard like yours? How could it potentially solve problem/frustration X for them?
  • If you could only offer them one thing that could make things better for them, what would that be?

All those questions are for you to understand their current behaviours, responsibilities and frustrations in their role. The last question helps narrow down what might be the most important aspect to them. None of the above questions asks the user to say specifically what they want or need in your product though, feature by feature. That's up to you to decide after analysing your findings.

Before moving on to Section 2, here are a few more references that you might find useful:

Section 2: What is a dashboard and guidelines to consider

A dashboard, as described by Stephen Few, is

[...] a visual display of the most important information needed to achieve one or more objectives; consolidated and arranged on a single screen so the information can be monitored at a glance.

Based on the above quote, a dashboard should not be considered as a comprehensive tool for analysis or decision making. It should be used as a stepping stone where from there you can drill down to other sections in your product for further details and analysis.

  • Treat your dashboard as a summary/overview of the most important information your users require to achieve their main goal - not just any other task.
  • Allow your users to view any further details they require by drilling down to another section in your product rather than on the dashboard. Keep the primary/most important information on your dashboard and for anything else secondary to link them to a separate detailed page.

The example I've created below shows a hypothetical scenario of the key information a bookstore might be interested to know at a glance on their dashboard. Any further information that's secondary e.g. editing functionality, book description, etc will be visible in a separate more detailed page on their system.


download bmml source – Wireframes created with Balsamiq Mockups

  • Alternatively, when you condense your information down to the most crucial aspects, you might think that a different data visualisation format might be better suited than a table, or not.

Section 3: Managing large tables

Even if that much information in necessary, here are some tips in how you could potentially arrange such a big table: https://www.youtube.com/watch?v=23AQBZzDUIo

I hope this helps.


The problem can be tackled in several ways.


  • Make it look like it is fast, without actually making it fast. An example of how this trick was applied is the design of the CanonCat typewriter appliance, described in The humane interface, by Jef Raskin. What they did is, roughly this: when the machine is powered off, it saves a bitmap of the screen on the sectors of the disk that have the highest read speed. When the machine is powered on, the bitmap is read and rendered on the screen, giving the impression that the system is ready, while in fact the user simply looks at a static image. Before they know what hit 'em, the real thing is loaded in the background.
  • Add spinning wheels to make it look like the interface is very quick at handling data

Technical means

  • Load the data sequentially and show fresh data in the first rows, and cached data in the subsequent ones. The cached data will be replaced with fresh entries, as the JS code retrieves them in the background.
  • Or just keep adding rows one by one, populating empty rows with entries as new ones are retrieved. Unlike the previous method, this one doesn't involve deception.
  • Change the paradigm. I suppose it is slow because when the page is opened, the data are loaded from a database backend and shown at once, and this happens every time the page is refreshed. How about loading the data just once, and then using a publish/subscribe approach to receive new data via websockets?

Change the UX

  • Observe their behaviour. What users say they need is not the same as what they actually need. By looking at their usage patterns, you can make educated guesses about the stuff they use infrequently, and take it off the screen.
  • Leverage progressive disclosure. As you observe them, you might notice that they only use some fields in the table in certain conditions. If such patterns are revealed, then you can hide those fields by default and show them only when that condition is satisfied.
  • Remove clutter. The right side of the table is filled with identical controls. Consider hiding that, and only showing the controls when the mouse is over an entry. This will not only reduce visual noise, but also make it less likely that users will accidentally click controls on adjacent rows
  • Consider using hotkeys. Besides the tip above, you can add keyboard actions for each entry. The user clicks on one, or navigates to it using the cursor keys, then they can press o to order, f to forward, etc.
  • Use 2 views - a lightweight one, which shows a subset of fields, and a detailed one that preserves the status quo. Make switching between them extremely easy. Ideally, you could use a quasi-mode, i.e. the detailed view is shown for as long as the user presses and holds Alt, when the key is released, the lightweight view is shown.
  • Be forgiving. If the user makes a mistake, provide an undo option. This will take the pressure off their shoulders and make them less wary of using the new GUI instead of the old one they're used to.

However, I would first make sure that I understand the root cause of performance degradation. All the measures described above might fail, when the culprit is in a completely different place.


Here is an interesting read on why data density can be good UX, if the information is truly needed: https://uxdesign.cc/how-white-space-killed-an-enterprise-app-and-why-data-density-matters-b3afad6a5f2a

I would recommend creating default tables with the most necessary information and letting users add and remove columns based on their needs. Allow searching and filtering for fast information finding.

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.