Finding out who our small-business customers actually were

TL;DR

• Context: The only UX designer responsible for the small-business segment at a retail bank (~160K customers).
• Problem: Nobody knew what groups were hiding among ~160K customers, so UX work had no specific audience.
• What I did: I built personas based on what money actually flows through the accounts. The result was 8 personas: 4 industry segments at 2 income levels.
• Result: 6 groups make up 75% of customers and 80% of inflows. Later I used the same method to forecast overdraft sales.

Diagnosis

Personas are usually made in a conference room. A few interviews, sticky notes on the wall and a catchy name. The trouble is they’re easy to ignore, because they sound like a designer’s opinion. We had ~160K small-business customers and nobody knew who they actually were. So no UX work could be aimed at a specific group. I based the personas on data the whole bank trusted: how much money came into and went out of the accounts, broken down by industry.

flowchart TD
    A["~160K small-business customers"] --> B["6 groups<br/>75% of customers / 80% of inflows"]
    B --> C["2 groups stay separate"]
    B --> D["4 of 6 groups merge into 2"]
    C --> E["4 industry segments<br/>2 separate + 2 merged"]
    D --> E
    E --> F["x 2 income levels<br/>lower ~5-6 decile / higher 7+"]
    F --> G["8 personas"]

    classDef neutral fill:#f0f0f1,stroke:none,color:#3f3f46,rx:14,ry:14
    classDef info    fill:#e9eff8,stroke:none,color:#1e3a5f,rx:14,ry:14
    classDef accent  fill:#27272a,stroke:#3f3f46,stroke-width:1px,color:#fafafa,rx:14,ry:14
    class C,D neutral
    class A,B,E,F info
    class G accent
    linkStyle default stroke:#a8a8b3,stroke-width:1.5px

What I did

• I divided ~160K small-business customers by the industry they work in (the PKD code, Poland’s public classification of business activity). For each group I checked two things: what share of customers it makes up and what share of monthly inflows.
• From 6 groups I derived 8 personas: 4 industry segments, each at 2 income levels.
• I used the segmentation to pick research participants and to match products to businesses with large money flows.
• I used the same method to forecast overdraft sales. The forecast matched actual sales.

Results

• 6 groups make up 75% of customers and 80% of inflows. Behind the general label “small businesses” there was a fairly concentrated structure.
• 8 personas: 4 industry segments at 2 income levels. I merged four of the six groups into two, so that product teams and researchers could actually work with it.
• The richest customers behave differently. Inflows grew roughly in proportion to company size up to the 7th–8th decile, and then jumped sharply. That’s why I split customers into two income levels (lower ~5th–6th decile, higher from the 7th up), so the largest ones could be served differently.
• A sales forecast. I used the method to forecast overdraft sales based on how each group uses credit. The forecast matched actual sales.

The problem

What did we actually know about our small-business customers?

Almost nothing structured. The bank served ~160K such customers, from sole proprietorships to small companies, but treated them as one mass. There was no segmentation, no map of industries, and nobody knew where the money really was. When you’re responsible for UX, that’s a big problem. You don’t know whom to invite to research, you can’t tailor products, and nobody has an answer to “who are we building this for?”.

Why not just do five interviews and call them personas?

Because personas built on a few conversations are the first ones people stop believing in. They look like a designer’s opinion. I needed something product managers, analysts and the business couldn’t just wave away. So I based the personas on data they already trusted: transactions.

My role / scope

• I led the analysis and all the thinking behind the method: what data to pull, how to split it and what each group means. The method is mine.
• I didn’t have direct access to the database. An analyst wrote SQL queries based on my guidelines. I came up with the questions, and the analyst pulled the numbers.
• I was the only UX designer for the small-business segment. I worked with product managers, development teams and a separate team of UX researchers.

Process

• Splitting by industry. I divided ~160K customers by their PKD code. For each group I checked what share of customers and what share of monthly inflows it represented.
• Looking for structure. Six groups gave 75% of customers and 80% of inflows. Four of them were similar enough that I merged them into two. Four clear segments remained.
• The richest customers. When I drew the chart, I saw that inflows grew roughly in proportion to company size up to the 7th–8th decile, and then jumped sharply. So among “small businesses” there was a group with much more money. I split each of the four segments into two income levels: lower (~5th–6th decile) and higher (from the 7th decile up). Same industry, completely different amounts. That’s how the eight personas came about.
• What customers do with their accounts. In each group I looked at how customers actually use their account. A few things clearly stood out (I’m deliberately keeping this general). In one group mobile payments dominated regardless of company size. In another, roughly every third larger company took a credit line, paid it off and took it again. Yet another opened deposits much more often than the rest.

The final structure: 4 industry segments at 2 income levels.

The sharp jump at the end of the chart is why each segment has two income levels (illustrative shape).

Key decisions & trade-offs

• Personas from data, not interviews. I have to admit we lost something. Interviews give warm, human details that data doesn’t have. In return, the personas could be defended and reproduced, and nobody could dismiss them as “a designer’s opinion”. We kept doing interviews, of course, but now we knew whom to do them with.
• Four segments instead of six, then two income levels. I could have kept all six groups. I merged four into two because, in my view, a segmentation nobody can remember doesn’t help anyone. Four segments was the maximum. The two income levels gave eight personas in a simple layout: four industries times two levels.
• Two income levels, because the chart showed it. The sharp jump wasn’t my assumption; it came out of the data. Splitting into a lower level (~5th–6th decile) and a higher one (7th decile and up) let us treat the richest customers separately instead of folding them into an average.
• My questions, the analyst’s queries. I had no access to the database, so the analyst pulled every number based on my guidelines. My work was the method and interpreting the results, not writing SQL.

How it turned out

The personas became the basis for work with the whole segment. Three uses mattered most. First, we finally invited people from the right industries to research, not whoever happened to pick up the phone. Second, offers for businesses with large money flows went to the four matching segments, in a version for the lower and the higher income level. Third, I used the same method to forecast overdraft sales based on how each group uses credit. The forecast matched what customers actually took. In my experience, a UX method that predicts revenue is very rare.

The forecast from a UX segmentation method almost matched actual sales (illustrative values, anonymized segments).

What I took away

• A persona is worth as much as the data it stands on. Sticky notes on a wall are easy to ignore; transaction data isn’t. Once I based the personas on real money, the rest of the bank started taking them seriously.
• The data suggests how to split customers. I wasn’t looking for a group of the richest customers. It showed up by itself when I drew the chart. It’s worth looking at the data first and only then deciding on the groups.
• A segmentation has to be usable. I merged six groups into four segments, because a map nobody remembers is just decoration.