A comprehensive dissection of one of the most illogical long-standing design traditions.

If you're a digital product designer in 2025, there is an extremely high chance that you'll either have to design a dashboard, or work on a dashboard someone else has created. It makes sense. Every interaction online is tracked, to a terrifying level, and companies need a place to display that data so it can be digested and acted on. This is where a dashboard comes in.

A product owner or manager will tell their design lead that they need a dashboard to display a bunch of metrics and the designer will go over to dribbble, check out whatever latest trends have made it into the world of dashboards (currently, ghosted glass effects and rounded corners, give it two years and we'll be back to solid blocks with square corners) and they design their dashboard. PM's get graphs, C-suite gets information, designer stays employed. Everybody is happy.

However, the problem is when the designer goes to dribbble to see what the current landscape of dashboard design is. When dashboards started becoming more prevalent in the design industry it seemed that every dashboard had a left side navigation. Maybe it was a trend at the time, maybe it was a way to differentiate a webapp from a website, or maybe it was just a hippo. Who knows, and honestly, who cares? We're talking about left hand navigation on a dashboard here. We don't exactly need historical context to fix what's wrong with them. But there are many things wrong with them.

From a design and development perspective they're an inefficient, inheritly limited and aesthetically compromised solution to a problem that only exists because the archetype of a dashboard has always had this attribute. So with that in mind let's dissect why they're a poor idea and what the superior solutions are.

Space

The biggest issue is that a left hand nav is that it is a complete waste of space. Dashboards tend to get cluttered very quickly. The have an abundance of elements - Graphs, Type sizes, numbers, colours, boxes, tables - All that fun stuff. Unless a designer is very good with displaying hierarchy and emphasis, this will make the dashboard devolve into an orgy of information overload. It will be difficult to navigate and to use some design-nerd terminology, unnecessarily increase cognitive load, which is bad.

We can free up valuable screen space by removing the left side navigation. This opens up two options for us.

1. We can now center the dashboard horizontally. This gives us some lovely whitespace on either side of the dashboard which helps focus the user on the content. This is a quick win in terms of hierarchy and aesthetics. People tend to like centered content and it looks less cluttered.
   
2. Or we can put even more content into the dashboard because we can go right to the sides of the screen where the navigation used to be. This is particularly helpful in occasions where data density is at a premium and aesthetics can take a backseat, for example, a day trader's screen.

By removing the left side nav we visually balance the screen and improve visual hierarchy of each element so users can quickly focus on the most relevant piece of information. It will also add a sense of space and visual relief, making the dashboard more aesthetically pleasing.

Okay, so I think we're all aware that getting rid of an element is beneficial because it visually reduces clutter. However, we now need to put that element and it's content somewhere. The solution for this is to put it in the top, horizontal navigation. Websites have been doing this for a couple of decades now, so users know how to use this form of navigation. That's the first problem out of the way. The next thing we need to consider is the sub-menu items.

For this we use drop down menus. Again, like normal websites have been doing for decades. This is superior to a left hand nav in most aspects, and the one that it isn't, has a natural solution (which we'll get to in a minute)

So lets assume we have 6 categories each with 6 sub-categories. This is roughly the amount of sections most dashboards I've designed (which is a lot) have had. Obviously there is always going to be some exceptions (Jira, Confluence), but the majority I've seen or designed have roughly this amount.

On a left hand nav, there will usually be the parent category, which, when clicked will show the child categories, like so:

Instantly we can see the first problem. The sub-categories push the parent categories down so you can't see them. This isn't a huge issue to be honest - It can be solved with typography and super interesting things like screen sizes and resolution mean that this issue isn't usually too difficult to solve. The main reason I bring this up is because people's arguments for why this is good always seems to involve the fact that they can't see each sub menu item. I'm here to make an admittedly quasi-anecdotal argument that this isn't an issue at all. Here goes:

If a user is navigating somewhere, they'll go to the menu, find the link they want and then click on it. They don't need to constantly refer to the link they just clicked on because they're now looking at the destination of the thing they clicked on. It's like if you're looking on a map for a location, you then go to that location and when you get there, you open the map and keep looking at it. It doesn't really happen.

By using a drop down menu we have exactly the same amount of information being displayed. However we're now only showing information when it needs to be shown (when the user is looking for it) and when it isn't needed (when the user moves their mouse away or taps somewhere else) it disappears. This cleans up the design and makes it easier to direct the user's focus to the areas we want them to be looking at. Users don't need to see everything all the time (maps, destinations, looking at maps again, etc).

The next argument that gets put forward right about now is "Well how will the users know where in the navigation they are if the active link has disappeared in a menu that is no longer visible?" Now we come to the natural solution I was talking about a few paragraphs back.

Each page in the dashboard will most likely have a title.

Just like after a person has used a map to find their destination, they know when they're at their destination because there will be a sign, or in our slightly more digital case, a page title. The other workaround here, is to introduce a second horizontal sub menu below the main menu, which I did here. It's like using breadcrumbs, which is pretty oldschool but it still holds up.

So now that we've discussed the negatives and how to mitigate them we can move on to the positives. Let's talk about space, grouping and pixels.

One of the worst things about a left hand navigation is that it takes up space and then fills it with wasted space. In this case my definition of wasted space is non-white space. Space is at a premium on dashboards and clutter is bad for navigation and hierarchy. Whitespace is the solution to this. As we discussed before, most navigations have about 7 items, so lets visualise this again using slightly more realistic proportions in the example:

We can see here that the red space is significantly less on the horizontal nav then the left side vertical nav. In fact, according to some google percentage calculator the left side nav creates 391.7% more wasted space than the horizontal nav. I'm sure a few of you are now thinking "hold on a minute, I thought you said space was good?" And my answer to that is, yes, whitespace is good. However, as this red space is grouped within an existing navigation box visually, we now associate it with those elements, so it's no longer white space.

So that's space covered, now let's move onto...

Grids

Lets get this out of the way, if you aren't using a grid and consistent pixel increments (4, 8, 16px etc) then you're going to have a messy design and you're really going to annoy your developers. So how does this specifically relate to left side navs on dashboards?

By having a left side nav you're adding an element to what is most likely going to be a fluid width section. Screens vary horizontally, where as vertical sizes are easy to predict. This horizontal variation makes it easy to mess up the visual design as the proportions between elements will be shifting constantly. This is always going to be an issue on responsive websites and now you're adding another component into the mix. This new component is a constantly floating-to-the-left-of-the-screen box and it just makes it more difficult than it has to be.

On the surface this doesn't seem like a big deal but like everything in digital product development, in practice it is. Allow me to explain. First of all, we have the menu component which (again, anecdotally) is often designed completely independently from the content on the page. This means that unless the company has a solid design system (spoiler, 99% of them don't) then there is a very high chance that a measurement has changed or they're using a new grid structure. Either way, the left hand nav could have an independent size compared to the other components on the dashboard.

So now the juniors on the team will be designing around this left hand nav, they'll start putting elements in the design that aren't on the grid, or they'll start resizing the nav so that it is on the grid, then the devs will start asking why the component sizes have changed, then the PM will get called in, then it'll become a 2 hour meeting as you try to explain that it really isn't a big issue, it's just that a junior that got confused, then they'll start discussing something else completely unrelated to the original issue, then you'll start to wonder how a childhood interest in drawing led you to being stuck in a room with a bunch of increasingly agitated men and one silent woman (who tries to talk once then gets talked over) arguing about why Jenkins isn't performing, and more importantly, you wondering yet again what the fuck Jenkins actually is.

So that's the first (admittedly shaky) argument for why grids aren't a great partner for left hand navs. At this point I can feel the internet collectively seething behind it's monitors. People who are just dying to out-UXsplain me so they can post about it on Linkedin to mentally justify the money they spent on their bootcamp, but simmer down for a minute because I've got another reason and it involves...

Development

Let's rewind for a second and talk about space again. The answer to left hand navs taking up space is usually a well intentioned: "We can just collapse it down." This is a solution to a problem that shouldn't exist in the first place and it's not even a good one.

Now we have all the main dashboard components shifting over to the left because the navigation has reduced its size by 80%. Now the devs have to figure out how this works on different sized screens and how that fits into the existing grid structure. Speaking of the grid, you now have to set up all your design files with these two different sized navigations in mind. Congratulations - You've just 2x'd your workload, for every screen (and that's being very generous and it's only counting one screen size, not responsive sizes). And now you've created a new problem for yourself. What does the nav show when it's collapsed? The text no longer fits in there, so obviously you'll use...

Icons

Duh. Unfortunately this creates a new and completely avoidable problem. We have to add an icon for each menu item. Now we're cluttering up yet another element on our dashboard, which will be getting cluttered up soon enough with other information that is actually important anyway.

Most people would put the icon next to the text that it represents, but this defeats the purpose of the icon. You've got two elements saying the same thing in two different ways. Now you only get the benefit of the icon when the nav is collapsed. Use either a title or an icon, not both. If you use both then the icon becomes decoration and not a navigation aid. Let's dig a bit further.

Icons work when everyone knows what the icon is. A magnifying glass is for search, a cog for settings. Everyone knows that. But what happens when your menu item is "Oil plant reaction phase" or "Yak fur density Q4?" There isn't an icon for that. And even if there is an icon you've then gotta get it designed, or buy it, or use google material icons. Then you have to go through a swamp of approvals for these icons and because nobody has a common consensus on what constitutes an icon for Yak fur density, and you'll likely end up in another meeting wondering again, what is exactly is Jenkins and why do devs talk about it so much? Then your icon problem will either not get solved or you'll get an icon which doesn't represent the thing it's meant to and your users will be confused then you have to do more user testing to solve a problem that you created in the first place. Great!

Conclusion

There are very few reasons to use left hand navigations in dashboard design. Just because something has always been done a certain way, doesn't make it the best way to do something. The appeal of tradition is a flawed ideology at best, and a really really irritating way of designing things at worse. It's inefficient, aesthetically weak and it's actively costing your business time and money that it shouldn't be. I'm going to keep updating this article because I'm sure people will argue with me because everyone always does, but unless you're designing a behemoth like Jira, 99% of the time you shouldn't use a left hand navigation for your dashboard.

TL:DR

1. Left hand navigations on dashboards are only popular because they've always have been, aka the appeal to tradition fallacy
2. Dribbble, and other design inspiration sites reinforce this pattern
3. Left hand navigations waste space
4. Left hand navigations increase development time
5. Left hand navigations increase design time
6. Left hand navigations are more difficult to work with in a grid setting than horizontal navigations
7. Left hand navigations often need to collapse to increase screen space, which leads to an increase in development time
8. Left hand navigation often need to collapse to increase screen space, which leads to a reliance on icons, which are often ambiguous
9. Horizontal navigations allow more space for content
10. Horizontal navigations make aesthetically pleasing design easier
11. Horizontal navigations make hierarchy and navigation easier