Five different labels for the same task. The constraint was real: we couldn't change the backend. The question was whether design could absorb what the system generates and keep it invisible from the people who have to use it.
HDFC's internet banking interface exposed five different labels for accessing account statements — Download Statement, Request Statement, Historical Statement, View Statement, Transaction Summary — because the data lived on five different backend systems, each with its own rules about what it could return and when.
From the user's perspective, they wanted to see their transactions. That's one task. From the bank's infrastructure perspective, it was five different tasks depending on date range, account type, and data source. The interface had faithfully reflected the infrastructure. The user was carrying complexity that the system had generated.
Systems carry the complexity from their constraints and burden the users with it. The question is always: who should carry it?
We could not change the backend systems. This was not a negotiable constraint. The five data sources would remain five data sources. The routing logic — which system to call based on what the user was actually asking for — could not be eliminated.
This is the constraint that defines most enterprise design work. The backend was built for operational and technical reasons that had nothing to do with the user experience, and changing it would cost orders of magnitude more than redesigning the interface. The question was whether the routing could be absorbed at the design layer rather than exposed at the user layer.
The answer was yes. Move the routing logic to the system level. Give the user a single entry point: a date selector. They choose the date range they want. The system figures out which backend to call — or which combination of backends to call — to return the data they need. The user sees one label, one interaction, one result.
Before — exposed to user
User must know which of five labels maps to what they want
After — absorbed by design
System routes to the correct backend based on date range. User enters dates and sees results.
The routing logic was not eliminated — it was hidden. Behind the single date selector, the system still needed to determine whether the request fell within the recent transaction window (one backend), the medium-term period (another), or the historical archive (a third). Multiple backends might need to be queried and their results merged for certain date ranges. The user saw none of this. They entered a date range and got transactions.
The deliverable was HTML wireframes — live, in-browser prototypes that demonstrated the interaction design at five responsive breakpoints: Mobile 320px, Mobile 480px, Phablet 540px, Tablet 768px, and Desktop 960px.
This was early responsive design — before responsive frameworks had standardised the practice. Designing for five breakpoints meant making explicit decisions at each one about what information appeared, in what order, and how the interaction model adapted to the available space. The date selector that worked as a horizontal row on desktop became a stacked control on mobile without losing its fundamental interaction.
HTML wireframes rather than static mockups meant the client could experience the interaction in a real browser, navigate the states, and understand the system's behaviour rather than infer it from a static image. They are also safe to show — the wireframes are distinct from production screens, and the live site has changed significantly since this work.
Every project at HFI reinforced the same insight from a different direction. The Standard Bank IVR was structured around the bank's product categories rather than the user's mental model. HDFC's statement section was structured around the bank's data infrastructure rather than the user's task. In both cases, the system's constraints had been faithfully translated into the interface, and the user was carrying complexity they had no reason to carry.
Good design doesn't eliminate the underlying complexity — it absorbs it. The routing logic still runs. The five backends still exist. But the user doesn't know, because they don't need to know. That's the job.
This is the same pattern that appears at every scale of the work since: clinical protocol lifecycle hiding infrastructure complexity from clinicians, agent operating systems hiding tool calls from humans, AI companions absorbing conversational signal without asking the user to explicitly track their wellbeing. The complexity doesn't disappear — it moves to where it can be handled properly.
The core move