Tax Harvesting for Wove Financial Advisors
SaaS • Fintech • Figma • Prototype
SUMMARY
- Financial advisors depend heavily on financial models to help with harvesting tax losses and gains.
- I designed an accurate, end-to-end workflow that was immediately used for sales demonstrations
MY ROLE
Lead designer, collaborating with: multiple product leads and dev manager
The important of tax harvesting for advisors
Tax Harvesting is a strategic move that financial advisors can make for their clients’ portfolios. The advisor can opt to sell some securities at a loss (i.e., sell a fund that was previously bought at a higher price point, but now currently trading at a lower value), all to offset some of high tax on any capital gains realized at end of year.
The tax harvesting flow needed to allow three primary paths to the advisor:
- They needed to be able to sell an account or sleeve and simultaneously be able to select or confirm a replacement financial model to buy instead.
- For some accounts, they could manually search for a replacing account, provided it was not the same or nearly the same (which would be considered a wash sale).
- Alternatively, the advisor could opt to leave the funds from the sale as cash with the understanding of allowing 30 days to pass (also to avoid a wash sale).
Complications included advisors needing to batch-process hundreds to thousands of accounts at time
The initial brief also didn’t consider the need to allow a user to make model replacements during this flow. Ideally the replacements should already have been selected en masse over in the Model Enrichment area of the platform.
I prodded at the question of what would happen if the advisor didn’t have a replacement model ready, and determined they would have to exit the entire tax harvesting flow. And since I found that wouldn’t be an uncommon scenario, I considered it too interruptive to force task abandonment and added needing a solution for that to the requirements.
I pieced together the user journey to reflect the required primary paths, along with the gaps and overlaps I found
Another issue? We couldn’t show everything
Advisors would be working with huge tables of data. Initially I wanted the chosen model replacement feedback to be 1-to-1. But there was no way to show how each piece of data would map to the other without simply showing way too much disparate information.
Several iterations that received positive feedback from product but that were ultimately put aside because they simply couldn’t scale
Additionally, the system wouldn’t validate until the request was sent
Apart from the excessive data, the true validation would occur once the data requests were sent to Model Enrichment, then fed to Order Review, which was the review stage before final execution, i.e. “you bough it and can’t take it back.” Mapping a previously-elected replacement was one thing; but mapping it along with any extra parameters indicated in the form was another.
The major issue: at this rate, the advisor could be making orders for hundreds of tax harvest events and merely hoping replacement models were already set
The Order Review stage would be the “catch-all,” so user could always go there and double check. But for hundreds, maybe thousands of orders? I was certain they needed more feedback than checking through a huge table at the very end. I ran through the scenario several times with my product lead and another Senior designer to help convey the risk of error and breach of trust in the order process.
My simple solution was a new data point on the tax harvest table: “Model Replacements”
Since the system could at least verify whether a replacement had been selected for a given account, I placed it as a single corresponding point in the table: the data column titled “Model Replacements,” with the possible values of Yes/No/null.
There being a replacement model available could now be confirmed at a glance at the table; additionally, I designed so advisors could select the value in the column and the hyperlink would prompt an immediate selection in-page.
Crucially, this solution would allow for in-flow selection of model replacements without having to stop in the middle of tax harvesting clients’ losses.
Something I kept pushing for: a “partial pass” alert
Elsewhere in the Trading app I had designed for a similar use case of advisors requesting orders or swaps on hundreds of accounts. In that case, a “partial pass” alert was given because of the high probability that at least some of the selected accounts wouldn’t meet all of the swap qualifications.
Similarly, I wanted to give the user an additional chance at understanding that not everything went through as expected, and they should take another look at their order post-validation.
Valuable development pushback I received centered around mixing account types
My developer counterpart and I repeatedly met to iron out technicalities, one of which included the mapping of both model and brokerage accounts. He advised that the back-end system would not be able to process this “mixed” order type. So I had to reconsider how to present a binary path up front for users, so they wouldn’t become frustrated at an arbitrary error.
The design importantly aligns with our platform’s big value add
The “switch-cost” associated with stopping and re-starting tasks can weigh heavily on our clients’ daily workloads. The tax harvesting flow helps to contribute to Wove’s value for financial professionals: an interoperable platform that doesn’t force advisors to stop in the middle of tasks in order to sync all their data sets.
