Here’s a recurrent complaint I hear in my design work on blockchain teams:
Dude have you tried putting money in Coinbase or setting up a Metamask account or buying a token on ICO? It’s so clunky! Crypto’s got so far to go!
I keep thinking, “That might be true, but …
Have you ever tried to explain “investing” to anyone new to it?
Have you ever read all 97 pages of funky tables that is your credit report?
Have you ever sat alone, set up a brokerage account, and tried to figure out how to get money into an ‘equity product’ - let alone which one?
Ever register a business bank account? Remember getting your first credit card? Have you ever tried to get a mortgage? Split a freakin’ bill among 3 people?
Clunky, all of it. Confusing, messy — and often proprietary. Using money means understanding multiple systems, all of which rest on vague concepts like equity, amortization, fractional banking, etc. No wonder crypto confuses people:
Money, on its own, is an abstraction layer.
As a financial coach who’s worked with several hundred people alongside my technology day jobs, I’ve recently found myself asking: What’s the onboarding path to using money?
As a thought experiment, below I outline the experience of someone in the US interacting with money from childhood, as if we were exploring their journey with a product or service, to reveal some of the challenges in blockchain and fintech design — and money itself.
When I’m working on design strategy with product teams, I ask questions like:
- If you were to address one of these problems, how might people’s experience improve?
- Can you identify the easiest to solve pain points? (we tend to find high-value feature opportunities here)
- What about the hardest to solve pain points? (we tend to find high-value product or service ideas with this one)
- Who in particular are you thinking of, and can you get information directly from them about this problem?
- What assumptions are you making about someone’s motivation for or experience of using this?
Speculative Money Journey Debrief
If I was to answer some of these questions as they relate to the onboarding path to using money, I’d have to decide how to contend with technical issues, emotional barriers, and/or cultural norms around money.
I’d want language to define the “money experience”, but I’d push back on vague words like “value” and ask for specific pains or gains our user was experiencing: security, hunger, fear of survival, comfort.
I’d need to dig into the assumptions embedded in any expected user action versus the path the user was actually taking, so I could ask why they were doing A when we hoped they’d do B.
I’d need to name and explore the context of their experience to identify and understand why they bothered to use it. In the case of money, we might need to unpack class paths, income as related to local cost of living and need, work and jobs,
And, in the case of money, I’d need to help the team figure this out for everyone under the sun and their mother.
Everyone’s money onboarding and initial experiences are different, often incomplete, and tied to big emotions like desire and fear. And each person still has to use it. Is it any surprise that there’s a divergent set of responses and pathways to using money?
This method reveals some problems people have both with using financial products AND concepts within our economic system itself. Perhaps we may wish to ask: what’s the onboarding process to consumer capitalism?
Refining our question allows us to name our assumptions around someone’s experience, and pain/gain goals.
If we assume that our user wants to spend money casually shopping for goods or services we see a different pathway than for a user we assume is reticent to spend. Our designers and engineers will need to know “why” at every step of the way to produce something people want to use.
… and that reveals a core assumption worth exploring: assuming that people want to use money.
Money is a complicated and culturally-loaded proxy: its use refers to other goals.
Before you get to technical solutions (an app with less friction, a more values-aligned investment product, an improved bank service experience) a key problem space we find is: use of money is not optional yet tied to survival.
Money use is a mandatory universal, even though how and why people use it is wildy heterogeneous. In this way, money is partially a civic product, the result of a combined development effort by governments and a public demand (for reliability, trust, interoperability). Money is of course currently co-developed with private entities, each of whom have their own motivations.
In my work as a financial coach, people I work with often speak about experiencing a set of similar technical problems, based in differing motivation, personal context, and emotions around their use of money. People struggle to technically solve these issues not because they’re inept at numbers, but because they believe money is hard.
In my work with developers and designers working on blockchain products and fintech solutions to economic problems, there’s an interest in adoption of crypto or tokenized solutions. It’s incredibly challenging.
I believe part of the adoption complexity of blockchain development is because money, as used in mandatory consumer capitalism, is an intersectional problem space that reveals a massive set of system failures and problems for a large number of users.
To truly understand the problem space our users are operating in as related to financial technologies, one has to explicitly talk about the failures of economic systems at a high level and the common, recurrent pains people experience as a result.
We must name that we’re in a system rife with assumptions, such as: extraction of profit is always good, shopping is meaningful, people wish to devote their lives to earning money.
We find ourselves exploring massive areas of failure like unbanked individuals, consumer debt, stagnating wages against cost of living.
As I proceed to work on human-centered design in blockchain technologies, I am keeping these questions in the back of my mind, so when we dig into the problems our users have, we’re exploring better questions: