I'm a software developer. There is a chicken and the egg problem when it comes to designing these things. I can ask "What do you want the dashboard to look like" and they'll answer "I don't know before I see the data". Then I'll ask what data they want to see, and they'll respond "What will it look like?", or we'll spend significant time on data collection only to find they never actually want it in a dashboard after…
Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
71–80 of 107 posts
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#72The hard part is knowing what information to surface, and how to drive the user towards those insights in an intuitive way. You need a strong team that intersects product, data science and UX. Engineering is the least important aspect of it.
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#73Earlier quoted context omitted.
I work closely on BI projects but from a finance perspective. The concept I like to explain to the BI teams is that the dashboard is always just a snapshot of “what” is happening. But the underlying base level data is always needed to understand “why” it’s happening. And without the why, there’s no actual intelligence gain. Take a metric like Average Order Value (AOV). It may be ; total sales / order quantity. But as…
Similarly titled towards finance. I specialize in what I'll call decision analytics for insurance underwriters. > Which means, the don’t even understand how un-intelligent their BI tool is or why the execs likely aren’t feeling like investing in BI has been worthwhile And this relates to what I was thinking about in my first comment. I once was conversing the COO of my company (my last job), at a 1000+ person company…
Totally relate to that AND I'm often on the receiving end of those questions in a live setting (eg. board/exec meetings). Funny to stumble on this because just last week I told someone on our BI team, there is not any one "use case" I can lay out. The use case is this, assume I need to answer any random question that comes up. I need analytical enablement not a fancy dashboard in most instances. It's not to say dashboards don't have their place, but they're just the easily digestible summary of underlying data that's meant to highlight areas and raise those questions about "why..."
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#74Original creator of (the now woefully dated-looking) GBD Compare [https://vizhub.healthdata.org/gbd-compare/] here, where we found this super useful since we had so many controls that it could take a lot of clicking (and knowledge of the UI) to recreate a graph someone else was looking at. It really helped with reach, as folks could email/tweet their specific view then others could use that as a starting point to dive in without starting from scratch or having to create an account.
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#75I've worked in many analytics projects across a number of companies as a consultant. I'm a big believer in "decision support systems". Find out what decisions your customers need to make, repeatedly, to their job. Quantify the heuristics and visualize that information (and that information only) in an easy to consume manner. More often than not that's an email or PDF . Another advantage is that by supporting the busi…
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#76I'll enjoy watching this thread evolve. Some thoughts from my experience: - Everyone asks to translate simpler spreadsheets and Excel charts/graphs into dashboards in your BI tool of choice. As soon as it's there, they'll ask you why they can't export to manage the data themselves. This vicious cycle can sometimes be stopped but is a slow-motion drag on productivity in lots of orgs. - Build in validations, and/or wor…
Brilliant summary - mirrors my thoughts and experience quite closely. Validation/testing has always been a challenge, especially given that dashboards are by definition quite “full stack” implementations where testing just the front end or back end is not sufficient and testing both in isolation can also often be challenging due to the huge possible variations in input data. Mocking data is also hard because dashboar…
> Validation/testing has always been a challenge, especially given that dashboards are by definition quite “full stack” implementations where testing just the front end or back end is not sufficient and testing both in isolation can also often be challenging due to the huge possible variations in input data.
Constantly evolving but I've always tried hard to keep calculations away from the display tools. So, I put lots of things in SQL SPs, or in Python, or more broadly in tooling that allows me to recreate the summary data without the front-end. My nightmare is having to check a PowerBI calc that itself is based on an underlying SQL calc. Which one is wrong? Now spend twice as long figuring it out!
> The visual aspects of dashboards can easily drift over time even if the data is correct. You’re often theming charting libraries for example and the compliance of the theme can drift slightly if you update the library without really checking every detail of the visual appearance/layout every time. Or you may not even notice the “visual drift”..
Love it, very smart. Why I prefer tables for many things too - one less thing to maintain and check.
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#77Lots of great suggestions here, but one I haven't seen is providing deep links. Let users share the exact state of their dashboard with others, ideally without requiring some convoluted system of logging in and sharing things. We implemented it by allowing a json config in the url, then providing a button to copy a shortened URL containing the whole config. Original creator of (the now woefully dated-looking) GBD Com…
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#78I've worked in many analytics projects across a number of companies as a consultant. I'm a big believer in "decision support systems". Find out what decisions your customers need to make, repeatedly, to their job. Quantify the heuristics and visualize that information (and that information only) in an easy to consume manner. More often than not that's an email or PDF . Another advantage is that by supporting the busi…
> More often than not that's an email or PDF > I think "self-serve" analytics is silly, the idea that you put all of the data in front of people and they'll derive "insights". That's not how normal people or data work So well said. It doesn't shock me anymore when someone asks for a succinct summary or a PDF version rather than digging through dashboards on their own. In my company, we have a user-facing analytics pr…
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#79I've worked in many analytics projects across a number of companies as a consultant. I'm a big believer in "decision support systems". Find out what decisions your customers need to make, repeatedly, to their job. Quantify the heuristics and visualize that information (and that information only) in an easy to consume manner. More often than not that's an email or PDF . Another advantage is that by supporting the busi…
In my experience, what "self-serve" really means is "non-developer". The end user won't build it, they'll have a BA do it. But it does mean they don't need IT to help.
Re: Ask HN: Lessons learned from implementing user-facing analytics / dashboards?
#80Earlier quoted context omitted.
Brilliant summary - mirrors my thoughts and experience quite closely. Validation/testing has always been a challenge, especially given that dashboards are by definition quite “full stack” implementations where testing just the front end or back end is not sufficient and testing both in isolation can also often be challenging due to the huge possible variations in input data. Mocking data is also hard because dashboar…
Interesting - great points > Validation/testing has always been a challenge, especially given that dashboards are by definition quite “full stack” implementations where testing just the front end or back end is not sufficient and testing both in isolation can also often be challenging due to the huge possible variations in input data. Constantly evolving but I've always tried hard to keep calculations away from the d…