While the nature of tax compliance work requires teams to be extremely efficient, their current workflow management practice is setting them back. Team members are frustrated about spending too much time chatting, calling, and emailing to stay current on everything that is happening. So I wanted to research the root cause of this issue and design a solution to help resolve it.
I studied two tax compliance teams in two different cities by interviewing participants ranging from Associate to Director. I then designed a workflow management web application, Flowie, with a clickable prototype as a proof of concept. It allows users to quickly set up engagements as clearly defined workflows with manageable components and helps them document and organize information by attaching it to specific workflow components.
The main way of tracking and communicating engagement progress in the teams that I studied is through messages, emails, and calls. In some cases, they create a Google Sheets tracker, depending on whether a tracker exists in the prior year, the volume of the engagement, and the preferences of team leaders.
However, regardless of whether a tracker is employed, team members are experiencing challenges in managing their workflow, which lead to low efficiency and productivity.
“I spend so much time talking with my team on the phone or chat. Sometimes I forget the answers but there’s no way for me to find them so I have to ask again.”
“I feel like I’m on the phone for the most of my day so I don’t have time to finish my work, especially since we started working remotely.”
“We have an internal tool for project management that we never use. We have a Google Sheet or Excel workbook sometimes but it's still not efficient.”
To understand the why, I conducted primary research to gain an in-depth view of the workflow of tax engagement teams and to evaluate the tool they currently use to manage workflows.
I talked to people at different staff levels and created a diagram that outlines the process of an entire engagement. This helped me understand user pain points and design opportunities, which fell within two buckets:
I then investigated the issues with the Google Sheets tracker to further understand the specific workflow management needs of my users. Although there isn’t a standard tracker for all engagements, which leads to potential confusion and frustration, most trackers have a similar structure.
The tax compliance teams that I studied faced two main issues in their current workflow management practice. These issues can be attributed to a deeper root cause, for which I proposed a solution that provides visibility into and control over users' workflows.
It was especially crucial to understand who I was designing for in this domain-specific project.
First, people in public accounting are generally not tech-savvy. They are experts working in a spreadsheet environment but are generally not interested in trying new technological tools that are not familiar to them or look complicated to use. Also, people's responsibilities and goals vary per staff level and so do their behaviors and needs, although they all have the same overarching goal of delivering tax services to clients in an efficient and accurate way.
I then divided my users into two groups, based on whether they’re in a managerial role. And moving forward, I focused on the primary persona, Jennifer, and made some customizations for Jason.
There were a few factors of their work environment that I had to keep in mind in my design process.
Because I was working on my own in a limited time frame, my goal was to focus on framing the main features of the app as well as how they work together to boost team productivity and visibility.
In terms of project scope, I wanted to design the details of some features that are most closely related to the problem I defined earlier; and I planned to create a clickable prototype as a proof of concept.
Since my users are generally not technical in digital technology and have limited time and energy to learn technologies, I wanted to keep the app simple and basic. It should focus on the most essential user needs, which I determined based on user interviews, but they need to be further refined and validated with my users.
I started from the dashboard screen as it is a good overview of where all the features reside.
In my sketch, I originally designated the most space to the "Engagements" feature for users to pick an engagement when they start working. But I found that because users usually worked on just one or a few engagements at a given time, it's more efficient for them to directly access their recent tasks or to-dos than to choose an engagement first. Meetings and notifications regarding task assignments, etc. are also added because they are important parts of users' work.
In user testing sessions of the dashboard design, I also gained a better idea of user needs, which informed me of what features are the most important as well as how they might be used.
The first challenge here was to decide at which level a task should be defined—entity, tax return, phase, deliverable, or workpaper. Because at any given time during an engagement, tax returns of different entities might be in different phases until delivery, defining a task in the workflow was challenging.
An early exploration was making each tax return a task, which is completed when it's gone through all the applicable phases outlined in the engagement diagram previously mentioned. This is because any engagement can be considered as the sum of all returns.
However, since each phase then involves multiple sequential approvals, a task defined at the tax return level would be consisting of more than one layer of subtasks. This approach also fails to inform users about the phase when given an entity, which is important information for a quick progress check.
After more ideating and testing, I finally decided to have tasks be activities that need to be done in each engagement phase. A task is completed by having all assigned members sign off. The structure or hierarchy of workflow components looks like this:
On my low fidelity wireframe shown below, I created a side panel for users to choose phases. Then they can filter tasks by entities.
From user testing, I discovered two main issues with this.
The design I decided upon was to move phase information inside the task table as a column and have filters for both entity and phase on the same level. This makes the table a little more crowded than before, but I thought it was a trade-off that I had to make between lowering the cognitive load and simple UI.
In the meantime, I was able to define and iterate on the six modules in this "Engagements" feature, which replace all functionalities of the existing tracker created in Google Sheets.
When viewing tasks, users at different staff levels had different preferences and needs in what and how much information they would like to see in what order. Each user had their individual preferences as well. As a result, customization was necessary. On the other hand, the team should also have a “standard” team version that reflects the team’s common goals and priorities.
Therefore, I created a private view on the tasks page that is customizable and hosts information that is relevant and visible only to the current user.
It also allows the user to record time spent on a task that flows to the "Timesheet" feature to eliminate manual preparation. This data also goes to the "Progress & Analytics" module of the engagement for team leaders, which will be explained more later.
I initially sketched out two versions of the view selector below. Most users with who I tested them were overall confused about what “personal view” was because the concept was completely new to them.
Therefore, in the lo-fi wireframing stage, I wanted to test a different way of presenting the same function in version A below, which has a “personal space” carved out on the right side of the screen. In version B below, I moved the toggler to the top right corner and changed "personal view" to "private view".
Based on user feedback, I decided to move forward with low fidelity version B and focused on improving user awareness of the currently active view and its effects. Overall, this design provides a customizable experience for users and improves the findability of information. Some benefits are:
Flowie targets corporate tax compliance teams in public accounting. It facilitates communication among team members and with outside teams. For each client engagement, it sets up a standardized but customizable workflow and helps users document and organize all information that is communicated or needs to be communicated by attaching it to the workflow components like tasks.
Users are given two options: fill out information on the page, and import data from an Excel template. The process is streamlined because it requires minimal information and utilizes defaults to set up a standardized workflow that consists of entities, phases, and tasks. Users can then make customizations by adding or skipping any of these items.
In addition to team members, key contact people from outside teams are also invited to the engagement for easy communication and information sharing.
In the Private View of an engagement, users are able to fully customize task orders and each individual task currently assigned to them as well as view comments sent to them. Reordering tasks, adding notes and attachments, and recording time spent don’t affect how everything looks for other team members.
This allows users to directly attach more information and references to the workflow for better information organization without interfering with other team members’ work.
While team leaders like Jason have the same full access to all engagement modules, they are less likely to spend lots of time completing detailed tasks. Instead, they more frequently do a quick status check and look at analytics like hours incurred vs. budgeted. Therefore, users logged in with a profile set to be Manager or above will see the Progress & Analytics module as the default.
In this project, I was able to leverage my accounting skills and past experience in public accounting in my design process. Overall, I did a good job of staying unbiased, avoiding making assumptions based on my own experiences, and asking non-leading questions in my user interviews.
I used hypothetical scenarios in the testing sessions and ask participants for feedback based on their general experience. To make sure this app can handle real engagements that might have some special cases, I would like to do usability testing with real or more realistic scenarios.
I would also like to address whether it’s necessary to and how to define user access at each staff level as well as for specialized team contacts and, potentially, client contacts. Since each staff level plays a different role in a team, they are likely to require access to different tools. It is clear that specialized teams and clients should only have limited access, but more details need to be considered.
Based on my research finding that users spend most of their time on a work computer, I decided to design a desktop-only app. But certain features like messaging can be available on a mobile device, so I would like to explore more in this area.
In this project, I mainly focused on the needs of the end-users. In the long run, to make this app a real product or business, I also need to consider the business needs of buyers, public accounting firms. Boosting productivity with this app will likely drive business growth, but there are more nuances such as the cost of adopting a brand new tool in an organization, how ROI is measured, etc.
