How do you support users (and keep Jira usable). What’s working right now?

[#1]

I’d love to kick off a proper admin-to-admin discussion on something we all deal with, but rarely document: supporting Jira users in a way that improves adoption without turning Jira into bureaucracy.

Most of the day-to-day friction in Jira isn’t caused by “bad users”. It’s caused by a gap between what the tool can do and how teams actually work. If Jira feels confusing or noisy, people stop trusting it, work moves to chat, and Jira becomes an after-the-fact reporting tool.

So the question is simple:

How are you supporting your users right now and what’s actually working?

Below are a few patterns that tend to help (not as “the one true way”, but as conversation starters).

1) Make Jira predictable (boring is good)

Users don’t need endless configuration options. They need consistency:

statuses that mean the same thing across similar projects

a clear “Done means Done” agreement

the same fields used the same way

templates for common work items

When Jira is predictable, users don’t need training for every project. When it isn’t, they stop trying.

Discussion prompt:

How do you handle standardization vs team autonomy in Cloud (especially with team-managed vs company-managed)?

2) Reduce noise before you add process

Most “user complaints” are really noise complaints:

too many fields on Create

too many statuses

too many notifications

too many dashboards that nobody trusts

A small amount of cleanup often improves adoption more than any new feature.

Discussion prompt:

What’s your best “low effort / high impact” cleanup that made users instantly happier?

3) Start with “why” before building anything

A lot of admin work becomes easier when you ask one question before implementing changes:

What information do we need, and what decision/action will it enable?

If nobody can answer that, the new field/status/app will usually become clutter.

Discussion prompt:

Do you have a lightweight way of capturing the “why” for changes (request form, template, intake ticket)?

4) Support users where they actually are

Most users don’t live in admin screens. They live in Slack/Teams and meetings. Common patterns that work:

a short “tip of the week”

a simple “how we do Jira here” page

office hours

a support queue / request type for Jira changes

The key is to keep it human and practical examples beat policy.

Discussion prompt:

What support model do you use: office hours, helpdesk queue, champions network, or “best effort”?

5) Use automation to remove boring work, not control people

Automation is best when it:

pre-fills known values

routes work to the right team/queue

creates standard subtasks

nudges gently (reminders, watchers)

Automation is worst when it becomes policing:

hard blockers everywhere

complex rules nobody understands

hidden logic that surprises users

Discussion prompt:

Where do you draw the line between helpful automation and annoying automation?

6) Reporting should be a mirror, not a weapon

One of the fastest ways to destroy data quality is to use Jira reporting to judge individuals. Teams will game it, and Jira stops being trustworthy.

Reporting works when it’s used for:

finding bottlenecks

improving flow

fixing recurring blockers

stabilizing definitions (“what is done”, “what is blocked”)

Discussion prompt:

How do you keep reporting healthy in your org (especially when leadership wants metrics)?

7) Jira environments drift over time. The difference between a healthy instance and a “maze” is whether you have a simple loop:

one place to request changes

quick triage (quick win vs needs discussion)

small releases regularly

short notes on what changed and why

No heavy governance board needed but just consistency.

Discussion prompt:

How do you collect feedback without becoming a bottleneck?

Over to you

What’s your current biggest challenge in supporting Jira users?

adoption / hygiene

permissions noise

too many custom fields

team-managed sprawl

automation complexity

reporting trust

constant Cloud changes

And what’s one thing you implemented that made a noticeable difference for users?

Would love to hear real patterns that work, and the ones that didn’t.

[Anne Saunders]

Our Successes:
We explicitly disallow Team-managed spaces by SOP, and I create and manage all team and project Jira Spaces. (our leadership team has a couple that they manage)

We offer (basically) 3 types of services (development, hosting/maintenance, and support), so each one has its own standard space setup. There's one major scheme of each type (workflow, screen, etc) for each service line. We only have one priority scheme and one notification scheme and they're applied to every space. 

Getting to this point was a monumental effort - it took incremental steps from 2021-2023 - but now we have a pretty serene and expectable instance.


Our Challenges:
I will say the recent changes to everything in the UI have caused a rise in our Slack messages that I believe (but don't have tools to validate) is a response to our teams preferring to communicate about tasks outside Jira, and I can't really blame them.

It can make tying specific content to a specific work item's context more difficult, but it also allows a holistic view of progress in Slack, so I don't mind it too much.

[Julia Foden]

I don't allow Team-managed projects, and I don't allow project admins to create automations either. I'm a control freak! But I'm also very helpful and expert at automation so it balances out :)

I find it's often really simple things that make Jira more usable for people. Where I work now has a lot of non-technical users and a big team of them were navigating Jira only through one particular dashboard. It had masses of data on it including current work of each team member and this month's figures and last month's figures and ... it was endless and slow to load and a bad experience for them. So I made a simple dashboard with just a few gadgets for the current user's day-to-day work. So simple but makes a huge difference to the users.

Another simple thing that a lot of people don't seem to know about is filter subscriptions! People ask for an automated email whenever X thing happens. But they only want it so that they can search in their inbox later. They don't really need to know instantly so it's enough for them to subscribe to a filter twice a day. I sometimes create the filter for them and then let them choose the timing of their own subscription.

On your question 3 about a lightweight way for capturing the 'why' for changes, I approach it differently. My questions are 'what do you want to accomplish' and 'what problem are you trying to solve'. I'd rather go deep with discussion. Often the solution ends up being different from what the requester had in mind but also way better. "Oh I didn't know you could do that in Jira"!

[Arkadiusz Wroblewski]

@Julia Foden  @Anne Saunders 

That's a valid and great Points.

Thank you for sharing it with us 🤗🤠

Definitely I agree, very big Problem becoming slowly, there's so much changes around Last couple Months, people not even aware there's so much New possibilities.

I can relate also about changes in UI, some of them are awesome, other still need to be polished or explained better to Admins and end-users - what's mostly our Job.

[Matt Smith]

You describe what should be standard practice !

We do not have TEAMS managed (escape control) projects, to ensure conformity.

Uniformity of request types is exceptionally challenging when they are not centrally controllable across spaces. Atlassian seriously need to address this.

a space is a customer with us thus they may share the same services as others however the request types for that service (Incident / request / change) have to be done individually ( per space) even though they are the same for that shared service ! time consuming.