AMAZON FINANCE TECHNOLOGY
T-RAIL
1 Designer
4 Months
T-Rail is a tax checking tool for Amazon businesses in Brazil. Brazil has one of the most complicated tax systems in the world. Every month, tax analysts manually scrutinize over 40 million invoices to ensure compliance with government regulations; this labour-intensive effort costs on average 8,000 man-hours annually and is expected to drastically increase as Amazon's Brazil market is growing at a staggering 41% each year. Tax analysts are not data engineers; lacking the necessary technical skills, they would soon be unable to handle such high volumes of data. To combat the technology debt, T-Rail is envisioned as a no-code, self-service platform to streamline this highly technical process.
Originally started in 2021 as a Priority 1 project for Amazon's LATAM Tax leadership, however, it suffered from lacking end-user buy-in. A prior version MVP failed because it did not meet the actual needs of the tax analysts. Finally realizing the importance of user-centred design, I was brought onboard to help restart the project from scratch.
RESEARCH
用戸研究
Personas
Unfortunately, due to the nature of their work, it was not practical for me to reach out to the individual tax analysts in Brazil and asking for one-on-one interviews.
Fortunately, the project managers before me had saved recordings of their user interview sessions. From these old recordings, and with help from tax team managers, I was able to create a new set of personas for the tax team users.
Journey Map
The whole tax filing ("closing") journey is a highly complex business process involving multiple personas from both tax and engineering teams. Before T-Rail, there was no standardized system or operating procedure. Tax analysts working on different tax categories and business entities often have very different checks they need to run on their invoice data, and each analysts would adopt different methods and tools to run them.
Competitive Analysis
Other than familiarizing myself with the users, I also needed to better understand the relevant product landscape. Currently, tax analysts use everything from Microsoft Excel to Amazon QuickSight to Python scripts to run their custom checks. The future T-Rail platform need to be robust enough to support all these tools' core functionalities, lest users be unwilling to migrate over. Bearing in mind the users' non-technical background, I focused my competitor research on both internal and external products featuring no-code and non-engineer-friendly interfaces.
IDEATION
設計構想
User Flow
A main reason the previous T-Rail iteration failed was because the MVP did not fully cover the tax checking process. There was no incentive for tax analysts to abandon their already familiar manual procedures only to migrate over to a tool that ultimately could not do all the work for them and required a different set of manual tasks to complete the tax checking. I knew from the start that the new user flow would have to cover the end-to-end process. From the overall journey map, I picked out key user actions needed for tax checking. They would become the foundation for T-Rail's product requirements. I proposed features that could automate the manual tasks, and identified ways to streamline cross-team interactions.
Information Architecture
T-Rail would be comprised of two main types of content — data and rules. Data obviously refers to the huge volume of invoices coming into the system every month, while each rule is a specific tax check that will be run against the data.
Data and rules would be organized into datasets and rulesets depending on the user scenario. At each level of the information hierarchy, there would be various analytics features and actions pertinent to different stages of the tax checking process. Users can start from the highest level of data performance overview and drill down all the way to read individual check results.
Screen Flow
Now the underlying structure of an application has been laid out, the next step was to further solidify the content and come up with actual screens. Taking the sitemap from above, I turned it 90 degrees and just plopped in screen thumbnails for each separate content piece. By using AWS' powerful Cloudscape Design System, I could easily start off with set of out-of-the-box screen layouts and make customized adjustment as needed along the way.
Very soon we had a screen flow overview of the entire T-Rail app. What so far had only been abstract information had finally turned into concrete UI. Now the various stakeholders, from high-level business managers to tax team end users, could have a clear picture what we would be building. The engineering team was also able to come up with more precise effort estimation. As engineers began the backend preparations, I moved on to frontend design.
PROTOTYPE
原型制作
Mid-fidelity Mockup
Thanks to the extensive Cloudscape component libraries available in Figma, I could quickly build out mid-fidelity mockups from the screen layouts. The design questions during this stage focused on content organization, check result visualization, and no-code rule configuration. In order to smoothly handle the millions of invoice entries in each dataset, we utilized a third-party plugin from AG Grid, which the engineers were already familiar with through another project.
Usability Testing
With a mockup to show, now I was ready to reach out to the tax team in Brazil. The tax analysts suggested a number of good-to-have features that were not considered before. Instead of solely focusing on tax checking, the performance-monitoring dashboard could be easily reconfigured and used for workpaper review (another task during the closing phase). The FinTech team was happy to implement those new feature requests, and we were able to expand the T-Rail project scope without a significant increase in engineering effort.
High-fidelity Prototype
As I kept gathering user feedback and engineering input, the mockup gradually became more and more fleshed out. Before long a polished high-fidelity draft was ready. I then connected all the screens together into an interactive prototype. After usability testing with the Brazil tax team to confirm the design, the final deliverable was complete.
REFLECTION
経験総結
T-Rail is a very unique case study in that when I first came onboard, it was not at all in a good place. The project was haunted by its earlier failures and plagued by frequent personnel reorgs. Before me, it switched 3 designers and 2 PMs within a year. By the time I started, many on the project team were new, had different ideas with the project scope, and knew nothing of the complexities of Brazilian taxes. It was safe to say that we were initially dealt with a bad hand. In order to get things going, I needed to quickly navigate through the archival resources left by previous designers, identify work that could be reused and referenced, and familiarize myself with the end users without being able to directly interview them.
However, the somewhat chaotic start also allowed me to take greater ownership of the whole project. Early on, I was able to take up a central leadership role not often seen for designers. As none of us had any concrete ideas of what of solution to build, I engaged with PMs and engineering leaders on an equal footing and explored together. We then jointly worked on scope definitions, and I was able to voice design considerations and impact business and product requirements. I think precisely because of such active UX involvement, we were thus able to overcome the earlier setbacks with user buy-in and ultimately turn the T-Rail project around with a successful product.