Case Study — 2020
Debugging Tool
Product Management, UX
TL:DR"Why didn't my SMS deliver" is the number one question support engineers are asked at Vonage. SMS is an easy API to program but a hard one to debug because it has many touchpoints when going downstream to be delivered.
They need in-depth knowledge of how the system works, an arsenal of different tools with access to all databases, and power functionalities to filter data. Consequently, support engineers are always suffering from context switching and experiencing a bump in efficiency and quality of life.
On this redesign, I've made one centralized tool with a focus on:
Modularity — so it's easy to update in case the tech changes
Search flexibility — so that experts can nail down odd specific parameters
Learnability — so that even junior engineers can get a reliable answer
↓
MY ROLELead and solo designer — requirements, research, ideation, design, branding, prototype, user testing, hand-off, QA
STAKEHOLDERSProduct Manager
Global Support Lead
All databases in one place
Initially, this project had a small focus that wouldn't solve enough useful problems or justify its existence. By interviewing support engineers and tech leads, I've realized that the initial scope was incorrect. It was a classic case of everyone seeing only one part of the beast, not the whole creature. I've gone back to the drawing board and helped our junior PM to redefine priorities. One aspect that was adjusted was exposing five databases instead of two - concentrating all SMS lifecycle information in one tool. We moved the initial written brief, analytics, as a phase two addition.
Complex filtering
Support engineers need to know what, why, and how exactly something happened. Custom filtering was a key component for tool adoption. It was modelled to be similar to Kibana - the main tool expert engineers already use - with the intent of increasing familiarity and learnability. Because of backend technology constraints, not all optimal UX could be built from the get-go. We made a complex filtering system on the front-end and opened requests with data-pipeline teams to improve the tool in the next iterations.
Arsenal of secondary tools and check-ups
Having all actions that might be needed for debugging in one place was very important, since context switching was one of the most significant issues support engineers had. So instead of just knowing the status of an SMS, they now can: fire a test SMS themselves, checkup if the number is valid, test the webhooks, or escalate the problem directly to an external supplier - all in one toolbar.
Beginner-friendly
More often than not, SMS debugging is done by experts. To make the content more beginner-friendly, I've worked closely with the support lead to develop definitions and polished micro-copy. Jargons and acronyms are now accompanied by tooltips and supporting copy. That way, the tool is powerful enough to be used by an expert, but self-explanatory enough for someone who's just starting.
🗝 takeaways
One power tool to rule them all
No more time lost tab-hopping between tools. Efficient UX with comprehensive checkups saves time.
Empowering newcomers
Explained jargons, considerate micro-copy, and relevant links to learn more.
Bringing it to self-serviced
We tested a beta version of this with end-customers, and it scored highly.