Marketplace tax and duty management

Context

Marketplaces need to make it easy for merchants to sell luxury goods internationally by calculating and collecting the right amount of duties and taxes for each shipment of products to customers. These fees vary by product type (leather boots vs handbags) and origin and destination country, and sometimes have complex rules based on price thresholds.

For the magic to work, marketplaces have to know all these rules, and keep up with the changes each time a country updates their policies. But this is a large task and very difficult to do manually accurately.

The marketplace I worked for partnered with a data provider to integrate a feed of more accurate rates, but since this affects revenue, there needs to be human oversight and traceability of any changes made.

The challenge

The goals were to reduce human effort, error, and to increase the accuracy of fees charged so that the marketplace neither collects too much or too little compared to what they actually have to pay to the carriers like DHL each month.

The design challenge was to figure out a user interface for reviewing millions of rows of incoming data. Users should approve only what's applicable to the business model. Since this was a brand new datasource, no one knew what it would be to work with and what features the tool would need.

Kickoff

I inherited this project when I became a design lead for the area. And it became clear to me that it was not going so well.

The team were stuck waiting for the stakeholders (the tax team) to tell them their requirements. But since they'd never worked with this data feed before and weren't experts in designing software they couldn't do this. It also wasn't even clear who the users would be. Until someone defined a new process no one wanted to commit to doing it. It also crossed several team's areas: the tax team, responsible for the financial policy, and the logistics team responsible for actually collecting the money correctly.

I visited Portugal and ran a workshop where we did some Event Storming with the expected users to understand their current process and design together their ideal process, with this new datasource, at a high level. This gave us all a much clearer picture of the system we should be aiming for, and where we had uncertainties.

Modelling

For the next couple of months the project ticked along with new iterations of designs being produced, but the tax team were still struggling to say whether the designs met their needs or not, and what was missing.

Things were stalling. The company's process is very waterfally, putting us in a catch-22: we can't decide the design without building something to try it out, and we can't build something without finishing the design.

I also realised that the work was happening at too high a level. We were having conversations about screens and flows but were not at all aligned on the underlying concepts. What is a charge? what is a rate? are they different? what granularity of decision do users need to make?

I started to define some concepts and map out their relationships, starting first with engineers to ensure I was defining concepts that were compatible with both the existing system and the new datasource.

I focussed not only on the objects and relationships but also the actions users would need to take. This caused us to invent some new concepts such as a 'policy' (a decision about a certain charge, with a proposer and a reviewier) and a 'context' (the most granular scope a decision needed to be made: import country, export country, charge type and sub-type).

This created a foundation on which to build new designs to test with users.

Prototyping

Now we were getting somewhere but a Figma prototype wasn't going to get us the learnings we needed when dealing with a large complex dataset. But because of the catch-22 above, we can't seem to start writing software.

I asked for a sample of the data to a CSV and built a rudimentary prototype in Google Sheets. Each row represented a decision we believed the team would need to take, and I made a dropdown in the sheet of the choices we believed we needed to offer them. I gave them the task to try processing 10 rows and tell me where they get stuck.

They succeeded, with a few small problems. This gave us confidence we were on the right track. And for the first time the users also understood what the system was going to do and what kind of work they'd need to do as well.

Interaction design

Staffing issues meant I needed to take over the design myself, which was probably a good thing for the project because I'd led the concept modelling and prototyping and had a lot of context.

From now it was a fairly standard interaction design challenge resulting in a data-table-like view that guided users to what needed processing and let them make descisions in bulk on sets of rows.

Several rounds of usability testing got us a design we felt good enough to start building.

Event storming again

An architect facilitated another Event Storming session, much more detailed this time.

This produced an architecture and API that was perfectly aligned to the design. That had often been a challenge at the company. The APIs were usually designed separately from the screens, giving us only CRUD operations to work with and limiting what's possible for the user, or creating slow, buggy experiences when bulk actions are needed.

The details

We split the project into slices to estimate and build, and then I did some just-in-time detailed design of each slice, adding to the design system where necessary.

The outcome

I left the company before it was fully rolled out. I think it took over 18 months to conceive and build the first slice. But I can see that it's one of those complicated, but fairly well-understood domains where mission-critical engineering takes time and planning.

I believe I helped this project avoid disaster by figuring out a workable concept model and prototying with a spreadsheet.