The Truth of The Thing
A talk on conceptual accessibility being fundamental for adoption, while discussing mistakes I’ve made.
Introduction
Hi, I’m Ricardo Méndez, and I’m Samsung NEXT’s Technical Director for Europe, where we are making venture investments on technology innovation, and running the Stack Zero Grant to help fund research and open source projects around decentralization.
That’s not what the talk is about, but I’ll be happy to chat about it after.
Now, this talk could just as easily have been titled Mistakes I’ve made, because in the end, that’s what it ended up being about.
I’m going to talk about lessons learned that, had I learned them earlier, would have made things much better not only for me, but for the people I was building software for.
The short version is:
- When building something, the underlying technology and principles should be solid, but it’s not all about tech;
- Access and understanding go beyond usability;
- Lack of either access or understanding deepens inequality; and
- We are running out of time.
But I’m getting ahead of myself.
There’s this bit by Max Planck that I feel encompasses a lot of discussions I end up having with people about crypto and decentralization.
I’m just going to give you the quote on its entirety.
“A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grow up that is familiar with it.”
– Max Planck
I mean, that’s a great line. Max Planck would have killed it at social media.
I believe this encapsulates well how we like to feel about change. It means that if you’re in the right side of history, or backing the correct platform, you only need to wait until enough evidence builds up, until enough people are familiar with your solution, and the world will prove you right. People who don’t get it will eventually go away.
This view, however, has a fundamental problem. It conflates those who oppose you with those who don’t understand what you are aiming for.
These people here… these are not opponents of a new system who need to see the light.
These are just potential users, non-technical people.
They are my parents, now in their 70s. And I don’t think we could sell them on any of the stuff we’ve built.
Backstory
I’ll explain why in a moment, but first, let me give you a bit of background.
Anyone here who’s Latin American?
If so, I’m sorry. I’m sure you’ve seen this thing play out a few times.
Bear with me here for a bit. This will likely be a familiar story, as it’s happening all over again. An editorial titled How Bitcoin Saved My Family came out when I was making my slides.
If you haven’t read it, do so. It’s a visceral piece by Carlos Hernández, a Venezuelan economist, talking about how digital, permissionless money helped his family when things went to hell.
The case I’m going to tell you about was not as much of a sudden apocalypse as Carlos’ was. For us it was more of a creeping doom scenario. It happened a while ago, but I can only talk about the one I lived through.
I’m from Costa Rica. Back in 1978, we got a new president. He came into power by and large to popular acclaim, stating “I’ll seize power with humility”.
You can almost hear the narrator commenting “He did not”.
First two years were calm enough, then in September 1980, the economy tanked.
Coffee was our major export. Its prices plummeted to a third. Oil prices were soaring. By the time he left power about 18 months later, the dollar had more than quintupled in price compared to the colón. It would continue to slide from there on future administrations, losing about 15%-30% of its value a year.
It wouldn’t stop there, either. The slide has slowed, but it never halted or reverted.
Anyone here who holds crypto knows what it feels like to see 80% or 90% of the value you hold evaporate.
Now imagine that this isn’t happening just to some new form of money which you directly control and made a choice to use, but to the very thing you’re used to relying on, to the salary that is supposed to support your family. And you already have barely enough to make do, nevermind invest or speculate, because it’s not like high-school teachers are landed gentry.
It gets worse! Now imagine … your house’s mortgage is in dollars.
Congratulations, you now owe five times as much!
These changes in the economy would also have a significant impact on social equality.
If you only earned colones, it didn’t matter if you had managed to save a little bit, your holdings evaporated.
If instead you were one of those people who could afford to have savings in dollars, and your mortgage was in colones… chances are you just got your mortgage paid off at a really nice discount.
And holding dollars before things went down was important, because the first thing in the playbook when this kind of thing happens is controlling access to foreign currency.
Now I wonder… what could my parents have done if back then they had programmable money? How would things be different if this whole thing played out now?
They were in their 30s, so… younger than I am now. Even so, I don’t think they would have easily figured out our morass of applications and platforms.
They were history and civics professors, non-technical. Nowadays, that’s the equivalent of someone who is comfortable using WhatsApp on a daily basis but doesn’t really get the whole “security code changed” thing.
They were also both working full-time jobs (which luckily, made the economic aspect of things a bit easier for us), but that means they spent their days preparing lessons, grading tests and assignments, navigating complicated situations around national patrimony projects, and raising two kids.
(Yes, I’m still doing the hands-on-hips thing)
In their situation, I don’t think I’d have a lot of mental bandwidth at the end of the day for sorting out Bitcoin vs. Ethereum vs. zCash, or that’d I’d remember 24 words in a foreign language a year or two after generating a seed.
These tools… they could have been available, but they wouldn’t have been accessible to me on time.
That deepening inequality I mentioned? We risk this happening again now, between those people who have access to tools and understand them, and those who don’t.
Mistakes I’ve made
Which leads into the mistakes I’ve made.
I’ve always prided myself on being someone who uses technology to solve problems.
And yet, with that background, I didn’t actually stop and ask myself until a few years ago “what could have made things different?”.
Having grown up in Latin America, I sort of accepted that this kind of thing happened. It was like the weather - you can’t change it.
But even with the weather, we can help others to be prepared.
So here are the mistakes I made. These weren’t exactly mistakes that I made in sequence. Some of them overlapped in time.
This is not just about getting them off my chest. I’ve been at this for a bit, and see other developers going through the same process over and over, so hey - the lessons might be useful for you.
Tech, not problems
For a long while I focused on technology, not problems.
This is an obvious one. We’ve all run into cases which are a solution looking for a problem. And while it’s easy to decry those from the outside… it feels much different when you are involved.
When you are the one building the tech, and you find the process of building things fascinating, it can be really hard to get perspective.
So I spent some time convinced that “the tech is the thing”. Building things because they didn’t exist, or were a cool area to tackle and I could build them.
I only started addressing problems after hitting my head against a few walls, but it took a few years of head-hitting for me to get there.
What I learned was that I hadn’t realized what my actual job was.
Nowadays, when someone asks me for advice about leaving whatever company they are in and striking out to build their own thing, the first thing I ask them is: “what is going to be your job?”.
The answers are usually the same: “to build X”, “to write code for Y”, “to address problem Z”.
Those are only correct in the sense of the activity they will be performing.
It misses that, whatever field you are working on, your end job is to keep the user happy, and writing solid code is only one aspect in that.
Which kind of tangles in with the next one.
Stability, not usability
This is a case of how our early experience colors our perspective.
Because as it turns out, when all you have is an obsession with computer science everything looks like a systems architecture problem.
I actually started my career making end-user tools.
Usability matter, but I didn’t really have to think about it myself that much. We were making small tools for Windows 3.1 which used poorly documented functions and the rather “permissive” memory management to integrate with applications across the operating system.
Stability was paramount, because if you made a mistake, you brought down the whole house and killed whatever the user had been working on for hours.
From there, I went on to build systems for banks and financial institutions. You can imagine how that caused me to double-down on taking my mental bandwidth further away from usability.
The obvious thing to have done here was to have someone along who only focus was usability, so that we could keep both in mind. This is common sense now, but… I don’t think we even used the word back then.
And yet, while usability is important, there are trade-offs to account for in there as well.
Usability, not comprehensibility
This one here… this is a big one. It bit me for a few years.
This is a major issue, because increasingly these systems we build have become a central nervous system which mediate people’s access to the world.
They are a lens, and a lens imposes a certain perspective. We need our users to understand what that perspective is, so that they know what is being left out of the picture.
If we don’t, then we are going back to the days where only a priesthood had access to or knew how to use computers. I’d rather we don’t.
We are obsessed with making things frictionless, since that helps with adoption, but frictionless doesn’t mean accessible.
In our efforts to smooth edges, we are making systems more usable but less comprehensible. This is only surface approachability.
True accessibility means something beyond ease of use.
Accessible means that our users can approach the truth of the thing.
If we don’t design our systems to be accessible, comprehensible, we are just asking users to trade a set of overlords for a hopefully more decentralized one.
We shouldn’t pretend that these things are chat apps that store money, or on the other extreme, banks you control, even if that would be an analogy our users would understand.
This would be doing them a disservice. Analogies beget mental models, and the mental models that they have built for these other things do not apply. These decentralized systems make different trade-offs - that’s the whole point of building them.
We like to talk about economic freedom, giving people control of their money, their data.
These are great goals.
But we can’t just tell them we give them control of their data, we need to explain what that means and what the trade-offs are, because a system you can use but don’t understand isn’t accessible - it’s a conceptual black box.
I realize that this might seem to be at odds with the whole spiel about not building a priesthood who actually understood every bit about a system. It’s not an either-or situation, but more like a gradient.
I do think there’s a requirement of understanding some fundamental facts of a system, but we need to sort out what these fundamentals are.
The key question to address here is:
Which aspects could cause irretrievable damage to a user who doesn’t understand them from the start?
When talking about wallets, a fundamental is the fact that if you lose the key, nobody is going to retrieve it for you.
A fundamental is that having the key and passphrase are the only authorization required.
A fundamental is that these are not credit cards, so they are non-reversible if someone gets your key - you don’t get to make a claim for a refund.
The technical specifics behind those might not be fundamental, so we don’t need to bother our users with them. But these fundamental things should be up front and center.
Problems, not people
Finally, there’s this one.
Addressing a problem in the abstract became a crutch.
I stopped doing it years ago, fortunately, but didn’t put a name to it until recently, when I listened to a sensational talk by Bruce Lawson on accessibility, standards and more importantly, the effect of our platform choices on people. I’m not going to repeat his whole thing, but I strongly recommend you watch it.
Because I started this talk mentioning the people I was building software for, but then left that aside. That is emblematic of a lot of projects I ran.
To directly quote one of Bruce’s points:
You need to see people, not problems.
Censorship is a problem. Frictionless money transfer is a problem. A dependence on central authorities is a problem.
And I know, it’s preferable to solve problems than to just build cool tech because nobody has built it before.
But you need to keep in mind who will be using this tech, whose problem you will be solving, because in the end their actual day to day situations are different.
We need to remember that we are in no small way privileged, if for no other reason that we know more about these technologies than the people who will be consuming them.
How those problems manifest for us here, those of us who can afford to come to Paris for a conference, is different from how they manifest for other people.
People in a country whose mining hardware might be confiscated if the government realizes they have it.
People working abroad, tired, just trying to send money back home regularly, more concerned about the chunk that the Western Union fee takes out than about a (for them) academic degree of decentralization.
People like my parents, unaware of the size of the truck that’s about to hit them, trying to figure out what to do when their money is worth less every day and their debt increases automagically.
Because the truth is…
This is no longer about waiting for people to grow up with digital money or decentralized applications. There’s no massive contingent out there opposing this anymore. It will happen.
There are situations where people have an immediate and pressing incentive to make a switch, where switching is very much an issue of life and death, like in Carlos’ case in Venezuela.
Those will be the easy sells.
But there are also the insidious cases, the situations where it could help people who don’t yet realize how bad things are going to get.
In those cases, people will make the switch to a new system early only if it is easy for them to do so.
Even if the thing that underlies this system might be the future.
Chances are, what you are working on is that future.
I’m not saying this to pump you up, or encourage you, or embolden you.
I’m saying this to put the fear of god into you.
If this is the future… People are going to end up living with the decisions you make.
Because I’m more and more convinced that we can’t afford to wait until crypto and decentralization creep into the general consciousness to sort these things out.
Someone will eventually figure out enough usability issues and users will flock in. Most of them will stay with the first solution that actually solves their problems in an easy-to-understand manner.
And if it is not you… well, there’s Facebook.
They already have a massive installed base. There is such a thing as inertia.
And as a privacy advocate, that is terrifying.
You will need to out-execute them, because it doesn’t matter how technically superior, uncensorable or more decentralized other solutions are, the code is not the only thing.
And I believe that a key part of this is to make sure your users understand your tool better than what they feel they understand anything else.
You will need to keep your users happier than they keep them.
So please, make sure that whatever decisions you make, help them understand the truth of whatever it is you have built.
Published: 2019-03-10
