Player Archetypes in the Age of AI

Player Archetypes in the Age of AI: Why one AI Companion Doesn't Fit All

Designing AI chats? Learn how to turn flat AI responses into engaging experiences using gamification strategies.
  • #Article
  • 13 min read

Gamification works in financial apps. It lifts engagement, pushes feature adoption, moves spending and retention – we went through the mechanics, the archetypes and 20+ real examples in our Gamification Guide for Financial Products.

Then AI assistants arrived and quietly broke a fair amount of it.

The mechanics that used to live in screens, progress bars and menus now have to survive inside a chat window that treats every user exactly the same way.

So the question worth answering: 

How do you design communication in an AI chat when the people on the other side are motivated  completely differently?

Illustration of four player archetypes reacting differently to the same AI co

4 players – 1 voice

In our Gamification Guide for Financial Products we use 4 player archetypes, borrowed from game design and adapted for finance because the same motivational splits keep showing up:

  • Achievers need progress. They want to see something accumulate.
  • Explorers are driven by curiosity. They want to find out what’s inside.
  • Socializers need connection. They experience money as something shared.
  • Killers need competition. They want to know where they stand against others.

Four player archetype cards with key motivations and financial behaviours

3 shifts that change how gamification works in financial apps

When we ran our full UX breakdown of Revolut AIR – 100+ scenarios, including a lot of deliberate off-script poking – one of the most consequential findings had nothing to do with answer quality.

AIR doesn’t open a separate chat per topic. Every question you ever ask lands in the same continuous thread, across days and unrelated subjects.

That’s a reasonable product decision, and it also removes something that used to do quiet work.

In a menu-driven app people stumble into features by accident: you go looking for your statement and find a savings vault on the way. A conversation doesn’t work like that, because it returns what you asked for and nothing adjacent.

Discovery now depends entirely on the system choosing to volunteer something.

The second shift is subtler. Gamification attaches meaning to an action, while an assistant collapses the action into a sentence.

“You spent €340 on groceries” is accurate, useful and completely inert. Nothing progressed, nothing is waiting for you tomorrow, and there’s no reason to come back except need.

And the third: assistant personality is tuned once, centrally, for the entire user base.

Whatever warmth or restraint it has was decided at the system-prompt level and applied to everyone equally. It’s the most uniform layer fintech has shipped in a decade – arriving precisely when the promise on the landing page is personalization.

So the same 4 people now get the same 1 answer. Here’s what each of them actually needs instead.

Achievers

This is the type most financial products already design for, because progress is the easiest thing to build. Goal screens, streaks, savings targets, a bar that fills – if your app has any gamification at all, it was almost certainly built for Achievers.

What the assistant broke here looks like an upgrade: it answers faster, but it answers without history.

The difference in practice:

Same data, three different questions – and three completely different reasons to open the app tomorrow.

For an Achiever the question is never “can I”, it’s “what does this cost my streak”.

We saw a clean version of this in AIR’s savings advice: it estimated potential savings from historical patterns, then recommended a textbook 50/30/20 split. The underlying data was specific and personal. The response was neither.

What to build for Achievers?

State, not just retrieval. The companion needs a persistent view of trajectory – targets set, targets hit, streaks alive, distance to the thing the person said they wanted – and it has to reference that history unprompted.

Retrieval over transactions gets you the first answer. A stored progression model gets you the second.

Explorers

If Achievers are over-served, Explorers are the ones who lost the most when the conversational layer arrived. And this loss is structural rather than a matter of tone.

Explorers are the archetype the conversational layer hurts most.

Explorers find things by wandering. They tap into a screen with no particular goal, discover Pockets or a spending cap or a card control they didn’t know existed, and try it.

A good share of feature adoption in banking happens exactly like this, by accident – which is why findability is one of the 8 usability principles we score products against.

An AI chat has no room for that. It’s linear by design: you ask about coffee, you get coffee, the exchange closes. Nothing in the interface suggests anything else exists, and unlike a menu there’s no visual hint of adjacent territory.

For a user who navigates by curiosity, this is a dead end wearing a friendly face.

The cost of losing this group is larger than it looks, because Explorers are usually your early adopters. They find new features first and tell you whether they work. Design them out and you lose your fastest internal signal, not just some engagement.

Now answers leave a door open.

What to build for Explorers?

For any intent the assistant handles, a ranked list of related things this particular user hasn’t touched yet – offered rather than pushed. That means you need feature-level usage data per user, not only transaction data.

Socializers

Nearly every financial assistant is written in the first-person singular. You spent, your balance, you’re above your average. The grammar itself assumes money is a solo activity.

Socializers are the archetype nobody designs the assistant for.

With this group the failure stops being about motivation and becomes a factual error.

Someone asks how their month is going. The assistant says €1,240, slightly above average. But €400 of that was a group trip she paid for, and 3 of the 4 friends will settle up by Friday.

Her real position is €840 – under her usual. The assistant hasn’t failed to inspire her. It has told her something wrong about her own money, and she knows it.

What to build for Socializers?

A model of shared money: pending reimbursements, recurring transfers to the same handful of people, group goals, and the concept of money that has left your account but isn’t really spent.

Most of the signal is already sitting in the transaction data – the same 5 contacts appearing over and over, splits, round-number payments that come partly back. It just isn’t modelled as a relationship.

Killers

Every metal card scheme in fintech is a Killer mechanic keeping a straight face. Tiers, status, leaderboards – this archetype is well understood in product design and almost entirely absent from conversational interfaces.

Killers are the archetype with the most upside and the most risk.

Assistants answer in absolutes. €200 saved, €1,240 spent, 12% above average – and “average” here almost always means your own average, which gives this person no external reference point at all.

Without a benchmark there’s no position, and without a position there’s nothing at stake.

What to build for Killers?

Cohort comparison: anonymised peer groups by income band, age, city or life stage, plus a way to express position that doesn’t require exposing anyone else’s data. This is more of a data and compliance problem than a design problem, which is why so few products do it well.

With no comparison, Killers read 1 answer and leave. With badly built comparison, you get something worse than churn.

Ranking people by financial behaviour in a regulated product needs careful framing – cohorts rather than individuals, context rather than shame, and no comparison that manufactures a reason to transact.

There’s a real line here between motivating someone and pressuring them, and the difference usually comes down to whether the nudge serves the customer’s goal or the quarter’s target.

How to find out who you’re talking to?

Behaviour is the most honest way, and most of these signals are already in your data:

  • Achiever – sets an explicit goal and returns to check it, and tends to open analytics after a large transaction rather than before.
  • Explorer – opens screens without completing actions, asks the assistant open-ended questions like “what can you do”, and shows high feature touch with low feature depth.
  • Socializer – a meaningful share of activity is P2P, splits, or repeated transfers to the same small group of people.
  • Killer – engages with anything comparative, and responds to percentile framing where absolute numbers get ignored.

Mapping of in-app behavioural signals to 4 player archetypes

There’s a genuine advantage hiding in all this, though.

The conversational format flattened these differences, but it’s also the cheapest probe anyone has ever had. Almost nobody is using it that way, which is strange given how much gets spent on segmentation elsewhere.

Offer a comparison once and see whether it lands. Drop in a discovery nudge and watch whether it gets taken. A menu can’t ask anything – a companion can, and it can adjust within the same session based on what it learns.

2 things to be careful about:

  1. Don’t lock someone into a type after 3 signals. Motivation shifts with context and circumstances – the same person is an Achiever about a savings goal and a Socializer about a group holiday.
  2. Keep the adaptation visible enough that a person could notice the tone changed and ask why. A system that quietly reshapes itself around you is a hard thing to defend, to users and to regulators.

Where to start?

Everything begins with understanding which user archetype you’re actually talking to. You can’t adapt your AI’s responses if you don’t know who is on the other side of the chat.

To help your team move from concept to implementation without starting from scratch, we created a practical toolkit:

If you’re tackling this challenge right now, we’d love to compare notes and share what we’ve learned from testing with real users.

Link copied to clipboard