User: “The interface is just too overwhelming and I can’t find the data I need.”

The difference between Configuration and Filtering.

I know, this seems self-explanatory. You couldn’t possibly make the mistake of falling into the blurred lines between configuration and filtering. In fact, what blurred lines? It’s black and white, isn’t it? Maybe not.

I’ve worked on applications big and small, but whenever looking at enterprise applications, there seems to always be a ‘UX issue’ around the ability to digest data or view data in the correct context.

  • Your users are overwhelmed and can’t comprehend your data? Filter.
  • Your users need to view the data in a specific context? Filter.
  • Your users want to see their data over specific time aggregations? Filter, Filter, Filter.

This shouldn’t be the solution.

Filtering is incredibly powerful, but many enterprise applications tend to overlook the power of configuration. Configurations allow users to define context up front to display only relevant data. Filtering allows them to traverse that data in a manageable way.

When it comes to rendering data, configuration is additive and filtering is subtractive.

Configuration relates to any information needed in order to actually render the report. For example, if the report is inherently time-based and you need to choose an aggregation period up front, ask your users for that information before rendering an empty state. Never drop users into a report that says ‘not enough data’ when you could have simply asked them for the necessary information.

Configurations are powerful and even if you’ve made a clear distinction between the two, take a second look. Adding richer functionality to your configuration can produce far more value for your reports. Users are far more likely to spend more time configuring than they are filtering.

The reason for this is they haven’t yet tasted value. The report they’re creating is an experiment and they haven’t reached the results.

Once a user reaches the filtering step, they’ve already made a decision on whether or not the data holds value to them. They’ll only dig in if they see a speckle of gold.

Of course, there’s a few bad practices to configurations that could make them an impediment.

  • We shouldn’t overwhelm our users with options. Configurations should only ask for the necessary information to render the report. Any other options should never distract from the core purpose. For instance, add an advanced tab to hide any other options — regardless of how powerful.
  • Keep configuration options accessible. There are two main use cases for users consuming data; they either know what they want and they need to be able to find the information effortlessly, or they’re exploring the data for patterns, stories and unknown answers. Changing the configuration on the fly is critical to the second use case, so keep those options accessible.

Filtering and Configuration are like the buns to a data sandwich. Configuration is handled up front to render the report, and after running the report, filtering can be applied to the rendered data. This pattern reduces depressing empty states, makes reports more powerful, empowers users to navigate and consume data in the context they want and provides an overall better experience.

This may not be groundbreaking for most, but as the root of most UX issues for enterprise applications rendering data, it’s important to get this pattern right.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.