This one is very specific to enterprise products. Often, listing screens are where users spend most of their time. They initiate transactions or follow-up actions from the listing page. This being the case, users often need a lot of information about the transaction so that they can filter and find data. If two different stakeholders use the same list page with different motives, the page design can become very complex. The details that each stakeholder wants to see before taking the next step is different. Let us take an example:
Logistics company ABC has two departments that need to look at trucking information:
- Transport planning department — Needs to look at a list which they can use to identify the status of trucks, what they are carrying, what was the loaded weight, where is the destination and a host of other information.
- Accounts department — Needs to look at a list of trucks that need to be invoiced to the customer. They need to see the customer names, the route, and the product.
Before we attack this scenario, I will explain another related concept. How much does the user need to see before clicking & why?
Well, it depends on who is clicking. Going back to the truck example, the logistics guy may need to see a whole lot of information to plan his next move whereas the accounts team needs to see a limited set of things.
It all comes down to user research. In most cases, we build one listing that fits all purposes. This leads to a situation where no stakeholder is happy.
So why is this a problem? Most transaction based systems use relational databases that store data in tables, there are several tables that are affected in one transaction in a parent-child relationship.
For example, A truck can carry multiple commodities between multiple destinations. If you assume that you need to capture locations and weights at both loading and discharge locations you have already created at least one set of parent & child tables. In order to query any record, you have multiple joins which eventually bog down performance. Ultimately, performance tuning on queries and indexing takes you only so far. The system will slow down and become painful to use.
Now let’s link this to our original issue. There are two stakeholder teams using the same listing — one needs granular information about the transaction and other needs high-level information. Granular information means more joins in traditional RDBMS systems. Performance of the listing degrades as time goes by. To improve performance the product will have to take calls to drop information from the listing that slows it down. This will impede the logistics user from making decisions. If you don’t do it, the accounts department will find it slow and raising invoices will become a pain.
The solution is clear, don’t mix concerns and build a one screen fits all listing.
Nobody can predict how things will pan out in the future. Design in a way that each listing can mature for its own stakeholder.
Sometimes you will have many stakeholders within the same team who need different types of information. Go ahead and build separate overview and granular info listings. As far as performance goes, make sure your developer knows from day 1 that this could be an issue. They can implement appropriate solutions like creating views, caches, writing stored procedures to populate flattened tables from the underlying joins, partitioning tables, archival, etc. Technology has evolved so developers have a plethora of techniques like caching to tools like Elastic & Algolia to solve search & list issues.To summarise:
- Don’t try to build a single listing that displays both granular as well as overview information.
- Don’t mix stakeholder concerns & build a one size fits all listing.
- Analyze volumes & have conversations with developers about listing and search at the beginning.