And let’s say that several or more times per session the user needs to find a specific THING and then see who it was sent to. While each THING has a unique ThingID (purple) the user knows the thing by the Name and Address (magenta).

To find transactions they need to scroll to the TransactionID (green). And SentTo is farther (cyan). At this point, most of the identifying THING info is not visible anymore.

Think about trying to follow a row while horizontally scrolling…

And if they need to check on TRANSACTION comments (2nd cyan) then none of the identifying info for THING or TRANSACTION are visible and the chance of reading the wrong row is very high.

Sometimes freezing the left columns so they don’t scroll can help but this case illustrates a time even that doesn’t help because the user identifies the THING by the name and address and that already means the TRANSACTION columns are off-screen.

Let’s look at some other options…

The following examples are not necessarily the best solutions — just examples of handling the data differently to optimize for different amounts of data or different tasks.

The importance of knowing how many things the user has to deal with

The image above represents hypothetical distributions for the two kinds of objects in our system. Each bucket (or bar) represents how often users encounter tables with that number of items. If these distributions are for all users over time then many users are encountering 30 to 60 THINGs with 7 to 12 TRANSACTIONs.

A uniform distribution — often said to represent the total user population.

You might hear, “Some people have a lot of items and others only have a few so we need to design for any number of items. A somewhat uniform distribution may exist for the set of all customers across time. But, who cares what every type of user sees all of the time. What is important to make efficient or delightful experiences is what each type of user sees per task.

For a given user the set of items they work with will usually have a shaped distribution.

Note that having the same shaped distribution doesn’t mean that the experience can be the same. In the distributions above — showing the number of THINGs or TRANSACTIONs from a sample of users, the 1st bucket is 1–10 and 1–2 respectively. A distribution with buckets running into the 10s of thousands or higher, like an Admin dealing with network traffic or HTTP transactions could have buckets in the 10s of thousands or millions.

Distributions give the best insight into design options when the possible number of objects or items is less than 100. When the average number of objects goes over 100 filtering and grouping strategies are needed on top of the design directions below to turn the data into small enough sets to understand, decide and act upon.

Bi-modal Distribution

A bimodal distribution is possible if your user base serves two kinds of users like both small businesses and enterprises. But if you do have both kinds of clients then you may want designs that cater to the needs of a user who only has a few items and some separate tooling that caters to the enterprise users with 100s to 1000s+ of items.

Solutions for different distributions

In the following, the examples are one possible way to handle the data based on the number of parent and child objects the experience needs to handle. The examples, however, do not take into account users’ goals and other use case factors.

If there are many items and many children than a table that leads to another page with a table may be appropriate.

Ping-ponging between THINGs page and TRANSACTIONs page.

However, going between the pages creates a ping-pong effect — Click to THING 1 page, return to TRANSACTIONs page, click to THING 2 page, repeat ad nauseam. If part of the task is to compare or understand transaction info this can be tedious — with every round trip eating up interaction equity.

The importance of knowing the user’s goals section below discusses some options for reducing the ping pong effect by giving the user better information to make decisions with the table.