Tax Workflow Management Web Application


The challenge

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.

The solution

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.

Individual passion project
October - December 2020
User research, UX design, UI design, user testing


The struggles in tax compliance teams

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.”

Why the struggles?

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.

Analyzing the workflow of a single engagement

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:

  • Communicating with team members and with outside teams, and
  • Managing engagement progress.

Taking a closer look at the existing engagement tracker

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.

#1: "Random" highlights
  • A single action, highlighting cells, is used to convey different meanings, including review status, importance, urgency, pending issues, etc.
  • It’s easy to highlight cells that are relevant at a certain point, but difficult to consistently clear the highlights when they are no longer relevant.
#2: One-way task assignment
  • The assign tasks function is used as a one-way action from an upper level to a lower level. Although the lower level can reply and follow up, he/she cannot initiate the action upward when there is a question or issue that needs to be raised.
#3: Lack of information hierarchy
  • Information is categorized on tabs with no sub-category possible, making it difficult to find things.
#4: Same area used repeatedly
  • Using the same area of the sheet for different engagement phases doesn’t support situations where entities are scattered among different phases.
  • When this area is expanded to incorporate multiple phases, the sheet becomes significantly wider and requires more manual work to manage the space, e.g. hide and expand.
#5: One version doesn’t fit all
  • No personalization is allowed for team members who have different responsibilities, focuses, and goals.
  • Any change, such as adding a filter and sorting the sheet, affects everyone.
  • Being the main way of documentation, the tracker hosts all comments and notes from and to all team members, which forms a flood of information.
#6: Non-standardized color coding
  • The meaning of colors is not clearly communicated across the team.
  • Inconsistency among engagements may cause confusion.
  • The disorganized visual effect makes it hard to find information.


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.


Understanding users

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.

Understanding design context

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.


Objective #1: How might we meet the most essential user needs with a simple set of features?

What features are essential?

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.

Dashboard design

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.

App features

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.

Objective #2: How might we set up and communicate a clear, accurate, and flexible workflow structure?

Defining the most basic workflow component, task

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:

Communicating this structure clearly to users

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.

  • Other engagement modules like "Meetings" should not be bucketed into phases as they are likely to be relevant across phases.
  • This approach prioritizes filtering by engagement phases over filtering by entities, but the hierarchical relationship does not exist. Users need to be able to choose an entity to see which phase it’s in and choose a phase to see the status of tasks associated with the entities.

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.

Engagement modules

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.

Objective #3: How might we accommodate team members' individual needs in a collaborative engagement?

The “what” and “why” of private view

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.

Versions and iterations

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".

My decision

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:

  • Strong visual signals like high-contrast highlighting to emphasize the active view,
  • Clearly named text labels for the view selector, and
  • Tooltips and instructions to help users understand the different views.
Team view
Private view


Flowie: A workflow management web application

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.

Easy engagement setup

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.

Setup method 1
Setup method 2

Private working space in a team engagement

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.

Further customization for team leaders

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.

Usability testing with real scenarios

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.

Define user access

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.

Consider designing a mobile version

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.

Consider the business needs of buyers

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.

What’s next?

I'm open to
UX, product, interaction design opportunities
in 2023.

Let’s get in touch