TOMS Design System

Overview

At InvestNext, sponsors managing real estate investments needed a way to set preferred returns that actually matched how deals work in the real world, like rates that change, distributions that don’t always match what’s accruing, and start dates that shouldn’t have to be set investor-by-investor. The existing system couldn’t handle any of that gracefully.

How do we let sponsors reflect real-world deal terms without breaking the math investors depend on?

My Role

As the lead product designer on this feature, I owned the end-to-end design of class-level preferred return settings, including the compounding interest option. I worked closely with the product manager and lead engineer throughout the build, staying involved through the dev process and into testing after beta to make sure the design held up in practice, not just in Figma.

A Flat Rate Wasn’t Enough

Before this update, sponsors could only set one flat preferred return rate per class, with no clean way to change it over time. That’s not how real deals work. One client, for example, had set an 8% preferred return but needed to actually pay investors 6% for a stretch of time. There was no way to reflect that without either breaking the math or manually adjusting every single investor’s numbers by hand.

Dates were just as brittle. Sponsors had to manually set the preferred return start date for every individual investor in a class, one at a time. And a related setting, at the hurdle level, could unintentionally override and wipe out prior calculations.

The Core Idea: Decouple What’s Owed from What’s Paid

The insight that unlocked the design was treating accrual and distribution as two separate things. What a sponsor owes an investor (accruing, potentially compounding, over time) doesn’t have to move in lockstep with what actually gets paid out.

Once those were separated, sponsors could set a class-level rate, choose whether and how it compounds, and adjust real-world payments independently, without the system losing track of the underlying math.

Designing for Clarity, Not Just Capability

Early testing surfaced a subtle but important usability issue: two different entry points on the settings page led to the same compounding settings modal, which read as a bug even though it wasn’t. I resolved this by removing the redundant link, so there was one clear path in rather than two that quietly did the same thing.

I also introduced class-level date settings, so sponsors could set a preferred return start date once for an entire class instead of investor-by-investor, saving meaningful setup time on every deal.

Built Around Real Sponsor Behavior

Testing with sponsors surfaced patterns that shaped the design: most weren’t using date-specific hurdles, pro rata splits almost always came last in a waterfall, and sponsors tended to over-complicate distribution plans in ways that scared off investors looking for something simpler. Design decisions leaned into favoring sensible defaults and clarity over exposing every possible configuration.

Impact

Since this shipped recently, we don’t have hard KPIs yet. Early signals from sponsor testing were strong, though: sponsors specifically called out the compounding option as a standout, and one client with month-to-month rate variability described it as solving a problem they’d been working around manually for years.

A More Honest System

What started as a request to support a wider range of preferred return terms became a deeper shift in how the platform models real deals. By decoupling accrual from distribution, sponsors got a tool that could flex with reality instead of forcing reality to flatten to fit the tool.

More Case Studies