I'd go quite a bit further. Most users have no idea what they actually want. I think the key to building a dashboard is to ask three questions:
1. How do you measure success? -- or -- How will you know that life is good? How do you know that the sky is falling?
2. If you see this number (something specified in #1) go above or below a certain value, what are you going to do? Anything?
3. When and where do you need to have the info from #'s 1 and 2 to actually take action? i.e.-Do you need to be inside the warehouse? On your phone? At your desk? Daily? Monthly? By the minute? Push?!
1 tells you what to put on the dashboard, 2 tells you how to prioritize the information (something that's important but not actionable will be something that can be found, but isn't prominent or on display above-the-fold), and 3 tells you the form factor/latency that's needed.
I've built a lot of dashboards over the years. Some have completely changed businesses. Some have languished in obscurity. Most are used fairly regularly (at least monthly), but don't actually add much value beyond time savings of having the numbers automated. The ones that really changed businesses and provided some benefit beyond just time savings have had clear answers to those three questions.
I would add a 4th also based on extensive experience, can the users do anything at all about the situation? Being able to order someone to generate numbers doesn't mean the recipients are permitted or capable of doing anything at all. It shows they "care" but a random number generator is more effective WRT dev time than trying to generate meaningful numbers.
I've seen dashboards get tied up in internal politics. The list of recipients of "quality" dashboard is a line in the sand vs the "quantity" dashboard political group. The recipient list and who controls it is far more important than the data contained in the report. Whats important is who reports to who, and why.
A fifth question is does anyone in the chain of command even remotely understand basic statistics like error bars and standard deviations? If the only purpose of the report is to loudly trumpet when pet division B beats divisions A and C thru G, then a very high std deviation / error rate makes stack ranking give the predetermined "correct" result more often. I've seen this personally in "metrics as a teambuilding exercise" where whats actually produced is a weekly report that every division will get to stack ranking win at least once a quarter to meet the Morale Improvement goal on some exec's goal list. Again a PRNG gives better data than real data, if the goal is to give everyone a participation trophy.
1. How do you measure success? -- or -- How will you know that life is good? How do you know that the sky is falling? 2. If you see this number (something specified in #1) go above or below a certain value, what are you going to do? Anything? 3. When and where do you need to have the info from #'s 1 and 2 to actually take action? i.e.-Do you need to be inside the warehouse? On your phone? At your desk? Daily? Monthly? By the minute? Push?!
1 tells you what to put on the dashboard, 2 tells you how to prioritize the information (something that's important but not actionable will be something that can be found, but isn't prominent or on display above-the-fold), and 3 tells you the form factor/latency that's needed.
I've built a lot of dashboards over the years. Some have completely changed businesses. Some have languished in obscurity. Most are used fairly regularly (at least monthly), but don't actually add much value beyond time savings of having the numbers automated. The ones that really changed businesses and provided some benefit beyond just time savings have had clear answers to those three questions.