ReclamaAI and VantFi serve people who traditionally aren't the audience for premium digital products. Most are Colombian adults in income brackets 1 to 4, with mid-range phones, limited data plans, and a relationship with technology that's more utilitarian than enthusiastic. Designing for them forced me to unlearn most of the defaults I had internalized.
Assumption 1: "the user has good wifi"
In Bogotá, Medellín or Cali, average home wifi is decent. But the moment someone pulls out their phone to solve a problem with ReclamaAI or VantFi is rarely from their living room. It's on the bus, in a waiting room, on the street, at a notary. It's mobile data, unstable connection, LTE dropping in tunnels.
Practical implication: every important action must be disconnect-tolerant. If the user starts filling out a petition wizard and loses signal, data saves locally and syncs when the network returns. Otherwise, the user abandons and never comes back.
Assumption 2: "the user will read the tutorial"
Designing onboarding tutorials is fun and satisfies the team. But the reality is almost nobody reads them. People open the app, try to do what they need, and if they can't in 30 seconds they close it and find something else.
This changed how I design first screens: there is no tutorial. There's a first screen that is the main product flow, with reasonable defaults, no preliminary steps. If the user needs help, there's a discrete button. But the happy path by default requires reading nothing. The metric that matters: how many users complete the main action in their first session with no assistance at all?
Assumption 3: "more options is better"
The standard US SaaS philosophy is: give the user power, give them options, give them customization. But for someone using an app for the first time, every option is a decision, and every decision is friction. Analysis paralysis is real, especially when money or a legal procedure is at stake.
In ReclamaAI, the wizard has 4 steps. Each step has aggressive defaults: if you're drafting a petition, we already chose the most likely target entity based on the problem type, the most common format, the tone. If the user wants to change anything, they can. But most don't — they want to be done.
Assumption 4: "the user understands technical English"
There are words digital products assume everyone understands: dashboard, account, sync, beta, KPI, features, settings. For a good chunk of our users, those words are noise. Some understand them, others don't, and nobody will admit it.
We systematically replace: dashboard → "summary", sync → "update", beta → "test version", features → "what it does". It's boring work but the difference in how many people complete their tasks is huge. Internal rule: if it's a word your non-technical family wouldn't use over the dinner table, we don't use it either.
Assumption 5: "the form has to be beautiful"
Forms designed for premium SaaS have floating labels, animated validation, microinteractions. They look gorgeous on Dribbble. In practice, for someone filling out forms every five years, those details are confusing. Why did the word go up and shrink? Did I delete it by accident?
We went back to a fixed label above the field, separated, with large text. No animation. The field grows when it gets focus, but the label doesn't move. It's less visually elegant, and much more understandable. Choosing between beauty and comprehension is easy when you remember who you're building for.
What's still hard
There's a tension I haven't resolved: how to make a product that looks professional and serious (because people trust things that look cared-for) without falling into unnecessary complexity. The partial solution has been obsessing over typography, spacing, and consistency, while simplifying copywriting and flows. The visual conveys competence; the copy conveys calm. You need both.