Sidebars and cognitive overload



hi folks!

We are starting a re-design project for the sidebars provided within some of our web apps.

Context: those apps are designed for professional people within the bank industry (eg asset managers, portfolio managers, relationship managers etc)
User Tasks: the apps are provided to help banks during the client lifecycle. The sidebars are one of the most used tools to start working with a use-case. They search for a specific customer, they want to open a portfolio to work with or they want to create a new object for a specific customer
Current Situation: all the sidebars we have are providing data within the same container (a container of 220px width). Due tot he size of the sidebar some menu items are very packed with content and actions (lists, CTAs, links etc)
Target Situation: Our goal is to drastically decrease the complexity of the sidebars and design a new version based on the “progressive disclosure” usability pattern. We want to be more mobile friendly and allow users to browse the apps with their tablet in landscape mode

After a couple fo design sessions, we figure out the first solution draft.

What do u think about it?
Did u work on a topic like this?


First off, your sketching skills put mine to shame. You’ve also reminded me I need to buy some new shading markers. Any suggestions?

Also, for anyone not familiar with the concept, here’s a rundown of progressive disclosure from

Summary: Progressive disclosure defers advanced or rarely used features to a secondary screen, making applications easier to learn and less error-prone.

Interaction designers face a dilemma:

  • Users want power, features, and enough options to handle all of their special needs. (Everybody is a special case somehow. For example: Who wants line numbers in a word processor? Millions of users, that’s who, including most big law firms.)
  • Users want simplicity; they don’t have time learn a profusion of features in enough depth to select the few that are optimal for their needs.

Progressive disclosure is one of the best ways to satisfy both of these conflicting requirements. It’s a simple, yet powerful idea:

  1. Initially, show users only a few of the most important options.
  2. Offer a larger set of specialized options upon request. Disclose these secondary features only if a user asks for them, meaning that most users can proceed with their tasks without worrying about this added complexity.

The print dialog box is the classic example of progressive disclosure. When you issue the command to print a document, you’ll get a dialog box with a small set of choices — mainly, how many copies to print, but possibly a few other variations, such as whether to print the entire document or a subset, and which printer to use. Sadly, print dialog boxes have grown bloated over the past decade, and some applications offer an initial dialog box with highly detailed options that would be better placed in a secondary dialog box.

The initial print dialog box typically contains one or more buttons for advanced options. These buttons lead to secondary dialogs that let users specify rarely used settings, such as scaling and printing the pages in reverse sequence. If the user clicks the advanced options button, the system discloses the additional features.

I work in a similar vein, in that my work deals with financial advisors and client management. Anything that you can do to increase the cognitive load is a plus.

I’ve found the most difficult exercise when designing a progressive disclosure system is identifying the functionality to expose first. In some screens and workflows, it’s apparent. In others, I’ve been surprised what my research has uncovered.


Thanks a lot, @dougcollins :slight_smile:
I use several brands but if I have to suggest a good one there’s only one answer:
They’re rechargeable!

I see your point. We have the plan to show a couple of proposals to some customers and collect findings from them. According to your experience did u deliver some sidebar with specific actions (search, filter, etc) at the first sight?

Within the design team, we have these 2 strong positions

  • one is about to showing only navigation (buttons and links) to the flyout
  • another one is about to show a minimal amount of features within the first view of the sidebar

We had a wild table soccer match to decide which one prototype first!


I think your solution is good here. I am just wondering instead of coming up with the “panel” on the right side. Why don’t you try something below the menu link. See my attachment


So much this.

Calling @mattymcg who has recently started a business importing markers. Prob won’t work for you given that he’s in Australia but I imagine he has good advice.


This is how the sidebar is implemented now.
As I wrote before the sidebar provides user-tasks and not only navigation patterns.
Each sidebar section as two status:

  1. default status with a search field and a list of “last viewed” items
  2. update status with the results coming from the search field and/or some filters

Last but not least, as I said, our goal is to keep the sidebar within the 1024*768 breakpoint and we want to avoid the scrolling experience


we had another design session focused on the user journey and we decided to expose the “global” search


I am working on a very similar problem (for a payroll software) and ended up with a similar solution.
Also during the assessment of the current experience of the product, I saw this pattern very often: I scan the navigation (top and sidebar), if I haven’t found what I needed, I then tap on the first search bar I see/saw. This is roughly half of the people, the others try a little be more to actually use the navigation.
Now, I only need to test my solution with the whole context around it.

Questions: you said that the sidebar is the most used piece. How do you know? Do you have analytics about the actions that users do on a given page? Are you thinking to use them also to take a first stab at what to show first?

Thanks! :slight_smile:


ciao @saratraverz
Thanks for your questions :slight_smile:

These apps have a strong legacy to our core desktop platform.
The UX strategy when the company started to provide web apps based on that platform was to decrease as much as possible the learning curve.
That’s why the user journey starts with the sidebar because is the only place in the UI where the user can search for an object to work with.
We run workshops and we send surveys to our customers to double check if the sidebar is still the most important starting point.
At the moment looks like they are happy to work with such component, and that’s why we want to re-design it. The next generation of sidebars will be checked by analytic tools too.

We believe that for soon-to-be customers this pattern will work fine and we want to keep the sidebars as the starting point for the user journey.

Did I answer to your questions?


yep! thanks! I was curious :slight_smile:


HI all, I stumbled on this post as I am busy looking into sidebar options.

I quite like the idea of a hidden sidebar, but I know some users find it annoying. And from my experience it usually has to do with the fact that some sidebars are “click” activated and some appear on mouse hover.

Any tricks and tips when to use which one?


Honestly, I don’t have any rabbit in my hat to answer your question.

I always rely on providing a design that scales no matter the device and the breakpoint.
Said that I avoid to hide/show UIs by hovering a control:

  • the behaviour is not finger-friendly
  • the click/tap action is more controlled by the user
  • it depends on the hierarchy level of the component, for instance, is this sidebar provides the main navigation items, I would not provide any show/hide feature to it

Did I, somehow, answer to your qeustion?


Yeah I fully understand…I think I might have been taking a chance that there is a Miracle Manual out there somewhere. :grinning:

Because my troubles now is funneling down all the results from my MANY google “best practices” searches into what I want my system to be…

Think I mentioned this in a previous post.

I have too many options and I am a kid in a candy store right now. I just need to decide and move on from there.


I would go for the option that is more consistent with the current UX patterns
it will be less costy in terms of development and it should be the fastest one to implement
Starting from that point it should be easier to measure the UX performances