A CRM is the acronym for Customer Relationship Management, a product for managing a sales wallet. It is a very popular tool, used by sales managers and salespeople, and it works for both B2C and B2B.
People usually use a CRM to organize the sales process, centralize the company's sales data and consequently use the functionalities so that they can sell more.
Within a CRM, the sales people work most of the time looking to their sales pipeline. They have these cards that we call opportunities, which is where the relevant customer information is centralized.
There are several ways to bring this customer information into the product. The most common are: manual registration, where I fill in a form with the information; via integration with other tools that automatically create these opportunities or via data import, when I have a spreadsheet on my computer and I import into the product.
Importing is the fastest way to bring data in large amounts.
In this journey of importing data into the product, there are usually several steps that people need to take even before reaching the tool.
So if you're trying to import a spreadsheet, you need to put all the information together in one place, which involves them understanding what information they need. There is a point of education that requires a lot of maturity from customers.
You need also to figure out how the product organizes the information so I can put it in the product, so I need to figure out how the tool names each piece of information, as there is no pattern.
And only then they build a spreadsheet or format the one I already have to the product and go through the import flow.
In the product, we already knew that there were several issues with this functionality. The team I was working on at the time looked at user adoption and retention and we always followed up on CX, support, NPS and other internal UX metrics that indicated problems in this flow.
We were sure that import was crucial in the use journey because we always talked to users, and import was seen as a way for many users to understand the tool.
Always appeared in the top 3 most frequently asked questions in support, with a lot of complains.
It had very low completeness metrics of out of 100 people, only 18 completed the flow. It was a ver low rate thinking that we had nearly 3 thousand users coming every week.
So looking at the product journey, and thinking about adoption and retention, it made a lot of sense to investigate how we could improve the import experience since it was so critical.
That's where the problem came.
After defining that we were really going to work on this functionality, to start with, I did the first data research. The basic desk research.
I gathered all the information from the reports, all the speeches from the customers, the metrics we had. I talked to a lot of stakeholders from support, sales team, business managers.
With this first data from the users' view, I decided to make a CSD with the whole team involved to technically understand what we were getting into.
I collected data from our analysis tools and thinking about expanding it to the investigation itself, I broke this research moment in two parts:
To understand use cases and jobs to be done on a larger scale, I set up a form to send to people and launched the survey within the product via typeform. We got over 100 answers.
To investigate pain points, and understand what kind of improvements people needed, I opted to do interviews directly. I set up the script and started recruiting users with an specific profile, like, they needed to be managers of the account, and they needed to have gone through the import flow at least once, so we could talk.
After having all the data from the qualitative and quantitative surveys, the use cases, the jobs to be done and the pain points, the problems started to look much more clear.
Here, too, we defined who was the person who could go through the import flow, mainly the sales managers. They are people who control the sales process, control the amount of information, people who manage even other salespeople. The sales manager is the one that normally assemble the spreadsheets and distribute the opportunities among the salespeople.
These people basically wanted the import feature to bring some results, like:
1. All sales people have access to the same information.
2. Manage and move information in large volumes.
3. Bring information from other systems into the new tool or bring information from spreadsheets into CRM.
4. Look for the amount of information they have centralizing everything in one place where the could visually see everything.
Migrate and test the tool on a large scale, right at the beginning of the journey. It represented nearly 54% of our cases.
Update data. If something new needed to be populated on a large scale people would update through the import.
Fill the product, this happened more recurrently over the customer's lifetime on the product, so every month, or every six months, customers would import a new base to work from, outside the beginning of the journey.
With this cases and jobs, with a PM, we made a matrix and prioritized which use cases we would attack first. We chose the most representative case, which was Migrating and testing the product.
To the previous version, I decided to do a pain points mapping.
The main screen would be this one bellow With two option, one to import a spreadsheet, and other to migrate from other tools, like pipedrive and google. And below that you could see the history of everything that you have imported. Here you could also see a lot of instructions of what you had to do to set up the spreadsheet and you could not see any obvious help page.
If you clicked to import a spreedsheet, you would go to a new menu where you could chose what type of information you would like to import. It also presented this huge big pink button.
The second step would be for you to choose your spreadsheet. And here we found one very critical pain point cause the user would have to go through here to have access to all the import rules. A second huge pain point here was that when you click to choose the file, all the options for spreadsheets on your computer appear, even those you cannot import.
If you clicked to import a file that was not accepted a huge red error would appear and the message didn't show why something went wrong. So the user couldn't even see what he did wrong, he had to figure it out and go to the support for help.
But if you were capable of import the right spreadsheet, the next step would be a step just to review your custom fields.
Another big pain point here was that if you needed to create a new field, you need to exit the import flow and lose everything that you did so far.
The next step was the most critical, the match the fields where you had to match what fields of the spreadsheet correlates to the fields in the CRM.
We start with a completely mess up steps count.
We had the match the fields with a horizontal scroll, so some people would try to import without matching all the fields because they didn't see the scroll here.
There was no status of what is checked, no information of what is mandatory, no visual feedback of how many fields do I still need to match, you can't see what field belongs to each entity. And you can't create fields here, you have to leave to flow to and miss everything that you have done.
And you can continue even if you didn't match everything.
The next page was to check duplicity, with tons of text and even with all this texts the rules weren't clear. As you check an option, other options appears.
And the last the review page, with no logical order to review the match fields. A lot of red texts, that could seems as errors, but you didn't to nothing wrong yet.
With these pain points well mapped, I presented them to the team, both design and developers, for us to discuss possible solutions. I always like to discuss solutions with the team because different ideas always arise and consequently more debates about what technically can be done or not.
I conducted a co-creation workshop with the team and we generated several ideas.
Here I tried to think more strategically about how I could break the project so that while I was working in other waves, the team could already develop the first ones. We broke into 3 main deliveries.
First the flow of importing Opportunities, then importing products and then the last one migrating from other tools.
I refined it to what made the most sense and built a first prototype in Figma for us to validate it.
After assembling the prototype, I again put together a test script and recruited people to test it. I ran over 30 tests on the three deliveries. And I know It was a lot but we needed to be sure because we were going through a lot of changes.
It's also important to mention that the company was undergoing a rebranding, and the Design Ops team was putting together a new Design System. The DS wasn't complete, but it made sense to think about the solution already in the new version, thinking that it didn't make sense to do something in one technology that was Angular and a few months later have to redo it in another technology that was React.
As it's not perfect, we had several turn overs and several reprioritizations took place like top-down situations, which meant that I had to review many things about the project. Our backend team couldn't do everything we needed to do and I had to redraw some screens. It was a huge learning experience because I had to prioritize things and readjust things that were already done.
I share the situation with de dev team, and we agreed on how to redo things. It is important to mention that not everything we planned was launched and it impacted at the final numbers.
Now we have visually clearer what needs to be done depending on your case. If you want to import a spreadsheet you can access the first option, if you want to import a spreadsheet with products, you have the second option, and if you want to migrate from other tools, you can choose the third option. Which is related to the use case that we chose to improve first.
At the top we have help, much more visual, which can be accessed without leaving the product. We also made an explanatory video and clear sections with common questions and rules.
Below we have a history table, with tags and more precise indications of what happened with the import. You can also delete or continue an import that has already started. So you don’t have to lose everything that you have done anymore.
Entering the main flow, we can clearly see how many steps there are and what needs to be done inside each one. We also have both options, with text much clearer than it's possible to import. By clicking on them, we have again the video, a spreadsheet template and the main rules for not making mistakes.
At this point you didn’t had to do nothing inside the product, just at your spreadsheet, so this took off a lot of cognitive thinking.
Then the Choose Sheet section now only displays the options that you can import. It's also much easier to understand what I need to do there, since we've removed all the other texts, the mental effort decreases and it's easier to understand the page. You just have to do one thing here.
While you click to upload a message also appears that it may take time and how much has been uploaded. If something goes wrong in the spreadsheet, an error message appears here and how to solve it too.
The next part was the most problematic. The match fields part has become clearer now. We have an option to not import the first row which is dynamic and remove the first option.
In the table we now have the status, if it needs to be mapped or if it is already mapped. We visually have an arrow to indicate what the field needs to be mapped with.
The select brings up the options and separate fields. Before, we didn't have this separation and it was hard to see what belonged to what.
We also have an option to create custom fields in here. It was quite an advance. Now I create the new fields without leaving this page. The options open in a drawer and the option is already mapped when I create.
In the options I have a message of what is mandatory.
We also have the option of not importing, which helps to identify what does not need to go into the product.
In footer we also have the number of fields that have been mapped, that need to be mapped and if there are any unmatched mandatory fields. When I'm done, he tells me that everything has been arranged and I can proceed to the next step.
The next step is the verification of duplicity. I separated the options into boxes where I was able to better explain what happened in each case. I worked really closed with the Ux Writer here, and she helped me a lot to make this more clear. And I passed the option of assigning a standard responsible for here, taking from the previous step.
Finally, I have a review of what was matched and what was not. Visually I separated what was of each entity and the arrow helps to identify where each one goes, which was a problem we had, because people didn't know exactly where the fields were going to be combined.
At the end, the spreadsheet enters the import queue and then appears as imported.
If we have errors, it appears in yellow what went wrong and also in which line and which error happened.
To remove an import I also put a second step, to avoid deleting something wrong.
My logic for building the flows was basically to remove friction. I tried to lower the cognitive load, knowing that the flow was exhausting and full of things that made you go back to the previous step or lose everything you had already done. The flow itself became much more fluid and gradual to be done.
I also thought about all the steps to do one thing only in each step. It was a trade off, cause we could do it in fewer steps, but I decided to make it longer but with only one action at each step.
For the launch, we decided to break into some groups, because as we were launching with the redesign, it was important to control this process. We launched it for a smaller base, which brought a lot of feedback for us.
We started to document and adjust what was going on bugs and what wasn't performing well.
After adjusting, we launched it for a second base, and when everything was going well, we launched it for everyone in the product.
After a month following how people's reception had been, we started looking at numbers.
We found out that the impact was very much as expected. Even though we had to use less backend, and we didn't deliver everything that was planned from the beginning, we managed to deliver a solution that improved the import flow by 101%.
Now, out of 100 people, 38 manage to make it to the end without leaving the flow. Also, the number of visits to the import page has decreased. Which indicates that people needed less page access to be able to complete 1 import.
Thinking about some considerations about the project, although we have promising numbers, we only managed to remove imports from the top 3, still appearing in the top 10, mainly because we were unable to change some business rules because of the reprioritization at the time of to develop.
Today I would revisit the project to update the design system because a lot of things have already changed.
I would also try to improve communication with the team to better break deliveries. I believe that because it was so big and less gradual, a lot of things took a long time to come out. As I said previously.
debsperandio@hotmail.com