Stop Shipping Dashboards that Don't Matter

Ben’s article goes through how to not ship dashboards that don’t matter. I think the article also highlights why communication and requirements gathering is so important.

Requirements Gathering

I just went through this the past week of so. I had a request to create a daily production report that could potentially turn into a dashboard. He had some good questions to ask:

1. What decision are you trying to make (or action are you trying to make)?
2. What does success look like for you?
3. What do you already know and what assumptions are you working with?

These questions are great not just for a dashboard but good initial questions for other kinds of projects. My project for example, they initially wasn’t sure if they wanted a daily report or a dashboard. Asking similar questions go me closer to getting some requirements.

I developed a mockup after taking what they told me and writing that down the requirements. While I believed that my mockup matched what I was told, I had a meeting with the stakeholders and got a better idea what they were looking. They were able to give me a better idea of questions above. Based on my experience, requirements gathering is a process and is a skill that will take work and experience. The less that your stakeholders’ skillset matches your own, the more work it will probably take to get the requirements.

Communication

Once you have your requirements, your mockup is approved and you deliver your initial release; make sure to get some feedback. In the dashboards I create, I log usage. I don’t really care who is using it but if only 5 or 20 people are using a particular dashboard. The number of people and frequency will dictate how much time and effort I will put into that dashboard. Also for a given dashboard how important is that dashboard to our business needs. Those 3 factors when put together will help me determine which projects, dashboards, etc. to focus on.

Unfortunately, not all my reports I typically can measure usage. If you ask, “Is the dashboard/report/etc. useful?” or “Are you using it and do you any questions?” these questions makes it too easy for the stakeholder to say “Nope, all good.”. Instead, ask questions like “I noticed that the Ajax production acceptance have been slipping, are there any other metrics that would be useful?”. The reason is giving the stakeholder some context can help them think and respond to you in a more constructive manner. They may really think that the reports are good and don’t need any changes, but getting them to think could get them to realize that while the reports are good, it doesn’t help them answer a question that pops up because of the reports.

Like what Ben mentioned in his article, another way is when you get questions that implies that they don’t use the dashboard or worse ask a dashboard that you already have done. For example, I had created dashboards for a weekly meeting I was a part of. Not everyone would join that meeting, so since most of the information came from my dashboards, I will generate meeting minutes for the meeting organizer to send out. I was in a conversation asking for weekly information that was exactly in those meeting minutes from someone who gets those meeting minutes!

Conclusion

Getting requirements, communication and getting feedback can be the more difficult, more time consuming than coding. Don’t shortchange yourself doing the requirement phase. While this can feel like the most demanding phase of a project where you may feel like you have the least amount of confidence, experience, etc. this is very critical to do. Once you feel comfortable enough with the requirements, any feedback from mockups, etc., then and only then work on your design. After you have any idea of a design, then provide an estimated completion date. As you are working on the dashboard/program/etc., any questions, adjustments to the completion date, make sure and communicate with your stakeholders. Finally after the release, keep communicating and gathering feedback. Dashboards can start answering questions but it can also generate more questions for you and your stakeholders. Doing this feedback loop will help you understand your stakeholders and the business needs better but will also help you provide timely reports, dashboards, etc. while getting fulfillment knowing that your work is helping others and the business.

I highly recommend reading Ben’s article as well as potentially signing up to his newsletter.