NFTs (non-fungible tokens) are unique digital assets — like an image, a song or even a tweet — that are stored on a blockchain.
The biggest NFT marketplace, OpenSea, hit a $1.5 billion valuation earlier this year, raising money from Andreessen Horowitz, Kevin Durant and Ashton Kutcher, to name a few.
But is the experience of creating and selling an NFT on OpenSea actually any good? That’s what UX analyst Peter Ramsey has been trying to answer by creating and selling NFTs on OpenSea for the last few weeks. And the short answer is: It could be much better.
This Extra Crunch exclusive is a more detailed conversation around this article, on Built for Mars, which helps bridge the gap between OpenSea’s mistakes and how you can make meaningful changes to your product’s UX.
Actionable routes
You may have heard of the concept by another name, but an actionable route is essentially a preferable next step at any given time. For example, after finishing an episode of something on Netflix, one actionable route would be to watch the next episode, another may be to find a different series to watch.
As a designer, you only really care about the actionable routes that are common and commonly preferable — the user may want to rewatch the same episode at 2x speed, but it’s unlikely enough that you wouldn’t prioritize it.
In the case study, I demonstrate this concept while creating a collection on OpenSea, but this is applicable to every product or service.
If you run an e-scooter company, what is it that a user is most likely going to want to do after completing a ride? If you’re starting a new payments company, what are the most likely things that the user will want to do after making a payment?
Too often, companies will lazily assume that the best next step is to push the user into sharing something on social media, or leaving a review on the iTunes store. This may be a good time to do both of those things, but they’re not the only actionable routes that you should consider.
Maybe after completing their first ride in a new city, the user would want to see a map of where they’ve been on the scooter, or learn more about if you can reserve scooters in advance for later (i.e., if they’re going into a restaurant and don’t want their scooter to disappear while they’re eating).
Tip: The process of considering and writing down your actionable routes is a useful exercise in itself, and it can be done in a few minutes. Yet, I’ve worked with some of the biggest companies in the world, who’ve never considered doing it (until I tell them to).
Subtasks
Studies have shown that multitasking increases stress and decreases productivity. Despite the evidence, people still think that they can do it effectively. One possible reason for this may be the issue of defining “multitasking.”
To clarify, because you only have one cursor on a computer it’s difficult to do two tasks at the same time. But, the term “task switching” and “multitasking” are interchangeable here. Or rather, the process of switching between tasks carries a penalty. It’s mental multitasking.
This is something that people often misunderstand. Multitasking doesn’t just mean simultaneously doing more than one task, but the mental strain of thinking about doing more than one task.
And that’s where products often get into hot water with subtasks — like OpenSea did, they’ll jump back and forth between tasks, and manage the transition poorly.
Another example would be sending an invoice using an accountancy tool. You may start by creating an invoice, but during that process, may need to customize your invoice template. After you’ve finished the customization process, the accountancy tool would need to get you back on the task of sending an invoice, and that’d require a context buffer.
Tip: A good transition between tasks will feel seamless, and probably use “context buffers” to remind the user what they were doing, what’s changed, and what they should focus on now.
Autosaving
A major factor in managing the subtask transition is to ensure that the user hasn’t lost any work. You never want them to have to reenter information. This can often be solved by autosaving.
There’s another common scenario where autosaving is immensely valuable: Encountering flow errors. You can’t avoid every error, and it’s not even realistic to build helpful error messages for every potential error. But, autosaving can be used like a UX airbag.
There’s a common misconception that autosaving is only valuable if the user is completing a lengthy input process such as a form with lots of fields.
This is not true, and I often recommend that products include autosaving functionality even when there are only a few fields. Nobody enjoys reentering information, and it’s frustrating regardless of the number of inputs required.
There are some exceptions, though, like credit card fields and passwords.
Tip: Ideally, the user should be able to refresh the page and not lose any progress in their forms. This is especially true for long-form inputs, such as descriptions.