How do I make every user's data "the most important"?

Question

I'm working on an internal website for our employees. [Apologies if this background is too vague, but this isn't a public-facing website.] This site tracks a huge amount of data made up of many different entities with complicated relationships and thousands of user-input values.

Our users come from many different departments, and each needs to look at the data in a slightly different way in order to make decisions or carry out their job. Often this data has to be input by one department and then read by a different one.

We currently have several ways to find the data you are looking for including a search on the most common objects, and a summary page for the top level objects (which includes a further summary of objects they contain). This summary page is incredibly dense with information, even though it is separated into tabs.

It is also currently a point of contention. Recently several people have requested more information to be added to the various summaries. The data they are asking for is all present in our system, but you have to drill-down through a couple layers of child objects to find the tab and data in question.

I understand the benefit of presenting more details at the top level (and saving time and effort hunting for buried details), but there is a finite amount of space on the summary page, and if we show every detail that every department feels is important it will cease to be a summary and just be the entirety of all the objects.

How can I make the data each department cares about easier to access without flattening our data model (and making it worse for everyone)?

Some possibilities that have been shot down (but could be reconsidered):

1. We have the ability to present the summary as a user-customizable table so they can decide which columns they are about. However, some of the requests deal with things like the ability to download attached documents or view child objects without digging, and table doesn't help in those cases. Additionally, the list of possible columns to display is absurdly huge.
2. We could give each department a unique page and view of the data tailored for them. However, our dev team is too small and this much extra work is impossible to complete given our current backlog. Also, some people are part of more than one department so deciding which view they get isn't trivial.
3. We could scrap our data model or rework it to better allow for these different requests and change the entity relationships, but again, our dev team is too small, and every time I suggest it I get a lot of dirty looks.

---

Edit:
Option 2 seems to be getting a lot of support, which I can understand. The problem is that I don't see a way to create the view customizations we need without requiring more work than we have time for.

For example, our data is a very strict hierarchy. Each node in the tree usually has a couple branches, which in turn have a couple more branches, and so on for about 4-5 levels.

One department wants to be able to see a customer and a brief summary of their order history. A different department wants to be able to see all of the serial numbers for all of the widgets ever ordered by a single customer. Both aren't available instantly because it takes a non-trivial amount of time to traverse the hierarchy with the number and variety of database tables that have to be joined.

The current page is a compromise between these two extremes where the user get as many details as we can without hurting the loading time too much, but they still have to dig for some of the widget details. It is too slow and hard to skim for the department that wants the summary, and it takes too long to drill down for the department that wants the details.

The data model has small changes on occasion, and option 2 would mean maintaining an additional 2-5 pages when a new node or branch type is introduced. Likewise for maintaining a custom API to provide a window on the data. (These issues with the model are why option 3 is on the list.)

If option 2 is the way to go, I guess I'm looking for something that will run fast, be easy to maintain, and be simple to use/customize. But, maybe I'll have to settle for two out of three?

Answer 1

I think this is a case where user research would be of valuable information where you should actually have a discussion with the different user groups and see what is the exact information are they looking for and what the cases where they want to dig down to the granularity of data. I have in my experience generally found that users usually want access to everything but are generally looking for a consolidated view with an option to drill down as needed.

Hence my suggestion would be to do the following

1. Establish the list of potential data sources and the information you can show on the screen
2. Establish the list of user groups and the primary stakeholders in those user groups
3. Define in discussions with those stakeholders on what they would like to see and ask them to prioritize in terms of what is most important and what can be surfaced at a secondary level
4. Look at best practices of dashboard design with regards to how to surface data and how you can enable users to drill down.

Here are some resources to get you started

The Psychology Behind Information Dashboards

Dashboard Design 101

With regards to the second link , I recommend going through these questions carefully as they would help define your focus and establish the starting point on providing content to your users.

What data should we display

What is a particular user’s main reason for visiting the dashboard? Is the user making a decision or reacting to specific events or situations?

What triggers a user’s visiting the dashboard? What happens that prompts the user to view the dashboard? Is there some information the user would routinely review at the start of a work day? Or would a user go to the dashboard in response to a system-generated email alert?

How frequently would a user visit the dashboard? Once a week or several times a day? What is a user trying to assess? Does the dashboard answer questions such as How are we doing? If so, complete that question: How are we doing at what?

What critical decisions does a user have to make? For example, would the dashboard inform the user about any reallocation of resources? If so, it needs to make the most critical information available to help the user make an informed decision.

Are there conditions of which we need to alert a user? For example, an industrial control dashboard might alert the user that a critical parameter is out of range. This is similar to the gas gauge or engine-temperature gauge on a car’s dashboard, which not only informs a user about a quantitative state, but alerts the user if the amount of gas in the tank is low or the engine temperature is too high.

Answer 2

I agree with all of the answers here.

I want to add another option you can consider based on option 2:

Build modular content/data blocks.

As the pain-point seems to be on the creation of assigned custom dashboards, can this not be dictated by the user?

I recommend providing universal access to all content to start, then create a way for each person to "favourite" the content they want to see on their dashboard.

I've seen this work in Analytics Suites like Omniture and makes the most sense considering the challenge you're faced with of a diversified audience.

It's also much more manageable for your development team as well.

Answer 3

Option 2 seems like the right way to go.

2.We could give each department a unique page and view of the data tailored for them. However, our dev team is too small and this much extra work is impossible to complete given our current backlog. Also, some people are part of more than one department so deciding which view they get isn't trivial.

Your website should present the data to the user in the format that makes most sense to them. I understand the dev team being too small, but I can't imagine how costly it would be to scrap your data model as described in option 3. And option 1 sounds like it would result in a very unfriendly experience.

One way you could mitigate the amount of work is to define each department and prioritize their customized view. Then get to each of them as time and priorities dictate. After you complete one or two the feedback you get might encourage management to assign more priority to the other department's customized views.

I'd also suggest (if you don't do it already) that you determine the user's department(s) when they go to the website and only present them the data that's relevant, assuming you have user logins. If they belong to multiple departments then they get multiple views (tabs/choices).

Answer 4

It is reasonable to ask the dev team to AJAX loading and sub-content 'roll-down' into the UI? Start with the sub-content by determining (most-frequently requested * most-politically visible). Team builds an API service that delivers one small function.

The tiny-API approach ensures that Engineering doesn't feel overwhelmed, and thus reject.

The sub-content prioritization lets you pick where to start

The UI AJAX loading prevents clutter while enabling a faux-circumvention to drill-down.

The dev team can deliver further such tiny additions as fast-and-quick as there is free time between projects / sprints. People feel good and look more productive.

bonus points: cookie the user and record/count which sub-content they use [the most], attach the info to their session so that the first load of the page's AJAX can pre-fetch the things they usually drill-down into. You could even auto-expand it...