I was recently thinking about Mi Retiro Seguro, the tool from Panama’s Social Security Fund (Caja de Seguro Social) for checking your contributions and calculating a retirement projection.
It’s an interesting case because, behind something we could technically describe as “a calculator,” there is a person trying to answer a much simpler question:
How much money will I have to live on when I retire?
#.What the system knows and what the person asks
That person probably doesn’t know the rules of the pension system. They don’t know what the different regimes are called, how contributions are calculated, or which variables go into the formula.
And, frankly, they shouldn’t have to.
That’s one of the differences between building software that works and building software designed for humans.
The system already knows far more than the user should need to understand. It knows our contributions, our reported salaries, the years we’ve worked, and the regime we belong to.
It could ask us to think in those terms: regime, contribution density, base salary, projection assumptions, eligibility rules. All of that matters to the institution. But the person probably didn’t arrive with that mental model. They arrived wondering whether retirement will be enough to live with dignity.
A system-centered interface asks which pension regime you belong to. A human-centered one already knows, or explains it only when it matters.
The user just wants an answer and, maybe, to understand what they can do about it.
The problem is that we often expose the system’s model directly to the user. We organize screens around database fields, business rules, internal terminology, and processes because that is how we understand the system. But none of those things are necessarily how the person understands the problem.
#.From human language to the system
Ideally, the experience should start there:
“This is roughly what you would receive.”
Then:
“This is why.”
And finally:
“These are the things you can still do to change it.”
That last step matters. Useful software should not stop at showing information; it should help the person understand which decisions are still under their control.
The complexity can still be there. It just doesn’t need to be the first thing the user sees.
From human language toward the complexity of the system, not the other way around.
#.And then AI arrives
This becomes even more important now that we have AI around practically everything we build.
Today we can generate a screen in minutes, add another form, build a chatbot, or put an AI assistant on top of a complicated process.
But adding intelligence to an experience that is already hard to understand doesn’t necessarily make it better.
Sometimes we’re just making the complexity more sophisticated.
A chatbot that still requires the person to know the right institutional terminology is not suddenly a good experience because it uses an LLM. It is the same burden, wrapped in a more impressive interface.
The opportunity with AI should be exactly the opposite: letting the software understand more so the user has to understand less.
#.Start with the question
Maybe building human-centered software starts with something fairly simple:
stop designing around how our system works, and start designing around the question the person came to answer.
Before adding the next screen, form, or AI assistant, ask: what question did this person actually come here to answer?