Conaliados
Two opposite products in one platform: an app where the credit is requested and a backoffice where it gets approved.
- Role
- Design owner, team of 2
- Duration
- ~5 months
- Platform
- Mobile app · Web backoffice
- Sector
- Fintech · Lending
- Status
- Frozen by budget reallocation
Outcome
We completed the handoff and development started. Before it went further, the company reallocated the project budget to other urgencies and development was frozen. It was a business prioritization call, not a product or design one.
What did remain: a redesigned document validation process, going from one or two days down to minutes, and a design system that became the base for the later work of the team.
The timing figure corresponds to the designed flow and internal testing, not to a production measurement: the project never went live.
Targeted metrics
The business metrics the redesign aimed to move, and under each one the value moving it would have.
Application drop-off
In lending, whoever gets no answer today asks for the loan somewhere else tomorrow. Every long wait is revenue walking over to a competitor.
Time to validate documents
A workday spent reviewing paperwork is a workday without advising or placing credit. The administrator's time is commercial capacity.
Applications handled per day
The administrator reviews applications in series all day. Raising how many they get through is more operational capacity without hiring anyone.
The bottleneck sat before the credit decision.
Conaliados grants credit to individuals and companies through five separate lines. We focused on the two main ones: payroll lending and SOAT credit.
The problem was not deciding whether to approve. It was validating the documents of the applicant: manual, and one to two days long. For the administrator that meant a workday reviewing paperwork instead of advising. For the applicant, a limbo with no idea which step they were on or how much was left. In lending that wait is expensive: whoever gets no answer today asks for the loan somewhere else tomorrow.
Underneath sat an inherited cause: part of the documentation being required had no real bearing on the credit decision.
Design owner on the project.
I worked with another designer, who came to me for judgment and implementation calls. The 2 developers came in at specific points, in the last stretch of the project.
- · The product design system, which I owned directly: foundations, components and their documentation.
- · The visual concept, including the decision to treat the app and the backoffice as two separate languages.
- · Research and flows, from the interviews through to handoff.
- · Both full interfaces, from information architecture to high-fidelity prototypes.
- · The states of applications and credits, including rejection, cancellation with a reason, and traceability of every change.
What was not mine: the credit business rules came from the area running the product, with whom we ran a dedicated consultancy. Implementation belonged to development, and the brand already existed.
Interviews first, then the fine print of the operation.
We interviewed 5 people who had applied for payroll and SOAT credit, and complemented that with a consultancy with someone responsible for managing those credits. That consultancy gave us the fine print of how the operation works from the inside, which no applicant interview could give us.
From there we built the flows for both sides of the product and the information architecture of each. Every decision in the journey was settled on the diagram before opening a screen. Then came foundations, components and high-fidelity prototypes through to handoff.
Two products, two visual languages.
I designed the applicant app and the administrator backoffice as two products with distinct languages: the app more expressive, the backoffice more sober and data-oriented. What I ruled out was a single shared responsive interface, cheaper to build and maintain.
The applicant and the administrator share neither context nor goal. The applicant asks for credit from a phone, almost always once, and needs confidence and clarity about which step they are on. The administrator works seated, reviews applications in series all day and needs to compare and decide fast. A responsive interface would have forced one of them to use a degraded version of the other one.
And the two do not weigh the same for the business. The applicant is the one who signs and the one who pays: the revenue comes from their credits. That tipped the balance on where to put the visual appeal and where it was enough for the tool to be efficient, and it is the reason I argued for keeping two languages instead of a single cheaper one.
The consequence was concrete: the backoffice was built with high density and the table as its main unit; the app, with one decision per screen and progress always visible.
Centralizing the process, not just speeding it up.
The whole process was manual and left no trail: the applicant handed things over at different moments and through different channels, and several people could step in without anyone knowing where each case stood. I decided to bring the full application and disbursement into one place, with traceability on every change, and along the way to cut the fields and documents down to the ones that did bear on the credit decision.
What I ruled out was leaving the chain intact and merely making it faster, the path of least resistance. The administrator's time was not lost going slowly: it was lost on repeated work and on tracking down where each application stood. Speeding up an unnecessary task is still wasted time. This was the change that took document validation from one or two days down to minutes.
Sensitive information gets shown, not hidden.
We prioritized keeping credit status and payment information reachable without several clicks in between, for the applicant and for the advisor alike. What I ruled out was the usual pattern in financial products of burying sensitive data behind layers of confirmation, out of caution.
The advisor needs to answer at the moment the client asks; if they have to navigate three levels to know whether a payment landed, the advice stops being timely. Protecting that data was solved in the authentication and permission layers, not by hiding the information from someone already entitled to see it.
Two journeys over one object.
The flows were how we saw the whole problem before having a single screen to defend. Mapping both sides at once forces you to settle on the diagram what gets expensive later: where the journey branches, what happens when something fails, at which point an applicant decision changes the administrator's work. Only with that picture on the table does screen design become a consequence rather than a bet.
Applying for credit from your phone.
The app solves three things: understanding which products I have, knowing how much and when I owe, and paying. The home opens with pending balance and next payment because that is the question the user opens the app with.
One application, understandable on one screen.
The backoffice is organized by product, and within each product by applications and history. The table is the analyst's main tool: filters by date and status, sorting on any column, and the status always visible as a tag.
The status is the product.
An application can be approved, rejected, resolved or cancelled; a credit can be current or in arrears. Each status changes what the analyst can do on the screen, and cancellation requires a reason and date so the decision stays traceable.
Color and type, with contrast verified.
Foundations are the part of the system nobody sees and that decides everything else: every component inherits whatever gets defined here, and fixing it later means revisiting the whole product. So color was not closed by picking nice values but by verifying combinations: which text can sit on which background, at what minimum contrast, and which pairings were ruled out from the start. Type was defined on the same terms, specified per device so the hierarchy holds up on small screens.
Components documented by state and by size.
The system ended up as a component library in Figma, with its states resolved and put together to be used without having to be interpreted. We only built what the product was actually going to use: every extra component is design, documentation and implementation work someone has to carry, so the catalogue stayed the size of the problem and not the size of an ideal system.
The project belongs to the product of a client, so I share a subset of screens, and the data shown is fictional, generated for the prototype. The full prototype, the flows and the decisions left out I can walk through in a conversation.
What I have applied ever since.
A ramp gets tested against every surface it will live on.
Visually we were proud of the result, but taking the components onto dark surfaces brought up contrast friction we had not anticipated: we defined the ramp by looking at how it read on a light background, the product default, rather than the full range of surfaces it would appear on. Today I check it against every intended background before calling it closed, and that includes the ones the design does not have yet.
In an all-day backoffice, dark mode is ergonomics.
We used a lot of white, and in the backoffice, where the administrator spends the whole day, that is accumulated fatigue. Today I treat it as a requirement of the context of use rather than an aesthetic preference: it weighs on the token definition from day one, because bringing it in later means redoing them.
In financial products, communicating is part of the design.
Working with sensitive data and payments, how the state of information gets communicated turned out to be as critical as the interface. Keeping every party current on the payments due was not a content requirement: it was the function of the product.