Patrimonio Hoy

CEMEX microfinance for self-builders: they asked for UX training, I ran a workshop that changed their premise.

Problem: CEMEX asked for UX training so their team could design a payments app. They believed late payments came from members not knowing how much to pay, or where.
Bet: Skip the course. Three days of co-design, with the six decision makers in the room.
My work: I facilitated the workshop, built the prototype, and we tested it with real members. The app shipped. Promoter turnover, the real cause, was never addressed.
Stance: Putting technology on top of a broken process costs more than fixing the process.

Seen over a person's shoulder, a phone shows a payment screen for 500 pesos with OXXO, debit card and bank transfer as options, held up in front of an unfinished cinder block house.

The team wanted an app to collect payments. Members were not falling behind for lack of places to pay.

CEMEX Mexico approached me to teach UX. The Patrimonio Hoy team, the microfinance program that lends to families building their own homes, had won an internal innovation contest and wanted to design their own app with what they learned.

I did not know yet what problems they had. I did know that a course would leave them with a layer of technology on top of processes nobody had examined. I proposed three days of co-design, with the decision makers in the room.

A digital board with the workshop questions grouped into six teams, each marked with an animal, every question on its own yellow sticky note.

Getting six people from 65 problems to one goal

The general manager, logistics, the team that deals with members, and Construrama, which supplies the building material, all went through interviews. They arrived with 78 questions and a wall of 65 challenges. By the end of the first day they had voted it down to one goal and three questions.

The goal they agreed on assumed something that was not true. The team was convinced a payment app would fix the late payments. The confusion was real. So were the payment points: OXXO, supermarkets, and correspondent agents. What was failing was the communication between the program and its members.

The team changed its mind in the vote

Each participant sketched a solution. Of the six, five proposed support or visibility. On the only payment one, someone from the same team handwrote a question: “Will it only be card payments?” The person who owned the idea answered on the note beside it: the member could download a barcode and pay at a correspondent agent.

Sketch of a three-screen phone flow: a list screen, a message screen and a checklist, taped to the workshop wall.

Sketch of a three-step phone flow with a calendar icon and a sticky note, taped to the workshop wall.

Sketch of a phone flow with a home icon, a materials grid and a detail screen with navigation arrows, taped to the workshop wall.

Sketch of a phone flow with a title screen, two arrows pointing to a home icon, and a list screen, taped to the workshop wall.

Sketch of a two-screen phone flow, a form screen above a list screen, taped to the workshop wall.

The six sketches went to a vote, and the flow that won puts payment at step three of six. The rival flow was payment from start to finish. The same people who had asked for it voted it down.

Illustration of a member sitting on a construction block, looking at her phone. — The member signs in with her member number and password.

Illustration of a member standing in an unfinished room near a window, looking at her phone. — The member checks her next payment date and how her payments are tracking.

Illustration of a member paying at a corner store, phone in hand, while the shopkeeper holds a card reader. — The member pays through the app and gets a receipt.

Illustration of a member at a construction site with a builder in the background, looking at her phone. — The member schedules a housing advisory visit or a material delivery, follows up on it, and checks the details of her build.

Illustration of a member standing on a street next to stacked building materials, looking at her phone. — The member rates how the scheduled service went, an advisory visit or a material delivery.

Illustration of a member with another person outside a house under construction, looking at a phone together. — The member follows up on promotions, perks, and past messages from Patrimonio Hoy.

The handwritten objection became a screen

With the flow agreed, the team drew eight screens and pinned decisions on top: payment options, the advisor’s rating. The payment screen carries the barcode receipt, the handwritten answer from the day before.

I brought the order. The decisions came from the people who would run them.

Wireframe of a sign-in screen for the app, labeled “Wireframe 1”, with account number and password fields.

Wireframe of a balance and progress screen, with sticky notes for general data and a customer-journey step.

Wireframe of a payment screen with balance and progress, sticky notes asking what payment options it should have and about paying by card.

Wireframe of a visit-scheduling screen with a calendar, sticky notes about a date picker and which day the member can be visited.

Wireframe of a chat screen with an advisor named Ricardo, labeled with a sticky note reading “Chat con asesor”.

Wireframe of a materials catalog screen with a search bar and product cards, sticky notes about material selection and photos.

Wireframe of a screen with promotions and requests, sticky notes about member-only promotions and general feedback on the visual design.

Wireframe of a delivery address form, sticky notes about the delivery date and confirming the address.

Seven phone mockups fan out on a dark background, showing screens from the prototype: account balance, a materials catalog, sign-in, a payment screen, a visit-scheduling calendar, a delivery rating screen, and a product detail screen.

The sprint ended in a prototype, not a document

I turned those eight screens into a clickable prototype and tested it with five of the program’s members. Actual members, not employees standing in for users.

Three of the five members had no bank account

All five completed the flow without help. Three of them had no account at any bank.

Mexico’s ENIF 2018 survey, run by INEGI and CNBV, reported 39% account ownership in towns under 15,000 people, where the Patrimonio Hoy member lives, so the sample was not unusual. That note someone wrote by hand turned out to be the right call: the prototype does not force payment inside the app.

They were the ones who brought up promoter turnover

The promoter signs members up and follows up with them. Turnover came up in the workshop, and when that person changes, the relationship breaks with them.

The chat screen shows the advisor by name and rated, as the team had drawn it, so the member had someone to ask. It is a product answer to an operations problem. It helps, it does not fix the cause.

I moved away from the brief, but not far enough

I prototyped assuming the architecture was there: scheduling with the advisor, connecting to Construrama’s ecommerce, taking payments. I stand by it: a sprint validates what the user wants before asking the system whether it can. The cost is real, a prototype like that can promise what the company cannot build.

The mistake was mine too. I moved away from what they asked for, and still not as far as the problem needed. The app shipped and the turnover stayed.

carlos@cabras.co linkedin.com/in/carloscarrascoe