Hierarchy in System Design

I’ve been thinking about a pattern I see in effective systems (including user interfaces, code, filing systems and other systems in the world which involve human interaction). They have a thoughtful “hierarchy”. Further, there are some specific patterns which seem conducive to making systems easy for humans to use. This first part might seem obvious to you, so feel free to skim a while.

For the purpose of this article, when I refer to a “hierarchy” I simply mean anything with a nexted tree structure (trunk and branches, and sub-branches). ie) nested folders, code in functions, blocks in a user interface. Infact, let’s just refer to ‘trees’ rather than ‘hierarchies’ from here out.

Trees can be tall and skinny, or even a single “stalk”. They’re still trees.

Or, short and fat. Even, a single flat bush of leaves. It’s still technically a tree (with a height of 2).

But, it seems clear these are not usually very good trees to use for organizing your files. Imagine a folder structure which like the skinny tree above. The “fat” tree is the case when you put all your files on your desktop. (Sometimes that might work well for you, because you are using your spatial intelligence to organize the files and you can see them all at once!)

You can probably imagine how user interfaces are trees of nested “blocks”.

As is code.

tree.py
   class Tree
      def branch1(self):
            for i in range(3):
                  print("leaf")
      def branch2(self):
            print("leaf")

Trees provide categories to organize our systems, and they provide categories of categories. They show up in systems that we build, so we can remember where things are, and find them using logical steps. This can be more important if you work on a team, and your project grows large. It may turn out to matter a great deal. According McKinsey, employees spend an enormous quantity of time (around 20% 1.8 hours) searching for documents and other assets, so it seems like a slight improvement could affect your team pretty dramatically.

This is where things become a bit interesting to me. Let’s do a thought experiment, and estimate how long it might take to find something in a company’s system of folders. Some assumptions to simplify things:

1. Let’s assume for now you can’t search or scan alphabetically because you don’t know the filename.
2. Your company has 5 root folders, “finance”, “sales”, “product”, “marketing” and “people ops”.
3. Each of those has 5 folders inside, and so on, to a “height” of 5 including the root. And then, there are 5 files in each “leaf” folder.
4. So, to find a file with a list of expenses: You have to click 5 times. ie) “root” -> “finance” -> “2022” -> “expenses” -> “expenses.csv”

Now, how many things do you have to “scan” visually, to find your file, in the median case?

If there are 5 items at each level, and you traverse 4 levels starting from the root, then you read the median 3 items at each level. So, that’s 12 items you have to “scan”.

If we put all files (there are 5 x 5 x 5 x 5 = 625 files total) in the root, you would scan half of those in the median case. That’s 313 things you have to scan instead of 12! What if you nested the folders far deeper, say 10 levels. Now you have to scan approximately 20 items, but you have to click 10 times. The point here is, I think we’re much happier to reduce the number of things we scan and click when looking for things many times per day.

So, there’s a sort of optimal hierarchy which might be at depth 5 (or an optimal tree with height 5), assuming we want to minimize the number of scans and clicks. I believe it’s the same principle in user interfaces (scanning fewer blocks to find what’s relevant without reading the whole page) and code (having reasonably sized files and functions). Note: I’m not referring to actual tree visualizations here, just the fact that the DOM has a tree and all UIs incorporate nesting information in some form.

Is this example contrived? Yes. But, I hope it illustrates there is a great deal of leverage in spending some time building better trees.

I’ve seen a lot of source code where everything is in one file (which is suboptimal because the tree is too short/fat). Or, code where the author likes making functions with only 3 lines of code (Java) leading to stack traces with 2000 function calls (too tall/skinny). Or, code projects with 250 dependencies (NPM). All of these situations likely waste an enormous aggregate amount of time and effort on the part of humans using and maintaining the system.

Of course, there are many other factors which affect system usability, and some of those may not perfectly agree with the optimal tree height calculation here.

But, all other things being equal, a system which allows you to find anything you need with a small number of easy choices is better than when it requires looking at additional material that is not relevant to the task at hand. A thoughtful hierarchy (including a practical height/depth) may help significantly in some cases.

At the very least, when we spend 20% of our time looking things up, it’s probably worth spending 1% of our time keeping things organized in order to reduce that effort.