AvaTax Onboarding (2024)
We designed part of an onboarding experience for setting up tax calculation with Avalara.
Product experience team: Reggie Ogbonna (UX Designer), Elijah Kull (Subject Matter Expert), 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 tax calculation for over 12,000 jurisdictions, so that businesses can collect and remit the correct amount of indirect tax to the appropriate collection authorities. Businesses rely on Avalara to provide accurate tax rates, integrate seamlessly with their enterprise systems, and above all, to make the tax compliance journey simple.
Problem
In order to start benefiting from the automated tax calculation that Avalara provides, users are required to complete three onboarding steps for their accounts.
(1) Provide Avalara with their primary business information
(2) Tell Avalara where they’re registered to collect tax, including the types of tax they are registered to collect
(3) Connect Avalara to their business software, such as QuickBooks.
Historically, it has taken multiple days for a user to complete these onboarding steps, namely the second and third steps, to “go live,” resulting in a frustrating introductory experience for customers. Moreover, users often require continuous assistance from Avalara’s customer support team during this process, reducing the capacity of that team and preventing them from focusing on other customers.
Objective
As one of the top-level initiatives of the year, the Product and Engineering organizations were tasked with understanding and addressing issues with the existing setup workflows in order to create a more simple and efficient onboarding process for customers.
Because I had previously designed for AvaTax, and had a fair understanding of the product’s tax collection settings, I was tasked with leading the design effort for the second onboarding task.
The second of the three steps requires users to tell Avalara where they’re registered to report tax. Generally, when businesses have a physical presence in a jurisdiction, or reach a certain amount of sales in a jurisdiction, they reach nexus, the point at which they are required to register with the appropriate collection authorities to collect and remit tax. One of the key services that Avalara provides is fast and accurate tax calculation, so that businesses remain in compliance with the government. In order for the Avalara tax calculation engine to provide accurate rates, it needs to know where users are registered to collect tax.
All of the six teams working on the new onboarding experiences communicated closely throughout this project. It was an extremely large effort with tight timelines. To ensure that we had a common understanding of our objectives, we began by establishing overarching goals for the project.
Overarching Goals
Reduce the amount of time it takes for a user to complete onboarding from multiple days to under a day.
Allow users to complete onboarding without assistance from the Avalara customer support team.
Reduce the number of onboarding-related support tickets.
Improve the accuracy of setup and the user’s confidence in their ability to use the product.
After establishing overarching project goals with the wider team, my team defined requirements for improving the Nexus setup and maintenance experience. To do this, we relied on insights from our User Research Team, conducted interviews with subject matter experts and leaders around the company, including our Chief Product Officer, and called upon our own past experience using and working on the product.
Target User Persona
While the new onboarding experience needed to accommodate businesses of all sizes, we chose to target small business customers because they often experience the most issues with onboarding.
Our small business user persona is named Lisa. Lisa owns a one-person business that does less than $10k a month in sales. She has very limited tax knowledge, and does not employ a full-time accountant or tax specialist. Because she wears all of the hats for the business, she does not have a lot of time to spend on tax compliance. She needs a simple onboarding experience so that she can leave the hard work of calculating tax to Avalara, and get back to her day-to-day tasks.
Defining Requirements
Clearly communicate why the user needs to complete the task.
Many users misunderstand the task as one in which they are indicating where they make sales, or where they would like to register, rather than indicating where they are currently registered for legal and tax calculation purposes. Communicating the purpose of the task was critical.
Make it easier for the user to make the correct selections when setting up their nexus settings.
Users are advised to reference registration documents when completing the second onboarding step, but they don’t always have the documents handy based on research. Users should be able to select the correct registration-type in the product through clear UI text and useful Help experiences.
Make it easier for users to select local taxes.
The historical experience for selecting locals was not very intuitive. We showed users a flat list of jurisdictions by default with no way of understanding the relationship between jurisdictions or knowing which tax you were selecting by name.
Accommodate all tax types and allow users to set up calculation for multiple tax types in one workflow.
Avalara provides tax calculation not only for Sales and Use tax, the most common type of indirect tax, but also for other types of transaction tax such as tax on lodging, meals, recycling, alcohol, and more. The historical experience for setting up tax calculation required users to add regions where they were registered for one tax type at a time. For a user registered to collect and remit four types of tax, this would result in four separate user workflows, increasing the setup time. Moreover, we understand our users’ mental models to reflect a “Geography-first” approach, meaning that they think of all the places where they are registered to collect all types of tax, rather than separating regions by tax type.
Allow the user to set up domestic and international tax calculation in one workflow.
Similar to the last point, historically users were required to set up international tax calculation (for taxes like Value Added Tax and Customs Duties) in a completely separate workflow. We created a dynamic onboarding experience that allowed users who are registered internationally to set up calculation for all countries where they report tax within one flow.
Clearly communicate error scenarios and ways to fix them.
Key Principles
To accompany the requirements we defined as a team, we came up with principles to guide our work.
Progressive disclosure
We realize we are asking users for a lot of information to start their journey with us. We should only show information they absolutely need to see at each stage of the process to limit confusion .
Flexibility
The experience we design should work for a wide range of customers. The experience should be dynamic so that it works well for customers only registered to report one type of tax in the United States, as well as customers registered to report seven types of tax in twelve countries.
Simplicity
The first touch point with a product should be a simple one. Explain unfamiliar concepts, reduce the number of choices the user needs to make where applicable, and minimize clutter in the UI.
Deciding on an Approach
The legacy approach to setting up nexus was centered around the different types of tax that users can calculate. Avalara allows users to calculate Sales and Use Tax, which is a common indirect tax in the U.S., as well as other U.S. taxes and fees for things like lodging and alcohol, and also international taxes like customs duties. Sales and Use Tax and Value Added Tax (VAT) are included with an Avalara subscription, while all other types of tax calculation must be specifically requested or purchased.
Historically, users were required to set up each tax type individually in all the places for which they were registered, which created a tedious and inefficient user flow. For example, if the user collected tax in 17 states, 17 of which they collected Sales and Use Tax, and 12 of which they collected lodging tax, they were required to complete two separate workflows for setting up each of the two types of tax in the relevant states.
Based on discussions with users and subject matter experts within the company, we believed that this experience was not aligned with most users' mental models. Typically, business owners and tax professionals view their tax collection responsibilities in terms of location first (“I collect tax in Wisconsin and Arizona”) rather than by tax type first (“I collect lodging tax in 2 states and sales tax in 5 states. The states in which I collect lodging tax are…”). For that reason, in the updated experience we decided to take a location-based approach where users would indicate where they were registered, and set up calculation for all tax types for which they had access in one workflow.
Auditing the Existing Experience
Throughout the process, and especially before beginning the UI design process, we spent a lot of time going through the existing experience for setting up nexus in AvaTax. Included below are screenshots of the old experience with comments.
The screen above is the first screen users see in this step of onboarding. It requires users to select U.S. States where they are registered to collect Sales and Use Tax only. Setup for other types of tax must be completed separately.
This screen reflects the state selections on the previous screen. For each state, the user may need to select a type of Sales and Use Tax registration, and/or local taxes.
One issue with this experience is that the static registration-type options (Sales tax or Sales or sellers use tax) do not always match the language on a state’s registration. For example a Louisiana registration will have the options Remote Seller, In-State Seller, or Direct Marketer. It is difficult for users to understand how the options on their registration document maps to the options we display in the UI. This leads to incorrect selections and inaccurate calculations.
Warning: Long Scroll
This long scroll experience is the one users saw when selecting local taxes in the old experience. The buttons placed at the bottom of the page were not sticky, which forced users to scroll through hundreds of jurisdictions to continue.
Users were shown a flat list of jurisdictions with no way of understanding the relationship between jurisdictions or knowing which tax they were selecting by name.
The old “maintenance screens,” the pages where users update their nexus settings after onboarding, are organized by tax type. Each tab shows regions where you collect that type of tax, which is not optimal for getting a holistic view of how you collect tax is a specific region.
This tab shows all the jurisdictions where users report Value Added Tax (VAT) or Goods and Services Tax (GST). Avalara provides tax calculation for Canadian provinces. Those provinces are displayed here on the same hierarchical level as countries, which is one area we wanted to improve as part of our progressive disclosure principle.
UI Design
We tried a few different design approaches before arriving at our final design for the MVP release. At the request of product leadership, we even attempted to design an experience where the entire nexus setup occurred on one screen, with a series of expanding and collapsing folder interactions as the user went further into a country (Country > Region > Local Jurisdiction). However, in the end we decided to go with a simplified approach that still prioritized efficiency while only showing the user necessary information on each page.
Because of the priority level of this project, as well as the tight deadlines, we had design reviews twice a week with stakeholders, including general managers and the acting CPO, to discuss our progress and critique the work. Although this was not a typical working situation, it allowed us to iterate quickly, explore many ideas, and get real-time feedback from those we usually would not have an open line of communication with. We designed an initial release version of the experience for users with the baseline tax types only (Sales and Use Tax, and VAT), as well as another version which we refer to as “Multi-Tax” for users who have purchased or requested additional tax type calculation options, like Lodging Tax. Below are the screens we arrived at after six months of scoping, research, planning, design, and implementation review for both versions of the experience.
Standard Version
We attempted to explain clearly on this initial page that users should only select regions where they’re already registered. We designed a sticky footer so that users didn’t need to scroll all the way to the bottom of selection pages to proceed if they didn’t need to. We chose to automatically select their home state based on the primary business address entered in the first step of onboarding. We elected to keep the three column grid, and edited the spacing and treatment of the checkboxes for easier scanning. We also added search functionality for all selection pages.
As stated earlier, during research we learned that many users did not understand the purpose of this onboarding step. To catch users who may have selected states where they make sales, or states where they want to register in the future, we decided to show a confirmation message for all first-time users.
This is a full page screenshot to show that all states selected in the previous screen are reflected on the next page. Some states require additional information, like a registration-type selection or local tax selections, while others are ready for calculation right away. We attempted to simplify the language, and display options that directly match language that is used on each state's registration.
For users who did not have their registration documents readily available, we wanted to provide an alternate way of making an accurate registration-type selection. Users can click a button in the state tile and see a modal with dynamic, state-specific questions that will lead to a selection.
We still advise users to check their registration documents to ensure they have selected the appropriate registration-type. The help modal selects how users should be registered in a given state, but that is not always the case.
View local taxes by county
View local taxes by jurisdiction
After discussions with subject matter experts within the company, we elected to organize local taxes by county by default. Users can select all taxes within a county, or expand the county to individually select taxes within a county. Users can choose to see an alphabetical list of jurisdictions in the filter section. We also provided search and filter options so that users can find the taxes they’re registered for more easily.
Once a user has selected the relevant local taxes in a given State, clicking “Done” takes them back to the state tile screen to continue refining their settings.
Depending on the state selected or the registration-type selected, users may not be prompted to add local taxes. Once the user is done refining their U.S. state nexus settings, they can Save and move on to the next page which deals with International taxes.
Here users are asked if they are registered outside of the U.S. If not, this is the last page of the Nexus step. These users continue on to the last step of onboarding, which is setting up a business software integration.
Users who are registered outside of the U.S. are asked if they want to set up other countries now or later. If users choose to set up other countries later, they can continue on to the integration step, and return to set up international tax calculation at another time after onboarding. Because their U.S. selections are saved at this point, they can start calculating Sales and Use Tax right away.
The process for setting up international tax calculation is similar to the U.S. tax flow. Users start by selecting all countries where they are currently registered to report tax.
For international tax, users are required to enter a registration ID number for each country where they collect and report tax. Users can also indicate if they have a physical presence in the country and if they are responsible for products imported into the country, both of which affect tax calculation. Avalara provides regional tax calculation for some countries like Canada and India. Users who select those countries are prompted to select any regional taxes that they collect.
Users registered in Canada can select any provincial taxes they’re registered to collect.
Any regional taxes the user selected are reflected in the country tile. Once the user is done refining their settings, they can Save and continue on to the Integrations onboarding step.
After onboarding, users can edit their nexus settings at any time. We commonly refer to this experience as “maintenance,” where users can add, update, remove, or expire regions as their registrations change.
With the Location-first approach, we removed the tabbed experience shown earlier, and start users at the highest geographical level, displaying all of the countries where they report tax. As they click into countries, they can see more information about how they report tax in the country, as well as their regional and local settings where applicable. Users can search by country name, and filter by active or expired records.
Clicking into a country record will show the settings entered when first adding the country, as well as any regional taxes reported within the country. This is a full page screenshot.
For Standard accounts, the United States does not have any country-level settings, but the user can view and edit any state settings by searching or filtering for the record, and clicking into it to see more details. Our principle of progressive disclosure allowed us to organize the layers of settings in an intuitive way.
Clicking into a state record will show a familiar looking detail page with settings that the user configured when first adding the state. Here they can edit those settings, view and update any local taxes that they’ve added, and add new local taxes. Local taxes can be filtered by tax type and jurisdiction type among others.
Users can edit the effective and expiration dates of all records based on their registration documents.
Users can update dates of multiple records at once, or delete multiple records at once.
Multi-Tax Version
“Multi-Tax” refers to accounts who have purchased or requested tax types in addition to Sales and Use Tax and Value Added Tax (VAT) that come with AvaTax. Here I will point out differences in the two experiences.
The process of selecting states is generally the same. The first main difference occurs in the state tiles. While users of standard accounts are restricted to Sales and Use Tax only, Multi-Tax users can select from all tax types that they have purchased or requested.
When adding locals, users will see local taxes based on the tax types that they selected in the state tiles. For example, if they told us that they only report Lodging Tax in Alabama, they will only see local lodging taxes.
For accounts that have purchased Customs Duties calculation, the first question we ask after they finish configuring their state settings is whether or not they ship products to the U.S. from other countries. This allows the user to set up country-level settings in the U.S. (if applicable) before moving on to other countries.
Afterward, they are shown the same international prompts as Standard Accounts.
For accounts that have purchased Customs Duties calculation, users can select whether they collect VAT/GST, Customs Duties, or both in each country they selected.
In the maintenance experience, accounts with Customs Duties calculation will be able to add Customs Duty calculation and VAT/GST calculation to any country they have already added without clicking into each country’s detail page by checking one or more records and clicking the appropriate bulk action.
Country-level settings are displayed for the United States in accounts with Customs Duties calculation. All tax types selected for each state are reflected in the States table.
Multi-Tax Version
Similar to the setup tile, users can select and deselect from a list of available tax types for each state. Local taxes are available in the table below to be searched, filtered, sorted, for easy management.
Special Use Cases
Throughout our time working on this project, there were many special use cases that we needed to consider in order to reach parity with the existing experience, address new tax legislation, reduce compliance risks for customers, and account for all account types among other reasons. I’ve highlighted some of the cases below.
To address new legislation in Colorado, we chose to store any state-specific settings on the state nexus detail page rather than on the company settings page where they were previously stored. This established a pattern for the location of all other state and country-level settings. These settings are not shown during onboarding, but sensible defaults are always selected. The user sees a reminder to refine any settings on the home page after onboarding.
When adding local taxes, we display a confirmation message for users who have selected all local taxes in a state. Reporting tax this way is unlikely, so we chose to warn the user to reduce compliance risks.
The general flow of the Standard and Multi-Tax experiences was designed with the understanding that most Avalara users are registered in the United States. The U.S. is also the trickiest country to set up in the product, so we start there. A relatively small number of users are not registered in the U.S., so we provided a way for them to skip this task if they enter a primary business address that is outside of the U.S. in the first step of onboarding.
U.S. states generally have state taxes and local taxes. Some states do not have state taxes for certain tax types for which Avalara provides calculation. When a user selects a tax type in a state for which the state does not have a state tax, they are required to select local taxes. Otherwise, the tax will not be calculated.
We chose to indicate the tax types that do not have state taxes with a blue tag. For logical groups of individual tax types that Avalara supports, such as Lodging, Hospitality, and Meals (tax types that are grouped together in the tile depending on what the state supports), we show a “No state tax” tag if there is no state tax for any of the taxes, and a tooltip if there is a combination of tax types in the group with and without a state tax explaining that local taxes must be added for the tax type(s) without a state tax in order for it to be calculated.
User Testing
User testing was conducted by our User Research Team, and led by Gerry Chu. The designers from all of the onboarding team put together an end-to-end interactive prototype for user testing sessions. The research team conducted hour-long usability tests with seven external participants and two internal customer support agents who have been historically tasked with helping users to onboard.
All external participants were owners, co-founders, or COO’s of small businesses, and none were accountants with expert tax knowledge. This was a good subset of users to test, because this segment is generally the one who has the most difficulty with onboarding. Six of seven external participants were not customers of Avalara.
The feedback received from these test users on the onboarding updates was largely positive. Regarding the 2nd step for tax reporting, multiple users commented that the registration questions were easy enough to answer, and that if they could not answer from memory they would know where to look on their registration documents to make the correct selections.
Below are two quotes from external testers.
“Everything seems to flow…No crazy questions like asking me stuff that I don’t think I could find anyways on my own as a business owner.”
“It’s not overly difficult and the questions are pretty basic to the point where you don’t need like a professional or anything to sign up through it. I think it’s just more of like a time consuming thing than a difficult thing.”
Updates from Testing
Our internal participants who had experience working with both small business and enterprise clients were concerned that not providing a way to select all states would slow down the workflow for large customers.
When asked, all seven external participants said that they would not select all states and would only select the states for which they were registered, indicating that the updated text and confirmation modal better communicated the function of the task. However, these were all small business customers.
We learned that large customers who are registered in a lot of states tend to “select all” first, and then deselect the states where they are not registered to save them time. Because those customers almost always have Multi-Tax accounts, we chose to add a “select all” button for the Multi-Tax experience. This will allow them to keep the same workflow while discouraging small business users with Standard accounts from over-selecting.
After user testing was completed, and we were confident in our proposed experience, I worked closely with the engineering team throughout their sprint planning and development to ensure that all designs were feasible (and design alternatives if not), help prioritize features, and participate in the quality assurance process.
Reflection
This project was both extremely challenging and rewarding. It was the largest cross-team effort of the year, and tested our ability to plan and execute properly as a small team, as well as communicate effectively across internal organizations. We were under a lot of pressure from leadership to move quickly, and I believe we did so while still prioritizing our users and trying to adhere to our core design principles.
For my work on this project, I received Avalara’s Business Champion award in 2024.