My Requests Extension for Jira Service Management (JSM) opens up a new set of possibilities in terms of visibility control and access for customers to their Requests pages. As an administrator you have full control over the view and permissions at the click of a button.

The team consists of 7 developers, product owner, quality assurance specialist and me - UX/UI Designer.

Analysis of our clients' support requests, competition analysis, interviews with users, wireframes, prototypes.

Jira default My Requests screen gives the users the possibility to view the list of all the requests they created or participated in on a given instance. Users can filter requests by their status, creator or request type, and search for them.

My Requests Extension, enhances those possibilities by:

allowing administrators to choose which fields users can add as columns, and which of them will be displayed by default

allowing administrators to limit the fields’ visibility for selected user groups

adding columns to the request list and reordering them

enabling users to customize the requests list to their needs and save such views as filters

expand search options to Description field

As the My Requests Extension is a powerful tool that allows you to adjust the visibility of requests on multiple levels, it can sometimes be confusing for the administrator. For example, after restricting Group 1 users to display a specific field and allowing Organization 1 users to display that field, the administrator may get confused if the two groups do not overlap and what exactly the user can see on the requests page. There may also be certain permissions or limitations due to other Jira settings that the administrator does not know about and cannot access.

We saw an opportunity to create a feature that allows the administrator to see how different users can see their request page. We can find similar solutions, for example, in Jira or on Facebook, where we can see how others will see our profile.

After analyzing user behavior and after analyzing support tickets, we realized that we needed a feature like View as.

We analyzed a similar feature that works in native Jira.

After research we have figured out who we are designing for:

Jira's administrator, a person who wants to see how other users see their request pages.

The regular user - who is not an end user, but we must remember that the administrator does not change something in user view.

After research phase, we knew that we wanted to:

allow administrators to see what other users can see

lets administrator easily choose the user which he wants to check.

warn the administrator that he is viewing it as another user

The first proposition was to allow administrators to enter “view as” mode through one of the requests page filters. It is supposed to filter all the requests to show him only the requests that selected user would see.

From the beginning, it wasn’t our favorite option. It had pros and cons but we weren't sure about it.
Pros:

easy to develop - just create a new filter which is easy for our developers because that’s all what this app is about.

Cons:

may be hard to find for some users

the administrator won’t get the whole context - he will see only requests but won’t see users saved filters

The second idea was to introduce a more powerful “view as” feature. It was supposed to be hidden under the user profile. Putting this option under the user profile miniature made sense, for as at this point, because we wanted to change the ‘viewing user’.

Then the administrator chooses the user he wants to look up to, and after confirming he sees what the user would see, with additional warning, that he is watching as the other user.

After testing our solutions with users, it turned out that they could not find our solution. First, they expect to find it in the application's settings, which is where the administrator can grant permissions. Secondly, as they already knew that it was not in the settings and in the request page view, they could not find it. The option with “view as” filter didn’t seem to be obvious, and the option with ‘View as’ under the user profile miniature was too much hidden.

We thought it would be right to put such a feature on the requests page, since this is the page the administrator wants to view as another user. It turned out that our users expected such a feature in a completely different place. Since view as applies to both field permissions and other settings, we decided to throw it into the main configuration view, accessible from any level of configuration.

We designed the final solution considering feedback from previous tests. We moved the ‘View as’ function to the configuration view where the administrator sets the permissions for the app. Thanks to this, immediately after setting permissions, you can easily check how they will affect specific users.

This project showed us how important it is to check how users will use the feature before introducing it. The thing that seemed simple turned out to be more complicated than we thought. Thanks to the fact that we checked the solution before implementation, we saved a lot of time and work of developers - which of course translates to business values.