Designing app features to make housing less painful

TL;DR

Problem

One of the largest banks in Slovakia wanted to help people with housing through their app — something no competitor had. The catch: nobody, including them, knew what that something was.

My role

I led the project end-to-end: managing stakeholders, executing the research, co-leading client workshops and brainstormings, and designing the final prototypes myself.

Solution

Instead of guessing, we let real customer problems drive the process. Interviews surfaced the pain points customers live through — and once the homework was done, what to design became much clearer.

Outcome

The client received 3 functional, user-tested prototypes ready to present to the board and hand off to development. There was, however, a major complication.

The problem

One of the largest banks in Slovakia came to us with an unusually honest brief: "We want to focus on helping people with housing. We want something in our app that nobody else has. We don't know what it is." That's it. Just a direction and a blank page.

The thing I genuinely hate in product design is inventing features at random, based on what some board member happens to like. It almost always produces something that solves no real problem, brings the customer zero value, clutters the interface, and then has the audacity to ask for money.

A product should do the opposite: solve a concrete problem people actually run into, and dismantle the specific barriers that stop them from adopting the solution. So that became our contract with the client. We won't guess. We'll find out.

My role

I led the project end-to-end. I managed the client's stakeholders, executed the customer research, co-led the design-thinking workshops and brainstormings, and finally designed and tested the prototypes myself.

Step 1

Find the real problem first

The very first thing we did was run in-depth interviews with the bank's customers about everything housing-related: searching for a home, renting, taking out a mortgage, renovating, financing a renovation.

We walked through how each of these processes actually went for them. What stressed them out, where things broke down, how they dealt with it, and what they wished they'd had in that exact moment.

Step 2

From stories to behavioral personas

From the interviews, we distilled the themes that kept repeating, and looked at which types of customers they repeated for and what those people had in common.

That's how we built behavioral personas: people grouped by the problem they were solving, not by demographics. A 28-year-old renter and a 45-year-old homeowner could land in the same persona if they were fighting the same battle. Each persona's core struggle became a sharply defined problem statement.

Step 3

Workshops, brainstorming, and prioritization

With the problem statements in hand, we ran a series of design-thinking workshops with the client, brainstorming solutions for each one. Then came the filtering. Together we assessed every idea on three axes:

  1. Customer impact — how many people does this help, and how much?
  2. Business value — does this actually bring the bank new business?
  3. Feasibility — can this realistically be built, or is it a fantasy?
Step 4

Prototyping and testing with real users

I designed three of the selected features as fully clickable, functional prototypes. Due to an NDA, I can only describe them in broad strokes:

  1. Property viewing assistant — a feature guiding people through property viewings.
  2. Mortgage refixation helper — supporting customers around their mortgage refixation.
  3. Housing companion — a complete guide accompanying people through their entire housing journey.

I then ran pilot UX testing with real users on all three prototypes and reworked them based on the feedback.

The results & complications

The client walked away with 3 finished, user-tested prototypes ready to be presented to the board and handed off to development. More importantly, every one of them was anchored in a real, validated customer problem.

And then reality hit. The board prioritized other activities and the budget went elsewhere. We offered to help build the case for the board, but the client preferred to handle it internally. So for now, the features sit parked in the bank's backlog.

What I learned

With an internal design team, framing comes before the work. At the first meeting I noticed they were skeptical. An external designer walking into their team, presumably to explain their own job to them.

I eventually made it clear I was there to help, not to audit, and things loosened up. But I did it too late. Some of them stayed closed for the rest of the project. Now I say it in the first five minutes.

Liked what you read and want to know more about how I work?

Get in touch