• Research
• UX
• UI
• Interaction
• Product Management

API token is a personal identifier of an application requesting access to your service. They are unique credentials assigned to individual users. An overly simplified way of thinking about it (and potentially flawed) is my badge that I use to buzz myself through the company door. It’s unique to me, but should I lose it, anyone could buzz in with my credentials (here is a very well written medium article explaining API tokens).

Today, every user can generate API tokens on id.atlassian.com, regardless if they’re a managed account of an organization or not. API tokens allow the user to authenticate with Cloud apps and bypass two-step verification and SSO, and retrieve data from the instance through REST APIs.

These tokens don’t expire and are subject to almost no limitation or controls today. The user can revoke their own token, but there is no way for an administrator to view, limit or revoke the use of these tokens. It’s hard for admins to even know that their users have created API tokens and are using them to call Jira and Confluence APIs. This means that the admin’s content is never fully secure or under their control.

We set out to have two high level goals:

• Give organizational admins the ability to control the creation and usage of API tokens created by the managed accounts of their organization in order to ensure that their content is secure.
• Enable better user, content and security administration at scale.

Atlassian has a concept of a Triad which is essentially a group consisting of the Designer, Product Manager and Engineering Manager. The triad, through a collaborative process, then establish a high-level product vision and the long-term roadmap for the product.

As a  triad, we concluded this timeline was tight and we didn’t have enough data on user behavior; so we decided to establish an MVP product to add value to our flagship product (Atlassian Access) as there were multiple other streams and projects we were all working on. We broke down the project in this way,

• Defined the problem space (why are we doing this? Impact of the problem, etc)
• Defined our metrics (How do we judge success? etc)
• Defined the hypothesis we wanted to validate (What user need are we solving while aligning with our company OKRs? etc)
• Defined our goal and milestones (What is the MVP? How does it align to our roadmap? etc)
• Defined our scope (what we are doing, not doing, future states, etc)
• Identified our dependencies and assumptions (who are the stakeholders? How will this affect their roadmap and our timeline? etc)

The design process was broken down into a variant of the design thinking process to adapt to product timelines,

• Understand & Gather Phase (summarize past research & design efforts, gather and analyze existing data, document current state, whiteboard, etc)
• Ideate Phase (Explore the problem space, high fidelity designs due to time constraints, prototype, early signal testing, begin scheduling customer interviews, E2E demos, etc)
• Refine Phase (Finalize design based on stakeholder & customer feedback)
• Rollout & Improve (Keep track of analytics, observe user behavior, capture any design debt, determine next steps for products)

Once we prioritized the user stories and knew our scope clearly we broke the project down into 3 major milestones.

We recently released Milestone 1 (MVP) which encompassed the must-haves we needed to deliver so customers can start deriving value from having API token controls. In summary, the org admin needs to be able to view the tokens created by their managed users on the user profile page, individually revoke the tokens for these users and set expiry scope on the tokens.

Since we have no sense of usage, customer awareness or expectations for API tokens today, our goal is to gauge customer feedback from the shipped Milestone 1 before commencing work on Milestone 2. Milestone 1 is currently in development and is set to release at the end of Q3, 2019 (Australian quarter, end of March 2019).