How does a protocol encourage end users to become node operators, and what stops them in the first place? What is the balance of effort vs reward needed for users to complete the set up of becoming a node operator? How does a protocol turn someone who’s just learning about what a node operator is into someone who is actively contributing to the network?

Over the last 3 months, OpenUX has been working with Rocket Pool on a grant-funded user research initiative to deeply understand, and find ways to improve, the experience for node operators in the Rocket Pool ecosystem. The goals of our study were to:

• Illuminate the existing user journey of becoming a node operator

• Identify the pains and blockers that prevent an interested party from setting up their own node

• Identify ways to encourage more people to become node operators

The findings from this report are relevant to all staking services and blockchain ecosystems that depend on node operators to guarantee the robustness of their network and encourage growth.

🌐 Please read our full report , which is packed with insights and includes ‘lite’ personas and recommendations to Rocket Pool 🚀

Here are just a few key learnings from our study to whet your appetite:

1. Procrastination is the enemy of completion. Users need a suitable ‘trigger’ to encourage them forward with their investigations into becoming a node operator.

The Fogg Behavior Model can be used by all product teams and protocols to explore whether they have the 3 necessary elements to encourage someone to use their product. According to the model, for a behavior to occur, there must be a convergence of high motivation (the person really wants to do it), sufficient ability (they are capable of doing it and/or the process is not too complicated/expensive etc), and an effective trigger (a moment in time that prompts them to action). If any of these elements is missing or too low, the behavior is less likely to happen.]

Many in the Rocket Pool community are really interested in becoming a node operator. They are motivated by the potential returns and ethos driven, and many are able to follow and complete the process, but without a ‘trigger’, or moment in time that moves them to action, they get stuck in procrastination; trying to decide exactly what the right option is for them, what hardware to get, how to optimize their set up, etc.

Current ‘triggers’ are pretty limited, one-time events. They include: when the Rocket Pool beta went live, when Rocket Pool was launched, when LEB8 was announced and when staked ETH was enabled. While Rocket Pool has more updates in the roadmap, leaning on such rare events can be a limiting factor for the protocol’s growth.

Our recommendation for Rocket Pool is to generate more ‘triggers’ that create a sense of urgency, and prompt people to commit. An example of a trigger might be a Node Operator Introductory Course, which inspires someone to begin converting their interest into action.

2. Not all node operators are equal. Rocket Pool needs to shape a bundle of benefits that can appeal to this diverse set of users with different requirements and motivations.

Our research segmented participants to the study by two main dimensions: the amount of ETH they had bonded, and their technical ability.

There were many notable differences in the needs and pains of these cohorts, and we encourage readers to check out the Segmentation & Insights section (Chapter 2 in the full report), but here are some notable learnings:

• Node operators with more ETH bonded have greater concerns around tokenomics. The required exposure to RPL makes many potential users feel hesitant about becoming a node operator. While the token is volatile, it also comes with a high yield for RP node operators. Therefore it’s important to nuance the understanding of RPL through making sure the upside is clearly communicated.

• Those with less ETH bonded are likely to attain fewer financial benefits from staking than those with more. Therefore it’s vital that Rocket Pool promotes the ‘softer’ reasons to be a node operator (community, exploring and learning about crypto, and helping to keep Ethereum decentralized). If Rocket Pool fails to communicate the softer benefits then people might rely solely on a rationalistic cost/benefit analysis. In that case alternatives with less effort, upfront investment and responsibilities will seem attractive in comparison.

• Less technically able node operators are more likely to struggle with node setup. The concept of consensus and execution clients is something that even most technical users need to learn in the onboarding journey. While this requires conceptual understanding of how Ethereum works, it also translates to tangible decisions with consequences for people, since the choice of clients affect hardware requirements and performance. Rocket Pool could optimize the experience by creating a more intuitive onboarding journey that prepares users for what’s to come, and provides the right level of guidance, at the right time, to aid decision-making.

3. There are different reasons a user might drop-off at different stages of the user journey to becoming a node operator. These include:

Awareness stage (discovering Rocket Pool)

• The user knows about Rocket Pool, but assumes it doesn’t meet their needs,they might perceive that the effort or risk is not worth the reward. They might also have criteria (technological, legal, practical, ideological, social or cultural) that Rocket Pool doesn’t meet.

Consideration stage (attracted to the value proposition of becoming a node operator)

• The user might choose another option due to tokenomic and/or security concerns, smart contract risk, be dissuaded by feedback from others, or be concerned about DAO governance — or just get stuck in indecision due to complexity, lack of information or motivation.

Choice stage (choosing Rocket Pool as the right option for them)

• The user might come across usability barriers. They encounter a steep learning curve, and don’t have the resources they need to help them overcome the challenge. They may lack time, skill, funds, or motivation.

Read the full report here: https://storage.googleapis.com/rocketpool/RocketPool-NodeOperator-UX-Report-Jan-2024.pdf

What next?

• In the coming weeks OpenUX will be releasing more posts about the findings from this research, including a full user journey map.

• We’re working with the Rocket Pool internal team and wider community to ideate and co-design possible solutions that can be implemented to ensure the continued success of the protocol in attracting and retaining node operators.

If you work at a protocol that might find these node operator insights helpful, get in touch and we can happily talk about some of the findings with your team.

• How to delight community managers the most

  • Why member attention matters

  • Why moderation matters

  • Why member growth matters

• How to support communities in switching off Discord

  • Why existing mental models matter

  • How to reduce friction by supporting migration

• Which communities are ready to switch

Thanks to Status for funding and collaborating with OpenUX on this research.

OpenUX and Status collaborated to ask community managers why they still use Discord

Since the rise of web3 communities and DAOs in 2020 and 2021, Discord has been the web3 community standard. Its ‘good enough’ user interface and options for crypto-integrated bots made it an obvious choice for most community managers.

Three years later, is a platform originally designed for gamers and content creators still the best tool for web3 communities?

What will it take for communities to leave Discord?

Status, an early entry to the web3 social space with the launch of the Status consumer app in 2017, wanted to explore this topic. While their flagship app was focused on individual-to-individual messaging, Status had a hunch that the crypto social rails they had created could be leveraged to create a highly-tailored experience for tokenized communities.

OpenUX worked together with Status to develop hypotheses about the current experiences and needs of community managers. We recruited over 100 community managers from multiple industries to participate in a large survey and 1-on-1 interviews.

How to delight community managers the most

One of the outcomes of our research was the definition of different cohorts of communities. We found community managers’ behavior and preferences differed based on the size of their community, whether or not their community was monetized, and the overarching purpose of their community.

While we discovered insights relevant to only a few cohorts, there were many themes relevant to all community managers. Our recommendations are listed below:

Build more reliable ways to grab members attention

One of community managers’ most used features on Discord is roles: assigning members to categories that can be sent specialized notifications. While these features are advanced, community managers say utilizing them takes an enormous amount of time.

“We cannot maintain the roles in our community ourselves. We have a lot of people helping us from the community. With so many people in the community, it becomes hard to send relevant announcements” — Manager of a large, non-monetized, crypto contributor community

Even if a community manages to set up their roles efficiently, challenges grabbing members’ attention doesn’t stop there. The continuous chat-based layout of Discord makes it very difficult to direct members to information in a way that matches members’ natural user journey. Connecting members to important community information is another important area to improve on in competing applications.

“Discord does a bad job at creating sources of truth and other pinned information for most members to see. When you have everything in one chat, it is super clustered, and super hard to find information.” — Manager of a small, non-monetized, crypto contributor community

Build more automated ways to moderate both improper and distracting member messages

Managers from all cohorts invest a lot of time into moderating bad actors in an effort to protect their members and improve engagement. Workflows that make it easier to moderate bad actors and unfavorable content would serve a large, high-visibility need.

“The biggest challenge we faced came from people who aren’t part of our community. They join with bad intentions and threaten the security of our members.” — Manager of a small, monetized, crypto social/educational community

“We have people on Discord focusing solely on security and it’s surprising to see how many bots, scammers, and exploiters try to join our server. If bad actors manage to get in they'll direct message our members or spam our channels.” — Manager of a large, non-monetized, crypto contributor community

“We’ve had people engaging in aggressive self-promotion and it’s something we struggle dealing with sometimes. How can we promote the right behaviors?” — Manager of a small, non-monetized, crypto social/educational community

Help communities fuel their own member growth with tools that boost discoverability to new members

Most managers are actively broadcasting on multiple platforms where their potential members may gather. If they have enough time and expertise, they’ll also seek promotional partnerships.

New platforms could build tools that boost outsiders’ ability to discover new communities or platform-wide benefits that grow the pool of active potential community participants.

“Growth of the community is our biggest job. We’re always trying to figure out how we can grow it further. Right now our goal is to bring more Web2 people into the space and our community.” — Manager of a large, monetized, crypto product community

“It's really about which partners are aligned with us and will amplify our message to help us find more members and get organic growth” — Manager of a large, monetized, crypto social/educational community

How to support communities in switching off Discord

Work with managers’ existing mental models by supporting basic channels, roles, permissions, and notifications

Many managers have developed their mental models for how community management works in Discord. Those who do have existing mental models expect to set up their communities with a few core features, including multiple channels, roles, announcements, notifications, multi-platform availability, and bot integrations.

Discord’s broad suite of these essential features is another major inertia factor that keeps managers from trying newer, more focused tools.

“I like that in Discord you can have multiple channels in one server. I don't think Telegram has this function yet. That is a must-have.” — Manager of a small, non-monetized, crypto social/educational community

“I think the one thing I might miss about Discord would be the option to create a live call. So I can go to the lounge section and start talking to people there.” — Manager of a small, non-monetized, crypto contributor community

Support communities with their migration to alleviate concerns over member drop off and lost engagement

For most community managers, momentum with growing engagement is the number one goal. Most of the benefits a new community platform could provide pale in comparison with the risk of losing engagement and/or momentum by making a switch.

New community platforms must share messaging that addresses managers’ concerns about lost engagement and builds confidence that hands-on help is available to manage the transition. Larger communities would especially benefit from services that automate member transfer.

“We picked and continued to use Discord because our community was picking up steam and we had lots of engagement so we didn’t think about switching from it at all.” — Manager of a small, non-monetized, crypto contributor community

“I would say for now we're gonna continue with our setup. Not currently interested in switching.” — Manager of a large, monetized, crypto product community

Which communities are more ready to make the switch off Discord?

Smaller communities have a lower bar of requirements to switch and may also have less to lose in making a switch

It may be no surprise that smaller and newer communities have less to lose in switching off Discord than larger communities. In addition to having fewer members to migrate, smaller communities may perceive the switch as less difficult given they have fewer sunk costs invested into Discord. Smaller communities are also often run by a few entrepreneurial leaders who are curious enough to explore and in need of new tools.

Many larger, more corporate communities are ready to switch if the platform is right

For all the reasons mentioned above, convincing a large digital community to leave Discord is no easy feat. However, a platform that highlights ease of migrating members and highly accessible UX appealing to less tech-savvy audiences may ease fears of these managers. Additionally, platforms can delight larger, more corporate communities in unique ways: supporting automated ways to manage large community bases, supporting payments and transactions from members, supporting modern support ticket-like features, etc.

What does this mean for community managers and product builders?

If you’re a product builder who is building for community managers, consider the insights we shared above and validate them by talking to your own active and prospective users. OpenUX is a collective of user researchers, designers, and product strategists working to make insights like these more available to builders. If you need help talking to your users, feel free to reach out to us at https://openux.xyz.

If you’re a community manager who’s dissatisfied with Discord but uncertain about switching, don’t worry, you’re in the majority. We have seen a lot of new promising platforms propping up in 2023, including our very gracious supporter of this study, Status. If you’re interested in learning more about Status, visit https://status.im. We’re confident their support of this research demonstrates their commitment to supporting community managers.

Credits

• Authors and lead researchers on this project: Henry Harboe & Manansh Shukla

• Special thanks to John Lea, Reise Officer, and the rest of the Status team for supporting this research

• Why new crypto products struggle to gain adoption

• How builders can out-innovate web2 incumbents

  • How you can understand the complexity of the ‘job’ users hire you for

  • How to attract users based on the ‘job’ you provide

    • Crafting a compelling GTM strategy

    • Providing a unique upside that incumbents can’t

    • Over-investing in trust

Thanks to Endaoment.org for funding and collaborating with OpenUX on this research.

Why new crypto products struggle to gain adoption

Why does Coinbase have so much market share? Functionality? Usability? Price? Branding? In a larger context, how does any popular web3 app maintain its market share? Uniswap, Safe, MetaMask—all of these products compete with close substitutes, yet they dominate. Why?

The answer for each is nuanced, but a central theme throughout crypto is that trust reigns supreme. Time and time again as new products emerge and innovate on old paradigms, the bulk of users stick with brands they know and trust, causing many new builders to struggle to retain a customer base.

How can new crypto builders succeed when incumbents’ moats of trust are so strong? Must all builders sidestep their competition by creating entirely new product categories?  If not, which areas should new builders invest in?

OpenUX explored this topic with Endaoment, a web3 startup looking to re-invent how we all give to charities by modernizing Donor-Advised Funds (DAFs), a philanthropic financial instrument that makes donating flexible and tax efficient. We interviewed 21 donors with various degrees of crypto experience about the extent to which existing tools support charitable giving today.

What follows is a  subset of the insights and recommendations OpenUX developed with Endaoment. Our goal is to help ambitious startups craft a compelling and sustainable product strategy in today’s challenging and incumbent-dominated space. Thank you to Endaoment for committing to keep insights like these open as a public good.

How builders can out-innovate web2 incumbents

Understand the complexity of the ‘job’ users hire you for

When we asked donors about their reasons for using (or ‘hiring’ in Jobs-to-be-Done lingo) Donor Advised Funds (DAFs), we identified two main camps:

1. The first camp hire DAFs for a narrow job: to deliver funds to charities with little hassle and cost. This group’s motivations begin and end with the transactional benefits of DAFs: give to a charity; receive a tax benefit. Additional benefits that improve the giving experience are of little interest to this group. Unless their DAF is actively making their lives difficult, they’re not seeking out alternatives.

2. The second camp hire DAFs for a broader job: to increase the impact they have through giving. This group is deeply motivated by the gratification of supporting causes they care about. They often go the extra mile to educate themselves on charities, meet individuals supporting the same cause, and take action in their local communities. This group pushes DAFs to their limit, often taking outside actions to achieve their giving goals.

For all builders, it’s important to understand the job your users are hiring your products for. When the job is narrow (e.g. “execute a task with little hassle”), you have much less room to innovate to get prospective users’ attention. You may be able to carve out a wedge by offering something with better usability or lower cost, but you risk not enough people caring about the job to switch.

When the job is broad (e.g. “increase my impact”), you have much more latitude to impress users with novel features and experiences. Moreover, smaller usability improvements to the most basic, transactional part of the job may not be enough to get your users’ attention. When you’re in this situation, understand where users are putting effort into workarounds, and build something that meaningfully addresses their motivations.

When focused on a narrow ‘job’, understand users’ inertia to craft a compelling GTM strategy

There are two negative forces that deter someone’s decision to switch to new products:

1. The first negative force is anxiety of new solutions—people are naturally averse to products they don’t understand, don’t see social proof for, or simply don’t like the look of. All products must combat user anxiety to gain adoption, and we provide some tips for investing in trust to overcome user  anxiety in the last section of this article.

2. The second negative force is inertia of the current solutions—it takes a lot of energy for someone to consider, commit, and follow-through on switching from one solution to another. Some products have higher inertia than others, such as products that rely on network effects, ecosystem lock-in, or have high onboarding costs.

What can you do if you observe your prospective users’ inertia is low—that is, they’re not at all loyal to your competitor’s product? If the job you’re providing for is narrow, you could try to build a product that better solves that narrow job—a “better mousetrap” if you will. If the narrow job is extremely important to your audience (e.g. a tax filing service), a combination of small improvements and crafty messaging may be enough to convert some of your competitor’s users. But if that narrow job is less important to your prospective users, a wildly better solution may fail to capture their attention enough to get them to switch.

What can you do if you observe your prospective users’ inertia is high—that is, they’re especially hesitant to leave your competitor’s product? As we mentioned above, if the job you’re providing is narrow, you could invest a fortune into marketing and still see poor results. A lower cost solution may be to find an audience of users who are good candidates for your product and have not yet been onboarded to a competitor. If the job you’re providing is broad, check out the next section in this article about providing unique upsides.

During our work with Endaoment, we spoke with users who use competitor products for a very narrow job and also have high inertia to leave. It turns out these users were not easily convinced by the proposition of switching to Endaoment based on new features and UX improvements alone given their position of high inertia. But we also spoke with individuals who have never heard of DAFs, despite making donations regularly. It turns out the biggest reasons these donors hadn’t tried DAFs was a lack of awareness and trouble onboarding¹. Endaoment may be able to gain traction faster with campaigns that target onboarding these non-consuming cohorts, rather than go after individuals already using a competing product.

¹ Interview quotes about awareness of DAFs:

• “Nobody’s ever asked me about a DAF” —Participant A, a financial advisor

• “I didn't even know they had a DAF. I mean, I've been with [my current wealth management platform] for years and I don't even know if I saw a DAF option on their website.” —Participant B, a donor

Builders should consider how this applies to them. If your job is narrow and users are dissatisfied with incumbents, consider how much inertia will keep them from trying your ‘better mousetrap’. If your job is narrow and users are already satisfied with incumbents, consider the likelihood of converting non-consuming users with new branding and frictionless onboarding. And if none of this is true because your job is broad, read the next section for suggestions on going after a different job entirely.

When focused on a broad ‘job’, provide a unique upside that incumbents can’t

We just went over a few strategies for builders when the job they’re providing is narrow. But what if the job is broad? As we mentioned before, when the job is broad (e.g. “increase my impact”), you have more latitude to impress users with novel features and experiences. The reason for this is that broad jobs typically span multiple categories of benefits that reach users’ motivations. If you’re serving users for a broader job, more often than not you can find at least one benefit within that job that is underserved or has room to delight users beyond what they’re used to.

If you can’t identify any leads within the core job you intended to provide, look for adjacent jobs. For example, if someone’s digital payment needs are well served, ask about other financial needs in their business—how satisfied are they with invoicing, tax filing, etc? Even if this ‘secondary benefit’ is not the core part of your product today, if you’re able to provide it successfully, you may be able to leverage the trust it builds with users to upsell them on your  product’s other core benefits.

Part of our research with Endaoment included interviews with Financial Advisors. Many established Financial Advisors hire DAF tools for narrow jobs and face significant inertia to switching. These factors include everything from forced ecosystem lock-in from an employer to concerns over new products’ compliance². However, throughout our interviews, we did hear from a subset of Financial Advisors about the continuous and frustrating challenge of growing a client base. Rather than wastefully designing and marketing features to Financial Advisors who have no interest in a new DAF tool, we identified an opportunity for Endaoment to win over Financial Advisors by providing an adjacent benefit: help them find clients by offering superior client-facing tools that make them standout.

² Interview quotes about ecosystem lock-in with DAFs:

• “There are 3 DAF sponsors that are approved. One is the American Endowment Foundation, one is BNY Mellon Charitable Gift Fund and the other is Renaissance Charitable Foundation. I didn’t choose Renaissance because it's held on a separate platform as the other two.” —Participant C, a financial advisor

• “If I were to try a new DAF, I would have to have compliance approval from [employer]… That would probably be the first hurdle to overcome.” —Participant D, a financial advisor

Going after adjacent jobs is not only successful when the job you’re providing is broad, it can also be effective when an incumbent has a lot of market share and users are satisfied. When most users are locked into an incumbent product and it appears there are few users left to sell to, your best path forward may be to innovate into a new job category or user group entirely.

Over-invest in trust

A reality is that even if you do all of the above well, if new users have never heard of you, have no peers who use you, or don’t trust your brand messaging, your users’ anxiety factors are going to make everything harder for you. The reality of the tech industry—financial tech especially—is that people are more likely to trust institutions they or their peers already know. Trust is itself a network effect, and until you reach critical mass, you are going to have a hard time gaining adoption.

Through our interviews for Endaoment, we discovered a similar trend: most DAF users chose their vendor based on an existing relationship through another product line³. For example, DAF users who manage assets with Fidelity were extremely likely to be using Fidelity’s DAF product. While part of their rationale for using two products from the same brand was convenience, we discovered lack of trust in new brands would be a significant barrier to convincing any of these users to switch.

³ Interview quotes about preferences towards existing providers:

• “They all seemed fairly similar, it wasn’t as if any one provider was totally differentiated. The ease of use of having the DAF with the provider that I already had a relationship with was gonna trump everything else.” —Participant E, a donor

• “Vanguard is an established name so they can kind of sit behind that brand recognition; there's a certain trust factor. I had come from their personal investment platform, so I already knew them and figured their charitable arm was probably legit.” —Participant F, a donor

While there are many ways to invest in trust, we recommend a few specifically based on insights gleaned during our interviews for Endaoment:

• Word-of-mouth not only expands your reach but also makes a meaningful impact on trust: Our interviews revealed that people hear about financial tools and strategies through people they consider experts via podcasts, investment groups or clubs, reddit, and many other outlets. Builders should lean into the benefits of having other people talk about their product by creating referral programs, getting mentioned in online media, etc.

• User-centric messaging can make discoverability and onboarding easier: When someone visits a product site, they should be able to immediately understand the product, how it provides them value, and how they can start using it. Builders can achieve this by serving content and messaging with language that speaks to the challenges and benefits users associate with the job they’re hiring a product for.  Brands that are disorienting on first impressions, project too much technicalities, and/or don’t ground users in where to begin can be very off-putting and create distrust.

• Human-based customer success can bridge feature gaps and provide additional stickiness through personal relationships with users:  We learned through Endaoment’s users that the core team was amazing in bringing new users’ experiences to life and as a result felt deeply connected to the brand in many ways. Builders should recognize the value of having staff make themselves available to help new users in their early moments using a product. Someone representing the brand can bridge a lack of features or good experience delivery until product teams can catch up to a fully realized roadmap.

Take action on these suggestions

If you’re a product builder and these insights sound meaningful to you, consider investing in understanding your users so you can chart the best path for your product and company. OpenUX is a collective of user researchers, designers, and product strategists working to make insights like these more available to builders. If you need help talking to your users, feel free to reach out to us at https://openux.xyz.

If you’re an individual active or just interested in donating more to charities, we would strongly recommend Endaoment. Endaoment is committed to building tools for the modern donor, and have demonstrated that clearly by funding this research into their own users. For more on Endaoment, visit https://endaoment.org.

Credits

• Authors and lead researchers on this project: Henry Harboe & Eric Aker

• Special thanks to Robbie Heeger, Vishal Kapadia, Noah Gallant, Alexis Miller, Bruxa, Dae, and the rest of the Endaoment.org team for supporting this research

1. "Building in the Dark" increases the risk of creating meaningless products.

   1. A meaningless product is a “thing” that no one wants that solves a problem no one has.

   2. Doing research with users "Turns the Light On"

   3. The point is to understand peoples goals, tasks, contexts, constraints, emotions, behaviors, beliefs, problems, and capabilities. So you can create something that is usable, useful, and widely used.

2. UX Research is like taking an insurance policy out on your product.

   1. UX Research is risk-management. And the best businesses are the ones who can manage risk.

   2. Engaging with users in the right way gives you an advantage because others can't or won’t. And with better insight and resources, the chances of winning increase.

   3. “Don’t Trust. Verify with Users.“

3. UX Research protects your business by helping create better experiences.

   1. Builders don't research because they're scared.

   2. Researching users can help you fill the bucket, repair the leaky holes in a bucket, and keep the water in the bucket.

   3. Failure is mandatory but it doesn't have to happen in the market where stakes are high.

Reason 1: "Building in the Dark" increases the risk of creating meaningless products.

A meaningless product is a “thing” that no one wants that solves a problem nobody has.

It’s the classic, “solution looking for a problem” situation. I think it’s a delusion shared by builders who insulate themselves from actual users. Who would much rather be “creative” over spending lots of time understanding other people and their lives so that they can deliver a truly relevant solution.

If you don't understand your audience, your product will likely be "meaningless" to them. They provide the necessary feedback loops that keeps you and your product honest.

You can stop building in the dark by turning on the light -- by researching your users.

When you understand people’s:

• Goals

• Tasks

• Contexts

• Behaviors

• Emotions

• Beliefs

• Problems

• Capabilities

• Constraints

You are in the ultimate position to create something that people can want. Instead of guessing, go out and figure it out with them.

These people are your teammates. They are not to be feared or disrespected because, at the end of the day, they are the ones that will make you successful.

Take action by attending an OpenUX Office Hours to learn about how you can make your users teammates through research.

For example, you’re thinking of building a new NFT marketplace

You've managed to raise some seed capital to build an MVP and hire a small team. Your vision is to build a "mobile-first" NFT marketplace that lets you "swipe" onchain art. If you swipe left, you mint the piece, if you swipe right, you skip it forever.

Your initial assumption is that art is all about the relationship between artist and art-enthusiast. And Tinder is the model for creating relationships online. So putting the two together makes sense.

The MVP gets made. People get hired. And you inch closer to releasing it.

You give it to 10 artists for "onboarding" purposes. They seem to like it and give you lots of compliments. But when you check analytics it's unclear if you've got a hit on your hands or if you’ve got a dud.

After a while, you get frustrated, since those artists seemed so supportive of your product. And so it doesn't make sense that their usage is so low.

A colleague suggests speaking with 5 of these artists to see what is going on. You create some non-leading questions beforehand and prepare by clearly defining what you want to learn:

1. How do artists think about their relationship with their community?

2. What, if anything, frustrates artists about releasing their art?

3. Why aren’t the artists using the MVP?

You book time and start having conversations. It becomes immediately apparent that artists don’t think of their community in the way you thought they did. And so the swiping feature comes off as disingenuous. Which might be why they aren’t using it.

You also learn that artists actually have a lot of trouble distributing their content to collectors who have their other works. They find this important because it’s highly likely that existing collectors will mint new pieces over new collectors.

Then, you ask them about the MVP, and you learn that the MVP is way too hard to use. And they weren’t able to successfully upload their art without investing a lot of time.

Just in the 5 conversations, you’ve uncovered that you’ve been thinking about the problem all wrong. That there are specific things that artists care about most and that your MVP doesn’t address those. You also learn that the current MVP has some major usability problems -- and you now have a clearer idea about where to improve.

The feedback loop that these interactions give you can be enough to adjust the course your product is on. It is also a way to learn unintuitive insights into problems that can’t be found anywhere else.

It’s this feedback loop that gives you the chance to deliver a meaningful solution.

Reason 2: UX Research is like taking an insurance policy out on your product.

Having more insight than anyone else is the ultimate business strategy. Many people only dabble in understanding their users. But research gives you an edge by uncovering information others miss, choose to ignore, or can’t find.

It lowers risk for the product, company, and yourself.

For example, you're going to invest $120k for a smart contract audit.

You’re told that if your product uses a smart contract, then this is a important investment to make. So you go ahead and find a vendor who can do it for you.

The vendor completes the audit, suggests some minor fixes, and gives you the green light to launch. The formal verification conducted by this vendor is important when the stakes are this high.

You then launch your product.

But let’s say, after launch, you realize that parts of your front-end experience are not working the way you intended it to. You notice that users are frustrated trying to do things on your product.

In a world where FUD can kill products, this is a problem. Frustrating experiences lead to people trusting your product less. And when people trust your product less, then you risk killing your business.

And so, even though your smart contracts are secure, it’s like they never existed at all, if the interface to those contracts doesn’t do it’s job.

That’s why conducting a formal UX verification is as important as a smart contract verification. Nobody wants the most frustrating way to do something. And so, save your users from that pain by verifying that your product is doing what it needs to.

Reach out to OpenUX to learn more about our 5-week formal UX verification service.

Research protects your biggest downside.

It clarifies your users goals. It uncovers what people are trying to do in certain situations instead of relying on opinions.

It is the ultimate form of “Don’t trust. Verify”. Maybe it’s time builders take their own medicine. Don’t trust your assumptions. Use research to verify them.

“Don’t trust. Verify with users.“

And once you verify, you’ll be able to avoid things that will cost you a lot of problems later down the line.

Your users don’t care about your goals, they care about theirs. So make it your goal to understand them and invest in helping your users reach their goals.

Verify that you’re understanding them.

If you do, they will pull you to greater heights.

Reason 3: UX Research protects your business by helping create better experiences.

Here are some facts about building products.

Products that fail to…

• Acquire people to use their product, fail.

• Retain those people, fail.

• Create value for those people, fail.

• Capture value from those people, fail.

Researching your users influences the types of failure you’ll experience.

It can help you:

• Discover where people are hanging out online and appropriate ways to get your offer in front of them. (Acquisition)

• Evaluate every part of your product so that churn becomes a "value" problem, not a "usability" problem (Retention)

• Understand peoples goals, constraints and contexts to see if your solution fits into their lives (Value Creation)

• Uncover how and if people will pay by running small experiments in the market (Value Capture)

And instead of failing in the market. You can fail in a “sandbox” where running experiments is your ticket to building something great.

For example, you’re trying to figure out how to grow.

But after spending time researching your users, you realize that growth isn’t your problem.

Retention is.

It’s like having a leaky bucket. You learn that a large chunk of new users coming in churn within 7 days of first use. And when you go to learn why, it’s because your product is confusing to use.

You already understand how to acquire more users. You’ve confirmed that you can capture value based on your value proposition. But the “Value Creation” and “Retention” piece are limiting your growth.

And so, to grow, it may actually be true that you have to work on preventing churn. So you invest resources to “plug the leaky bucket” and test again.

And again. And again.

You’re going to fail. It’s your choice where. In the market? Or in the sandbox?

Building something new and bringing it to market can be scary. But, you can reduce your anxiety by doing UX Research early and often, with support from experts. Like OpenUX.

Findings are used incorrectly because it isn’t immediately obvious what to do with them. It’s unclear what needs to happen next.

The root cause of this problem? Not knowing how to translate a finding into a clear decision or next step.

Translating research findings is a hard skill to master. Here’s why:

1. You need to trust in both the researcher and their process, which can be overwhelming

2. A “smart-sounding” finding can fool you. It’s hard to know what is credible without thinking deeply about a finding.

3. A finding alone doesn't dictate action; it requires interpretation to guide the next steps.

And so, while knowing how to translate findings is useful. It isn’t enough.

You also need to shift how you think about findings in the first place -- that way you can feel certain that you’re reliably translating findings.

Here’s how to think about findings so that you can reduce decision-making risk

1/ Before you start any research, develop a shared understanding of what findings are, why they’re important, and how they’ll be used.

The researcher is responsible for educating their team, advocating for the research, and establishing a strategy for translating findings. While there's no single 'right' way to interpret findings, it's essential that the team agrees on a specific approach.

Answer these questions:

• What is a finding? What is a finding not?

• Why are findings important?

• How can we apply what we learn? In response to our findings, what decisions might we need to make?

  • Consider the potential impact of your findings on your product or business strategy. What specific changes are you ready to undertake? Clearly define the range of changes you are willing to make in response to the research.

• In what contexts should our findings not be applied, and where are they most relevant?

  • Determine the limits of research findings. Recognize that findings relevant in one context may not transfer well to others.

Again, the goal is to make sure everyone thinks about findings in similar ways.

2/ Once your research is finished, translate findings into decisions

1 - Examine context

It’s easy to find facts. But it’s hard to figure out what those facts mean for your product/business. That takes a special skill. Without this skill, people will do what they can with the knowledge and biases they have to move forward. And this may not lead to favourable outcomes. This is why you need to examine context.

Why?

Because it’s risky to generalize a finding. And it’s even riskier to just “wing it”.

So, ask questions like:

• Does this finding fit in the context of the decision we need to make?

• Where does this finding not apply?

• What’s the “shelf-life” of this finding?

2 - Once you understand context, think critically about what needs to happen next.

Don’t make immediate and irreversible changes based on a research finding without first thinking about what the finding means. Avoid being reactive. Be reflective.

Reflect on the finding to figure out what it means for your business and the implications of applying this finding.

Ask questions like:

• What is the decision that needs to be made?

  • Why does it need to be made?

  • Is it the most important decision that needs to be made?

  • Is there finding x decision fit? Does the finding help inform the decision that needs to be made?

• If we use this finding, what are the knock-on effects?

• What are the risks of using this finding? What are the risks if we don’t use it?

Once you’ve gotten answers to these questions, and it still makes sense to act on the findings…

3 - Make the decision and move on.

If you’re a small-team building a new product, you don’t have 2 weeks to think about findings. As soon as you feel good about the decision, make it and move forward.

Your decision might mean a change to the product or business. It might also mean you need to do more research. Both are okay.

All that matters is that you make some type of decision because making no decision wastes a lot of time. Time that you may not have. So make the decision and move on to the next adventure.

Wrapping up

You now have everything you need to use user research findings correctly. The next time you need to do some user research, use these guidelines to help establish a shared understanding and reduce your decision-making risks.

If you need support applying findings, OpenUX offers complimentary office hours for products trying to level-up their UX practice. Click here to find time.

Here's a rundown of the most frequent issues you might encounter

1. Your screener doesn’t get filled out by participants

The problem: You've crafted a compelling offer and designed a sleek screener survey, yet you're not receiving any responses.

Potential solutions:

• Pilot the Screener: Test your screener with someone else to identify and correct potential misunderstandings or errors. Participants might be leaving due to confusion.

• Refine Your Messaging: Tailor your communication to resonate with your target audience. Ensure clarity and relevance by incorporating keywords and symbols that are meaningful to them. This helps to clarify why joining your study is beneficial and can significantly reduce the likelihood of your message being overlooked.

• Rethink Incentives: Carefully consider the incentives offered. They should be sufficiently motivating to encourage participants to complete the screener. If not, your participants won’t go through the hassle of filling out your screener.

• Explore Alternate Channels: If adjustments to the screener and incentives don't yield results, consider using a different distribution channel to reach potential participants.

2. Not enough qualified participants respond to your screener

The problem: Despite people filling out the screener, not enough participants meet the specific qualifications outlined in your participant profile.

Potential solutions:

• Adjust Qualifying Criteria: Check if your criteria are overly restrictive. If so, consider broadening them slightly to attract a broader range of participants.

• Keep All Responses: Avoid discarding responses, even from those who don't initially meet your qualifications. They might be helpful in the future.

• Switch Distribution Channels: If current efforts aren't attracting enough qualified participants, try using a different distribution channel to reach a broader audience.

  • Try using a recruitment panel like web3UX, despark, or userinterviews to broaden your reach.

3. People don’t show up to the calls they book with you

The problem: Participants are scheduling time with you but fail to attend the scheduled call.

Potential solutions:

• Over Recruit: To account for no-shows, book more participants than needed. For instance, if you need 10 participants, schedule appointments with 15.

• Send Reminder Emails: Email participants to remind them 12-24 hours before a scheduled call.

  • Use a message like: “… Reminder of your call booked on [date and time]. The researcher is counting on you being there. Please reply to this email confirming your attendance.”

• Minimize Time Gap: Ensure the interval between the booking and the actual session is short. A lengthy gap can lead to participants forgetting about the session.

• Limit Booking Window: Create a narrow window for session bookings. Aim to schedule sessions only within the next 3-5 days to reduce the chance of no-shows.

• Account for Time Zones: When scheduling calls, consider the time zones of your participants. If there's a significant difference, like between Asia and North America, schedule sessions at times that are feasible for both parties.

If you've tried these solutions and still need help, don't hesitate to consult a Web3 participant recruitment expert at OpenUX. They're ready to assist you with tailored strategies for your specific needs. Click here to get in touch.

Start by communicating your context, constraints, and goals.

For example, you’re unsure why a specific feature isn’t being used. And your team needs to decide whether to keep it in the product. The team speculates why this is happening, but no one can say for sure.

Your team has ten days to decide. Which means you need to figure this out quickly.

So you think about your options. One obvious solution would be to talk to the people who are and aren’t using the feature to find out what’s happening.

• What do they think it does?

• Why are they using it? Why are they not using it?

• What is it helping them do?

Goal = Learning why people are not using this feature so you can decide whether to keep it.

Context = Pressure from the team. Uncertainty around low/no usage.

Constraints = Need to decide in 10 days. Haven’t researched users before. Some members are skeptical about researching users.

People on your team need to understand the connection between the “problem” (ignorance around why people aren’t using a feature) and the “solution” (researching users) in order to buy-in.

2/ Answer the “so what?” question by tying user research outcomes to your team’s goals

For example, If your team aims to improve onboarding so that at least 25% of new users make a “valuable first action,” ground all discussions about researching users in that context.

Communicate outcomes of the research process that can help reach this goal.

“When we research we’ll learn what our users goals, pains, and needs are while onboarding which we can then use to make decisions about the current flow.“

This way, people understand that researching users is a tool that supports the team’s goals and not a intellectual exercise.

3/ Offer multiple options, clearly explain the trade-offs, and let your team pick one

Make the decision to research users easy.

All you need to do is give them four options:

1. Do nothing

   1. Pros

      1. It’s free!

      2. You don’t need to change anything

      3. A low energy/time commitment

   2. Cons

      1. You continue to build on risky assumptions that can eventually sink your business

      2. You’re forced to make decisions without reliable information

      3. You can’t figure out the “why” behind user behavior.

2. Do research yourself (Do-it-yourself)

   1. Pros

      1. The upfront cost is lower.

      2. You can control the research process

   2. Cons

      1. You can do it wrong

      2. High energy/time commitment with a potential for little return if the process is not executed correctly

      3. If you don’t have the relevant skills/experience, you risk not getting the answers you need.

3. Do research with the help of a research coach (Done-with-you)

   1. Pros

      1. Get coached by an expert (like our coaches at OpenUX)

      2. Get access to all the tools/expertise you need to execute research end-2-end

      3. Learn how to do the process yourself

   2. Cons

      1. There is an initial $ investment.

      2. High energy/time commitment

      3. You need to trust the coach

4. Hire/contract a researcher to do it for you (Done-for-you)

   1. Pros

      1. Very low time/energy commitment

      2. Get an expert researcher to do everything

      3. Get answers in the shortest amount of time

   2. Cons

      1. The highest investment

      2. You won’t learn how to do it yourself

If your team is still unconvinced, book a complementary OpenUX Office Hour session to walk through your situation and get guidance here.

UX Research isn't about understanding users. It's about minimizing risk.

The risks include building:

1. The wrong thing (market risk)

2. The thing wrong (execution risk)

3. Something nobody can use (usability risk)

If these risks aren’t minimized, if they aren’t dealt with. You put yourself, your company, and your vision at risk as well.

So research your potential users, customers, and stakeholders. It’s worth the investment.

Reach out to OpenUX to learn you can protect your biggest downside by researching users.

Table of Contents

• Introduction

• Why do research

• The PGP Framework

  • How to define a persona

  • How to define a persona’s goals

  • How to define a persona’s problems

• The Hackathon Method

  • How to recruit participants

  • How to conduct an interview

  • How to reflect on what you learned

  • How to present to hackathon judges

Introduction

Is the product you’re building valuable? Is it usable? Is it effective? Are you unsure how to go about answering these questions?

In this guide you’ll learn efficient ways to think like a UX researcher and de-risk your product idea. We wrote this article for hackathon participants, but anyone building a new product should be able to take advantage of these steps.

Let’s get started.

Why do research

Most solution ideas aren’t compelling to their intended users, and of the few that are, even fewer are shipped in a package that can scale.

The surest way to position your product idea for success is to get unbiased user feedback early and often.

And before you collect feedback, it’s wise to document how you think your solution solves a problem. Writing your assumptions down upfront will help you maximize how actionable your feedback sessions are.

The frameworks below include simple structures to document your assumptions, get immediate feedback, and build confidence in how well your idea fits the market.

The PGP Framework (Persona, Goal, Problem)

A simple way to understand a product’s impact is to define its target users, their goals, and the friction they run into when trying to achieve those goals.

Example:

1. Persona: A person getting paid in DAI who also has a debit card that spends ETH

2. Goal: Minimize fees when spending crypto on debit card

3. Problem: Transferring DAI to ETH is costly and time-consuming

An important step to any product research is to define these parameters, so you can identify the right kind people to give you feedback.

How to define a persona

To define a persona, ask yourself, what externally observable behaviors do expect users of your product will have? As much as you can, try to think of behaviors that meaningfully separate users you want to focus on vs. users you don’t.

Example:

• Onramps with MetaMask Buy

• Mints at least 1 NFT a month

• Uses Opensea as their primary marketplace

Do this now: Create a list of 5-10 behaviors that potential users exhibit. You’ll use these behaviors to determine who to talk to later. Feel free to give this persona a name, like “Defi Degen“, “NFT Artist“, etc…

How to define a persona’s goals

To define a persona’s goals, ask yourself, when your target user is in a particular context, which goal of theirs are you supporting?

Example:

• When NFT artists are listing digital art on a marketplace, they want to notify past collectors that new work is available.

• When DeFi degens are talking to their accountants during tax season, they want to share transaction history with accountants.

Do this now: Think about what types of goals your persona likely has. Don’t just pick any goal, think about the situations/contexts those users might find themselves in and think about what types of goals they have in those situations. Create a list of 1-5 goals.

How to define a persona’s problems

To define a persona’s problems, ask yourself, as your target user pursues the goal you’re focused on, what frictions or problems are they running into?

Example:

• When NFT artists want to notify past collectors that new work is available, they have to manually scan smart contract transactions to find all accounts who minted or bid on their work

• When DeFi degens want to share transaction history with accountants, they have to manually add currency outflows from multiple wallets

Do this now: Put yourself in the shoes of someone with the Goal in question. What types of behaviors, activities, or mindsets do they exhibit in pursuit of this goal, and what interrupts them? Which of these interruptions feel particularly meaningful to you? Create a list of 1–5 problems that you believe are most significant for your persona achieving their focused goal.

How PGP fits into your next steps

Once you define the PGP elements you’re building for, you can reference them when you look for people to talk to. Only invite people to talk to who share the goal you’re focused on. And if you want to get really specific, filter out people who don’t experience any of the problems.

The Hackathon Method (Recruit, Interview, Reflect)

The Hackathon method is an efficient way to get the most relevant people to give you actionable feedback in a short, in-person session.

At a high level you will:

• Recruit (Find users to test with)

• Interview (Test with users)

• Reflect (Examine what you learned and consider changes)

What follows is everything you need to execute this method with a high degree of confidence.

How to recruit participants

Hackathons are crowded events which is ideal for quick user feedback sessions. After following this guide, you should feel confident finding 5 people to talk to.

How to approach people

Before you start inviting people to give you feedback, there are a few things to keep in mind:

1. Most people aren’t there to test your product

2. Most people might not be a good fit

3. Most people might not have time to test with you

Asking for someone’s time is always hard. People come to these conferences for different reasons. Before you ask for 15 minutes of their time, take a few minutes to chat with them with them about conference and build rapport.

Example:

• Say hello: “Hey! My name is X, what’s your name?” [Response]. “Are you enjoying the conference so far?” [Response]. “That’s amazing to hear! We’re working on a submission for the hackathon, I was wondering if I could take 2 mins of your time to ask you few questions?”

• Qualify: If they say yes, you can start asking them your qualifying questions.

  • See the next section of this article for help writing qualifying questions

• Ask for 15 minutes: If they’re a good fit, you’re going to need a larger chunk of time to ask more pressing interview questions so you can get proper feedback. If they’re not a good fit, tell them thanks and look for someone else to speak with!

  • See the next section of this article for helping writing interview questions

• Reward: Our research shows that participants are much happier and will be more patient with you if they know they’re getting a reward for their time. Offer to buy them a coffee, a snack, or a free NFT. You can say something like, "Hey, I think you fit our user profile really well. Do you have 15-20 mins to help test our submission? I'd love to buy you a coffee or snack for your time. You'd really be helping us out."

How to qualify people

Once you’ve approached someone and they’ve agreed to spend 2 minutes with you, it’s time to ask them 3–5 qualifying questions to make sure they’re a good fit.

For example: Say your persona definition is MetaMask Users that have used the “buy” feature at least once before.

You might ask the following questions to determine if someone fits the definition or not.

• What wallet do you use?

• How long have you been using that wallet for?

• How do you get crypto into that wallet?

• Have you tried other ways to do this?

Note that we did not mention “MetaMask” or the “Buy” feature in any of the questions above. It’s always best to avoid giving away details that might bias your participant into accidentally giving you a wrong answer.

After asking your questions, it’ll be obvious whether the person you’re speaking with is a good fit. They may not even fit your definition fully, and that’s okay. As long as you’re taking time to qualify them in some way, you can be a bit flexible with participants.

Do this now: Put it all together. First, prepare your qualifying questions. Then, go talk to 5 people and ask them if they can spare 2 minutes of time. Ask your qualifying questions, and if they are a good fit, offer them a reward and your gratitude for spending 15 minutes with you.

How to conduct an interview

Understanding goals, behavior, and problem severity

One of the most important parts of a user feedback session is getting people to talk about their problems in context.

This isn’t therapy. You don’t need to learn about every problem that our participants have. The purpose of this section is to get unbiased answers on the following topics:

• How meaningful is the problem you’re focused for your audience?

• How does your audience solve the problem you’re focused on today, if at all?

You can’t just ask people these questions outright—you won’t get reliable answers. You need people to describe their personal goals, behaviors, and context without bias, THEN, you can infer how their answers impact your core questions.

How to ask about goals

Ask them about the Goals they have in your solutions general domain. Do they mention the ones you’re focused on without you mentioning it to them?

Examples:

What do you know about [solutions general domain]?

• “What do you know about onramping?“

When was the last time you [had X goal in solution general domain]?

• “When was the last time you had to convert FIAT to crypto?“

How to ask about behavior

Ask someone about the last time they did the Behavior you’re talking about. Do they mention it?

Example: Tell me about the last time you [did behavior + any relevant context]

• “Tell me about the last time you on-ramped into crypto.“

• “Walk me through the last time you minted an NFT. Where were you? Which tools did you use?“

How to ask about challenges

How painful is the problem for them? Ask them to rank it 1–5.

Example: Describe a challenge you faced while [doing some behavior to achieve a goal].

• “Describe a challenge you faced onramping into crypto.“

• “How much of a challenge was that for you on a scale from 1-5?“

• “Can you describe another challenge?”

As you ask participants questions about their goals, behaviors, and problems, there are a few important behaviors you should follow:

• Use open-ended questions (Rule of thumb: Avoid asking questions that are easy to reply “Yes” or “No” to)

• Avoid leading participants to answer in a certain way (The answer should not be implied in your question)

• Remind participants there are no right or wrong answers.

• Ask for examples from the past.

• Listen more than you talk.

Do this now: Put this all together to write a few questions exploring the goals, behaviors, and severity of problems your participants face. It might look something like this:

1. “When was the last time you had to convert FIAT to crypto?“

2. “Walk me through that experience. What prompted you to do it? Where were you? Which tools did you use?“

3. “Can you describe a challenge you faced while onramping?“

   1. “How much of a challenge was that for you on a scale from 1-5?“

   2. “Can you describe another challenge?”

Understanding solution “fit” and usability

Another important opportunity during a user feedback session is to get participants to actually use your product. This is your chance to test both the concept of your solution (how well it “fits” the problem you’re focused on), and how easy it is to use.

Provide a narrative to contextualize your tasks

You can’t just drop participants into your submission and ask them to figure it out. You have to create a realistic narrative for them to follow, and a specific task they should complete inside your solution. Here’s an example:

“Imagine you’re at the grocery store and you’re about to pay for your items. You realize the store accepts crypto payments and you recently installed a new app that lets you pay for grocery items with crypto from your phone. Open up the app and attempt to pay for your groceries. Take your time and speak out loud as you think about look around the interface. There are no wrong answers and we want your honest and direct feedback.”

As you give users tasks to complete, there are a few important behaviors you should follow:

• Remind them to think out loud as they navigate your solution. This is not a common behavior for most, so if they stop, continuously probe them to describe out loud what they think is happening, what will happen next, and how they’re feeling overall.

• Let your participant struggle in key places. You’re not trying to trouble-shoot your participants to success. Instead, you’re observing how they make sense of and ultimately use your solution. You will need to take the training wheels off to get the best feedback. Sometimes it’s best to shut your mouth and watch

• Remind your participant that you want honest feedback. Because you’re allowing users to struggle, it’s important to remind participants that they’re not being graded on performance. This is not a speedrun. Your goal is to have them complete the experience as naturally as possible.

Take notes on key moments during their experience

As you observe participants work through the tasks you provided from the section above, it’s wise to take notes on their thoughts and behaviors in a structured way. What you take notes on might change based on what you want to learn most, but here are some examples of things to write down for an average study:

Do this now: Pick 2-3 of the biggest tasks and write them down. You’ll be giving these to your users later. For example: If you’ve built a wallet, you’ll likely want users to test these tasks

• Initial Wallet Creation

• Sending Transactions

• Connecting to dApps

Starting your interviews

If you’ve read the sections above, you should be ready to start interviewing. Follow the guide below to kick things off.

Do this now: Here’s a quick checklist start your first interviews:

1. Define your Persona, Goal, and Problem (PGP Framework)

2. Prepare your Qualifying Questions (Recruit)

3. Prepare how you’ll approach new participants (Say hello, qualify, ask for 15 minutes, and offer reward)

4. Prepare your questions on Goals, Behaviors, and Problem Severity

5. Prepare the Tasks you’ll ask users to complete

6. Confirm your solution is ready to be tested

7. Prepare a notetaker to take notes on key moments during the usability test

8. Go out and find your first participants

9. Remember to thank your participants and reward them for their time

When you’re done with a few interviews, read the final section of this article to help you gather your insights and package them together into an actionable report.

How to reflect on what you learned

After a few interviews, compile your notes and look for themes spanning multiple participants. Discuss these with your teammates—people with different experiences may infer different insights from the same data.

Valuable

• How many users experience the problem you’re focused on?

• How severe do your users describe the problem you’re focused on?

• How well does your solution improve the problem you’re focused on?

Usable

• How successful are users at onboarding to your solution?

• How successful are users at navigating the core valuable experience of your solution?

Delightful

• What moments of your solution experience spark joy for your users?

• What aspects of your solution are so good they’ll motivate users to tell others about your solution?

How to present to hackathon judges

Most hackathon judges want to see you’ve taken some time to consider the value and usability of your solution. Once you’ve conducted interviews and reflected on your learnings, create a presentation slide that shares some of your conclusions.

As you create your slide, consider adding evidence from your user research that clarifies your points on value, usability, and delight. You may consider adding:

• Insightful quotes

  • Valuable: “I really use MetaMask Buy monthly and always struggle with it.“

  • Delightful: “I loved seeing transaction metadata displayed this way. I immediately understood where my coins were going.”

• Photos

  • If you can get consent, see if you can take a picture of your testing setup with your participants

• Screenshots

  • Include sections of your solutions where users ran into the most problems. Then show how you made changes that addressed those issues. A before and after will work well here.

Good luck!

Follow OpenUX for more content like this

OpenUX is an agency and community that envisions a world where web3 understands its users.

Join our community to meet likeminded builders, researchers, and strategists contributing expertise and promoting an ecosystem of open-source user research.

Hire us to conduct user research or trainings to help your team understand your users, improve your design, and achieve adoption.

Have more questions? Feel free to write to us at hello@openux.xyz.

Background

The team at OpenUX coached a working group of product and marketing teams from Hiro and Stacks to support them with a deep understanding of the potential target users for sBTC.

sBTC is a new Bitcoin synthetic derivative that has a decentralized, two-way peg mechanism with Bitcoin. It uses Stacks smart contracts to facilitate the movement of BTC in and out of Bitcoin layers in a trustless manner. DeFi applications are in development right now, which means BTC holders will soon be able to put their tokens to work, just as they can on Ethereum today, thereby unlocking utility for the large amounts of BTC currently idle in wallets and on exchanges.

Building for the unknown

The team hopes that sBTC will benefit two potential retail audiences; Bitcoiners  and Web3 DeFi users. The teams building sBTC are deeply immersed in the Bitcoin-sphere but, until engaging OpenUX, had conducted relatively little research around the more DeFi-savvy user profile.

Understanding these two audiences – what user needs, pains and goals are the same (and which are different) – was essential for reducing development risk and building the right products that are genuinely usable, useful and widely adopted.

From assumptions to deep learnings

Having conducted some research themselves in the past, the working group sought OpenUX as an expert to guide them through the process of gathering reliable and highly actionable findings that they could rely on.

The Coaching Program

• OpenUX worked with the team over an 8-week period. We created and led a workstream that progressed the team from assumptions and research questions all the way to deep insights widely shared within their ecosystem.

• The coaching was hands-on and collaborative. We had working sessions for writing recruitment copy and screeners, designing questions to ask in user interviews, and what framework to use for analysis.

• Each week included some best practice teachings, which were always grounded in the actual work to be done during that phase of the research.

• OpenUX led by example, sharing our own templates and ways of working, and conducted some of the user interviews to give the team a grounding in how best to run qualitative research sessions.

Research Outcomes

• The mixed-discipline team successfully completed their own research. Read the published findings by the sBTC team.

• The team landed on research-driven behavioral personas for their target users that aid decision-making.

• The sBTC team had a useful framework to help developers in their ecosystem (who were not involved in the research activity) make sense of the learnings and apply them to their own product use cases.

• By the end of the engagement, the team not only had reliable findings, but also had the templates, tools and frameworks they needed to be able to replicate the process without any hand-holding.

“Working with OpenUX was essential to the success of this research project. Georgia kept the team focused and on-track week over week, helping us break down a large, complex initiative into weekly, actionable steps.”

Elena Giralt, Sr Product Marketing Manager, Hiro

A few key learnings

The folks at Hiro and Stacks are committed to open sourcing their research findings, which is aligned with what we do at OpenUX. When research is widely shared, it provides more starting points for product teams who don’t have the skills or time to do this important work themselves, and lifts the entire web3 and crypto ecosystem.

You can read the full report here, and below we’ve pulled out 3 key learnings to share.

1. Bitcoin holders have an emotional attachment to their BTC, regardless of whether they identify as Bitcoiners or Web3 degens.

Regardless of what they do in crypto now, many experienced web3 users started off in the space by buying Bitcoin. As such, it holds a special place in their hearts; it marks their entry into the space, and due to lack of utility, a lot of users have not done much with it other than accumulating it or just hodling it.

“Bitcoin is the first crypto I’ve bought and never sold. I’ve not sold it out of respect. Bitcoin is a very philosophical idea, it’s more than money for me. It’s a message. Ethereum is where you can play around, it’s more like a playground.”

This means that whether Bitcoin maxis or Web3 DeFi users, products that ask users to move their BTC out of cold storage must speak to this emotional attachment, and make users feel good about putting it to work. The launch of Bitcoin Ordinals has reignited interest in "using" Bitcoin for many, so there’s precedent here, but it won't hurt product teams to consider how their positioning and marketing resonates with the “respect” users feel about their Bitcoin in order to encourage users to make use of new BTC protocols.

2. Trust/Security and Financial Opportunity are more important than a Bitcoin-first UX design

The team used the “Trade-off Triad” method to test potential product trade-offs with users. We presented them with a visual, and asked users to place an icon where they felt they best sat between 3 opposing product features, whilst explaining their thoughts.

We analysed the clusters where users placed their markers on the triangle, and listened to the rationale as they explained their choice between the trade-offs. When considering a Bitcoin first UX, Financial Opportunity, and Trust/ Security Design, most people said that financial opportunity and security design were the most important factors in deciding to use a new BTC DeFi product. Only a few mentioned the Bitcoin-First experience, if at all.

This means that any product utilizing BTC must be laser focussed on trust and security design in order to encourage users to adopt, and the financial opportunity has to be worth it for them to use their treasured BTC. These 2 factors trump UI designs that feel Bitcoin-native.

3. Decentralized lending and borrowing options are the unmet need for BTC holders

For many holders, the risk-to-ratio of lending their BTC on a centralized exchange doesn’t make a lot of sense, especially given what we know about their emotional attachment to BTC, the (comparatively) low returns on lending BTC with exchanges, and the recent exchange closures and risks.

When we interviewed users, the biggest unmet need was a way to earn interest on, or borrow from, their BTC – without counterparty risk.

This is good news for the Stacks team and Bitcoin DeFi builders as it confirms their hypothesis that a programmable Bitcoin could be widely adopted - if built and communicated the right way for users.

What next for sBTC?

• The Hiro and Stacks team are continuing with user research discovery, using the tools they learned through coaching to conduct interviews with developers in their community.

• They’re using frameworks to help product teams building in the Stacks ecosystem to come to actions from the findings.

Talk to OpenUX about coaching

To learn more about getting your team from assumptions to reliable insights, drop us a line, we’re happy to share advice and explore how coaching might work for you: hello@openux.xyz

In the fast-paced world of crypto, where innovation often outpaces understanding, user research can be a critical — but often overlooked — tool for building successful decentralized finance (DeFi) projects.

Glif, a project within the Filecoin ecosystem, conducted user research before writing any code for their new staking protocol, unearthing valuable insights which guided their purposeful building process.

In this article, we explore the significance of this approach, highlight its crucial role, and unveil some of the insights into the unique needs of Filecoin users.

The Filecoin challenge (and opportunity)

Filecoin, created by Protocol Labs (the people behind IPFS) is a blockchain that allows for distributed file storage. People “mining” Filecoin are known as Storage Providers — they store data, verify they’re doing so on the network, and get rewarded. But they have to stake FIL tokens as part of this process — this means that if they go offline or delete the data, they lose some of their stake. This consensus mechanism keeps the network running.

Until lately, the Flecoin network has suffered from a “Capital Efficiency” problem; FIL tokens are locked up in centralized exchanges or in cold wallets (users to date have had nothing better to do with their tokens!), whilst Storage Providers have had to borrow FIL through centralized lenders, which is costly.

The Filecoin Virtual Machine (the smart contract layer that allows for programmable applications as we see today on Ethereum) went live in March 2023, and now DeFi applications can solve this capital efficiency problem, by allowing for non-custodial interactions between holders and Storage Providers; token holders don’t have to trust a centralized entity with their funds, they can use DeFi protocols to earn rewards, and miners now have more borrowing options.

OpenUX co-founder Georgia Rakusen has been working with Glif for over a year; they’re a team that has been building in the Filecoin space for over 4 years, and has launched multiple Filecoin-related tools, including a native wallet and vital infrastructure. Glif has just launched their own DeFi protocol. And the results of their efforts have come from deeply understanding their users.

Conducting user research before writing code

Bringing on a User Researcher before writing any code is very unusual in the web3 space, and especially in DeFi, where the needs of users are thought to be well understood — token holders want a trusted place to earn yield on their funds, and borrowers want good terms and low collateral when taking out loans. Simple, right?

However, the Glif team had a hunch that building a copy-paste DeFi protocol as we see on other networks wasn’t the right approach. They suspected that Filecoin users are somewhat different from your average DeFi user. And user research confirmed this.

Since May 2022, Georgia has run multiple rounds of user research with >50 profiled study participants (roughly an equal mix of Filecoin holders and Storage Providers). She used mixed research methods for better triangulation of data, beginning with 1–1 discovery interviews and surveys, moving onto early concept testing, and finishing with in-depth user testing of the Glif landing page, app interfaces and journeys via prototypes.

The outcomes of this research have informed the design of the Glif DeFi protocol at a protocol level, not just the interface designs for end users. It’s allowed the team to

• Design the protocol around the needs, pains and motivations of those end users

• Design user journeys and interfaces that actually work for these audiences

• Build faster, and with confidence

We’re very happy Glif sees the value in open sourcing some of the research insights, and we hope that sharing the following learnings proves an effective model for raising the bar for new DeFi projects for the whole Filecoin ecosystem (and beyond).

Learnings about Filecoin users

1: There’s a real problem to solve for both Storage Providers and Filecoin holders

We interviewed Filecoin Storage Providers of all sizes, from hobbyists to some of the world’s largest commercial setups. We learned that borrowing FIL to run their mining operation was the most expensive cost for all Storage Providers. Current options for borrowing FIL don’t work well for them; the loan terms aren’t favorable, the minimum borrow amounts are too high for some, and they must give over control of their miner to the centralized lender (a technical necessity). These Storage Providers want to grow their operations, and often have file storage space waiting to be put to use — but without the FIL they need to do this.

“If I can get the loan without [giving up] miner keys it would be great!”

“The difference with [CeFi lenders] is that I have to share my miner owner key, and I was not interested in doing that with them; that’s one of the reasons I’m not using them”

“Assuming that there are no catches, nothing would stop us from using [a DeFi option]… If this was available now, yeah let’s do it….”

For FIL token holders, especially those who are ethos-driven, they really want Filecoin to succeed and are looking for a way to put their FIL to work in a way that genuinely benefits the ecosystem.

“I first acquired FIL 18 months ago. I bought it on Kraken and then switched it to Gemini for the return. The rate was good but I could see Gemini was getting a lot from it. And I didn’t like that my money wasn’t secure with them. I felt worried about it disappearing tomorrow [due to recent CeFi concerns]… I have moved it to my cold wallet. It’s nice that it’s secure now, but there’s nothing I can do with my FIL*.”***

“I want to loan it out so that Storage Providers can make Filecoin a better protocol. I want the ecosystem to improve. I don’t plan on exchanging my FIL so why not put it to work?”

“What’s missing? Staking. The Filecoin Virtual Machine is adding the logic layer which will unlock staking and yield farming. I would love to stake.”

2: A Filecoin DeFi protocol needs to work for a less DeFi-savvy audience

Storage Providers have specialized knowledge around hardware and storage solutions. They’re into mining FIL because it aligns with their interests or makes for a financially sustainable business, and in many cases mining FIL is their only crypto activity. They tend to be more risk averse and less knowledgeable about the elements of web3 that require trust in decentralized services, and may have never participated in DeFi before.

Many FIL holders own a small amount of the token as part of their total crypto portfolio, but for larger holders often Filecoin is their only crypto holding. These types of people are use-case driven, with a strong belief in distributed file storage — but this means they’re unlikely to have tried out much in web3, or have familiarity with DeFi.

Some of our interview participants who were holding a large amount of FIL had never owned or used a web3 wallet. These users are not looking for maximum rewards, they want something easy to use that they can trust.

“I’ve done research into high yield lending on Ethereum and came to the conclusion it’s not for me. I believe in ‘get rich slow’ schemes!”

3: Supporting users to feel safe and understand risk should be a builder’s primary concern

Glif’s potential users are fearful of trying something new, more so than the typical web3-native DeFi user.

Storage Providers are eager for FIL and if the borrowing terms are good (and they maintain ownership of their miner) then they’re up for trying a new lender, but they have a lot of educational and onboarding needs.

Risk is felt more strongly for people lending out their FIL, and the lack of trust in decentralized services is a huge obstacle for adoption.

“My initial thought is how on earth could [a DeFi offering] be possible? It’s so good I almost don’t trust it. I don’t see how that could be financially viable for investors. I don’t trust it.”

“I want to experience it, seeing is believing.”

Trust is earned by:

• Communicating risk and safety in a simple to understand way

• Designing interfaces that speak to the user in their own terminology, and are easy to use.

• Not hiding interfaces behind ‘connect wallet’ modals.

• Creating ‘try before you buy’ demos, such as video tutorials, to demystify the entire process of using the product — and web3.

• Having named individuals responsible for the project (not hiding behind anonymity)

• Humanizing the engagement with potential users through social channels.

• Surfacing the results of rigorous smart contract audits.

What next for Glif

As Glif continues to build its DeFi product and iteratively improve, they will be addressing all of these concerns, and many more rounds of user research are in the works to test the solutions they develop.

“Aside from knowing with certainty about the direction we were headed, injecting real user data into our development process enabled us to rapidly hone in on a specific solution. We think our approach demonstrates the value of getting out of our own web3 bubbles by researching with people outside of our network.” (Jon Schwartz, Glif)

In conclusion

Glif’s decision to prioritize user research over code, and the subsequent learnings, demonstrates the importance of understanding and addressing the specific needs of users from the outset, rather than building for an imagined “DeFi user.”

Embracing user research as a fundamental pillar of development raises the bar for new DeFi projects, leading to products that empower and serve the needs of real people.

Teams looking to launch DeFi projects in emergent ecosystems can get in touch with OpenUX to see how deeply understanding your users can support better decision-making, and more effective product development.

Read the full user research report, or scroll on for a high level summary.

Layer 1 protocols (L1s) have bold growth ambitions, and NEAR is no exception. But the growing number of L1s are fighting for attention — and funds — from the same pool of existing web3 users (without more compelling use cases and easier onboarding, adoption by non-crypto users remains a ‘one day’ goal).

We talk regularly in web3 about increasing adoption, but projects and protocols are swamped by the loud voices of those already onboarded and engaged. The problem of being too close to one’s own ecosystem and its existing users is that teams can forget to focus on the groups of people who have not yet adopted. What dissenting voices, naysayers and apathetic users are being consulted to understand their experiences, and attract that audience?

The OpenUX research approach

In January 2023, NEAR Foundation awarded OpenUX a grant to conduct exploratory user research that would benefit them and the broader ecosystem of builders. We decided to focus our user research study on the experiences of users who are brand new to the ecosystem, and investigate the discovery, research and onboarding phases of their journeys.

We recruited participants to the study, interviewed them, and then observed them going through the process of discovering and learning about NEAR, and then trying (and mostly failing) to onboard themselves. We began with users looking at tweets from NEAR (Twitter is a popular starting point for the discovery of new crypto projects). They then spent around 40 minutes visiting anywhere they liked on the internet to research what NEAR is, and whether it was right for them, all the way up to attempting to engage with a dApp.

We recruited our participants via Web3UX. The participants were those already well-versed in web3, actively transacting and engaging on other protocols, but had never used NEAR and in most cases knew very little about it.

Some key learnings

• L1 ecosystems like NEAR need to adequately address all types of users in their messaging, not just developers. Dedication to attracting ecosystem builders can lead to off-putting messaging and poor signposting for the average web3 user (and we know from previous research for NEAR that developers are disappointed to be building in an ecosystem with few users).

• Open and distributed protocol teams without a coherent UX and comms strategy end up with fragmented domains and products all across the web that cause confusion in the mind of the end user. The tooling and website documentation created at launch of a protocol or service that is “good enough” for motivated early adopters often gets forgotten about as more ambitious projects are initiated internally, and these legacy artefacts — no longer fit for purpose — become a hindrance to new users. The best messaging and documentation may be hidden deep within a site. How much should we expect of a brand new user to deeply research a new protocol when they may be already satisfied with the other options available to them?

• Users want to understand uniqueness, use cases, backers and partners, and what real projects they can interact with. They need very clear ‘what next’ CTAs.

• Trust remains key. Personal recommendations are the number one driver for whether a user decides to use a network or not.

• “Try before you buy” experiences are essential for new users in a world where it costs real money to make interactions. If an L1 requires the user to hold a specific token just to sign into a dApp (you need $NEAR to sign in, not just to transact!), then the battle to onboard new users is even harder. The requirement for a user to commit to exchanging crypto into a new token, or on-ramping via fiat, in order to just to tell if a product or network is worth using is a huge ask. This is why Product Design and Protocol Design should go hand-in-hand; users should not be an afterthought after the code has been written.

Read the full user research report for detailed findings and recommendations.

Why ecosystem research like this is important

User research like this widens our perspectives, providing fresh eyes on all the elements of the user journey that we take for granted. L1s are in a unique position to conduct holistic user research; every part of the experience is important to them, not just a singular wallet, dApp or informational website. Individual teams will (hopefully) run their own robust UX research to optimise their part of the journey, but who’s looking at the big picture?

We encourage all web3 ecosystem foundations to conduct deep user testing of the experiences of new users. If you’re interested in speaking with OpenUX about how user research can support your own adoption goals, reach out to us.

And lastly, it’s the ambition of OpenUX to publish as much research as possible in order to equip the entire crypto and web3 ecosystem with robust and reliable insights. What published research would people like to see in the future? Let us know in the comments.

That’s the vision of OpenUX, a collective of product and user researchers working to make crypto applications more needs-based and user-aligned.

By conducting tactical user research, training teams to fulfill their own data needs, and publishing open source insights, we exist to accelerate web3 adoption.

Crypto has an adoption problem

Most people working in crypto have considered the question: what will it take for crypto to reach the next 100M users? How can we accelerate adoption and keep new users engaged long-term? Instead of exploring how we get to 100M users, OpenUX has been considering, what is holding us back?

2021 and 2022 brought an influx of designers, developers, and product people to web3—many with valuable experience launching high-adoption consumer applications. Yet despite this new wave of talent, many web3 teams still struggle to chart a path to product-market fit.

We believe the biggest barriers to adoption are not limitations in technology, creativity, or effort; they’re oversights in how web3 product development is coordinated. More specifically, we believe web3 teams are taking unnecessary risks by undervaluing the user research and discovery process.

The costs of poor discovery

Many teams who undervalue discovery only collect user feedback after a product is developed. Others will address surface-level usability risks but skip testing foundational assumptions of how well their product addresses user needs.

Some builders justify this approach with claims that time spent on discovery has too big an opportunity cost. Others say that user feedback only pushes teams away from novel use cases that crypto is pursuing.

These beliefs fundamentally miss the value of research in an assumption-driven, iterative development process. By testing assumptions about user demand after multiple development cycles, teams delay resolving their products’ biggest risks. This can lead to several negative outcomes, such as:

• Building a product without an audience

• Building a complicated product for too many audiences

• Building a product with a misaligned audience

• Building an unusable product

When these issues compound, teams get fewer chances to work on solutions with realistic paths to adoption. This leads to web3’s collective ‘brain drain’—the misdirection of talent away from products that will reach 100M users.

OpenUX is pursuing user research as a public good

OpenUX is a collective of product and user researchers helping teams build widely adopted, delightful, and valuable web3 applications. We invest in research, training, and other projects that proliferate the meme that user research is a public good.

Our launch is inspired by many institutions who’ve come before us. As a metalabel producing research artifacts, we aim to meet standards set by W3C, Nielsen Norman Group, and Other Internet. As a decentralized network of web3 contributors, we’re motivated by our colleagues at VectorDAO and Water & Music.

Towards our mission, our operations are structured as follows:

Teaching better discovery methods

Just as many founders benefit from financial literacy training, we believe many web3 builders would benefit from product discovery training. OpenUX is assembling a team of some of the brightest user research and discovery experts to lead seminars, office hours, and training for teams on the following subjects:

• Recruiting a relevant user base

• Writing testable assumptions and hypotheses

• Conducting unbiased interviews

• Designing actionable experiments

• Running a cost-effective discovery process

If you’re interested in joining trainings in these subjects, we’d love to hear from you.

Running bespoke studies

OpenUX has been running private research studies for crypto protocols and startups. Today we’re excited to announce our first public study through the NEAR Foundation.

If you’re interested in working with us on a research study, please tell us more about your project.

We’re also recruiting researchers to collaborate with us on client studies and other projects. If you’re a researcher with capacity for work in 2023 and you feel aligned with this post, we’d love for you to apply to do research with OpenUX.

Curating open and accessible research

Today, many permissionless DAOs and developer ecosystems are recognizing the value of community empowerment over short-term information asymmetry. In pursuit of user research as a public good, OpenUX is publishing open and anonymized studies and encouraging our partners to do the same.

We believe that a subset of user research insights—especially those rooted in deductions on human behavior—can be extremely valuable to other builders. We also recognize that most published research today is neither accessible nor actionable for most teams. OpenUX will spend 2023 collaborating with partners to make our research more digestible and reusable for web3 builders.

If you do research with a web3 product or community, let’s talk about collaborating!

Get involved!

There are many ways to get involved with OpenUX:

• 🔍 Apply to be an OpenUX researcher

• 📝 Inquire about user research studies or training

• 🤝 Collaborate with us on publishing open research

• 🐦 Follow us on Twitter

• 👾Join our community in Discord

For ongoing updates, please subscribe to this publication: