The #1 problem I see with clients trying to design good analytics products

When it comes to analytics products that need to show data to customers, one of the biggest misconceptions I see with clients is the believe that their trove of data is actually information, by default.

Your data is not informative until it has been presented–i.e. designed–in a way that customers can inform their future decisions or actions.

The #1 problem I see with clients trying to design great analytics products is a lack of clear, actionable, and accurate user scenarios and business objectives by which their designs can be created and measured.

"Easy to use." "Simple." "Rich intelligence."  These are wonderful end states to shoot for, but these types of adjectives don't help teams create better products. As a product owner, you have to get specific with your goals and user scenarios, and you have to talk to real users to discover latent problems and needs.

Here are a five design considerations when you're making a new analytics product/feature:
  1. Define, or hypothesize a small set of actionable user scenarios and business goals. If you're a product owner, you probably have "hints" about what information could be culled from the data. Write those out into specific user stories and align your UI/UX design effort with those. Get the design right for the small list first; then figure out how to "genericize" the design for additional scenarios.
  2. Interview customers, and usability-test your designs, but focus the early studies on validating the problems you are trying to solve for. The design solutions are almost less important to validate early on. Good designs emerge more quickly out of teams that have a good understanding of real-world user problems and needs.
  3. Offer UI customization later, after you understand high-frequency, high-value customer scenarios, and business goals. Don't start with a generic tool (query tools, customizable dashboard widgets, etc.) that allow people to look at "whatever they want." Focus on solving the narrowly-defined set of goals/needs first, then broaden your solutions.
  4. If you are piping data into a BI/reporting tool, don't assume that the tool knows what the interesting, informative potential of your data is. Last year's pie charts might be called "donuts" today, and they might look great on a dashboard cosmetically, but often times, you're really just presenting low-density data with little information, and a lot of paint to doctor it up. Additionally on this topic of third-party BI/reporting tools:
    • Third-party tools are not good at knowing what data needs to be put together to tell a useful story that satisfies a known problem.
    • Customers aren't information designers. They are more likely to be viewing "data" vs. "information."
    • Requisite "tooling time" is not a value to customers; it's a tax.
    • Good UX design looks beyond just your product into people's real scenarios. This might mean facilitating the tasks required to get a customer integrated with the third-party tool, or providing them with useful starting templates that solve for the scenarios that you uncovered during your research.  You did talk to the customers, didn't you!? 
  5. Custom indices (index metrics that roll up a collection of smaller data points) can be great at distilling multi-variate data into useful information, but consider whether users need to know what ingredients went into your recipe (and sometimes, what didn't go in).

Need to improve your product's design?