Monitoring in our Developer accounts comprises two tools, API Call Logging and Webhook Logging. Our integrators use these tools to check on their apps performance and debug issues.
API Call Logging
We have seen a number of postings to our developer forums asking for integration feedback such as success and failure messaging for API calls. This need was backed up by a consistent number of cases in Support with developer users looking for debugging assistance.
Decrease the number of Support cases having to do with developer portals. These tend to be more technical in nature, taking up more time and are more expensive than the average case.
Make app creation easier for our developer community, increasing the efficiency and stability of these apps and lessening the time it takes to bring a new integration to market.
USER TESTING MAIN TAKEAWAYS
- Correctly expected UTC link would switch time zone; suggested UTC to be default
- Expected ‘Fancy’ JSON view to be default with collapsible tree structure
- Enough data was surfaced on errored calls to troubleshoot
- Preferred cURL format with Copy to clipboard functionality
- ‘Show details’ tab was biggest point of confusion, did not expect to see overview graphs; liked the information and display but wasn't in intuitive location
Based on the data from the forums and our Support department, we knew the best place to surface integration status details would be in-app in the form of a skimmable call logging UI. After doing research on API call logging interfaces and several white boarding sessions with my product manager and engineering team lead, we came up with a list of features to focus on for the MVP.
I wireframed various layouts to take to my team for an initial round of feedback, keeping in mind the following main design decisions:
- how to structure the UX/UI so that the list of API calls was skimmable yet still offered enough detail for debugging
- how to quickly indicate errored vs successful API calls
- how to allow for advanced search capabilities and filtering
This is currently live in production and continuing to receiving feedback via on-page surveys and monitoring support tickets.
After the Webhook Subscriptions tool was in production, we were able to build off of the API Call Monitoring UI to create a call logging UI for this new data. The API Call Monitoring tool originally lived in the app level navigation and, with the introduction of Webhooks, the nav bar was quite congested and no longer fit the original IA correctly. The two logging tools display different sets of information, but it was important to me to keep the overall patterns and interactions consistent across the two.
Tie in a few important IA changes
Surface Webhook activity to our integrators to allow for independent troubleshooting.
Keep the overall patterns and interactions consistent across the monitoring tools
The brunt of the work involved figuring out how to surface the most useful information while staying within the confines of the existing UI structure. To not overload the app nav bar and maintain a clear hierarchy, we merged the two tools into one app level nav item with secondary navigation.
This is currently live for users in production.