Introduction

For designing with Stack or Spend, we’ve decided that the paradigm of “stacking” vs. “spending” will be represented with a combination of iconography and colour. Our first iteration was functional but needs a round of improvement on some of its design philosophy to be better suited to the SoS problem and the hypothesis it’s trying to prove: Bitcoin and Lightning users can be better informed by taking a long-term perspective on their wallet usage.

User experience

Colour

We will use colour to delineate the general “state” of the user’s current balance, relative to the current buying price of bitcoin. ˇA simple color coding that implies “good” vs “bad” is the easiest way to do this. Interestingly, SoS was always intended to show both actions as “positive”—regardless, it benefits the user—but I think it’s okay to set a paradigm for a preferred action being good, and the less recommended one being bad. At the end of the day, it’s the users choice.

The original colour scheme wasn’t as successful as it could have been, so we have a new plan. I still think red may be too strong a choice to show the “stack” indicator, since it’s not a bad thing to spend your fiat instead of your sats, but maybe it’s something we can use as a moment to try and force a pause: You sure you want to spend those sats right now?

Old color system: cute, but ambiguous, needs mental model development. Unfortunately neutral.

New color system: No bad decisions, but one is preferred: spending sats when it makes the most sense to. the flip side to this is to make a decision that you should probably think about.

Icons

We had an early set of icons created to represent stacking vs. spending, and their use was relatively intuitive, but again, there’s this mental model development that needs to happen. What’s a visual mnemonic that we can use to avoid having to explain iconography?

Emoji, easy. It was there at the original project post, even. The first sprint we did eschewed thinking about the application of the icons in lieu of something more generic, but for our pilot, we think emoji-as-icon makes loads of sense.

Interim icons used for our 18-hour sprint

New icons: referential, mnemonic.

Language

In asking questions about SoS, one of the big ones has been, “who’s this for?”

As a service-based studio we’re more accustomed to responding to a problem or a specific user context than a general “what if” but working on the project and thinking about its design implications have kind of pointed toward that: clearly, SoS is for the conscientious user of Bitcoin.

This user would have to use Lightning, probably from one or more wallets, is probably less obsessive on the HODL mission than users who prefer things like cold storage wallets, and is likely less solely dependent on sats as their spending medium as someone with a high time preference. Some core product attributes can come out of this:

1. User-friendly: Users should be able to navigate this idea that Stack or Spend is trying to introduce easily. Using a Lightning wallet is an intuitive set of activities by now, but this idea of “is it a good time to spend your sats?” isn’t.

2. Relational and mnemonic: using as much references to real life and to a user’s existing scenarios (ie, one of someone using BTC) will help SoS become more than just something to check your balance and pay with.

This implies a design language (and, indeed, written language) that needs to speak to users on the grounds that they’re on: they’re not newbies, they’re BTC users. But they also have an experience that they’ve become accustomed to. How can our design work disrupt this pleasantly?

We could see then, a design that can evolve past the basic wallet experience. What if your wallet could help you spend smarter by telling you more about your current term bitcoin position? What if there was a tagging system that allowed us to track expenses over the month, for example?

Regardless of the turns, these questions beg answers that are UX-based. The real opportunity is to take a look at the way that the wallet experience happens, and there’s a lot more to that than sending/receiving that we can cater for. We’ll keep working toward our next prototype with these elements in mind, and will take to prototype testing to test for intuitiveness.

Next steps

The stack-or-spend paradigm is one specific to users and their own personal journeys with Bitcoin, but for now we can definitely test to see if some of the assumptions we’re making about design and our ability to make it intuitive can get answered. We can test for the value of “do you feel more empowered in your spending decisions after some users have been able to test it after syncing their own wallets and taking SoS for a spin.

Or, debunked. you know.

Keep up with my bad design (before @chris steps in and makes it magic) here