December 2024: Studio Twentyone Newsletter
Happy 100K bitcoin! Gonna share some cool bitcoin design updates and educational pieces here. Hope you enjoy!
- SAHIL
Studio Twentyone Show with Erik of Hoseki & Cashu
This month I published episode 2 of the show with Erik. We recorded on a riverwalk trail in Riga, Latvia during the Baltic Honeybadger conference. We dive into Erik’s path into Bitcoin UX design, his design inspirations, the art of communicating design ideas clearly, and balancing aesthetics with functionality. Hope you enjoy it!
You can watch on YouTube, Apple Podcasts, or subscribe wherever you get your podcasts (click on the Twitter thread below).
Grouping elements with the Similarity Principle
This is a Gestalt principle that describes how UI elements that are visually similar (eg. color, position, shape) will be treated as related: whether we want it, or not (more on this later).
For example, the paragraphs of text you are reading are grouped together lines of text. You know that sentences are related because they are grouped together by position and size. If I wanted to draw your attention to a bulleted list, I could shift the position of those bulleted items, grouping them together, which would help you to treat them as visually distinct items.
It’s all about shortcuts to guide users to have a better experience!
You can achieve a similar effect with color - even if unintentional. In this example below, NN/g highlight a case where both a button and icon are the same color, which links them together visually. You’d think that both would be clickable, to upload the document - but the icon is only there for ornamentation purposes, and is not clickable.
There’s some more great examples in the article — check it out. Worth thinking about!
Linear: spacing + text hierarchy = 🤌
Related to the previous piece, Noah shares this onboarding guide from Linear which is total eye candy. I love the simplicity and attention to detail with simple type choices, grouping (using the Similarity Principle!), good use of space, appropriate line width, and more. What do you think?
Discussion on address type warnings
Many exchanges like Cash App or Coinbase warn users about address types when sending funds to a bitcoin address. Here, Stephen poses a question of if this is even a real concern. I also wonder how common of an issue this is, and if it could be needlessly scaring customers with a warning message.
If you work at an exchange, I’d be curious to hear from you, is this common? Are we just showing the warning because “it’s the way it is”? Maybe an artifact from the fork wars of 2017?
✨ Sponsored ✨ Interested in reaching an audience of builders in bitcoin? Reach out
Austin Bitcoin Design Club
ABDC is a monthly gathering of bitcoiners, designers, engineers, and more, from all walks of life. We are building a space for fostering connections, idea development, and most importantly creating a strong sense of a design community from which we may all draw support.
RSVP for the next meetup using the link here: https://www.meetup.com/austin-bitcoin-design-club/
Technical jargon vs familiar terms
There’s a payment protocol for reusable, privacy friendly bitcoin addresses called “reusable payment codes” or BIP-47 payment codes. Here, Christoph makes a suggestion to Nuno at BlueWallet to change the technical name of “payment code” to something more user understandable, like “reusable addresses”.
Nuno’s argument seems to be that, as a new feature, the early adopters will be familiar with terms by their technical name (eg. payment code, or bip47), so we should use those terms for now.
I wonder if this is the right approach: we’ve seen other jargon-y terms become standardized because they were so entrenched over time. This might be a disservice in the long run.
That said, I wonder if the solution proposal is still confusing. At Austin Bitcoin Design Club, Paul talked about designing for intent rather than a “feature”. In the “After” screens from Christoph, I’m still left wondering: “Why do I need a single-use address at all? Why not always show me a reusable address?”.
What do you think?
RIP overspecialized design teams
Skyler brings up a good point about how designs teams are becoming leaner, with a few generalists supplemented by specialists from independent designers or agencies. This resonates — especially in the age of AI, where the generalist can be the playwright with overall strategy/taste, delegating specifics to specialist AI agents and agencies.
Might be best to get T-shaped: good at everything, specialize in a couple things!
Competing visions of bitcoin inheritance UX
We’re beginning to see some competing visions of how to solve the inheritance problem with bitcoin wallets. Some wallets like Unchained take more of an assisted legal route: working with estate planning to set up a legal transfer as well as physical bitcoin transfer. Two other ones I wanted to highlight today are Liana and Bitkey.
Liana takes a more technically complex approach, using miniscript and bitcoin on-chain timelocks. A benefit here is that you’re not trusting a company with your inheritance setup: it’s all provable and executable on-chain. The downside in my view, is that the process involves moving all your funds (yes, a full transaction) at every period, to ensure the inheritance key is not usable before necessary.
Bitkey is going with an approach where you trust the company, and can just say “I’m not ready yet”. The inheritance process won’t start until the “off chain” timelock is not triggered to be unlocked. The obvious benefit here is it’s way simpler, and no expensive transaction needed every time period. I could be wrong, but a downside is that you’re trusting that the company will be around to ensure that the inheritance process is triggered appropriately.
I’m still thinking through how I feel about it, but I think until we get better systems (eg. allowing me to simply sign a message to stop the inheritance process, rather than sign a transaction), the Bitkey approach will be more practical for most people.
Strike: website update!
I just love this new Strike website update. It’s so PUNK, so JACK. Check it out!
See you next month!
Thanks for reading. Let me know what you think on Twitter or Nostr. Feedback is welcome!
Love u,
- SAHIL
Great work & meetup!
Thanks for the mention.
To your point about: "I’m still left wondering: “Why do I need a single-use address at all? Why not always show me a reusable address?”.
The issue was meant to be minimally invasive, and even just the text change turned out to be too big of an ask and spiraled into a conversation around feature adoption across the whole ecosystem. I've gotten very careful around scoping these types of requests and keep them very focused because of these types of dynamics.
Big picture, once reusable addresses are adopted, you will not need the single-use ones anymore. We need to ensure that the ecosystem is actually cool with the reusable address tech, wallets need to implement it, and then we need to migrate users over. The reusable address type that Blue Wallet recently implemented uses BIP-47, which was created in 2015. Almost no wallets support it. So you might think that the ecosystem either does not think of it as a good technical solution, or does not see the feature as important enough to bother implementing. And you have a competing, fairly similar at the top-level, approach with the more recently published BIP-353 (silent payments). Now we're in a situation with two competing approaches and need to somehow figure out which one should be the one. Once all this is sorted out and we have broader adoption, then reusable addresses can be the default.
So easy in our design tools, yet so messy and complicated IRL, but that's how things are sometimes (and what makes them interesting challenges).