Avalara

UX Researcher

The Goal: To provide product managers tools and guidance on identifying and documenting end users interactions with their products.

The Problem:
Avalara needs consistent documentation of their users’ journeys throughout each of their different products. This required training product managers to be self sufficient to alleviate the strain on the UX research team.

The Solution:
I created a rubric for building journey maps to be used by product managers at any stage of the product’s lifecycle, and finished almost 40 individual journey maps.

About
Avalara has over 60 individual products and use cases in their suite of automated tax compliance softwares. The products range from 20 year old acquisitions with their own working processes, brand new systems branching into new territories for the industry, and everything in between. The company decided user journey maps were the best way to break down silos between the products, and to create a consistent way for anyone what a product is, who uses it, and how.

Overview
It was my responsibility to work with key product managers to advocate for and build a user journey map for their primary user and a primary scenario. Due to time constraints and scalability concerns, I developed a way for over 50 PMs to become self-sufficient in the creation and upkeep of their individual, maturing user journeys.

I used my experience creating the first two user journey maps to start to identify what the key elements were, and begin to build checklists for the process. I worked with product managers to create 38 journey maps during my 6 month contract.

Role
UX Researcher

Tools
Visio, Google Sheets

Results
38 individual journey maps were created, with 25 different product managers. I created and recorded a training on how to create a user journey map, and created an easy to use template in a software the company was comfortable with using.

Impact

The value I brought to Avalara was less about the specific impact of the user journey maps I develop, and more about the cultural shift I helped cultivate at the company about the importance of user research.

My assigned project was “create a user journey map for every product we have”. It soon became apparent that I had neither the time nor the subject matter knowledge to accomplish this goal.

Instead of scrambling to build every map myself, I created, presented, and facilitated trainings and workshops to educate product managers and other stakeholders on how to leverage their own expertise and knowledge of the user to build their own journey maps.

This had a dual effect. #1, I was able to utilize existing knowledge to significantly increase my effectiveness in creating more journey maps, and #2 by involving internal stakeholders into the creation process, it demonstrated the value of speaking with user to enrich their understanding of how their products are used.

Instead of only having a team of 2 full-time user researchers and myself interested in our user’s experience, I was able to demonstrate the value of user research to stakeholders across the business.

My contributions of journey maps and training to the research organization has resulted in Avalara creating a plan to expand the research team in 2021.

The Process:

When I began, Avalara needed a consistent reference point for people to see how a user interacts with each of their products. There were a few user journey maps already created, but the UX Research team did not have the bandwidth create every journey map needed.

I was brought in to assist with the process, with the original idea that I create each map by myself. There was a template that other UX researchers on the team created before I arrived, and it had been used for three or four maps throughout the previous year and a half.

It became apparent within the first two weeks that it would take me over a year to create a map for each of the products needed, and that didn’t include individual scenarios or personas. My manager and I decided that given our constraints, I would work directly with some product managers, and create a training for others. I also wanted to figure out the strengths of the pre-existing template, and augment it to be used throughout the company.

For this to work, I needed to come up with and document a process that could be taught to product managers and they could use this framework to create journey maps for more than their primary scenario and personas.

These slides were taken from the training I put together for product managers.

My manager was working on a journey map for a developing product, and the first map I worked on was a product that was almost finished. Because of the myriad of situations, each map needed to be highly adaptable.

I started with the template, and worked with my first PM to start to identify the key components. These were the scenario, personas involved, and our user’s goals.

Chris Auty and I began by identifying our primary user, and scenarios. The product was not yet launched, so it was a future state journey map. The UXR team was still working on the company personas, so Chris and I had multiple conversations on the difference between a customer and a user.

Once we had this identified, we walked through the individual user steps were for a user coming into the product, and flushing out exactly what the set up process would be for our user. This was documented from our chosen starting point to the end of the set up, trying to be as detailed as possible.

This forced Chris to really consider how the process would go for our user, and what they would need to accomplish.

We worked down from each step to identify what screen the user was looking at. Transitions are extremely important to focus on during the design phase, as it is often a pain point for users. We needed to make sure to note when the user was looking at one of our products, and when they were working in other products (such as Quickbooks Desktop).

Avalara was working on analyzing their user communication, so our next row of information was planned contacts. Some products had a lot of ad hoc communication, but it was important to identify the planned emails.

From there we documented how the Avalara team supports the user at every step, as well as what screen or system the employee was using.

An extremely important row is the “user sentiment”. Here we documented any known user pain points, with the knowledge that as the product launched, we would have more information. There was a lot of tribal knowledge around issues that Support knew about, and the journey map was a great way to let stakeholders know of real issues. There was a future plan to add layers of data to the user sentiment, but it was after I left.

Our final row for this map was notes and opportunities. This was used to jot down any important information, or areas of opportunity.

This journey map was created in Visio, which was the preferred tool for mature journey maps. We took the draff to other people within the company who had knowledge and expertise on different parts fo the journey to internally validate our assumptions about the process.

To the left, you can see the Visio template

Working on the two simultaneously, it was clear that the individual rows for the journey maps might have some variation between products. The second product had a third party to factor in, one that interacted with the user and Avalara. I adjusted our template, and added a row for the third party’s steps.

A pattern was starting to form between these two maps, and the start of my third. I started to see the stages I was going through with product managers, and ways to expedited my process. I also noticed a major flaw in my work. For my first few maps, I would meet with the product manager, ask a bunch of questions, parse a bunch of documents, and synthesize this information to a drafted journey map, and then review it with the PM.

I’m not sure if you’ve ever looked at the nuance of sales tax compliance, but it is a complex system that I had very little prior knowledge on. It would take me a long time to find the individual user steps, and I realized shortly the time I was spending was unnecessary. The PMs knew these steps. It was my job to capture this information and facilitate needed discovery, not be the person to discover.

This was a shift in how the team and I viewed my work. It was a company initiative to create a journey map for every product in the Avalara suite, and quite frankly it would take one person over a year to get them all done. After consulting with my managers we hatched a plan. Some products I would co-create a map with them and closely facilitate the process, and I would coach and consult as needed.

I saw three main barriers for PMs to actually create journey maps for their products.

First, training. Maps were a newer concept in the company, and not widely used beyond the User Research team.

I created and executed training that was recorded for future PMs.

Second, time/attention. PMs are very busy, and they have a lot on their plates. There were many conversations between my manager and I to establish who was ultimately responsible for the maps. Was it the Research team? Or the product manager? We talked with the boss, and then the boss’s boss, and ultimately decided it was the product manager’s responsibility to have a journey map for their product, either created with me or not.

The final barrier was the software. I was using Visio for the maps, and most PMs worked on a Mac. Visio Desktop is a Microsoft product, and only worked on PCs. Many PMs were uninterested in learning a new software, as well as learning what journey map was and how to make one. As I contemplated this issue, iit struck me. The template was basically a grid, and I could easily recreate it in a spreadsheet.

Everyone in the company had access to Google Sheets, why not make a template in Google Sheets that PMs could mark up themselves? There were some logistical things to consider. Who would “own” these? I wasn’t a permanent fixture in the company, so it couldn’t be me. If they were scattered throughout different PMs drives, they wouldn’t be an accessible resource. I ended up housing them on the UX team’s drive, with the instructions that as PMs were using the template and making new maps, they would reach out to the team to add the map to our collection.

I created documents to put on wikis to show what to expect in each phase of the journey map creation, and did what I could to assist! Here are some examples. I kept them intentionally small, to protect company information.

Visio examples:

Google Sheets examples: