Prospective clients were hesitant to adopt our accounts payable product because there was not an easy way for them to import the necessary data to get started. This included data about their vendors, and contracts, which are necessary in the accounts payable process. As the product designer, I worked with our product manager and a team of engineers to understand the nature of the problem space, design & test iterations, and implement a data import solution that would afford our users an easier way to get started & get value from the product.
With some initial thought after being introduced to the project, my team and I determined there were three primary problem areas to assess:
We concluded that a source-agnostic data import was the best near-term solution. A CSV import for vendors and contracts would have the best trade-off of time for potential impact. Clients have dozens or even hundreds of these records, and it did not make sense for them to re-enter these one-by-one just to get started in the program. Telling them that there was a quick way to get this data into the software during the sales process would go a long way towards closing the deal with small and mid-sized companies, although some larger companies would commonly hold out for direct integrations.
Since we knew CSV import was needed for at least two data types, we landed on a pattern for performing CSV imports in a somewhat-abstract fashion so it could be modified for any specific type of data.
We used a step-through workflow that we made accessible from the pre-existing “Add New” buttons for each type of record, which now gave the option to create a record manually, or import records in bulk with CSV. The step-through workflow had the user focus on one task at a time until the import was complete:
What were our clients saying?
My team and I used a variety of discovery and research techniques to understand the problem space:
reviewing recorded client calls
leading interviews with a list of prepared questions, and some on-the-spot questions to drill into interesting answers
researching existing solutions in the problem space for possible insights
This combination allowed us to collect the data we needed, so that we could get specific about which problems needed to be solved, and the rationale to back it up.
Among the first things we discovered was that not having a means to import certain types of records into our software would shut us out of deals. It began with sales saying “we need integrations”. This high-level language would continue in other conversations until we learned to get extremely specific about what “we need integrations” means, which turned out to mean something very different than what it seemed.
What does "import" really mean?
During discovery with current clients, we realized that there is a difference between data import needs for onboarding vs. data import needs for operating. There is usually a large quantity of records to input or import when they do a one-time event like onboarding, such as vendors and contracts.
After some time, we determined there were some types of data that kept coming up over and over from clients. In thinking through what it would take for them to onboard vs operate our software, we determined that the actual objection was focused around onboarding. Clients had dozens or hundreds of records that they didn’t want to manually re-enter just to adopt the software, but manual creation of these records on an ongoing basis was not really a big deal.
Analyzing the data sources
Another dimension to this were the data sources. Now that we knew which data types to focus on, we needed to understand where the data came from. There is a wide variety of tools and processes that businesses in our target market may choose or invent in order to reach their business goals. This influenced the format of their data, and it was not very common that any two businesses had similar processes.
Another consequence of the variety of tools is that there is also a variety of data models and corresponding attributes present in those tools, which may or may not map cleanly to those in our software depending on how they were designed. This could be challenging for both up-front mappings for onboarding, as well as ongoing imports.
Because of these observations, we concluded that our solution had to be agnostic to the data sources. There were simply too many different sources and formats present to go with direct integrations at first. The solution would be too narrow, and even if we developed an integration, there was no guarantee that clients that used the software we integrated with would buy our software.
Overall, we concluded that the best near-term solution would be a CSV import pattern, which would initially allow us to build import workflows for the most crucial two sets of data: vendors and contracts.
Who has already solved this problem?
Before looking at external sources, we wanted to know if this feature had already been attempted internally. Fortunately, there was existing research from another team that we were able to build upon.
In a user test with similar personas, 7 participants were tasked with importing records by uploading an existing spreadsheet and mapping the column headings. Terminology for data fields can vary between companies, but it’s necessary to keep the data labeled consistently once it is imported into our system.
No participant easily passed the core task of this workflow - CSV import and mapping. Although this low success rate could have been attributed to a flaw in the design pattern, 6 out of 7 participants said that they prefer to do any verification and clean up of data before they would import it into the system. 6 out of 7 participants also explicitly said they would not import a CSV that was missing required data.
“I think it’s really important for everyone to spend just 5 - 10 min making sure the import is working.”
“I would rather clean up everything before importing.”
Knowing that this method tested poorly with users, we opted to move in a different direction. Another common pattern used by many companies is copy/pasting into a predetermined template. Participants from the previous user test had actually confirmed that copying/pasting data was a pattern they were already familiar with, so that gave us the validation we needed to explore the concept.
We used the design thinking method for discovery, design, and testing. The results from each test were treated as material for future design iterations.
User flows
I started out with some user flows to determine the sequence of events that a user would take to import the CSV. We started with vendors and kept an eye towards using this as a pattern for importing other types of data. The difference between these two user flows (pictured below) is the entry point in which a user would begin their contact import. We determined that option 2 was more in line with our existing design system and patterns.
Wireframes
Once the team aligned on a user flow, I started working on wireframes to get the basic visual layout down before spending time on color, typography, etc. Once these had gone through a feedback cycle with my design peers, I put together some low-fidelity mockups to start validating with a few users.
I used a full-page modal for this workflow, as that was the standard pattern per our design system for CRUD operations.
During design reviews with the product and engineering team, it became clear that there were a number of ways a user might run into problems when trying to upload their CSV after reformatting it to our template. These issues also required providing feedback to the user so they could better understand how to proceed.
Missing headers
Every uploaded file was checked for missing data headers. This would help to catch modified templates, older template versions, as well as completely wrong types of files. We determined it was best to display an error message to the user explaining that one or more required headers were missing, and the best course of action would be to download a fresh template and input the data there to try a reupload. This case would hard-stop the user until the error was corrected.
Missing required information for creating a specific record
Files were also checked for missing data. This case would also handle data that wasn’t the right data type, which could happen in cases where users copy & pasted data into the template from another sheet. To help with this, users would get to preview the data that was parsed prior to records being created, and any records that were missing data was pointed out to the user. Users would have the option to proceed with the upload if they wanted, with the records missing data being left out of the creation process. Otherwise, they could go back to their template and correct the issues before trying another upload.
The new workflow was tested internally with 3 Client Success Managers and 2 Account Executives who were familiar with the type of prospective clients that we were targeting. We concluded that this was enough to confidently say that the lack of a CSV import workflow was no longer a blocker for sales, which was our primary goal.
The CSV import workflow started with vendors, with the plan being to eventually integrate it into importing other types of data such as contracts, invoices, projects, and more. Once our product was in the hands of clients, we would be able to gather direct feedback on the workflow and make the necessary changes and improvements.
This project reinforced that firsthand observation and discovery are crucial in order to make the best design decisions. After dedicated discovery by the product team, the call from sales for “integrations” was determined to be not the full story, as clients core objection to adopting the product was due to perceived difficulty with onboarding their data, not operating. With the team focused on solving the right problems, the eventual designs were effective, allowing small and mid-sized companies to onboard much easier than before.
It also reinforced that it is critical to distance yourself from the designs and not assume that your first crack at solving the problem will be the right one. The first usability test that we executed is a perfect example of how important it is to be open-minded to new information and be willing to pivot to new concepts quickly.
More work ↓
