During my time at a data governance company, I was tasked with re-imagining the data source connection experience for the flagship product. This established a user-friendly workflow which catered to those less familiar with connecting data sources.
For this project, I was tasked with re-imagining the data source connection flow for users at all experience levels. I worked as the lead product designer for a duration of six months alongside a product manager and two front-end developers. The project phases we went through included:
When I first joined the company, I was tasked with re-designing one of the first interactions that a user has with the product. Having never used the product before, my own personal user test session was recorded with the head of design and a senior product manager, and I used the speak aloud method to document my thought process. To my surprise, at the end of my session I was told that my first task at the company would be revamping this exact user flow. From here, I mapped out what phases needed to occur before ideations were to begin:
With my own user recording and a Figjam filled with pain points documented from other users, I began collaborating with a product manager and the lead front-end developer to start mapping out a plan towards a much cleaner user experience.
This heuristic evaluation focused on understanding how the documented pain points fit into the live product. Being completely new to this project, I was able to frame better questions when talking through pain points, and I could determine which issues could be addressed without a complete UI rework. From this, I was able to:
One of the major UX problems I found when reviewing the live product was the amount of cognitive overload that was present when connecting a data source. The user was faced with inputting a vast amount of information where inputs were ambiguous, and the tooltips were confusing and unhelpful.
To give the screen below context, once a user's account is configured their first experience with the product is this page where they can connect their data source. As shown below, this is a tiny slider modal that contains an overwhelming amount of information.
Note: In the example below, a sample of the product is shown, however, it is shown in a way to not display the live product. Regardless, it does reflect the same flow within the product prior to the redesign:
That was a long scroll. As you can see above, when a user connects to a Snowflake database, the slider modal becomes even longer and overwhelms the user. Other components like "Force Remove Data Source" is in a hidden area that most users are unable to find. Along with this, instead of incorporating tooltip icons, helper text drives the size of the modal by being placed underneath the labels.
After the heuristic evaluation, I met regularly with the product manager and developers on the team who would be incorporating the future changes to the app. I also took into account user feedback we had received for this area of the product:
As I moved into the brainstorming phases, I decided to focus on an improvement that the front-end developers also agreed with which was reducing the cognitive load. This was a relatively light lift, and it would immediately help users to better understand the process flow. This led me to talking with product managers and developers to understand the purpose of each input and how customers and our application engineers used each one.
We also agreed to resize the slide out modal to cover 2/3 of the screen space rather than just 1/3 to allow for more breathing room. This gave the modal the ability to handle a two column grid rather than every section being stacked on top of one another.
To reduce the cognitive load on the user, I broke the slider modal into a step-by-step process similar to what we used in the onboarding flow.
I also added sections for illustrations to add more visual interest. It also indicated to the user what each section for Usage History and Data Classification meant. In the last step of the flow, I added a summary so that the user could review the inputs for each section before saving their changes.
Although I cannot show the final live flow, the feedback from users and application engineers was positive. It allowed them to understand where they were at in the flow, reduced the amount of accidental force deletions, and gave an overall better taste to the product as they started to explore other features.
Thanks for reading this far! Here are similar projects that might interest you:
