From Banking to Startup Agility: Lessons from My UX Journey

Seven years at Zup, designing for Brazil's largest banks — Itaú, Santander, Pine, ABC. Then a move to a fitness SaaS startup in Dubai, serving the Middle East and the US. The switch wasn't gradual. One month I was navigating compliance approvals across four departments; the next, I was shipping features in a week.

Here's what actually changed — and what didn't.

How decisions get made

In banking, a small design change — say, moving a button on the credit simulation screen — needed sign-off from product, legal, compliance, and the business unit. That could mean three weeks before a prototype even reached a user. Testing schedules depended on formal recruitment pipelines and internal approval chains.

At the startup, I can schedule a user interview with a client in the US on Monday and iterate on the design by Wednesday. The team is small enough that a Slack message replaces a formal presentation. That speed changes the kind of risks you can take: instead of betting everything on one heavily-vetted proposal, you can test three rough ideas and converge on what works.

The trade-off: less process also means less documentation. Decisions that took weeks but left a paper trail now happen fast — and sometimes get lost if you're not deliberate about recording them.

What the daily work looks like

In banking, my scope was usually one section of a larger product. I followed strict design guidelines, and presenting a proposal meant building a detailed deck and walking through it in multiple meetings — sometimes over several days just to get alignment.

At the startup, scope is everything. One day it's a new onboarding flow, the next it's a pricing page experiment. Decisions happen in quick, informal conversations, and the expectation is that you bring a solution to the table, not just a problem statement. That demands flexibility. It also means every design decision has a visible, immediate impact — there's no hiding behind a 200-person team.

What carried over, what didn't

The banking years built strong habits around documentation, stakeholder alignment, and structured communication. Workshops, presentations, and written specs weren't bureaucracy — they were the only way to coordinate a team spread across departments and cities.

At the startup, those habits still matter, but the format changes. Instead of a 30-page spec, a one-page brief. Instead of a formal workshop, a 30-minute sketch session. The underlying skill — making design decisions legible to non-designers — turned out to be more transferable than expected. Working closer to developers has also pushed toward more practical, implementation-aware design choices.

The real takeaway

Both environments have genuine strengths. In banking, the reward comes from seeing a feature reach thousands of users after months of careful work. At a startup, the reward is launching something in a week and hearing feedback the next day.

If you're considering a similar transition, here's the one thing I'd prioritize: invest in explaining your design rationale clearly. In a bank, that skill gets you through approval chains. In a startup, it earns trust from a small team that needs to move fast without second-guessing. The skill is the same — the format changes.