The Australian Government coat of Arms

Communities of practice

Communities of practice

Sidebars - User testing results and best practice


I’m currently working on the front end of the ABS website and I’m hoping the community can help with a question on sidebars and if there have been some user research results that could be shared.

Looking at some content page types of beta version of the DTA website, (example) the sidebar is on the left and on large devices the main content begins some way in from the left margin. Is there any research in for the change from right sidebar to left?

We are looking at implementing a similar style layout for large content pages, potentially with fixed inline nav on the left. Our concerns are that users may struggle to scan content or won’t make the effort to look over and read the content when the content starts far from the left. Or customers using Magnify may be frustrated having to scroll to the right to read the content. Really interested in others research findings so we can decide to include or eliminate this option from our next round of user testing.


Hi @Nathan.McDowell this has been brought up before, however I am not sure where. Often it comes up to what is most important to the user.

In a large structure like a book that has been translated to a web interface. It may be very important to see what section they are in and what other sections exist. In this case you may want to prioritise the navigation so having a sidebar on the left would be better.

Most cases in government sites the sidebar is used to help the user know where they are, and the content is really what the user wants when they arrive on the page. In these cases I would recommend putting the sidebar on the right and giving the content the priority.

There is no perfect answer and I would always recommend usability testing.


Agree with a priority being to orientate a user who lands within the site and therefore use a left sidebar for site navigation (left nav example).

However, we do use a right sidebar for in-page navigation in our digital publications layout (example: right sidebar nav). In this case, we drop the left sidebar (site navigation) so that we are only focusing on publication itself. You’ll notice a design influence from ANAO website publications.


Hi Nathan.
Our initial research on both the ‘classic’ DTA website ( and early versions of our alpha site showed us users had real trouble locating information in the site. Even though we provided a right hand menu, there was a blind spot for people right there, apparently because it is usually where ads are shown on other sites. There were other problems around clustering of information, and general IA.

To that end, we decided to use a left hand menu instead. Our hypothesis was it would allow users to become familiar with the layout of a site section (as @thomas.buckland also does) , and quickly find content because it is right there when you open up a page. We combined this with a card system on our Level 1 and Level 2 pages which provide immediate access to lower levels of the IA. Our Level 1 pages have no side menu at all (for example and our research has shown this to be a very engaging way for people to navigate the IA.

The actual position of the menu has not come up at all in our recent user research, but maybe it is something we could directly address.



Hi @Nathan.McDowell, in case you haven’t already take a look at our work on Design System’s new Side nav component. My contributions have come from our information product Digital Guides (

Based on your use of ‘may’, are these assumptions your team have or did you observe this in usability testing? (If the former, test those assumptions with end users, pronto :smile:!)

Keen to get more info. There are many elements that can contribute to the structure and order of information in the layout, a.k.a ‘information hierarchy’. It’s worth understanding what works and what doesn’t for users within the existing layout before adding or making changes to it.


Thanks @alexandra. Correct, it is just an assumption and we are in the middle of user testing now. I was more hoping to get some user research data from other projects. I’ll report back once we have some more results on how we went.


I look forward to seeing what you find out. Knowing what people want to do on the site and what specific things are impeding them will also help you understand what elements of your page are important, and when.

Coming back to the inclusion of a sidebar, it’ll depend on what user goals the containing content aims to serve…perhaps the layout could accommodate a different structure for the content you’re considering putting in a sidebar. Think content-first around your users’ goals and the structure and form will start to fall into place.

If there are internal requests to put in ‘quick links’ into a sidebar so users will find them, perhaps you could first consider the factors leading to not finding those links in the first place. Maybe the links are buried and/or not integrated with the body content? If there are ads (incl. campaign site ones) to display, is there a way in which sponsored web ‘real estate’ could work harmoniously with the content rather than distract from it? If the sidebar is a side nav what’s your information architecture like, and how much do users need at any one time before deciding where to go next becomes overwhelming?

It wasn’t until about end March this year that Digital Guides had a new and improved side nav, formerly on the far right side of the screen and attached to an ‘intro’ content item.

We only use a sidebar (which collapses down into a page-top accordion on small devices) for category navigation. This was because we found through prototyping, site analytics and usability tests that our users tend to focus more on one section of the site in a session or two, less so going constantly between topics of very different categories, eg service design and signing off on a content brief. Our side nav therefore didn’t need to provide links to everything local to the category AND then some.
And then I thought through edge cases like very deep pages :unamused: and main pages. On Digital Guides we have a few main ‘category’ pages for in-depth topics, like Content Strategy Guide’s landing page:

We have a primary nav bar across the top of all pages that tells users what the overall structure of the site contains and which bucket they’re browsing. To go a bit deeper into the chosen bucket we list all of the next-level (level 2) pages in a sidebar, like so :point_up:. This serves as a quick lookup and point of access for frequent/returning users, whereas the cards with the descriptive text in the main content area of the page communicate the relationship between topics and an overview of what they’re about.

Going further into these content modules (topics can have sub-topics and sub-sub-topics or templates attached) on Digital Guides, I ensured that users would know where they were in the site, where immediately relevant pages could be found (as siblings or direct children) and what parent it belonged to. Some decision timing tests (Side nav) helped me narrow down a viable concept for how much information and how much styling might be adequate before putting a simpler concept in front of end users.

Before this, the Digital Guides team had done many iterations on the content types for our pages and we upgraded the site to use UI Kit 2, which also meant (much to my own relief) we could ditch our earlier prototype scaffolding and make best use of the available space. Supporting navigation via a left-anchored F-frame didn’t just work aesthetically and more flexibly with our responsive grid, it also eliminated disjointed breaks in the content and freed up more space for where users predominantly give focus.