5 ms·

The biggest issues I have with JIRA have to do with it being one of the world's most inconsistent, unintuitive, and undiscoverable UX's possibly ever made. All

The biggest issues I have with JIRA have to do with it being one of the world's most inconsistent, unintuitive, and undiscoverable UX's possibly ever made. All manner of things are hidden in "..." menus, and any screen will have several such menus visible at once, but they're all different. It feels very much disjointed and like the UX is done in a deeply siloed process that considers only the most local region of the screen the user could be working in (or where a feature lives), and like no attempt is made to consider the UX as a whole. It feels like using 15 different independent apps at once that just happen to be crammed into adjacent or overlapping screen real estate, and each one is a different lens with its own side effects that come from interacting with it. Some things are randomly modal and others aren't and require you to actually load an independent details screen. The only significant consistency to any of it is the fact that it all shares a somewhat common graphical style. Despite having used JIRA for a decade or more, at no point do I ever feel like I know where I'll find something on the first try or know what's going to actually happen when I deviate even the slightest from the very, very narrow repeatable process groove I get into after much trial and error.

foolfoolz 9y ago
older jira versions hid less and has way more buttons. it was overwhelming and complex. how do you balance a very powerful product and simple day to day uses of it?
- notalaser 9y ago
  That's the thing -- it's (no longer) easy at all. When accessing every other function requires guessing which hamburger menu it's hidden behind, it looks clean and easy to use, but it's not.
- im_down_w_otp 9y ago
  It's still overwhelming and complex, so that part has stayed consistent. I imagine it starts with always considering the thing as a product, not as its features, so that you can always make sure all the work being done integrates intuitively and intentionally into the original thesis of the product. The very fact that one has to hunt through various layers of oddly organized configuration screens (several of which do almost the same thing), and has to often click on more than one "..." menu to poke around looking for assumed-to-exist functionality before actually finding it, is an indicator that JIRA might be developed as an ongoing train of user stories to create features unmoored from a central thesis. Because if it was developed like a product in total, then its metaphors would be consistent, its language would be consistent, its modes of interaction with those metaphors would be consistent, and intuitive organization would largely fall out of that.
- Juliate 9y ago
  You don't. You don't use "very powerful products" for "simple day to day uses". Used JIRA for 7 months now. Can't understand how people get anything done and tracked with it (trying to forcefully carve teams into a per-the-book SCRUM methodology with it).
manyxcxi 9y ago
The thing about JIRA hate (or love), is that it only has a little to do with the actual product. As the article says, crappy process will give you a crappy experience. But a crappy configuration will do just the same. If you're constantly hunting behind menus to get to stuff it's likely that they've enforced some process on to you but not properly reconfigured the screens or transitions so that you get what you need when you need it. It took a bit of trial and error but on my team we can work almost exclusively from our agile board and have transition screens configured that will collect the info we need when someone is moving things around on the board. Now, don't get me wrong- the UX needs a lot of work because it is so inconsistent, but I feel like almost every complaint I've ever heard about JIRA could be remedied by a better implementation. Maybe not solved completely, but remedied to a degree that it's not too bad.
- albedoa 9y ago
  > the UX needs a lot of work because it is so inconsistent > almost every complaint I've ever heard about JIRA could be remedied by a better implementation. Huh? You're replying to a complaint about the UX.
- Domenic_S 9y ago
  > every complaint I've ever heard about JIRA could be remedied by a better implementation Erm... what can't be fixed with better implementation? My big point of hate on JIRA is how it uses some mutant hybrid of markdown and wiki text, so going between JIRA and Github is a nightmare of context switching. Can that be fixed with a better implementation, of course it could, but the point is Atlassian doesn't seem to think about UX.
  - manyxcxi 9y ago
    What I meant by implementation is that you can implement your company's processes via JIRA configurations, workflows, and occasionally plugins in such a way that the way your instance operates is almost unrecognizable from the way someone else's might. You can configure a nearly infinite number of input screens with all manner of standard and custom fields to be presented to users at any given point. The rules can be quite complex and handle forward and backward transitions. As a system administrator it can totally be overwhelming, but you are quite free to do most things. If you have a process that default JIRA configurations doesn't serve well and drives users into deep menus and weird contexts, you can very likely fix it, or at the very least make it more palatable with those customizations. For example, for a given project type, we don't just have To Do, In Progress, and Done. We have To Do, In Progress, In Review, and Done. When a dev moves from In Progress to In Review they are prompted to input a number of required fields so that QA can know how to test it, where to look for it, etc. If QA fails the review, they're prompted with a specific screen that brings forward the inputs they'd need to document why it failed. When they fail it, it automatically goes back to the dev that kicked it to review. When that dev kicks it back in to QA it's going to go back to the person that reviewed it the first time. This process, if done with no extra JIRA configuration would be a damn nightmare and it would break down fast. We spent the time to make it fast for everybody using it, and to make sure that they are presented with the things they'll need when they need them. If JIRA is new to a team I recommend they run it completely vanilla for a while and then come up with a list of things they'd need it to do or do differently to fit their meatspace processes and interactions. I'd also look at what you could do to make your existing processes more streamlined that might cut some of the complexity in the first place. Vanilla JIRA Agile is actually fairly simple and only more complicated than Trello because of the UI and various issue types. You'd be surprised how far it can take a team if you don't have some arcane internal requirements or unrealistic expectations of the software revolutionizing your team's performance. At my last company we quelled a near JIRA revolt (it was there before me) by literally just going to default JIRA Agile workflows. I do agree about the 'markdown' support in JIRA/Confluence. It would almost be better if they just didn't support anything than the way they support it. I've got a lot of gripes with JIRA around UI/UX issues, but the vast majority of hate I hear spewed at JIRA is usually because they had really crappy (or just complex) team processes implemented with crappy JIRA configurations and it made everyone's life hell. I'm not a JIRA apologist or anything, if there was something else out there that was better and had the same level of available integrations (Jenkins, Slack, support desks) I would cut over in a heartbeat. I just think it gets a worse rap than it deserves (not that it doesn't deserve some mind you). Confluence on the other hand, that deserves every complaint I've ever heard about it...

foolfoolz 9y ago

older jira versions hid less and has way more buttons. it was overwhelming and complex. how do you balance a very powerful product and simple day to day uses of it?

notalaser 9y ago
That's the thing -- it's (no longer) easy at all. When accessing every other function requires guessing which hamburger menu it's hidden behind, it looks clean and easy to use, but it's not.
im_down_w_otp 9y ago
It's still overwhelming and complex, so that part has stayed consistent. I imagine it starts with always considering the thing as a product, not as its features, so that you can always make sure all the work being done integrates intuitively and intentionally into the original thesis of the product. The very fact that one has to hunt through various layers of oddly organized configuration screens (several of which do almost the same thing), and has to often click on more than one "..." menu to poke around looking for assumed-to-exist functionality before actually finding it, is an indicator that JIRA might be developed as an ongoing train of user stories to create features unmoored from a central thesis. Because if it was developed like a product in total, then its metaphors would be consistent, its language would be consistent, its modes of interaction with those metaphors would be consistent, and intuitive organization would largely fall out of that.
Juliate 9y ago
You don't. You don't use "very powerful products" for "simple day to day uses". Used JIRA for 7 months now. Can't understand how people get anything done and tracked with it (trying to forcefully carve teams into a per-the-book SCRUM methodology with it).

manyxcxi 9y ago

The thing about JIRA hate (or love), is that it only has a little to do with the actual product. As the article says, crappy process will give you a crappy experience. But a crappy configuration will do just the same. If you're constantly hunting behind menus to get to stuff it's likely that they've enforced some process on to you but not properly reconfigured the screens or transitions so that you get what you need when you need it. It took a bit of trial and error but on my team we can work almost exclusively from our agile board and have transition screens configured that will collect the info we need when someone is moving things around on the board. Now, don't get me wrong- the UX needs a lot of work because it is so inconsistent, but I feel like almost every complaint I've ever heard about JIRA could be remedied by a better implementation. Maybe not solved completely, but remedied to a degree that it's not too bad.

albedoa 9y ago
> the UX needs a lot of work because it is so inconsistent > almost every complaint I've ever heard about JIRA could be remedied by a better implementation. Huh? You're replying to a complaint about the UX.
Domenic_S 9y ago
> every complaint I've ever heard about JIRA could be remedied by a better implementation Erm... what can't be fixed with better implementation? My big point of hate on JIRA is how it uses some mutant hybrid of markdown and wiki text, so going between JIRA and Github is a nightmare of context switching. Can that be fixed with a better implementation, of course it could, but the point is Atlassian doesn't seem to think about UX.
- manyxcxi 9y ago
  What I meant by implementation is that you can implement your company's processes via JIRA configurations, workflows, and occasionally plugins in such a way that the way your instance operates is almost unrecognizable from the way someone else's might. You can configure a nearly infinite number of input screens with all manner of standard and custom fields to be presented to users at any given point. The rules can be quite complex and handle forward and backward transitions. As a system administrator it can totally be overwhelming, but you are quite free to do most things. If you have a process that default JIRA configurations doesn't serve well and drives users into deep menus and weird contexts, you can very likely fix it, or at the very least make it more palatable with those customizations. For example, for a given project type, we don't just have To Do, In Progress, and Done. We have To Do, In Progress, In Review, and Done. When a dev moves from In Progress to In Review they are prompted to input a number of required fields so that QA can know how to test it, where to look for it, etc. If QA fails the review, they're prompted with a specific screen that brings forward the inputs they'd need to document why it failed. When they fail it, it automatically goes back to the dev that kicked it to review. When that dev kicks it back in to QA it's going to go back to the person that reviewed it the first time. This process, if done with no extra JIRA configuration would be a damn nightmare and it would break down fast. We spent the time to make it fast for everybody using it, and to make sure that they are presented with the things they'll need when they need them. If JIRA is new to a team I recommend they run it completely vanilla for a while and then come up with a list of things they'd need it to do or do differently to fit their meatspace processes and interactions. I'd also look at what you could do to make your existing processes more streamlined that might cut some of the complexity in the first place. Vanilla JIRA Agile is actually fairly simple and only more complicated than Trello because of the UI and various issue types. You'd be surprised how far it can take a team if you don't have some arcane internal requirements or unrealistic expectations of the software revolutionizing your team's performance. At my last company we quelled a near JIRA revolt (it was there before me) by literally just going to default JIRA Agile workflows. I do agree about the 'markdown' support in JIRA/Confluence. It would almost be better if they just didn't support anything than the way they support it. I've got a lot of gripes with JIRA around UI/UX issues, but the vast majority of hate I hear spewed at JIRA is usually because they had really crappy (or just complex) team processes implemented with crappy JIRA configurations and it made everyone's life hell. I'm not a JIRA apologist or anything, if there was something else out there that was better and had the same level of available integrations (Jenkins, Slack, support desks) I would cut over in a heartbeat. I just think it gets a worse rap than it deserves (not that it doesn't deserve some mind you). Confluence on the other hand, that deserves every complaint I've ever heard about it...