The challenge of product design in open source crypto projects

Over the next few years, the crypto space is going to welcome a wave of new users coming for the benefits, but not necessarily with deep interest in the technology.

To onboard these people with minimum friction, and help them realize the benefits of crypto, among our top priorities today should be improvements in the usability of products such as wallets, and discovery of ways to communicate new paradigms in terms that are familiar and understandable.

Most crypto projects are open source, and evolve collaboratively. While providing for the essential properties of transparency and trust, developers are ultimately the gatekeepers, and in this article I’m going to explore how this can present some impediments to design progress.

Demonstrating the problem

To demonstrate my concern, I want to talk about a recent interaction with the developers of the PIVX project.

For context, you know that Bitcoin transactions are not private. DASH forked from Bitcoin, adding transaction mixing to provide a level of privacy through obscurity. PIVX forked from DASH to push further into anonymity, through the zerocoin protocol.

Common to both DASH and PIVX is that their wallets allow for sending both public and private transactions. And since privacy is at the core of both of these projects, the design of their respective wallets should prioritize making sure that user transactions are private, when they want or expect them to be. And particularly for a product named “Private Instant Verified Transactions” (PIVX), I would argue we should assume the user’s expectation is privacy.

Despite these design concerns, however, it’s actually quite common to hear the following complaint from people new to both DASH and PIVX:

I came to the coin for privacy, and just discovered that none of my transactions are private, because the default transactions are public!”

This problem is so widespread that even the hosts of the CryptoBasics podcast—a show intended to explain the basics to new users—were completely confused, and stated, “A great benefit of PIVX, compared to say, DASH, is that the wallet by default sends private transactions!” A member of the PIVX team had to join the show the following week to clarify that, no, that’s not the case.

Does this concern developers?

As a product designer, a misalignment in user expectation and product experience is a huge problem. In addition to errors, frustration and wasted time, such misalignment can ultimately drive our customers to better offerings.

In a previous article, I highlighted these problems within the context of the PIVX project, and proposed some mechanisms to help.

This article was circulated within the project, and a while later I was contacted by one of the core developers, who wanted to communicate a response he’d provided internally on the issue of “unexpected default behavior”:

Regarding “privacy by default” in terms of sending transactions: When a system offers multiple transaction types such as we do, the term default implies that given no user input of which to use, the program will make the decision for the user.

In this sense, we do not have any default, as the user is required to make a conscious decision otherwise no transaction is made. All arguments made about transactions not being “private by default” are born from a misunderstanding of the way default works in such systems.”

What concerned me with this comment is that, to me, it feels authoritative while, (in my opinion) completely missing the point. Why is that concerning? Because it’s hard to change someone’s mind, if their mind isn’t open to the possibility they’re wrong.

To my response that misalignment between expectations and experience is a very important problem, especially in the context of privacy, the developer wrote:

I’m not in total disagreement with you, but I will say that “expectations” with how a particular piece of crypto software operates are largely “inherited” (meaning that the expectation from one program to another remain the same) and this is nothing short of a falsehood in the expectations themselves. There are no grounds nor precedent to expect one program to perform exactly like another, even if said two programs are similarly related in field.

He believes the problem is with users, and their inherited and false expectations.

Feeling we were talking past each other, I tried to communicate my point through an admittedly non-perfect analogy:

Let’s say you install VPN software, and click connect. Later you learn your connection wasn’t private. You raise a concern that the product experience didn’t match your expectation, and you’re told you missed the setting to “Make connection private”. You say that that the default behavior in a virtual “private” network app should be privacy, and you’re told that there is no default, because you have a choice, and if you expected otherwise, then that’s a falsehood in your inherited expectations.

His response was that the analogy was largely irrelevant, but where it was, the problem is with users not having done their due diligence; particularly, not having read the documentation.

The case you describe is closer to a “not knowing” case, in which we provide abundant information on via the website and the technical papers that have been published. I’m not saying that the user is “at fault” per-say [sic], just that they have not performed due diligence into the product itself if their expectations match what you have stated.

So if their expectation is privacy, in a product who’s name is Private Internet Verified Transaction, then they clearly have failed to do proper due diligence.

He went on to say that the time for UI discussion had anyway passed, and raising these concerns now was doing more harm to the project than good. He pointed me to a closed GitHub pull request, representing the “UI overhaul” that had taken place for the forthcoming version 3.1 of the wallet.

I haven’t used version 3.1 of the app yet (since it’s not out), but looking at the pull request, it seemed to consist of little more than a developer changing the fonts, colors and spacing within the Qt wallet, and moving the tabs from the top to the side. When I pointed out that this “UI overhaul” was little more than an aesthetic makeover, his response was:

UI overhauls are usually aesthetic makeovers.

Point by point

Let’s start with the question of whether the product presents a choice to the user. When a user who wants to send some PIV opens the PIVX wallet, here’s the navigation structure they see:

As soon as their eye and mouse see the “Send” tab, we can expect they’ll conclude they found the place where sending happens. We can also anticipate that the user will expect if there are any decisions to be made about sending, they’ll find those choices in the “Send” area.

What we can’t expect is that it will occur to the user to continue exploring other areas of the wallet, looking for additional send features. In the case of PIVX, if the user wants to send private transactions, they need to first navigate into the “Privacy” tab. And since western users scan from left to right, we can expect that a user opening the app to send PIV won’t even see the Privacy tab!

So user choice in the PIVX wallet is obscured through a problem with UI hierarchy. If the default path through which 99% of users send a transaction doesn’t inform them that there actually is a choice to be made, then the product really isn’t offering a choice.

Next, let’s talk about the view that the user should be reading manuals—something completely antithetical to the end goal of every product designer on the planet. Put their products in front of users, and there is no clearer pointer back to the drawing board, than seeing a user get stuck and have to go digging into documentation.

Finally, let’s talk about the notion that a UI overhaul activity is “normally an aesthetic makeover”. Show the PIVX 3.1 “UI overhaul” to the community of professional product designers worldwide, and the response will be uniform—what we see here is putting lipstick on a pig. In the words of Steve Jobs, “Design is about how it works, more than what it looks like.”

What’s going on?

Fundamentally, there are two problems here:

First, there’s the problem that UI/UX design isn’t considered a discipline. To many, anyone with an aesthetic opinion is qualified to participate in product design.

This view, which couldn’t be further from the truth, is unfortunately widespread. When the DASH project posted the competing logo re-design candidates from Ogilvy & Mather and Tharp & Clark, fifteen minutes didn’t pass before considered conversation was overwhelmed with a flood of people posting their own logo candidates. Why pay those firms when I bought Corel Draw?

Second, in open source projects like these, the developers are ultimately the gatekeepers, as they are the ones who can commit code to the project repository. This means that the job of the designer is not only to create an effective user experience, but also to convince developers to agree with their views.

And developers tend to be people who are both capable of, and actually enjoy, managing complexity. They desire freedom through tools that are maximally configurable. It’s not in their nature to remove functionality in the interest of broader adoption. Why would we ever remove the ability to manage a “masternode server” from the product everyday people are supposed to use to send and receive crypto currency?

If you’re a developer, and actually interested in understanding this frustration, imagine the roles are reversed—that designers are the gatekeepers, and you’re trying to point out that implementing a state-machine through the human-natural approach of a nested if/then/else statements will eventually collapse at a certain complexity.

And to your argument that computer science offers a more reliable and maintainable implementation approach (although less understandable from a common-sense perspective) the designer replies, “Nah, I kinda like the look of this nested structure.” Or worse, he says something along the lines of, “If the state machine gets out of hand, it’s probably because you didn’t indent properly.”

At some point, you’d tire of talking, throw up your hands and say, “Listen, I’m sorry but this just isn’t a matter of arbitrary opinion!”

Where do we go from here?

So that’s where we are today. How do we move forward?

Well, we don’t abandon hope, because crypto is just too important. We need well-designed products in order to deliver the deepest level of benefits to the common person, and to adequately introduce them to a world of new paradigms.

We also don’t push against the open source model. That’s critical for trusted, verifiable and peer-reviewed software.

Somehow, we have to find a way to evolve the open source model to accommodate the role of product designers.

This will involve education. We have to get to a point where developers defer the product design role to designers, and come to believe themselves that effective design is as important as quality code. And they have to come to believe that product design is a discipline, involving principles and techniques that come through training, and involve depth of thinking far beyond surface aesthetic judgements and common sense.

It also involves people speaking up. In the PIVX discord, so many people sent private messages saying, “Keep it up! I agree with you! This is important!” What these people should do, instead, is express those opinions publicly. Let the developers know that this is important.

Finally, it will likely involve the emergence of tools that allow designers to do their job. These tools will come from those rare developers who are, themselves designers, and have the technical insight necessary to create design and prototyping tools that expose the services and capabilities of the underlying blockchain to the designers.

In the meantime, I plan to stop talking, and start sketching. Starting with the crypto wallet, my plan is to wireframe my take on the ideal product, and post it to the community for comment. Perhaps actually seeing a usable alternative to what exists, members in the community will rally around the idea of making it happen.

In consideration of those future users, like my doctor, neighbor and family members, I sure hope we get there!

Leave a Reply

Your email address will not be published. Required fields are marked *