The following is a very rough, very disguised view of what I'm really working on, so hopefully it will suffice as a visual example for the following conundrum:

I have an app with a large spreadsheet view, which potentially has hundreds of rows. The idea behind this view is that it includes some key data that exposes trends e.g. percentage changes year over year, etc. The goal for this data is to then allow the user to spot either a disturbing trend, something to watch out for, or perhaps to investigate further.

In the wireframe example, I've given the fictional metaphor of a sales account spreadsheet. You'll notice that each account has a checkbox, and multiple accounts can be selected. The idea behind this is that you can group accounts, and view their sales data in an aggregate graph.

Regardless of whether or not you select multiple accounts or a single account, the next step would be to view that data in a graph.

My question is - what's the best way, in terms of navigation/presentation/layout, to display the graph for either single or grouped accounts. The graph view contains various things like date ranges, pre-set intervals, and various visualization options (bar/line, etc.).

In a previous, much simpler, iteration of this, the page was divided into 2 columns, with the graph view being omnipresent, and taking up 2/3ds of the page, and the table of accounts taking up 1/3, but with an expand button that opened the table in a drawer that partially covered the graph. While this worked well for users switching back and forth - the table view is actually the primary view, and is more important for this set of users, in terms of getting the birds eye view of their accounts, and spotting trends/problem spots, while the graph is more of a secondary component. Additionally, because of the volume of accounts for some users, the sidebar was too difficult to navigate within (multiple scrollbars, etc.)

Here are some of the new options we've been discussing:

1) Lightbox/new screen with the graph view 2) Have a small graph above the table view, which can be resized at will 3) Drive to a separate graph view, each time the user wants to view a single or multiple account graph

None of these really feel like great solutions, and I'm kind of stumped. What would be some things I should take into consideration here?

Table view

  • Can you provide mock-ups of the new options you've been discussing?
    – Monomeeth
    Commented May 9, 2016 at 4:14

2 Answers 2


Thanks for the description of the (anonymized) use case. I assume your statement "is more important for this set of users" is based on some form of validation (interview, observation, test). Such information is the basis for design, I think, although sometimes you need to think beyond what your users say and do today (after all, you might be able to create a new presentation that will help them do even better).

I still feel some inconsistency in there, though: You say the table may contain hundreds of rows, and users are looking at it to spot "either a disturbing trend, something to watch out for, or perhaps to investigate further". The table you show only contains 3 number (possibly four, if the micrograph represents another key figure - can't determine that without label).

I've seen many use cases where people want to scan tables looking for certain patterns, but in these cases the number of columns was much larger. For example, the columns represent sales volume per week over 3 three months (4x3=12 columns). In such a data set the user may search for patterns.

The data set you show is small enough to let the system search and present the issues, I think (but I don't know whether this is a result of "anonymizing" your use case & design).

So I would think about adding some one-click sorting functions ("Lowest Sales This Month", or whatever you users are looking for), which will bring the interesting rows to the top (i.e., the user's attention). The table thus contains the interesting items first, and its place on the screen can be reduced, giving room for a parallel display of the graph.

  • Thanks for your answer - there has been a great deal of sanitization here to anonymize this. Some of the details have been lost in the process, but to your point - here are some of those details, which are all things you've noticed: a) There are a lot more data points/columns in the real-life app - I believe it's at 14 columns currently, with lots of comparison meta data and trend icons up/down to indicate trends/changes in patterns b) The columns will have one-click sort functions
    – Phoebe
    Commented Mar 10, 2016 at 0:01

A closer examination of the user scenario will help clarify your UX. I can imagine two equally likely user paths.

1. User selects table rows then immediately moves to inspecting and analyzing the resulting data visualization.

2. User selects table rows, generates report, then immediately modifies selection in order to generate another report for comparison. In this scenario a user might generate many reports at once before moving on to the report analysis. (I think this experience would be dramatically simpler (though perhaps less powerful) since it requires users invoke the graphing action with a "Generate Report" button. A card or other piece of UI representing the graph could then appear below the list and serve as an entry point to that graph.

Design your product to have an opinion on which of these workflows will better serve your users. Constraining the experience around this will help you make design decisions and should answer other UX questions like "Is live-previewing of the graphed data a requirement for our users?"

Your Answer

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

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