Unidos
por Ellxs

Unidos por Ellxs coordinates disaster response in Mexico: it connects volunteer brigades, companies and communities before, during and after an emergency, and it is where the donations that fund that response arrive.

Unidos por Ellxs is not a single organization. It is a coordination platform that sits on top of a civil society association, and it shares its public surface with a business-resilience programme aimed at small companies. Three names, three audiences, three different reasons to visit — all of them arriving at the same homepage.

The audit scored the existing site 4.5 out of 10. But the score was not the finding. The finding was that the problem was one of message before it was one of design: the homepage was simultaneously trying to establish institutional authority for someone who had never heard of the organization, and to persuade someone already convinced to donate. Those two jobs pull the same screen in opposite directions.

The architectural decision that unlocked the rest was to stop treating the homepage as the place where donations happen. Cold traffic — someone who found the organization through search and does not yet know who it is — needs authority and transparency. Warm traffic — someone redirected from a campaign post about an earthquake that happened yesterday — needs the shortest possible path to a completed donation.

The separation was pressure-tested in a session with the digital team at UNICEF México, who reported that their redirected traffic must not pass through an intermediate landing page — their donation interface collapses context and form into a single screen. One nuance mattered: they have a media budget that guarantees pre-persuaded traffic, and this organization does not. The separation still applies, but for a different reason.

The practical consequence for development is the part that survives past this redesign: the donation interface is a reusable per-campaign template, not a new page built each time an emergency happens.

The individual donor's job turned out to be the one that governs the homepage. It is not "give money" — it is closer to converting anxiety into something verifiable. The push is a worry with nowhere to go; the anxiety that stops the action is where does my money actually end up; and the inertia is that sharing a post on social already feels like having done something.

That reading is what makes Transparency a page rather than a block. It answers the donor's main anxiety head-on, and it doubles as due diligence for a company evaluating a partnership.

The process rule on this project is that structure and copy get approved before the design system is applied to anything. It exists because the alternative — showing stakeholders a beautiful screen and asking them to react to the words inside it — reliably produces feedback about the colour of a button when the argument of the page is what is broken.

The load-bearing line of the hero is "before, during and after the emergency." That phrase is what separates this organization from the ones that only appear during the crisis, and it was written into the wireframe rather than left to be discovered later.

An organization that asks strangers for money during a disaster cannot afford a number it cannot defend. The rule on this project is absolute: no figure ships without a verifiable source and a date. Applying it honestly meant discovering how much of the available material did not survive it.

So the prototypes annotate themselves. Every figure without documentary backing is wrapped in a red dashed outline directly in the mockup, which turns the design review into a data review at the same time. Three items are currently held back that way: a headline percentage of spend going to programmes, which comes from an internal draft rather than a financial statement and carries the highest reputational risk on the page; the organization's stated years of operation, awaiting confirmation for unqualified public use; and the use of three partner brand marks, awaiting written authorization. A fourth is an open contradiction between two internal figures for the same count of mobilized brigade members.

None of them are in the shipped copy. The red outlines are the reason.

The architecture, the wireframe and three homepage directions are done. The design system exists as tokens and components, the production bundle is generated, and none of it is deployed — because the process rule says the design system is not applied until structure and copy are approved, and that approval is sitting with two stakeholders. The payment integration is written and installed as a plugin with its own database table and endpoint, and it is blocked one step earlier, on credentials for the payment account needed to run the sandbox test. Sandbox first, production second; that order does not get skipped to make a status report look better.

What I'm proud of: the bifurcation. It reframed a redesign request into an architecture decision, and the reusable donation template means the next emergency does not start from a blank page. What I'd do differently: the volunteer job is still an assumption with no research behind it, and I documented it as one rather than designing confidently on top of it — but I should have run those interviews while the wireframe was waiting for approval instead of treating the block as idle time.