Note: The penguin-shaped word cloud up top is based on the text of my previous post. I assume you’ve learned nothing. (Credit: WordArt.com)
Have you ever told someone something they didn’t care about? Not to brag, but I’m something of a master at this.
I’ll read or hear about something that interests me and rush share it with my wife or a colleague, who then has to figure out what the hell any of it has to do with anything. Remembering that just because something interests me doesn’t automatically make it interesting is one of my New Year’s resolutions (not a bad one for writers).
Hopefully you’re more socially adept than I am. But ask yourself this as a product person: Have you ever said something like, “When our users log in, the first thing they should see is a dashboard”?
I’ve heard that many times and said it a few times myself. The truth is that for many SaaS products, including many analytics products, the dashboard landing page idea is not what users want or need.
Why We Make the Dashboard Landing Page Mistake
The dashboard landing page (hereafter “DLP”) is often a classic result of inside-out thinking as opposed to starting with users’ needs. There are plenty of reasons why teams go down this road:
- Dashboards appeal to mankind’s desire for order
- They’re pretty and demo well
- They seem like a good idea for data-heavy or project-orented SaaS tools
- Showing dynamism can imply usage and value, which helps renewal conversations
- It seems better than showing a blank screen when the app loads
- Managers like dashboards
Any of those sound familiar?
However, you get there, seeing your users routinely blow through the dashboard page in order to get to the functions or page they want to use is sobering. More importantly, attractive, well-functioning dashboards can be time-consuming to implement and maintain. You can spend a lot of cycles keeping them pretty when the underlying data structures change. I’ve been there, and many of you have too.
As we all know, wasted effort means wasted development time, and wasted development time can be fatal if left untreated. It might not seem like a big deal, but it could be worth a lot more than you think.
Make the Right Decision
If you’re thinking about implementing a DLP in your product or being told to do so, start by taking a step back. Make sure you understand what kind of dashboard you’re building before you do anything else. Then ask yourself these questions:
- Who is the user? Yes, duh. But seriously don’t build a slick management dashboard for people who don’t consume data that way. If the people want simple tables, give them simple tables I say.
- Is a dashboard really what users should see first? When users first come into your app, do they usually want to know something or do something? When I open Excel, I usually want to create a spreadsheet. When I open MailChimp, I usually want to either update lists or create a campaign. If I was checking the core temperature of a nuclear reactor, that would be a different story. Know when to use a feature launcher instead of a dashboard.
- Can your data be aggregated in a user-friendly way? Some data simply lends itself to aggregation on a single screen better than others. If you can’t roll up the data into something the user gets value out of, don’t bother. Figure out another way to provide a useful data digest, even if it’s less sexy.
- Would other delivery methods be more effective? You might be more successful pushing data to the user rather than creating a page in your app. Facebook’s ad management console is no beauty queen, but every morning I check my phone alert telling me how much I spent and how many people I reached yesterday. It’s helpful and saves me time. Never underestimate the power of a simple data point to engage users.
Final thought: If you ever find yourself conjuring up metrics for the sake of making a chart on a dashboard look pretty, take a break and go talk to some potential users about what they really need. Life’s too short.