Atlassian
Jun 2026
User requests
────────────────────────────────────────── · · ✿✿✿ · · ──────────────────────────────────────────
.overview
Unifying user request platform for admins into a single extensible platform
User requests is a feature within Atlassian Administration that helps admins manage end user requests for app access and new Atlassian and marketplace apps in one centralized surface. The challenge was unifying the different request surfaces across different levels of Atlassian's infrastructure into a single extensible platform. Each request surface is scoped to different admin roles and found on different levels of an organization, forcing admins to visit several surfaces to manage end users requests.
.my role
I was the lead designer responsible for designing the end-to-end User request platform that centralizes and streamlines user access requests and user interest across all Atlassian and marketplace apps. I architected the vision for this unified request management center and drove the launch of a net new feature, User interests, laying the foundation for admin-driven upsell and cross-sell. I worked alongside Content design, Product, Engineering, Growth, and Ecosystem teams and I owned research, product design, and final delivery of the admin experience for User requests.
.impact
+7%
Access request approvals
30%
Cross-sell click-through
Displaying user count improved admin efficiency and increased access request approvals by 7%. The redesigned access request flow reduced admin overhead and improved time-to-resolution. The new User interests feature saw a 30% cross-sell click-through rate, providing actionable insights for strategic purchasing and portfolio growth for our customers. This supported Atlassian's upsell and cross-sell strategies making user demand visible and actionable.
Key outcomes
Strategic Alignment
User requests is foundational to Atlassian’s System of Work, supporting enterprise-scale administration, platform extensibility, and data-driven decision-making.
Admin Empowerment
Delivered visibility, control, and ease-of-use for admins, consolidating all requests and interests into a single, actionable view.
Platform Growth
Introduced transaction states, merchant context, and clearer activity flows.
────────────────────────────────────────── · · ✿✿✿ · · ──────────────────────────────────────────
.problem
Understanding users' product needs felt unnecessarily difficult
Organization admins and site admins need to manage multiple end user request surfaces for Atlassian and marketplace apps. This disjointed request experience stifles admin productivity, impacting admins’ ability to effectively monitor end user needs and stifles long term efficiency, costing our admins opportunities to expand their Atlassian tools with confidence.
01
Lack of visibility
Difficult for admins to glean end-user needs from a high level
02
Multiple surfaces
Different surfaces and inconsistent workflows prevent admins from efficiently addressing to end user needs and notice signals for expansion and does not scale
03
Outside solutions
Lack of cohesion in managing requests pushes admins to turn to IT service management systems outside of Atlassian to manage end user requests at scale
────────────────────────────────────────── · · ✿✿✿ · · ──────────────────────────────────────────
.designs
One request surface for all end user requests
User requests is a platform capability designed to streamline and centralize the handling of user requests within Atlassian. This feature is a single organization-level interface designed for organization and site admins. Consolidating these requests allowed admins to efficiently manage access requests, improved admin collaboration, and empowered admins to understand user demand for new Atlassian and marketplace apps.
Access requests
A unified “Request Center” that aggregates all user access requests at the organization level, eliminates the fragmented site-level workflows and enables admins to review, approve, or deny requests in a single, efficient interface. This introduced a consistent, intuitive UI for reviewing requests, with contextual data (e.g., available licenses, requester details) to support fast, informed decisions. Access requests is an extensible platform that allows internal and external teams to integrate new access request types and approval workflows.
01
Requester details
02
Available licenses
03
Request details
User interests
A net new surface, User interests, aggregates signals from users requesting new Atlassian and marketplace apps not yet purchased by the organization. This surface included cost estimation, enabling admins to compare pricing and make confident expansion decisions. User interests is an extensible platform with backend and API designed for extensibility, allowing seamless integration with new Atlassian and third-party apps.
01
Trending Atlassian or marketplace app
02
Interested signal
03
Cost estimator
────────────────────────────────────────── · · ✿✿✿ · · ──────────────────────────────────────────
.key decisions
Displaying user count in context
During research sessions, admins often expressed needing to reference user counts before approving access requests so not to go over their license limits, stating that it was tedious because it forced them to leave their workflow. I influenced the decision to include the user count in the request to improve admin workflow and provide necessary context at the point of decision.
Aggregating user interests across Atlassian ecosystem
Admins who’s organization use other ITSMs often use these tools for more than just Atlassian but for other apps and IT requests. Showing early designs of an aggregate Atlassian focused user interest, received positive responses as it helped guide admins towards understanding end users interests in Atlassian and marketplace apps that would be meaningful towards budget planning.
Tech constraints
Due to technical constraints, we were only able to display the total number of interested users and could not display list of users. On the engineering side, we capped interested users at 2,000 users which does not scale for our enterprise customers. During user interviews, admins expressed while total number was helpful, they needed more data than just a simple number to influence purchasing decisions.
It shows me the number of total interested users. It doesn't tell me who they are. I think possibly knowing who they are, or a bit more information around this. So who they were, I think would be quite important because their role obviously could vary throughout the business. And then why they think it's useful would be good. I, otherwise it doesn't give me too much information about why they think it would be useful.
Interview participant
Organization Admin
Released design
Proposed design that shows full list of interested users
────────────────────────────────────────── · · ✿✿✿ · · ──────────────────────────────────────────
.lessons
Build-in deprecation as a requirement
While I reflect that it was a great achievement to consolidate all request surfaces into one organization level interface, I recognize the massive amount of clean-up that remains. Building a new surface is great but following through means deprecating old experiences. I have learned how necessary it is to build-in the clean up as a requirement and lock down firm commitment to follow-through.
────────────────────────────────────────── · · ✿✿✿ · · ──────────────────────────────────────────
