By Peter Ramsey

19 Aug 21

Selling an NFT on OpenSea Company Logo
Opensea6 min read
Listen

Selling an NFT on OpenSea

Selling an NFT on OpenSea Featured Image

NFTs (non-fungible tokens) are unique digital assets—like an image, or a song—that are stored on a blockchain.

And like traditional art, some NFTs are worthless, while others are hyper-valuable. In February 2021, an NFT from the artist Beeple sold for more than $69 million.

Every day, art that you probably wouldn't even hang on your wall is selling in a JPEG format for thousands of dollars. It's a total NFT-feeding-frenzy.

So people have flocked to OpenSea: the biggest platform for buying and selling NFTs. But is the user experience of actually creating and selling one any good?

To test that, I've created my own collection, and the short answer is: it could be much better.

Summary:

  • 🚗

    1. Why you need to use 'Actionable routes'

  • 🗂

    2. The trap of sub-tasks

  • 3. Don't forget to auto-save

3 key takeaways

1. Actionable routes

You may have heard of the concept under 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. i.e., the user may want to rewatch the same episode at 2x speed, but it's unlikely enough that you wouldn't prioritise it.

It's evident that OpenSea haven't spent much time thinking about these. As an example, look at this:

null image

At this point, the user has clicked into the 'collections' field, whilst adding a new NFT. I imagine that these would be the likely actionable routes:

🌱

Add a new collection

🧠

Learn more about collections

🤷‍♂️

Do nothing

And so the UX for that empty state really writes itself: you help the users get to their actionable routes as efficiently as possible.

2. Sub-tasks

Studies have shown that multi-tasking 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 'multi-tasking'—occasionally called 🗯 Context Shifting

To clarify, because you only have one cursor on a computer it's difficult to literally do two tasks at once. But, the term 'task-switching' and 'multi-tasking' are interchangeable here.

Or rather: the process of switching between tasks carries a penalty. It's mental multi-tasking.

As an example:

⛳️

1. Creating an NFT

The user has a clear task: to create an NFT.

☝️

2. Creates a collection

The user has to switch tasks, to creating a collection.

⛳️

3. Back to creating an NFT

They need to re-orient their focus back to this.

My point isn't that you should always refrain from any type of task-switching—it's often unavoidable.

But rather, that bringing the user back into the original task is more challenging, and what OpenSea have done here is actually make it harder for the user.

Here's the nuance: it's easier to engage with a new sub-task, than it is to refocus on your original task.

OpenSea should be bringing the user immediately back to their original task, with a context buffer like this:

null image

This would confirm what has just happened, and provide transitionary context—i.e., that sub-task is now complete, and you can get back to creating your NFT.

OpenSea would probably find that this approach makes the process of creating an NFT and a collection feel more intuitive.

3. Auto-saving

A major factor in managing the sub-task transition is to ensure that the user hasn't lost any work. You never want them to have to re-enter information.

This can often be solved by auto-saving.

There's another common scenario where auto-saving is immensely valuable: encountering flow-breaking errors.

For example, during the collection-creation process I kept running into this bug where clicking the main CTA would give the impression that it's doing something, and then just spring back into it's default state.

Click.

Click.

Wait.

Wait.

Click again?

Click again?

You can't avoid every error. It's not even a realistic expectation to build helpful error messages for every potential error. Sometimes things just break.

But, auto-saving can be used like a UX-airbag.

And it would have prevented a lot of frustration here, because I had to refresh the page on OpenSea, and enter everything again.

All of the UX analysis on Built for Mars is original, and was researched and written by me, Peter Ramsey.

Get original UX analysis straight to your inbox.

Unlimited access to over 60 case studies and playbooks, for free.

🚀

Related Case Studies

How (not) to get people to download your app
Reddit
9 min read minute read

How (not) to get people to download your app

Reddit's strategy of canibalising their own web experience, and blocking third party apps, might not be working.

Exposing the growth engine of Threads
Threads
10 min read minute read

Exposing the growth engine of Threads

A deep dive into why Threads' launch strategy was so effective, and the UX theory behind their A/B tests.

Wise: UX without borders
Wise
9 min read minute read

Wise: UX without borders

Wise are a multi-currency financial service that, during the age of incumbent banking, earned success with their radical transparency.

Ticketmaster: the UX of a true monopoly
Ticketmaster
12 min read minute read

Ticketmaster: the UX of a true monopoly

Behind the growing ticket sales and returning user base, lies a troubled experience with fundamental problems.