AvaTax Transaction Import Case Study (2022)
We designed updates to a feature that allows Avalara customers to manually import transaction data for tax calculation and remittance.
Product experience team: Reggie Ogbonna (UX Designer), Jerred Metts (UX Writer), Gerry Chu (UX Researcher)
Context
Avalara provides tax compliance software to businesses of all sizes. Avalara’s core product, AvaTax, provides both real-time and batch sales tax calculation for over 12,000 jurisdictions. One of the ways Avalara customers calculate tax on their transactions in bulk is by importing them manually in AvaTax.
For years, customers have been using one Avalara-created template to import transactions through what is now referred to as the legacy import tool. The template contains all the columns necessary to calculate tax and more. In 2021, Avalara introduced a brand new import experience with a new API, new Avalara-created templates that accounted for multiple tax types, as well as the ability for users to create their own custom templates using exported spreadsheets from other platforms like Shopify.
Despite the new import experience being available to all AvaTax users, many users preferred to use the legacy import tool that remained live. Those that did make the switch were largely unsuccessful at creating their own templates, or encountered errors that led them to revert back to the legacy importer.
Opportunity
With Avalara intending to deprecate the legacy import in the coming months, we saw an opportunity to learn from users of both import experiences to identify the key problems and make improvements to the new importer.
User Stories
In Miro, we started by writing a list of user stories based on our own experiences testing the import tool. This exercise allowed us to identify functionality that would give us confidence at each step in the manual import process, whether we were creating our own template or leveraging an Avalara template. We continued to add to the list as user interviews began. Here are some of the stories we recorded.
As a user manually importing transactions, I should be able to download and enter my transaction data into Avalara templates so that I can upload them successfully.
As a user manually importing transactions, I should be able to upload a file with my unique transaction columns and data, and map them to Avalara’s columns so that I am not restricted to Avalara templates.
As a user manually importing transactions, before uploading my file I should have an understanding of what fields are required so that my import file is processed successfully.
As a user manually importing transactions, if I make a mistake while mapping, I should be able to see the error before moving to the next step.
As a user manually importing transactions, I should be able to save my progress while mapping columns, so that I don’t have to create a template in one attempt.
As a user manually importing transactions, I should be able to easily identify my templates, edit them, and delete them, so that I can better manage templates that I use regularly and remove ones that I don’t.
Learnings from User Research
User research was led by Gerry Chu. Initially, we used FullStory to understand how users had engaged with the new import feature within the past 30 days. We had FullStory “watch parties” where we would watch users attempt to import transactions manually and take note of their choice to use an Avalara template or create their own, where they abandoned the flow, and common errors they received.
Gerry reached out to users from these FullStory sessions in order to better understand their experience with importing transactions. I was able to sit in on six 45 minute interviews with Avalara customers who have attempted to use feature or import transactions regularly. Here is what we learned:
Users import transactions manually for a number of reasons, but most commonly because the integration between their source system (ERP, marketplace, etc.) and Avalara has not been set up correctly, or Avalara does not provide an integration that the user needs.
This project’s scope was restricted to improving the manual import process. However, integrations account for the bulk of transactions being sent to Avalara, and we recognize that improving the number of integrations provided, as well as ensuring the successful set up of integrations for users will provide the best and most seamless experience.
Only 15% of users who began creating a custom template in the past month finished successfully. 27% of users abandoned the setup after the first step.
We believe there are multiple factors that contribute to this low completion rate. When creating a custom template, there are a number of required columns that the user must map their source columns to, such as Document Type (whether their transaction is a sales invoice, purchase invoice, etc.), and Line Number.
The required fields are not displayed in the UI before a user uploads their file and enters the mapping exercise. Without reading an external help article, the user would not know what fields they need to account for in their upload file. Many users begin mapping columns, learn that their spreadsheet does not contain one or more required columns, and must abandon the flow to add the columns in Excel.
This FullStory funnel shows the drop off in users at each step of the transaction import process.
Due to the rigidity of Avalara’s template requirements, users may have to do a number of transformations to their spreadsheets in Excel to account for the columns and data that Avalara requires. Examples given during interviews include changing the formatting of columns, performing VLOOKUPs to get data from other spreadsheets, removing summary tables, and adding columns, among others.
Lastly, the original template creation flow has as many as 6 steps, with no option to save the user’s mapping progress and continue at a later time.
67% of all saved custom templates were created unnecessarily
When uploading transactions, users are presented with two radio buttons, one to “Use a template” and another to “Upload your own file.” The first option allows users to leverage either an Avalara template or a saved custom template, and the second option leads to the custom template creation flow. Both options require the user to upload their own file, which could contribute to the confusion users are facing.
Original transaction import uploader page with two radio buttons
One key finding from research was that 67% of all saved custom templates were actually just the Avalara template re-mapped. Users had downloaded the Avalara import template, entered their data, and uploaded it while the “Upload your own file” radio button was active, instead of uploading it under the “Use a template” option, leading them to map Avalara columns unnecessarily.
Template creation is a secondary option for most users
The primary distinction between the legacy import experience and the new import is the ability to create custom templates. However, we found that the majority of users only leverage the Avalara-provided template to import their transactions.
The number of columns in the standard Avalara template is overwhelming
During interviews and tests, when asked why they don’t use the standard Avalara template, multiple users responded that there were a lot of columns present in the template that they didn’t need or recognize. For context, the Avalara import template has 87 columns with only around 15 of them being required. The template itself doesn’t make a distinction between required and optional fields.
Defining requirements
After speaking with users, we were able to challenge our assumptions about what the problems with the new transaction import were, and define requirements for the updated experience.
Users need to know what fields Avalara requires before they upload their transaction data.
We should be clear about what fields need to be included in a user's spreadsheet so that they do not get an error or begin a mapping exercise that they cannot complete.
The template creation needs to be separated from the data import and presented as a clear secondary option.
This would help remove the pattern of users uploading the Avalara template and remapping fields. It will also simplify the error handling by distinguishing between mapping errors and data errors.
Complex error scenario from the original experience where a users import file had errors but their template could be saved.
The custom template creation experience needs to be flexible.
Many users may not have all the columns that Avalara requires in their source system export file. In fact, for Avalara-created fields like Document Type and Process Code, we know they will not. For fields such as these, the user should have the option to assign default values for all of their transactions each time they upload, so that they do not have to edit their template in Excel to include these columns if they do not want to.
Users need the ability to save their progress when mapping.
They should not have to abandon their work if they do not complete it in one attempt.
Users need the ability to manage existing templates.
They should be able to edit, delete, download, and duplicate their custom templates, as well as preview their mappings of each template.
UI Design
With requirements defined from user research, we were able to begin designing new user flows for the transaction import experience.
We identified early on from user interviews that we wanted to test separating the custom template creation from the actual transaction import. The large majority of users leverage the Avalara templates as opposed to creating a custom template. As previously stated, a significant number of users were accidentally entering the custom template flow with the “Upload your own file” option, causing them to re-map the Avalara template. In the interim, we changed the radio button label to “Create a custom template.”
As stated previously, a combined template creation and data upload process led to a complex error scenario where users templates would be created successfully, but the import failed because their data had errors (see screenshot above).
To eliminate this error, and present custom template creation as the true secondary option, we introduced some deliberate friction by adding a tab specifically for creating custom templates and managing existing templates. Here, users have the ability to add, delete, edit, preview, duplicate, and download templates. The custom template tab should also reduce the number of users who remap existing templates.
Updated import transactions page with a separate tab for template management and a new entry point for the custom template creation flow.
In our design, when users create a custom template, they upload an example file, meaning we do not import their transactions when the user saves their template. Upon saving, they can then use their template to upload their transactions in the “Import transactions” tab. This change only requires a few extra clicks from the user, and makes it so only validated templates are used to import transactions, as opposed to displaying errors for both an invalid template mapping and invalid transaction data at the same time.
Updated entry point for the custom template creation flow
The key word in our mind when designing updates to the existing experience was flexibility. The import process to this point has been very rigid. The user’s import file needs to perfectly align with Avalara’s required columns or they will encounter an error; their custom templates need to be completed in one workflow without the option to save their progress and continue at a later time.
To increase flexibility and efficiency in template creation, we wanted to provide another way for a user to enrich their transactions with data that Avalara needs for tax calculation without requiring them to do a lot of manual work in Excel.
We tried making all of the import settings (Avalara-specific fields) optional mappings. If the user did not map these settings, such as Document Type (the type of transaction such as a sales invoice), we would prompt them to select a document type for all of their transactions when importing with that template. This would allow us to remove the first step of the mapping process entirely.
We could not move forward with this flow, because there are a couple conditional fields that are required based on import settings selections. To best reflect this, import settings needed to be shown before the other required fields.
User flows created in Miro
We still decided to try giving users the ability to “skip” the template settings prompts though. These are primarily Avalara-specific fields that a user would never have in exports from their source system. Our idea was that allowing users to forgo mapping or assigning values to these fields would allow them to move forward to columns that they could most likely map, like Document Date (date of the transaction) helping them build confidence in the flow and get through it quicker.
We also opted for more of a conversational tone with this page in an effort to better communicate the impact of each field.
Both the original settings page and the updated settings are shown below for comparison.
In the original import settings page, users were confused by the UI text and the checkboxes that hid their options. “What is special processing?”
The updated version takes a more conversational tone, giving more explanation for each field. We also added a third option to skip a step so the user could continue with the template creation without mapping a column or assigning a static value to the template.
We felt that the original required columns page was too cumbersome, and observed users struggling with the address forms specifically. We saw success on previous projects by breaking longer forms into more manageable pieces, so we decided to create an additional step specifically for the address columns. Continuing the pattern from the template settings page, we provided users with three options to either assign a previously configured location code (a unique code that represents an address) to all transactions, map location columns, or skip the step and enter a ship-to or ship-from address for all transactions when importing their transactions using the template.
See the original required fields page below.
The original required columns page
We’d previously struggled with the term “required,” as there were columns on other pages that users needed to provide in order to move forward. Added flexibility to template settings and address pages allows the required columns page to be the only step where the user needed to map columns from their spreadsheet, making them truly required.
We’d also discussed extensively the idea of auto-matching columns with our product manager and lead engineer in efforts to help users save them as much time as possible.
For the updated required columns page, we wanted to only display columns that the user needed to match. We separated these columns from the address columns that offer more flexibility, making for a less intimidating step. Our hope is that user’s confidence grows with each completed step, reducing their desire to abandon the flow .
The address columns page provided users with the option to assign a location code to all transactions, match columns, or skip and provide an address when importing. We also used an informational alert to be more direct about which columns are required when matching.
By keeping the template settings step as the first page, we can add conditional columns on the next page depending on the process code the user selects. For example, if the user selects a process code for overriding tax (i.e. bringing in transactions with tax already calculated and asking Avalara not to calculate tax), we’ll display an additional Amount column on the required columns page.
Updates to the Attributes step were not in scope for this project. This page is only shown to users with certain entitlements, such as customers who have purchased beverage-alcohol tax calculation. The users we studied had the basic sales tax calculation plan and never encountered this page. We may look to address this step in future quarters.
We didn’t make any changes to the optional fields page, other than updating the modal that displays unmapped fields and editing the UI text. We did not observe major problems with this page during research, largely in part because the vast majority of users who started the template creation process abandoned the flow before making it to the optional columns step.
The optional columns page allows users to include additional data in their transactions for returns. Unmatched columns are not imported.
Finally, we designed a few different versions of the review screen. We got feedback during user interviews that the original page was overwhelming, showing a list of mappings from each page. Our thinking was that this information was only useful when creating a custom template, so we decided not to show the page when a user imported transactions.
See the original review screen below.
Original review page
We ended up with two versions of the Review page that we wanted to test. The first version is similar to the original page, with tables displaying the mappings and default values from each page for easier readability. During testing, we’ve received feedback that users prefer to see each section expanded by default with the option to collapse them.
One version of the review screen shown to users which displayed matchings, tags for default values, and one row of sample data in a table.
The second version displays the mappings as they’d be shown in a spreadsheet that the user would download. The header cells show both the Avalara column name and the user’s source column name, with 5 rows of sample data from the uploaded file beneath.
We wanted to emphasize a second time that the transactions would not actually be imported at this step, and that we’d use the column mappings and assigned values to create a new template for future imports.
For the second version of the review screen shown to users we displayed the data in a table/spreadsheet view, with mappings and default values in the header row and 5 rows of sample data underneath.
Once saved, we decided to forgo the processing page, taking users immediately to the import history page after importing transactions, as we observed that users navigated to that page after each import to download their results file with Avalara’s tax calculations.
We also made the error handling process more efficient in the case that a user’s transaction import fails.
The original error flow is as follows:
Upload spreadsheet
Land on review screen and save
Land on processing screen
Navigate to import history page
Download error file
Fix error and re-upload on transaction import page
The processing page in the original flow is misleading because the success toast caused users to believe that their transactions processed without errors. We chose to remove this page from the updated flow.
We cut out unnecessary steps in the updated flow:
Upload spreadsheet
View error modal
Download error file
Fix error and re-upload
The updated error handling flow features a modal with clear instructions on resolving errors which was absent before. It displays on the upload page, so users can quickly download their error file and re-upload the corrected spreadsheet.
With the screens designed, I made them into an interactive prototype that would allow test users to explore each page without many dead ends in hopes to gain valuable insight into how useful these updates are to them.
Testing
Ten user testing sessions were conducted by Gerry. Users recounted similar problems that were discovered through earlier interviews, such as not understanding all of Avalara’s required fields, and not being able to delete previously created templates.
The majority of test users got through the prototyped flow fairly easily, but still wanted more easily digestible information regarding Avalara fields, such as how to distinguish between different process codes.
Every test user preferred the version of the Review page that displayed their mappings in the form of a spreadsheet, because that was how they were used to viewing data.
Two users had trouble finding the entry point for creating a custom template, as we removed the radio buttons they were used to and added tabs. They both clicked into the template dropdown when asked to create a new template. It would be helpful to include an additional entry point within the dropdown for users that don’t notice the “Your import templates” tab right away.
We created an additional entry point for creating custom import templates based on user feedback.
Next Steps
There were a number of updates we discussed that were outside the scope of this project. One hypothesis we have is that more in-product help in the form of videos could allow users to better understand nuanced information, such as the difference between document codes. We’d love to explore that with the appropriate teams in future quarters.
We’d also like to update the standard Avalara template in Excel to better communicate the meaning of each column, as well as clearly marking required fields, which is not done today.
Multiple users stated that they were overwhelmed by the amount of optional fields in the standard template, leading them to create a custom template unnecessarily. We believe that creating a simple version of the standard template with only required columns and a few of the most commonly used optional columns would be another improvement to the import process.
Further research and testing will allow us to better understand the different data errors that users encounter, as well as how to explain them in a clearer way.
Moreover, we know that increasing the quality and volume of Avalara’s integrations will provide the most seamless experience for users, eliminating the need for manual transaction imports.
In the meantime, it’d be really helpful to create additional preset templates for commonly used platforms such as Shopify, so that users don’t need to do a lot of work in Excel to prepare their export file for importing.
We will continue to iterate on these designs based on user feedback, and look for new ways to improve the manual import process for AvaTax users.