Piraeus Bank · winbank ecosystem

Arriving

Piraeus Bank is the largest bank in Greece. Millions of users, decades of legacy infrastructure, and no tolerance for disruption, because the people on the other side of the screen are checking a balance, paying rent, moving money they cannot afford to lose. I came in through Code.Hub as a product designer and UX consultant, embedded across the UX and Rapid Response teams. The mandate was to modernise winbank, the digital banking platform, across web and mobile, without breaking the trust of the people who depend on it every day.

What I walked into was not one project. It was twenty-seven, running at the same time, across retail and corporate banking, each with its own stakeholders and its own technical constraints. There was no unified design system. The documentation was scattered. Nobody held a single map of what already existed.

Staying coherent when the volume fights you

Twenty-seven parallel assignments with no shared design language is a recipe for twenty-seven slightly different banks. So before I drew anything, I built the smallest thing that would hold them together. A minimal UI kit in Figma, enough to keep the parallel projects consistent without pretending to be a full system I did not have the time to build. I kept every decision in a Notion system, so the next person could see not just what was designed but why. I checked contrast as I went, because in a bank an inaccessible screen is not a polish problem. It is someone locked out of their own money.

This was not glamorous work. It was the discipline of holding a line while the sheer number of things tried to pull it apart.

Blocking credentials, from the one screen you would reach for

One brief has stayed with me. Give users a fast, unambiguous way to block their own access credentials, available right from the login screen, at the exact moment they would reach for it. Someone who thinks their account is compromised is frightened. The old instinct is to bury that action deep in settings, where it feels safe to the bank and useless to the person in a panic.

So I put it on the login screen, and I framed it as something the user controls rather than a failure they are confessing to. The surface was small. The stakes were not. The wrong tone here makes an anxious person more anxious. The right one tells them the bank has their back on the worst day.

The remittance flow that changed how I work

Remittance packages were where I got it wrong first.

The goal was to help users explore, choose, and send prepaid remittances clearly. I designed the first round of prototypes the way I always had, from the experience inward. Then they met the backend, and the backend said no. Constraints I had not accounted for, that made parts of my flow impossible to build as drawn.

That failure changed my process for good. From that point on, every sprint opened with the backend and payments teams in the room before a single screen was touched. What is technically possible, what the systems can actually return, what the regulation requires, all of it settled first. The remittance flow shipped in the end, structured so people met the complexity a step at a time instead of all at once. But the flow was never the lesson. The lesson was that at a bank this size, the constraint is the design, and you find it upstream or you find it the hard way.

What the nine months actually changed

Nine months. Twenty-seven assignments. Twenty projects shipped across web and mobile. Support volume came down as the credential and remittance flows got clearer.

But the change I am proudest of does not show up in a screenshot. The product team shifted from reactive firefighting, where every request was a fire to put out, to a structured sprint cadence with the hard thinking done first. That change outlived any single screen I drew. In an institution this size, the way the team works is the design that matters most, because it is the one that keeps working after you leave.