2

I'm working on an app in which you can create an endless number of dashboards with (so far) an endless number of reports in them. Considering performance, we came up with the idea to limit the number of reports per each dashboard. However, it doesn't go hand in hand with the Premium account. Creating your own dashboards is possible only within the highest plan, that's why I don't feel good limiting the number of reports in dashboards ("I'm paying you big money, why can't I have so many reports as I want to?!!?")

I came up with the following solutions:

  1. Limit the number of reports per each dashboard. Say explicitly that the User cannot create more than 20 (I don't like this).
  2. Educate: do not limit the number of reports, however, when the User does so inform him that it might affect performance. Show some kind of hint or tip that will suggest creating dashboards with fewer than 20 reports.
  3. Do "nothing", well... kind of. Create lazy loading for the next reports apart from the first 20 (labor illusion, nudging?), or create pagination that's not very helpful in case you have over 20 reports. Or anything of the sort.

But I am not sure as to the direction we should go. Did you have a similar problem to solve at your work? Or what would you do in such a situation?

Improve this question
6
  • Sorry to say so but what you (want to) offer is not what you can actually deliver. Educating a premium user to create less reports on a dashboard while that was the exact reason for him/her to become a premium user would not be ok. So be honest and deliver just 20 reports per dashboard for premium accounts or be ready for the heavy load. Lazy loading seems a nice solution if it is guaranteed that each load has the same good performance allowing as many reports as the clients computer can handle.
    – jazZRo
    Jun 1, 2021 at 13:53
  • Having the unlimited number of reports is not the main reason they go Premium. This app's purpose is totally different and Reports is just one of many modules, one that is not the core of the app (33% of all Users use Reports). Also, we do not want to limit the number of the dashboard. Only the reports in them.
    – Madzik
    Jun 2, 2021 at 7:38
  • 1
    Another thought: I understand that you don't want pagination but are considering educating the user about performance limitations. Pagination can also be used to educate users about limitations by making them think creatively and use different dashboards when they want all reports on one page, and this without explaining the reason and without leaving the problem to the user (e.g. guessing whether or not it will generate performance issues when adding more than 20 reports).
    – jazZRo
    Jun 2, 2021 at 8:12
  • I think this is great solution. Thank you!
    – Madzik
    Jun 2, 2021 at 8:32
  • I spoke with the dev and it appears like there's a major problem. The reports in dashboards can be reordered, they might have different dimensions, so the index no. has nothing to do with what the User sees. And implementing pagination to a grid layout might be hardcore.
    – Madzik
    Jun 2, 2021 at 9:27

1 Answer 1

Reset to default
4

Performance is always the business' problem, not the user's. Education is appropriate in some cases, to keep the user from stalling out ("Are you sure you want to query the entire database in this report? It might take hours to generate.") But when the user wants to access objects that they've already created, that can be frustrating.

Personally I think option 1 (limit the number of reports) isn't egregious if you set user expectations and have a generous upper limit ("You're using 5 of 100 dashboards.") But if a user already has 106 dashboards before the limit is imposed, it's going to be a battle to get them to cut 6.

That brings us to lazy loading and pagination, which are very appropriate patterns for heavy data objects that could overload the system if too many are requested at once (pagination is better than lazy loading in this case). Showing 20 at a time with a good search/filter option would likely be acceptable to users, and can buy you time to keep working on the issue.

Because from a UX perspective, you might want to understand why your users need so many reports per dashboard. There could be many reasons that would be uncovered through testing. For example:

  • Something is going on with sharing/team access, so everyone is building their own reports
  • Users don't feel like digging through existing reports, so they just generate new ones each time they need one
  • There are small, incremental tweaks they need to make, and it's easier to create new reports than update existing ones
  • They're afraid of losing past data if they change an existing report, so they keep building versions
  • They're afraid of making changes because of organizational policies
  • They're creating new reports to test a hypothesis
  • Training issues, where reports were not being built correctly in the first place

Each of these problems has its own UX answers, so it would be good to see what arises in user testing once you have data gatekeeping in place.

Improve this answer
2
  • Lazy loading is not persee infinite scrolling. Infinite scroll is an implementation of lazy loading. There are other ways to make good use of lazy loading.
    – jazZRo
    Jun 2, 2021 at 7:54
  • 1
    Correct - pagers are still the better pattern when a user is looking for something specific in mind, vs browsing a stream of content.
    – Izquierdo
    Jun 2, 2021 at 11:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.