The Australian Government coat of Arms

Communities of practice

Communities of practice

Side nav

Conversation for the Side navigation component.
See also Main Navigation

Also known as

  • Side navigation
  • Local navigation
  • Verical navigation


A way to navigate within the current section/area or to sibling pages, which works well on both mobile and desktop without conflicting with the Main Navigation

You can also view the component page on our documentation site for the Side Nav component.

Moved from:

Currently there is no tabbed navigation module similar to UI Kit 1. Are there plans to include one in 2.0?


govau-nav design

primary-nav design


  • [ ] variation for the hamburger to be left or right

uikit 1

Design guide

secondary-nav design

auds 1

Design guide

We’ve been noticing a lot of user confusion with the local nav collapsing down to “in this section” on mobile. We’ve tested alternate layouts and the best performer is based on Material Design, it gets around the problem by embedding the nav into the page on mobile. The parent page becomes a kind of back button at the top, the children are listed below the content and the siblings are listed below the children. This raised task completion when finding child pages on mobile from 4% to 60% across a sample size of 50 users per variant in remote unmoderated testing.

Expand the image to see the nav elements

1 Like

This looks great @podgkin
Thank for the data. We will have to embark on that journey soon to find a nav model that suits many needs (although not all) and build some prototypes.

Did you have anything in production yet?

3 posts were merged into an existing topic: Navigation - Main / Horizontal

We also have a DTA style “in this section” secondary navigation in production, however our testing routinely shows users unable to recognise the collapsed version as a navigation element.

We had trouble rolling it out across the whole site, due to a lot of our content having multiple parents. We have now developed a new content model and relationship based site architecture, that lets us do some funky stuff under the hood to render unique versions of shared content according to where you are in the site. This will let us roll out the secondary nav and improved breadcrumbs over the next couple of months. Once that is done, well can roll out the design I posted above.


Thanks @svict4, that sort of checklist is awesome for anyone working on navigation regardless of UI-kit/DesignSystem. :+1:

In regards to a side-nav (or local nav) I’ve just had to close a PR #204 because it got too far behind master. But I’ve pulled out the basics into a code pen so that we could continue to discuss the goodness.

The proposed pull-request by Alan was a side-nav in a similar style to DTA, Health, and DHS which is ace.

One of the design challenges I’d like to see if we can overcome with this component is the double menu buttons on mobile. Where the main/horizontal nav, is hidden in a hamburger icon and the local-nav/side-bar are also in a button. “Menu menu” obviously isn’t good labeling but I’m curious how this pattern is working for other teams?

Not sure if i’m super keen on the DTA example if comparing it to Health and DHS. Both the global nav and the complementary nav are labelled as ‘Menu’.
Two UI components that are named the same but which perform different functions could lead to confusion.
It’s good that each are in their respective landmarks. But the ‘in this section’ labelling given by the other examples seems clearer all round.

@chris.lamb, yes, I agree. As per above it’s an example of what’s not working. (Edit. And something that should be resolved with any proposed navigation component. :slight_smile: )

1 Like

With apologies Trevor, I misread your above post and now realise that I was pretty much echoing what you said :slight_smile: I wouldn’t go far as saying those examples are ‘not working’ tho. I think they work well enough. But I’m at a loss as to suggest an alternative that’s perfect.

One option that I’ve gone for in the past is including sub-nav items within the main nav. Nested within ‘show / hide children’ expanders.
Example on:

I feel that this gives a nice experience on mobile for small web sites - no more than maybe 3 levels deep. But will likely turn into a nightmare of nested lists if used as-is on larger departmental websites (for eg).

@chris.lamb yeah no bad vibes, i know you’re being constructive :v:

Yeah I’m personally fond of the side-nav being included into the hamburger on mobile, but yeah, could become unruly on large multilevel IA :thinking:

Hi everyone,

Thought I’d give a quick update on the new navigation systems we’re developing for Digital Guides.

Up until now this beta site hadn’t provided users with the means to get between sibling topics within a category. At least, not other than going back to the category page (which we know is slow and extra effort for users).

In our April 23 release we added global navigation, the tab-style primary navigation pattern that is now featured on DTA’s new site ( This allows users to get a sense of the breadth of content covered by the site and go between areas of interest.

We’re currently developing our secondary navigation, which will appear to the side of the flow content and separate from the header/global nav. This secondary nav will allow users to navigate between siblings and to direct children (i.e. sub-topics) of the page they’re on. We hypothesise that knowing what pages are immediately around the page they’re on (via secondary nav), how deep they’re into the site (via breadcrumbs), and what section (reinforced via global nav) they’re in will improve wayfinding, users’ understanding of location and allow them to better connect with related material.

Given the depth of the Content strategy guide - I’m limiting how many layers of nav are exposed in the secondary menu, so that users don’t get overwhelmed by layers of pages that likely aren’t relevant to decision making at the category level.
Rather than going with an accordion group-style list of nested links:

^ which you can see provides too many choices and potentially costly interactions to make an informed nav choice

We’re going with a static list that only shows up to three levels:

  1. Page parent (unless already viewing the top-most page)
  2. My sibling(s)
  3. My direct children (not grand or great-grand children) if available.

We’ll be testing our hypotheses of course, to see whether or not these nav choices align to user’s mental models during some info-seeking activities.

p.s. on smaller devices like tablets and smartphones, the secondary nav will be collapsed into an accordion titled ‘In this category’ and will appear under the mobile ‘Open menu’/ header and before the page title. The accordion and header are split into distinct areas so that one might not be confused with the other.


Moving this topic to 'in progress’

Thanks everyone for the awesome conversation happening here :+1:

It’s was always clear that this component was needed but given the conversation it’s clear we can officially move it from suggestion into in progress.

I’ve been doing a quick review of the IA for a few large government (and non government) websites to make sure that anything we put together can accommodate even the largest of teams:

The note worthy takeaways

  • Even the big IAs are reasonably managed by 5 levels in the navigation components.

  • Anything larger than 5 levels tends to get managed with listing/pillar pages.

  • Some use very high-level cohort/user-type/sub-site navigation
    Eg Auspost: Personal, Business, Enterprise & Gov

Mobile navigation

  • Seems to be a trend towards a multi-level ‘hamburger’ menu

  • Some also have a section menu (becomes the side menu on desktop)

Desktop navigation

  • Main nav typically goes to 2 levels.

  • Side nav typically goes to 3 levels.

Where to now?

Our current thinking is to start small so that we can create value in the system sooner.

Starting with 2 basic navigation components:

  • Main Nav with 1 level
  • Local Nav with 3 levels

With support for any HTML in the hamburger menu on mobile so that a login, search, cohort nav, ect could be added.

If we do go with an option like this it means that it already covers a significant amount of our before-publication requirements and we can rely on a bunch of existing community code and learnings.

In future
A multi-level drill-down main nav adds more complexity to the accessibility, javascript, and responsive solution, so we would look at that as a new component using these proposed components as a dependency.



Am liking (and agree with) your analysis so far @treb. For Digital Guides, I’m currently evaluating some extreme cases in the site’s architecture where we’ve got 4 or 5 levels of pages (IMO too deep). For sure, showing up to 3 levels in a secondary nav, in most cases is ideal. But how deep can be less important than how many options are exposed to users. This is the issue I’m trying to cater for at the mo.

The content within this content strategy guide was based on user needs: to ensure the breadth and depth of topics on how to develop and manage such a strategy.
But how you get around these topics wasn’t really factored into our information architecture: this is the big challenge. I want to fit a relatively safe and robust pattern to an architecture that’s a bit unwieldy.
Here’s an unstyled version of the nav I’m working on at the moment, with

  1. direct parent (“Content strategy guide”)
  2. siblings - this is where the issue is exacerbated: so many related topics at this level)
  3. direct children of the selected page, “Set goals and measure success”

Doing some Hick’s law calculations, it can take an average 130.56 seconds to choose one of these menu options (which is ridiculous). P.s. the same tests carried out without the bullets and underlines (closer to the in-progress style): 113.75 seconds.

Bottom line: 21 menu options for this kind of secondary nav isn’t ideal, even when you put in nice margins and colours. But styling does still have an impact on reaction time and therefore how long it takes for users to choose menu options.

I suppose as designers we can advise on the ease of use of a reasonable styles and menu logic. But it’s a greater conversation to take up with the architects and content designers who are structuring the site: with what page names, categories, tree depths and number of options test well with our users.

So far we’re looking at this option for a basic side nav which supports 3 levels.

Mostly because it’s a style which is consistent across a bunch of gov sites.

Early draft code here:

As always. We’re open to feedback or test results.


If we had a choice we would have a single menu, however right now that isn’t actually possible. govCMS is inherently non-hierarchical, all items are created equally within the system without any inherent folder structure. Hierarchy then emerges by establishing a taxonomy which is reflected in a menu. Our menu structure is currently a reflection of this process, and is polyheirarchical, with multiple different taxonomies driving multiple different menus around the site. We have a lot of shared content that appears in multiple hierarchies at different levels, and we have non directional or multidirectional content relationships, like a web.

We are adopting a new content model based on an ontology which unifies the polyheirarchical node system into a whole of site navigation system. This will eventually result in an overhaul of the entire menu system so that it appears to be a single hierarchical menu, while actually still being semantically polyheirarchical.

In our testing of navigation systems it appears that Alexadra’s approach is the optimal approach, and the proposed three level system should work well for our use case, once the underlying architectural challenges are overcome. Three levels deep seems to be the ideal balance of providing sufficient information without overwhelming the users. A traveling menu that always shows you the parent, siblings and children allows the system to always be three levels deep, despite in some cases actually being potentially infinitely recursive. We aren’t planning to actually make it infinitely recurse, but it does demonstrate the ability to handle depth gracefully.

FWIW we are currently testing interim labels for the secondary navigation element. “in this section” is not clearly conveying the purpose, so we are looking for other terms. We’ve conducted several hundred user tests at this point, in sorting activities, task based testing, word suggestion tests and preferences tests. At this point the winning approach is “$section topics” with $section being whatever part of the site you’re currently in. For instance “Newstart topics” or “Child support topics”. The reasoning being that it makes it clear what the section is, rather than using a generic title, which makes it feel relevant to the page you’re on. The “topics” term was tested extensively and seemed to be the preferred grouping term for arbitrary site content in our context, your mileage may vary depending on your content. We’re currently testing out different hierarchies of content labels, to explore how users conceptually group content and what they label those groups.

1 Like

@treb the prototype looks good, however one thing we found in testing was that some users had trouble with the indentation. This lead to them getting lost and confusing siblings with children. This is particularly problematic when you have long titles that line wrap awkwardly.

We put in list decoration and text decoration to try and solve this, and while it resolved the indent issue, it brought its own issues of looking over ornamented and heavy which in turn lowers scan-ability.

We’ve been toying with different ideas, and the best concept we have so far is indenting or duplicating the coloured left margin. Like so:


I’d be interested to know if anyone else has found this in testing, or found a solution.

Oh that’s awesome feedback.

Yeah that example of above could indicate that the arrows will rotate open. But I was legit looking at the bars as an option today to better emphise the levels:

I moved away from that because it didn’t match the existing designs that teams are already using, i also worried it wouldn’t play nice with other components.

I think it would need a little more love then I’ve given it, but if you are looking at testing something more; input on this component is appreciated.

1 Like

I love the bars <3

1 Like

And here’s a quick annotated wireframe we’re working to on Digital Guides for building the secondary nav this sprint:

It’s a skinned version of the menu I shared earlier in the thread with the 21 choices!