The interface is where the problem becomes visible, not where it begins
Why senior product design work requires understanding systems, not just screens.
By the time a problem appears in the interface, it has usually travelled a long distance.
A confusing button is rarely just a confusing button.
Same goes for a broken dashboard or a messy onboarding flow; it rarely is just a broken dashboard or just a messy onboarding flow.
The screen is where the organisation’s unresolved thinking finally becomes visible enough for everyone to complain about it.
That is why I am increasingly suspicious of design conversations that begin and end at the interface. Not because the interface is unimportant. The interface is where the user meets the product’s judgement. But it is also the last visible layer of a much deeper system.
When a product feels confusing, there is often a hidden chain behind that confusion: unclear business rules, competing stakeholder priorities, poor data models, weak permissions, mismatched incentives, operational shortcuts, engineering constraints, legacy decisions, compliance anxiety, support gaps, copy that sounds like it was written by a committee trying not to offend a spreadsheet, and occasionally, a founder who wants five different products in one tab.
You can make that tab prettier.
You have not solved the problem.
This is one of the sharper lessons I have learned across fintech, education, agricultural platforms, learning tools, and operational systems. The more complex the environment, the less honest it becomes to treat the UI as the primary site of design.
The interface is evidence.
The system is the crime scene.
I learned this in practical ways, not theoretical ones.
At Farmcrowdy, what looked like screen problems were often model problems. The product had made a marketplace promise, but the interface kept absorbing questions that should have been settled in the operating model: farm status, sponsor confidence, update cadence, accountability, harvest timelines, fulfilment realities.
In education, a coach cannot understand a learner’s progress simply because the data exists somewhere. The data has to be organised around the decisions a teacher or coach actually has to make.
In youth finance, a parent cannot trust a child’s financial product if the permission model does not reflect how families actually negotiate responsibility, which in a Nigerian household can look very little like the consent flows imported from American family-finance apps.
In fintech, a support team cannot resolve complaints quickly if the product was designed only for successful flows and treated exceptions like rare events. In fintech, exceptions are not a footnote. They are half the work.
In operational software, a manager cannot act on a dashboard if the system knows that a task exists but does not understand the state of the people, dependencies, and handoffs responsible for the next action. The work may look fine on screen while the reality of the floor is on fire.
In each case, the interface is only the surface wound.
Senior product design begins when you stop asking only “what should this screen look like?” and start asking “what underlying truth is this screen failing to represent?”
That question is less glamorous. It also makes you more annoying in meetings.
A designer who only asks for better visual hierarchy may be useful. A designer who asks why the hierarchy is incoherent in the first place is more dangerous, and therefore more valuable.
This does not mean every designer needs to become a product manager, engineer, operations lead, data analyst, and amateur therapist for organisational dysfunction. That would be absurd, although some weeks at any startup do try their best to turn you into all five.
It means senior design requires systems literacy.
You need to understand how decisions move through the product. Where data comes from, who creates it, who trusts it, who ignores it, and who gets punished when it is wrong. How roles and permissions reflect power. What support teams hear every day that product teams conveniently forget. How business models shape user experience. A product that makes money from speed will make very different trade-offs from one that makes money from accuracy, trust, retention, compliance, or habit.
This is one of the more useful gifts of studying Computer Science with Economics at OAU. It was not a glamorous combination. Half my classmates seemed destined for only one of two paths; engineering or banking. But being one of the few ones who picked design mean the pairing has served as a constant reminder my whole professional career, that every system has incentives and constraints at the same time. Software is just where they collide visibly.
You need to understand that “simple” is not a visual style.
Simple is a successful compression of complexity.
And compression does not mean the same as deletion.
This is where many products go wrong. Teams decide that because something is complex, the user should not see it. So they hide it. They remove labels. They flatten states. They turn meaningful distinctions into generic statuses. They pretend every edge case is an edge case until the edge becomes half the usage.
Then the interface looks cleaner, but the product becomes less truthful.
A clean lie is still a lie.
The best interfaces are not the ones that hide complexity most aggressively. They are the ones that reveal the right complexity at the right moment, in the right language, for the right person.
This is especially true in emerging markets and operationally messy contexts. Many imported UX assumptions collapse because they were designed for stable infrastructure, predictable institutions, individualistic usage patterns, constant connectivity, and relatively high-trust environments.
What happens when users share devices?
What happens when internet access is intermittent?
What happens when financial decisions are social, not purely individual?
What happens when screenshots become a parallel documentation system because users do not fully trust the app’s records?
What happens when an “admin” is not a neat role, but a teacher, manager, accountant, operator, customer support agent, and unofficial fixer depending on the day?
What happens when the person using the software is not the person who bought it, configured it, trained others on it, or takes the blame when it fails?
These are not edge cases. They are design conditions.
If the system does not account for them, the interface will eventually confess.
I think this is why I have become more interested in what sits behind the screen. Data structures. Decision rights. Operational workflows. Permission logic. Service recovery. Trust cues. Content models. State design. The boring but necessary ways products maintain coherence under pressure.
I still love a well-made screen. I care about layout, typography, rhythm, hierarchy, interaction, visual language, and the small satisfaction of a flow that finally stops fighting the user.
But the screen is not the whole work.
Sometimes the correct design move is not a new component. It is a deeper conversation about the product model.
Sometimes it is changing the sequence of a workflow because the current order only makes sense to the company.
Sometimes it is splitting one user role into two because the system has been pretending different people are the same person.
Sometimes it is adding friction because an obsession with speed can unwittinglyy create risk.
Sometimes it is removing a feature because the product is trying to solve an operational problem the organisation itself has refused to own.
This is the part of design I find most compelling now. Not decoration. Not Dribbble theatre. Not the performance of innovation through gradients and rounded cards.
The real work is making systems intelligible.
A good interface says: here is what is happening, here is what matters, here is what you can do, here is what happens next.
A good product system says the same thing at a deeper level. It aligns the user’s task, the business rule, the operational reality, the data model, and the technical possibility closely enough that the interface does not have to keep apologising for the system.
That is the standard.
Once you see it, you cannot unsee it.
Every confusing screen becomes a question.
Where did this confusion begin?
That is where the real design work usually lives.