Seeking clarification for design Guidelines for page headers

atlaskit
design

#1

Hi,

I’m in the process of re-designing one my addons and I’m looking for some guidance as to how page headers should be structured.

According to ADG3, page headers should have a breadcrumb and title, actions on the right (same line as title), and filters below that (left aligned).

The thing I’m struggling with is… let’s assume I have a way to switch views from list to grid or details. Similar to Jira issue list. Where should that go? Where the actions are? Same row as the filters?
If same row as filters, what if I don’t have any filters on the screen? Would I then still keep the row where filters go, but only put something on the right for switching the view?

I tried looking at Jira Cloud and Confluence Cloud for reference, but neither of them actually follow the patterns prescribed in ADG3.

Any guidance from the Atlassian Design team would be greatly appreciated.


#2

Hello there!
I’m an Atlassian designer in the ecosystem space, and I think I can help here :slight_smile:
You’re describing a complex challenge here (and a really interesting one from a design point of view :slight_smile: )
The reason why we’re not more specific in the ADG is because there are plenty of decision points where it’s about the context: some stuff that would be right in one page header, would be really counter-intuitive in another.
Ultimately, you need to find the right balance between discoverability (how much do users have to find those controls easily?), not overloading that area with controls, and making sure that users get what the various buttons will actually affect on the screen… not easy!
The general way we’re doing this can be seen in the main issue navigator in Jira (Go to Jira > Issues and filters > My open issues (or really any other filter)).

  • General page-related button are on the top right.
  • Filters are in the row below, left aligned.
  • Sorting controls are on the same line as the filter controls, but right aligned.

See this more as a suggestion / guidance than as a rule. However, plenty of other product UIs, both Atlassian and non-Atlassian, use this structure, and that in turn makes it easier for users to immediately understand how it works.

I hope this helps a little bit!


#3

Hi @mschreck!

Thanks for the reply. I appreciate you trying to answer this and give some guidance.
To be honest though, looking at your sample (filters screen) brings up more questions.
For example: https://screencast.com/t/vHsJCM9SVW

  • ADG3 suggest placing primary & secondary buttons on the right (same line as title), yet Jira doesn’t do that.
  • Similarly, why wrap the filters bar when there is enough room to expand?
  • Looking further down the screen at an actual issue, I see actions (pagination) on the same row as the breadcrumb.

I understand that ADG3 is more of a guideline, and we need to account for context and what works in one screen vs another, but I keep getting the impression that Jira itself pretty much ignores the guidelines it is trying to provide in almost every instance I find. Doesn’t that create a rather inconsistent UI and UX?
Or is that something we should basically ignore, in favor of what works “in the moment” so to speak, even if it creates inconsistency between screens, or even sections of the screen?


#4

Hey again :slight_smile:
I want to be as helpful as possible here, but I’m a little bit at a loss regarding how I can help you in the best way. I got the impression that you were looking for guidelines that would allow you to construct your user interface in the best possible manner. As already stated, this is highly contextual, and a very tricky balancing act that you as the designer on your app need to strike in the way you find best. That’s why we deliberately call them ‘guidelines’ and not ‘rules’.

You seem to put a lot of weight on consistency as a guiding principle. That’s certainly not a bad place to start: consistency helps users by not forcing them to relearn things they already learned elsewhere. However, experienced designers know that it’s easy to become a blind follower of consistency (as it’s so easy to prove whether something is or isn’t consistent), ignoring opportunities to serve your users better in particular situations. This is not a hard science, and I have been in plenty of design critique sessions where a discussion would go one way, when with different people in the room, it could have gone the other way, simply with different pros and cons. I hope this makes sense.