#112 A rose...
...is a rose.
How to present a technical feature to users, abstraction in a way, is big part of UX design and building products in general. You don’t really need to know how your car works, you just need to know how to turn it on, steer, rules of the road, etc. When you bookmark a webpage, you don’t literally place a bookmark in between two pieces of paper like you do in a book.
This type of conversation comes up regularly in Bitcoin Design. Over the weekend, I got separately pinged about how to present VSS (Versioned Storage Service) and LSP (Lightning Service Providers) options to users. Recently, questions came up around how to communicate lightning channel reserves and BIP-353 Human Readable Addresses.
For the latter, I quickly wrote down some thoughts in Discord that I’ll copy here. Not a 100% solid framework, but it’s a start. So how do names come about?
Naming often starts at a technical level. Creators need to refer to their work somehow. Sometimes it’s a very descriptive name (like Versioned Storage Service), or it describes a design goal (Human Readable Addresses), or otherwise (Silent Payments, Payment Codes, Payjoin, Liquidity, etc). I propose that those names should in no way be expected to be user-facing. They might end up being, but there should be no expectation.
When a technical feature is implemented, teams often have an internal feature name. Maybe it’s called “Project Tango”. It will make sense to the people who work on it.
Catchy-sounding public-facing feature names are often used for marketing. You call high-resolution screens "Retina screens" because it sounds cool and is abstractly representative (pixel density matches what your retina can detect). Different projects might come up with different names for the same thing, which can cause confusion when users try to compare products or interact with multiple ones.
UI labels are what the user sees in the interface. Often it's 1-2 words, maybe with an extra descriptive sentence. Here we need to be very practical and communicate effectively. If we use potentially unfamiliar terms, we need to make sure we explain them ahead of time or give a way to access an explanation. People with all kinds of backgrounds and levels of expertise need to make sense of these.
People build their own end-user mental models of what is what and how things work. There are different levels of abstraction to this. To me, Taproot addresses and BOLT12 offers all fall into the general bucket of "addresses". In my own brain palace, I can distinguish deeper into onchain and lightning addresses, and assign properties like re-usability, expected fees and confirmation times, etc. But maybe others can't distinguish that since they have less technical understanding in that specific regard. So let's say you call them "Bitcoin address" and "Lightning address", you're already collapsing one level of association. Or thinking of the conversation around "external signer" (preferred by technical peeps because it's more precise) and "hardware wallet" (recognized term by users). Wallet vs keychain is another one of those evergreens.
In user interactions, like when someone wants to pay someone else and asks for an address. This is a bit like a negotiation, where the mental models of two people need to be bridged super effectively and it's great if they have been exposed to a common language. When I quickly need to pay at a grocery store, it would need less thinking if I saw "Instant address for low amounts" and "Slower address for high amounts", because my job to be done is that of quickly paying. Even easier if I have a dedicated wallet for small, fast payments (separate from my savings product). But this is of course where it gets really messy because there are infinite unique situations. User research and prioritized user stories can help find a good approach.
Whether these categories are perfect or not, the most important thing is to be aware about which realm you are discussing. Without distinguishing, it’s easy to discuss in circles, or talk past each other (aka mismatched communication modes).
In my update last week, I also posted about naming:
outbound liquidity → send limit
inbound liquidity → receive limit
open channel → increase send limit
purchase channel → increase receive limit
Why does this make sense?
Abstract away underlying mechanics of channels and liquidity
Draw focus to the property of those mechanics that the user cares about (has to care about), which are “how much can I send” and “how much can I receive”?
The term “limit” is familiar from traditional finance (credit card limit, ATM withdrawal limit).
The action of “increasing” is easy to understand
But of course it’s tricky because the people who build the products are working super hard to tame the technology. But users just want the benefits, and mapping technically precise functionality to ambiguous user needs is not clean.
Language is messy. I sometimes come across opinions where somehow assumes that what is intuitive to them should apply to everyone else. But that’s just not how it works. The human experience is too diverse. It’s a squishy science (Richard Feynman would not approve).
Anyhow, it was a busy week, mostly spent with Bitcoin Core App stuff (PR reviews, QA, design docs, designs system tweaks, and Guide stuff (PR reviews), the newsletter, and the Bitshala design fellowship. Reviewing other people’s work really takes a lot of time (and is generally a great way to contribute in open-source).
Happy Monday ✌️