Flow Cauciones -
InvertirOnline

Stakeholders flagged that cauciones — one of the platform's core investment instruments — only existed on the web. Users who worked exclusively through the app had no way to access it. The ask was simple: bring it to mobile. But before designing anything, we needed to understand how users actually used the web flow — and whether just replicating it would be enough.

These weren't feature requests. They were signals about where friction would show up on mobile.

Then we looked at the data.

We analyzed heatmaps and quantitative behavior across 732 screens over 1 month on desktop, and 134 screens on the responsive version.

Desktop insights:

The pattern was the same across platforms: users don't want to configure — they want to confirm. The default behavior was the dominant behavior. That became our design principle.

To add qualitative context, we ran 3 short interviews with active web users. Not statistically significant, but they consistently reinforced what the heatmaps already showed: users wanted speed, 'use all' was essential, and the app felt like a gap in their workflow.

We also audited 3 competing apps (Cocos, PPI, Taurus) to understand how the market structured the same flow — and set a benchmark for step reduction.

That finding reinforced the decision to pre-select 1 day as the default — not because it was the minimum, but because the data confirmed it was the optimal behavior for most users. Removing that decision from the flow meant users got the best outcome without needing to understand the math behind it.

It also surfaced a future opportunity we flagged during the project: an automatic daily caución feature that would reinvest returns on the user's behalf every day. The smart default was the first step toward that vision.

Working within real constraints

This project involved constant back-and-forth with the dev team to figure out what was actually feasible — and those conversations directly shaped some of the design decisions.

The clearest example: the term selector. My initial proposal was a calendar picker — more intuitive, clearer visual mapping between dates and days. Dev flagged it as significantly more expensive: it would've required a brand-new component. The more pragmatic path was to reuse an existing dropdown already in use across the product. We negotiated. The result was that existing dropdown — cheaper to build, no new component — but with one key addition I pushed for: the day of the week shown alongside each date.

This wasn't just an aesthetic preference. In a financial product with market hours, the date you think you're investing isn't always the date that counts. If you initiate a caución after market close on Thursday, the operation executes on Friday — so "3 days" becomes ambiguous. Showing "3 days — Sunday" gives the user the information that actually matters: not an abstract number, but a concrete moment in time. A small addition that resolved a real point of confusion without requiring any new infrastructure.

That tradeoff taught me something I apply consistently now: the goal isn't to win every design decision — it's to identify which details actually matter for the user and hold the line on those, while being flexible on everything else.

In a financial product, that visibility directly affects whether the user actually completes the transaction. Uncertainty at the amount-entry step is where hesitation happens. Removing it before the confirm button reduces the cognitive cost of committing.