The Problem
Clients had the ability to press a Sync Now button to sync data from their systems to ours.
We received feedback early on that it was difficult to find and use, in it's current location on a sub-page, so we moved it to the sidenav where it was always on display. Innocuous decision, right? Simple, elegant. Easy-to-access from anywhere.
Growing Complexity
One day, we ran into our first use-case where a specific client had two systems we needed to sync from.
Shoot, now what? Do we put one Sync Now button for each client integration? Do we display a modal popup and ask which system to sync?
We opted to move the Sync Now button to the integration settings page.
The next morning a new Slack message:
Clients are furious we removed the Sync Now button from the sidenav, we need to hotfix it back. Highest priority.
Multiple Attempts At A Fix
Round 1
So we hotfixed it back while figuring out our game-plan and that's when things became not-so-innocuous. At first we tried to implement a strategy to ask the user what they wanted to sync from a list of integrations that were enabled.
We're getting feedback from most of our customers, who have one integration per property that they are upset they need to take that extra step.
Round 2
When each page loads (because it's on the sidenav), return a list of integrations and so we know if 2 or more are enabled. If so, ask them to select an integration to sync from, otherwise just show the toast popup for "Sync started"
...That worked for a while but over time new problems arose:
- We said Sync started (processes that can sometimes take 10 minutes or more) when we didn't know if it started because we couldn't keep network requests open for that long. Sometimes it failed due to invalid credentials or misconfiguration, leading to support requests
- There was no feedback around what synced, if anything. Sometimes it would connect to the integration and re-sync data, but no new data was synced, and furthermore we didn't have a place we could easily showcase how much data we were able to pull over
The Solution
The idea behind the final UI iteration was to move this button to any page where users are checking if their data is synced or needs to be synced. If multiple integrations were enabled that supported syncing data, show a dropdown and have the end-user select the integration they want to sync from.
First, this cuts down on data-fetching on every page load since it's no longer in the side-nav.
Second, with the ability to refetch the data to see if new data was synced in, there is a feedback loop where clients can see if the Sync Now click worked or not. The clients are also happy that the ability to Sync Now happens on the page where they see stale or missing data.
Third, utilizing websockets notify the button clicker when the sync completed or that there was a problem with a Toast popup or Alert. If there is a problem, include a link to where they can triage the problem and then resume their data syncs.
Lessons Learned
- Design and UI/UX are a critical facet of the SDLC and when building new products or systems, early design decisions can become quickly solidified in Product Marketing content and Knowledgebase How-Tos. The cost of changing Design decisions later is very high.
- End-users can become resistant to change, especially if the product is a SaaS offering that is meant to improve their productivity or help them perform critical tasks. Redesigns must be properly communicated and in some cases, it's beneficial to let have both experiences in parallel (or to toggle between them) so that they can get familiar with the new design patterns when it's not interrupting their daily workflows.
- Whenever a relationship between two entities exist (organizations and data-sync integrations, for example), building with a many-to-many relationship instead of a one-to-one relationship in mind can cut down on refactoring costs later, even if there aren't immediate use-cases for many-to-many relationships present