Improving Reporting in SnapComms

As a Senior UX/UI Designer I collaborated on this project with a team of developers, a PM, QA, and a UX researcher. My responsibilities included UX research, UI design, data analysis, customer interviews, wireframing, prototyping, and user testing.

Exploring reports for published content is an important part of the journey to send a message to the employees, and to make sure that message has been successfully opened.

SnapComms is a very powerful platform with a lot of customization in targeting and delivery methods, and reporting should be as powerful as the other parts of the product, but easy to understand as it has a lot of complex information related to message delivery and performance.

In addition to those mentioned above, the primary source of research was the customer interviews. Together with an in-house UX Researcher, we were looking for experienced SnapComms users who regularly publish content using our platform and have used the reporting feature at least once. We were able to target those specific people (thanks to Pendo) with a custom invitation message directly in the product, with a direct Zoom call booking link via Calendly.

The final script had a total of 10 assumptions to be tested. This was done using 17 questions, some of which could be skipped, and some that allowed the interviewer to dig deeper with the help of a semi-structured format - depending on how the interview goes. Most questions were focused around defining the primary goals of using Reporting, and what business problems it helps (or fails) to address.

During the interviews, we asked customers to demonstrate a few reports for their content and to perform several drill-down actions to test some assumptions about how reports are being used.

Combining all the research streams, we were able to highlight these insights and pain points of the old Reporting UX:

The primary user story described below helps the team by providing a visual representation of how large items of work on reporting break down into smaller specific features and future tasks in Jira. To make it easier, I have split it into two parts - reviewing generic message reports, and Survey/Quiz reports.

While developers were working on new user story features development, I wanted to test if my new design addresses the pain points I have discovered during the research process.

After a step-by-step testing script was created for an interactive prototype I came back to some of the participants of the original interviews. I also recruited more testers for this - both new users and some existing SnapComms Reports users.

It was also useful for developers - as it was easier for me to demonstrate some of the details and animations of the new UI inside the prototype - such as skeleton loaders, filter popups, and some other features.

Overall feedback on the prototype was positive with most users having easily completed all user testing tasks. In particular, the added functionality of allowing customers to switch between tabs to view multiple reports on the same page had an overwhelmingly positive reaction.

Some polishing has been done based on customers' feedback - some column labels have been renamed, filtering range for dates designed, and exporting options for surveys have been redesigned.

After all the polishing based on feedback from user testing and some new requirements from developers, I completed the designs and started working with the team to make sure that the final result would look and behave in the same way as planned.

After each sprint was completed, a design review was necessary to review how features were built and provide feedback on any inconsistencies with the design.

New reporting was launched in portions, with one report after another. To make sure the transition is smooth, and acknowledge the fact that some users might resist the change, even if it offers an easier, and more robust experience, the team has decided to add a switch to the old reporting.

By default, the new report format will be opened, but if a user prefers they can always switch back to the original/old design. By doing that, I have added small friction to accessing the "old and familiar" interface.

Our product team embarked on a comprehensive project that encompassed research and user testing, enabling us to optimize development time and focus on addressing the most critical pain points and user needs.