Apr 2019 - Nov 2019
New product design
SaaS web application
I was the design lead on this project. Because this is a new product, I was responsible for end-to-end product design from concept to implementation. I worked with architects, prodcut owner, engineering lead to define functions, and came up with user flows by brainstorming with PMs. I created wireframes to socialize within the team to collect feedback, and build hi-fi prototype for user testing. I also planned user research and did user interview with agency users.
Design plays a key role in the making of the product since the requirements are not fully thought through at day 1. Visualizing the user experience is a way for the entire team to approach the ambiguity and make up chunks of actionable item.
The project started with a clear goal: build an ETL (Extract, Transform, Load) tool for marketers and advertisers to import data into [m]Platform for data visualization and segmentation. I build the user flow based on this technical process.
Extract data from the source system, this will need authentication and security settings to make it happen.
Redefine the raw data based on the new business requirements or target data structure etc.
Load the data into a data model that is well defined for specific business goal such as building audience.
My initial proposal is based on the ETL model. Extracting source data from the left side, and selecting target data object on the right side, then transformation in the middle while connecting from the left to the right. In this interactive approach, all of the tasks can be done in one screen and it's very intuitive for user to understand the process.
Since this is a new product, the UX design and technical architecture design was almost happening in parallel. When we planned to deliver the design to UI Engineering team for implementation, I was notified the technology architecture has changed to a different direction, which could significantly impact the UX. Shifting the mental model towards the new architecture was a big challenge for me.
I hosted a whiteboarding session with PM and architect, to sketch out what's happening under the hood. We talked through all of the changes to prioritize what are important to users.
1) Display the raw data, transformed data, and data model object from left to right. Then use some UI transitions to guide user through the two tasks between them.
2) Display the extracted data table and user can transform based on the table. Then user can map the transformed data to the data model object.
3) Use the mapper to define the "data in", and user define the mappings in another flow.
When data model is the destination of the ingested data, data mapping is naturally involved in the flow because it defines how the data flow in. If data do not flow into data model, it is not necessary to include data mappings in the definition of data ingestion.
Breaking the data onboarding flow into 2 parts was well recieved by some technical users who understand database. However, users with less technical background think data will directly become available for use once they deploy the data asset. Therefore, we need to make sure user still see the continuity of the tasks as we separate them out.
Data model is the foundation of any utilization of the data in the system. When user bring in new data, the data asset will need to be mapped to the data model to become available for use. How to design a data mapper that doesn’t require good understanding about data model is the challenge for me.
The line mapper approach makes a lot of sense when the target data object is the data storage. The lines match with the analogy of ETL “pipelines” which means the data is from some place to a new place and being transformed during the transition.
Some user got confused between the mapping and the data relationships they see in a regular ERD view. The line connecting from one data set to another reminds user of the ERD.
This is a very interesting comment I noticed in the user research. Even though we told the participant this is a data mapping task, the visual form of the interface led him to think this is setting relationships between two tables.
Since the lines connecting from left to right, we can hardly scroll in the left or right panel. But in that way, you will probably connect a cell from top left to the very bottom right corner. That would be a bad user experience.
I explored 4 other interaction approaches for the data mapping: dropdown menu selection, tagging, pairing, and drag-drop. They are not just different in the micro interaction but also variant in terms of the mental model focus if we see them in the affinity diagram below.
Eventhough our architect and engineers think the concpet of "tagging" exactly explains what really happens in the background, I found a lot of insights from previous user research showing that user always focus more on the data model. After all, the data model is what eventually defines how the data is being used, so it should be given more attention.
For most data awared advertisers or marketers, data model is a warning zone. Being able to create data model object on the fly while bringing in new data sounds pretty desirable, but also a little bit intimidating on the other side. So I tried to provide the convinent UX of customizing the data model, but let user see the modification on data model as a serious action.