Users were unable to gain further insight into their users’ interactions due to the lack of data export functionality in MTRIBES.

Two main use cases were defined based on feedback from existing and prospective clients:

1. Export data for long-term storage, as MTRIBES only stores data for 30 days per GDPR regulations.

2. Export data regularly for detailed analysis in external analytics platforms.

Build a clear and developer-friendly data export feature that allows users to easily setup and manage exports of MTRIBES event data for use in external analytics platforms.

I was responsible for owning the design research, approach and testing. I collaborated with the copywriting and engineering team to help finalise the approach.

To understand the way export data features work and to document the commonalities across features on existing platforms, I conducted a competitor analysis of eight products with varying specialisation in analytics:

• Clevertap: Analytics and personalisation focus

• Funnel: Marketing analytics

• Optimizely: Experimentation focus

• Segment: Data management focus

• Mixpanel: Analytics focus

• Adobe Target: Personalisation focus

• Amplitude: Analytics focus

• Heap: Analytics focus

Before UI, I focused on understanding the technical details of exporting data and laid out all necessary minor interactions in user flows; in particular the setup flows. Validating iterations of these flows with the engineering team ensured the necessary details were correct, providing the foundation for prototyping.

Working in Axure, I prototyped lofi concepts to get a feel for the three setup flows:

1. Amazon S3 bucket setup and linking to mtribes

2. One-off export setup and monitoring

3. Recurring export setup, management and monitoring

Despite being a straightforward user goal, the technical details and functionality in these flows needed to be presented in an equally straightforward way. The challenges I faced were:

• Displaying necessary information without overwhelming the user.

• Keeping the user in context despite the need for nested settings and external S3 bucket setup.

• Grouping the functionality required logically and clearly

I settled on an approach that aimed to keep the essential export information front and center. I minimised the recurring export feature to a summary of the export statuses. Access to the history and settings were shown on a sub-page, as displaying a table of hourly exports on the main page would potentially overwhelm the user. For the one-off export, as it is simpler than the recurring export, it did not require a separate page, but rather could display its history on the main page and be set up via a modal.

Testing these decisions would help to refine the concept further before release.

I tested the prototype with 7 participants with technical experience but varying knowledge of data:

• 3 Backend Engineers

• 2 Frontend Engineers

• 2 Data Engineers

I facilitated five of the sessions, with two observers in each session. I wanted to validate the: 

1. Feature discoverability and clarity.

2. Usability of connecting an Amazon S3 bucket.

3. Usability of setting up a “one-off” export.

4. Usability of setting up a “recurring” export.

Overall it tested relatively well, with 4/7 having no significant problems, 2 partially completing one task, and one failing a single task. We identified several areas to improve before release.

6 out of 7 participants successfully located and connected a bucket within the developer section. From feedback, the clarity of a few aspects could be improved by adjusting and adding copy.

Improvements included adding more details on required bucket access permissions and displaying the connected bucket name directly on the main page. For clearer guidance during setup, I added a stepped process to the top info section and numbered the cards accordingly.

“I’d expect to be able to confirm I’ve used the right path [...] I didn’t notice the button down there” -Backend Engineer

"...have I connected my bucket? It doesn’t look like the recurring export is connected to one" -Backend Engineer

All users successfully set up a one-off export, but improvements were needed on the setup modal. With the intention of giving the user all the info they needed at this point, it ended up increasing the mental workload of what should be a quick task.

We refined the amount of information in the modal; simplifying the file format copy and removing the “Data” section, instead titling the main page “Export Event Data” to clearly set user expectations from the start.

These improvements would also benefit the recurring export functionality.

6 out of 7 successfully completed the setup of a recurring export. A few improvements needed regarding the “Manage” CTA and its subsequent "Manage recurring export" page.

Notably, two users overlooked the recurring export log due to the export settings being located above it and consequently affecting its visibility. Secondly, the ordering of information within the settings section affected usability, particularly during setup.

To address these issues and improve consistency, I restructured the settings into a modal similar to the one-off export setup modal. The default CTA state was changed to “Set up”, changing to “Settings” and “View log” when an export is running to clearly separate the functionality. Hierarchy issues with the settings were mitigated by displaying the toggle and status only once set up.

“[the toggle] feels like I’m immediately switching on something I haven’t configured yet” - FE developer

“I didn’t expect to go [to Manage] to see the logs” - BE Developer

This project demonstrated the importance of good copywriting, showing the right amount of info at the right time as well as understanding the requirements and expectation of the user at precise points in the user flow and reinforcing this by using consistent UI patterns.