I know the endoplasmic reticulum is a thing. I know the Inuit people have 50 words for snow. I couldn’t tell you what the endoplasmic reticulum does, nor do I know a single Inuit word for snow. But, to a biologist or someone from Nunavut or Quebec, these might be considered common knowledge. Just like how “Sankey Diagram,” “Level of Detail” or “Data Management Add-on” feel like common knowledge to me. It’s important to know what you don’t know, and the best way to figure that out is to talk to someone who does know.
When it comes to building dashboards, the first thing good developers do is reach out to those who are going to be the end user of said dashboard to find out what they don’t know. This exchange of information between dashboard developers and dashboard users is ultra important to producing the right dashboard solution.
TLDR: It is important for dashboard developers to communicate with users in order to:
- Share expertise
- Check any assumptions that may have been made
- Streamline work
- Improve happiness*
*I cannot guarantee happiness, but I do hope that following these tips can make your work life more pleasant.
It is often forgotten that dashboard development and requirements gathering is a two-way street. The dashboard developer must understand that they do not know every aspect of the business and decisions being made, but the stakeholder must also understand that they don’t know every aspect of data visualization best practices.
While stakeholders often have more intimate understanding of their data and its outliers, a data expert may be able to uncover a larger underlying issue. In my work as a consultant, I’ve seen such issues be small, like a data collection issue. I’ve also been in situations where such findings cause us to reexamine the way the business calculates vital key performance indicators.
I once had a client that had an employee who was an expert in various coding languages but had since left the company. While doing some digging, I found they were prepping the data using PHP, a language typically reserved for web development. While this worked under the original employee, the system was hard to understand if you were not an expert in PHP. We were able to replace this system with a more universal and replicable process.
While it’s valuable to exchange expert knowledge, sometimes ignorance can be enlightening, as well. I was once in a meeting where two stakeholders used the same TLA (Three Letter Acronym) every other sentence. I eventually asked what the acronym stood for and was surprised to receive two different answers. Once we were all on the same page, the project really picked up. Not only did we work better as a team after that, but one dashboard became two, and they were used regularly throughout the company. This allowed for more focused, relevant dashboards that addressed a wider audience.
Different problems require different perspectives. Sometimes you might need an Einstein, sometimes Occam’s Razor. This is why we collaborate: to get all different types of skills sets, knowledge and assumptions.
Realizing your assumptions can always be tricky on your own. When I was showing this article to a coworker, they asked “do the Inuit people really have 50 words for snow?” The claim is something I had heard many times in life but had never truly looked into. I found that this statement is actually at the center of one of the linguistic world’s hottest philosophical debates: What is a word.
While this instance of collaboration sent me down an existential rabbit hole, it also helped me catch an error and learn more about the Inuit people, linguistics, and my coworker. It also helped me prove this point.
Streamline Work and Improve Happiness
Finally, by putting together stakeholders and developers, we are reminded of a essential fact: everyone involved in dashboard development is human. We can better explain issues we are facing, feel more comfortable reaching out and get insight into decision making processes. Not only is it more efficient than having a “middle man” try to translate, it also fosters a more pleasant work environment. And, in my experience, happy workers who can rely on and trust each other, while also being comfortable providing critical feedback, always produces the best results.
Better communication leads to better work which leads to better ingredients which leads to better pizz … sorry, I’m writing this around lunch. Ignore the second half of that. Better communication = better work. Now, go out there and do the thing that could solve most problems in every movie made in the 1990’s: communicate!