Democratising Jira Project Creation and Configuration
I worked on making it easier for end users to create and configure their own Jira Projects and restoring the power balance between site admin and project admins.
I worked on simplifying the conceptual model and modernizing the user experience of configuring projects in Jira. This was one of the massive design undertakings in Atlassian due to the impact and scope of the project. So get a coffee, sit back and relax - cause we're about to head to the land of enterprise admin and Jira land.
Background
Setting up a project for success is critical to being able for every team to make full use of Jira. However, with 12 years of architectural complexity, the system is over-engineered for admins at the expense of power and end users. This causes one side to shoulder the burden of making the most trivial change to a project, whereas not empowering team leads to independently tweak any part of the setting.
Project? Settings? What?
But let's step back. What is a project, you say? In simple terms, it's pretty much a collection of trackable items grouped under a box. Now what makes Jira powerful is its malleability, flexibility, and scalability as a system. Which means, as a user you can transform the box from an issue tracker into an artwork or event tracker, as you want it to be. This is incredibly powerful, because in the setting of an enterprise, for instance, you could theoretically hammer the box away to track HR requests, marketing campaigns, or even as a design tracker.
Sounds wonderful, what’s the problem?
The problem lies when it comes to how the conceptual model works. In the past, in order to make a small tweak like a recording a certain information in a ticket or adding a person to a team, it requires days / months to implement as requires a user with admin privilege to perform the task. This admin-centric view is designed for a reason – only the worthy could hold the hammer. The motivation was to make it easy to manage multiple boxes in one go by making projects connecting with each other through schemes. It was super scalable. But it was also hardly usable. Over time, we heard feedback from admins that they have to do so many menial tasks that keeps them from doing their actual job. Meanwhile, end users yearn for the ability to tweak their own project and move at a more agile pace.
A new model
After rounds of interviews with our largest enterprise customers, we started to think of how we can restore the power balance back between admins and end users. The ideal vision is to provide a sandbox for end users with the appropriate permission. This means they should be able to play around with the settings of their own project without any consequences to other projects or adding more task to the Jira admin. On the other hand, the system should be designed to ensure bulk management of projects so that an enterprise admins with thousands of projects shouldn’t have to visit every single project to make a tweak.
Design solutions
The major changes in the new model were:
Democratising project creation and configuration. People in the project knows best about their own ways of working. They should be empowered to create their own working space, invite the contractors they work with, or create their own custom fields, not asked to rely on another admin.
Better way to visualise configuration. In the old experience, the way how settings is structured purely mimics the code architecture. This is pretty much not how a user thinks about it in terms of mental model. We redesigned the configuration experience to be much more inline with how users think about them, a trackable item with its own fields to record and a workflow to go through.
The removal of schemes. This was a granular configuration object we found through research that none of the major instances were using. We believe that a system of templates makes more sense, as it basically allows the global admin to apply a “master” to multiple projects, similar to a master slide in Keynote or Powerpoint.
Measuring success
Measuring success for a big, ongoing project like this is always difficult. Our main measure at the time was a comparison between project settings active rate between the old vs new version in a given week. I also suggested the micro metric to monitor engagement over a common user flow. For example, say a project admin made a tweak in their project by adding a custom field. If they successfully saved the configuration, returned to the ticket and then actually filled out a field, that’s a task completed. Overall, projects with the new configuration are more likely to be engaged with compared to the previous experience.