Mapping Process Revamp and Map Editor Design
Team: Product Manager (1), Front-end Engineers (2), Back-end Engineers (2), UX Designer (1), Map Team
Time: Ongoing project since August 2018
Manage store locations that come from 3rd-party sources (Front)
Edit tenant information (Back)
Background
Problems
Maps are the foundation of Point Inside. However, the map maintenance cost is super high to keep the maps accurate and up-to-date with the existing mapping process and mapping tools.
For example, it used to take a mapper a few hours to update just tenant names and at least 24 hours to release the changes - this sounded unreasonable to a lot of stakeholders (including me) as well as some of the customers. Given its large influence on sales deals, the company finally got serious about that and would like us to find out what was causing the costs.
Project Goals
-
Understand the mapping process including
-
Identify primary friction points in the mapping process.
-
Share research insights across teams to explore opportunities and solutions.
-
Progressively migrating mapping tasks to Map Editor to increase operational efficiency.
Outcome
To just update a tenant name: 30+ minutes (past) → less than 1 minute (now)
Time took to update a tenant from "Xfinity" to "Starbucks" in the production map.
Outline
User Research
Research Plan
I started the user research with a study plan. After discussion with my product manager, we set the research goal to understand:
-
Roles: What are the different roles involved in the mapping process?
-
Goals and Tasks: For different roles, what are their primary goals and tasks?
-
Tools: What are the tools they use to complete their tasks?
-
Map Elements at Different Stages: For each element (e.g., tenant label, tenant shape, shape style), at what stage of the process are they mapped?
Methods
-
Read: In the past years, the Map Team has been creating a lot of training documents to explain the mapping process in detail. Reading through these documents helped me to quickly grasp a blink of the workflow.
-
Observe and Learn: a map training was held by the map expert to walk through the mapping process step by step. Afterward, we were asked to be a mapper and to create a map on our own.
-
In-person Interview: I coordinated 7 in-person interviews with mappers and other stakeholders to understand their frustrations and needs.
Analysis
To better demonstrate the research findings and to give teams across the company a clear picture of the current mapping process, I created the following diagrams:
Overview of All User Research Deliverables
Stakeholder Mapping
What are the different roles involved in the mapping process?
Map Creation Workflow
For different roles, what are their primary goals and tasks?
At what stage of the process are different map elements mapped?
Cost Analysis with Change Request
To fulfill the requests to change different elements of a map, how many phases a mapper needs to go through to update these changes. The image was blurred for confidentiality.
Pain Points Affinity Diagram
By the mean of an affinity diagram, user pain points and needs were sorted, grouped, and categorized by different stakeholders and task types. I also added some thoughts and suggestions during the process.
Mapping Process Revamp
This is a long-time team effort to improve an old and complicated mapping process. It involves different stakeholders such as customer success analysts, engineers, mappers, and map leads. And it requires changes to the established workflow for years. Below are some changes that have happened following this round of the user research.
Batch and Load Automation (Backend)
One of the biggest pain points from user research was the batch and load process. It was frustrating, error-prone, and time-consuming. Gladly, the old process was replaced and save our mappers a lot of time and clicks.
One of the biggest pain points - Old batch and load process
Batch and Load Process: Old v.s. Current
Migrate Place Name Update to Map Editor
The place-name update feature was already built in the map editor. However, it was set up for a specific partner back then. To increase operational efficiency, we decided to migrate all the place name update into the Map Editor.
Time It Took to Update Place Name: Old v.s. Current
Map Editor Improvement: Change Tenant
After the tenant change task was moved into the Map Editor, our mappers came across some new issues with changing tenants by using the map editor.
Context
Tenant Name and Information are managed in the tenant form in the Map Editor (see the original tenant form below).
Original Tenant Form in the Map Editor
Problems with the Original Tenant Change Flow
It took too many clicks (7) for a mapper to change a tenant. This would be time-consuming when mappers need to update a bunch of tenants during a routine map update.
Original User Flow for Tenant Change
Requirements
In addition to making tenant change flow more easier, my product manager would also like to separate two different use cases to better record the tenant history for the location:
-
Change Tenant: e.g., Xfinity was closed and Starbucks is open. We should recognize this as one record in the tenant history
-
Fix Tenant Template: e.g., we confused Macy's with Macy's Home. And this change should not be recognized as a tenant change.
1st Design Proposal
In this phase of the design process, I made an assumption, without being aware of it, about the 2 different use cases stated above: Mappers would need to deal with tenant changes more often than template fixes. Combining the requirements to record tenant history, I brought a few mockups to the weekly design review to talk about my ideas.
1 Design Proposal: Add an independent location form to list active and historical tenants. Users could view tenant history on this page and change tenant directly by clicking the "Change Tenant" Button. Users would need to open the tenant form to fix templates.
Disagreement
There were some disagreements from CTO and the engineering team during the design review:
-
Users would need to do one more click to fix the template. He doubted that tenant change would happen more often than a template fix.
-
Could we avoid adding an entirely new (location) page which would cost more engineer resources?
Informal User Study with Mappers
To understand how mappers update tenants using the map editor, I spent some time with the map expert from the map team asking questions and watching him perform different tasks. After this informal user study, I got a lot of new insights:
There are two scenarios in which they would need to update a tenant:
-
Routine Check/Quality Control: they usually compare our maps with reference maps side by side.
-
Requests from others/customers to make a change on demand: they usually use the left List+Search to get to the specific tenant.
In the case of updating tenants:
-
50% of the changes are tenant change (e.g. Red Robin to Xfinity)
-
30% of the changes are marking the place to Vacant Space (e.g. Red Robin to Vacant Space)
-
10% of the changes are fixing templates and mostly (Confuse Macy's with Macy's Home etc.)
Design Iterations
I shared my new findings with the team and move onto iterate on my designs.
To be continued...
The 2nd round of user research just kicked off. And I will be working on the map editor design task on and off moving forward.