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.
I hope this helps.