Onboarding, daily operations, permissions, states, edge cases. The operational layer of a Mexican B2B banking platform — designed end-to-end across mobile and web.
Cero comisiones. CLABE para cobrar. Tarjeta. Todo desde tu teléfono.
Esto define cómo abrimos tu cuenta.
Frente primero. Todas las esquinas dentro del recuadro.
Tus datos están encriptados.
Mira a la cámara y parpadea cuando te lo pidamos.
Confirma que eres tú.
Te tardaste 9 min 47 seg.
A business banking product isn't a feature set. It's an operational system that has to behave correctly across many client types, many states, and many edge cases — most of which the user only sees when something goes wrong. That's the design problem this exercise focuses on.
Plata's banking license unlocks B2B. The market is 4.5 million Mexican SMBs, mostly underserved by incumbents and partially served by competitors that each own one slice — Konfío owns SMB credit, Clara owns expense management, Clip owns acceptance. Nobody owns the operational bank. The V1 designed here is the foundation that makes everything else possible.
A business account isn't always "active". It moves through nine states across its lifecycle, each with different permissions and different UI affordances. The state machine is the source of truth — every screen renders from it, not from a hardcoded happy path.
A bank that only works on the happy path is not a bank. The screens below show how three common failure modes resolve into states the user can act on, without ever exposing an error code or a dead-end.
Se ve borrosa o le falta una esquina. Inténtalo otra vez con buena luz.
Tip: apoya la INE sobre una superficie oscura.
Tu información está completa. Necesitamos un par de horas para confirmar todo.
Te avisamos por WhatsApp en cuanto esté lista.
Each edge case follows the same three-beat structure: state the problem clearly, show what we already know, offer the single most useful next action. The OCR case offers retry plus an alternative document. The review case shows progress, not waiting. The card freeze case respects the user enough to ask whether the suspicious activity was theirs — and protects the money first.
Onboarding is one day. Operations are every day after that. Four flows account for roughly 90% of the daily sessions in a typical business account: receiving, sending, categorizing, and reconciling. Each one is designed to be a single tap from the home screen.
Two compounding decisions in these flows. First, the Pagar list orders recipients by recent frequency, not alphabet — because Mariana pays the same five vendors every month, and an alphabetical list buries Café Olmedo in a flat directory. Second, categorization is auto-suggested but always editable — the system makes a guess, the owner corrects it once, and the system learns. Small operational details. Big effect on daily session friction.
Mexican accountants work on desktop. They serve 20–50 small businesses each. The web console is built for them: a multi-client list, read-only access to each client's account, exportable to the formats their software actually uses. Same backend as the mobile app. Different permissions enforced server-side, different UI rendered client-side.
| Fecha | Concepto | Categoría | Monto |
|---|---|---|---|
| 28 may | SPEI · Juan Pérez | Venta | +$1,500 |
| 27 may | Café Olmedo SA | Sin categorizar | −$8,200 |
| 26 may | SPEI · M. Hernández | Venta | +$420 |
The "Solo lectura" badge is visible at all times. Hidden, not greyed, are: sending money, managing cards, closing the account, inviting users. The accountant can categorize movements (which is useful for them), but they cannot dispute them — that's reserved for the owner, who has the legal authority.
The mobile app and the web console share the same backend, the same state machine, and the same design tokens. They differ only in permissions and in the affordances that surface from those permissions. That's what makes the system maintainable when V2 introduces employees, V3 introduces auditors — each new role is a new column in the permissions matrix, not a new product.
This case isn't styled in a vacuum. Every token, type scale, and component comes from Menura DS — the design system I built for my own SaaS company. Bringing a mature system into a new product is faster than reinventing one each time, and it forces consistency across everything I ship.
Plus Jakarta Sans + DM Sans + JetBrains Mono. Warm orange brand ramp + stone neutrals. 8px spacing grid. Generous radii. Subtle shadows. Motion tokens for ease-out / spring / smooth. Built for my own product. Applied here to a banking case study because a real DS travels.
Three composition layers: primitives ship once from engineering. Patterns compose primitives. Flows compose patterns. New products extend the primitives — never replace them. The same Button renders an active "Send SPEI", a disabled "Send SPEI" (when frozen), and a destructive "Confirm freeze" — by switching tokens, not components.
Plata — российская компания, строящая банк в Мексике. Это редкое сочетание, и оно совпадает со мной: я свободно говорю на русском, английском и испанском.
Каждый пункт в описании вакансии — то, чем я занимаюсь каждый день: сложные B2B-продукты в финтехе, веб и мобайл одновременно, нативные паттерны iOS / Android / web, матрицы прав, состояния, edge-кейсы и собственная дизайн-система, на которой я строю свой SaaS. Этот кейс — две недели соло, с чистого листа — показатель того, как я веду задачу целиком: от ресёрча до DS. Я подхожу под эту роль не на 80%, а полностью — и мне действительно хочется делать этот продукт вместе с вами.
Full research and design documents available on request. Or DM me on LinkedIn — I'll send links to the research doc, the MVP design doc, and Menura.