I was the UX Designer on a team of product managers and developers tasked with creating an API subscription management tool.
Please note: the information displayed in this case study has been significantly altered to adhere to confidentiality agreements.
Preview of the Final Product
Prior to the start of this project, the monitoring and management of API subscriptions was handled solely by developers, with input from product and implementation managers. This caused a significant bottleneck, as this work would need to be scheduled and budgeted for in the same way as other development tasks.
In order to free up the developers’ time and empower the product and implementation managers to access info about and manage API subscriptions, it was determined that we would need to build a user interface that non-developers could use to aid with this process.
Gathering Requirements
First, I spent time working with the product manager to bring myself up to speed about how APIs work in general. This involved looking at services such as AWS to see what were commonly accepted naming conventions, paradigms, and overall flows.
Once I had a general understanding of APIs, it was time to work with the product and development managers to figure out what our specific requirements would be for this tool. This involved getting a better idea of who would be using this tool, and figuring out typical situations and use cases for the users.
Users would need to be able to:
- View summary metrics for each subscription, such as:
- Event Count
- Success Rate
- Status
- Sort and filter subscriptions by a variety of attributes, including:
- Subscription ID
- Subscription Name
- Organization
- Expiration
- Identify problematic subscriptions
- Stale subscriptions – no data delivered over a certain period of time
- Automatically disabled subscriptions – disabled due to events such as an unavailable destination or credentials no longer being valid
- Troubleshoot and perform limited operational actions for any given subscription
- View event log, including error messages
- Re-enable a disabled subscription
- Pause a subscription
- Delete a subscription
- Create and manage Event Definitions, to be used as the framework for different Events
- Add and manage Destinations
Understanding the Typical User
The typical user for this product would be Internal Employees who:
- Have high technical literacy
- Have a solid understanding of our products and systems
- Use our products exclusively on Desktop setups
- Are often tasked with collaborating with developers to manage API subscriptions
- Are responsible for fielding and managing client requests
- Have a good enough understanding of the system to determine when they should use a tool like this to make changes or when to pull in developers for more complicated tasks
Designing the Solution
Once we felt that we had a good understanding of the requirements and typical users, we moved on to figuring out which specific data would need to be displayed via a series of rough wireframes and tables.
It took some iterative trial and error, but we ended up identifying which sorts of data a user would need to be able to access, and how to best group it all.
We established the following definitions for different parts of this product:
- An Event is an individual API call. Each Event has a status of “Successful” or “Failed”, with the option to resend failed events.
- A Destination is a pre-set location that the API call would send info to and receive info from.
- An Event Definition is a template for events which defines attributes such as Event Type, Destination, Response Type, and various Response Options.
- A Subscription is a collection of Event Definitions and Events. Each subscription contained attributes which tied it to a specific institution or application cycle, as well as a notification email.
Based on these definitions, our wireframes, and the identified requirements, we ended up with the following:
