Elevating developer experience in web3

Speaker

Olia Dukova

Job title

Dev Experience and Ecosystem Growth

Company

Event

DevRelCon London 2023

In this talk from DevRelCon London 2023, Olia Dukova discusses the importance of evaluating and improving developer experience in the Web3 space. She explores the key components of developer experience, including ecosystem, technology, and community, and provides insights on how to create a positive and supportive environment for developers.

Olia also highlights emerging trends in developer experience and emphasizes the importance of focusing on the human experience in Web3.

Watch the video

Watch the video on YouTube >

Key takeaways

  • Developer experience in Web3 is about making it easy for developers to use technology and feel good about themselves.
  • The Web3 ecosystem is still fragmented, making it difficult for developers to navigate and use platforms effectively.
  • When designing developer experience, it’s important to consider the different types of developers and their motivations, interests, and skill sets.
  • Emotions play a key role in developer experience, and it’s important to understand and address the feelings of developers.
  • The three main components of developer experience in Web3 are ecosystem, technology, and community.

Transcript

Ben Greenberg:

We are delighted to have the first talk of the first Web3 track at DevRelCon by none other than Olia who’s going to be sharing with us amazing insights about evaluating developer experience in Web3 best practices and emerging trends. Please give a round of applause for Olia standing ovation.

Olia Dukova:

Thanks Ben. Thanks for the introduction.

Right. Welcome everyone. I’ll start with a bit of gratitude. I’m grateful for you all to be here today in this first ever Web3 track at DevRelCon, and in the next half an hour, 40 minutes, we’ll be talking about elevating develop experience. So as Ben introduced me, my name is Olia. I’ve been working in developer relations for just over a decade by now, and fairly recently I’ve moved to the known of the Web3 World. So this was me probably about two years ago. So in the stock, I’ll be sharing lessons I’ve learned and my personal experience in building developer experience this technology along the way. So let’s start with the basics. Experience is something that happens to you that affects how you feel. Very simple, but I encourage you all to have that nation in mind throughout this talk, but also when you work on your own developer experience strategies within the web. Three, when we talk about developer experience in generally in simple terms, it is an initiative to make it easy for developers to use our technology and feel good about themselves. Oh, I just love the things. Don’t think it’s amazing. You can actually give somebody brownie points by pressing a green button, which takes bit of a second. I was at the airport recently and i’s not judgment going for the red one just because his back got an extra search I thought was really quite unfair. But anyways, I’m getting a attention there. This is all great that when we measure how a person is feeling about the service, so our client or customer, a developer in our context in particular, but what’s the problem with this?

We don’t know why they’re feeling a certain way. We know they might not be feeling great about the experience, but we can’t really change and make them feel better because we don’t know the reasons.

So before we dive in into different components of developer experience in the Web3, I would like to just give a little bit of a context. So we currently estimate about 23,000 to 120,000 according to different sources, excuse me, of Web3 developers in the world. And the law figure was taken from looking at open source contributions and they’re 120 is more across other blog posts and white papers, whereas the entire developer population is approaching 30 million. So we are looking at about 0.4% of Web3 developers. So why is that? I do strongly believe that the developer experience in Web3 is still very quite fragmented. So the Web3 ecosystem is growing pretty fast with all the different blockchain networks emerging, but they all have different consensus mechanism, functionalities, features, which makes it really quite hard for developers to navigate and use the platforms effectively.

So before we dive into different ways on how we can help those developers on their journey, learning about Web3 technologies and our tool and in particular something very important to think about is who those developers actually are. Because one label for web developers and we hear that a lot is quite misleading because everybody’s got different motivations, interests, skill sets, and in Web3 that goes even further. So I think this is quite a useful way of looking at the developer audience when you are building developer experience for your developers. So we’ve got on one axis we’ve got exposure to Web3 technologies in general, and then we’ve got another axis where we’ve got experience with your product service protocol, whatever it might be. So kind of in the top left quadrant, we’ve got a developer audience who don’t really know much about your technologies, but also act pretty much clueless about Web3 in general.

So when you design a developer experience for that audience, something to have in mind is that it will be useful to provide additional materials and educational resources for them to understand how the different pieces of Web3 infrastructure fit together. On the bottom right, we’ve got a developer audience that understand already and have had exposure to Web3 technologies but don’t know much about your product. And from what I’ve seen working in develop experience like across Web3, this group is the most stagger that everybody wants a slice of that kind of developer community. But the thing is remember the 0.4%, they’re really not that many of them. So we kind of all end up going after the same people. And I don’t necessarily say that we shouldn’t focus on those developers, but just something to have in mind that this is a bit of a harder group I guess to get on board because there’s not that many of them.

And then top right, we’ve got another group of developers that already have experience with Web3 and also with your protocol or projects in particular. So when we think about develop experience for them, they might be forgiving that you’ve got a lack of education resources in one place or the other for them, they’re already building something for them. What’s important is you helping them bring their project further. So when we imagine the usual funnel of developer position and we start with we creating awareness with Web3, what I find it doesn’t really when the technology is implemented or deployed, it doesn’t finish there. It is just the top of the pyramid, which would call developer success, where we’d encourage you to really help those projects to start building their communities and perhaps they could need some grants or funding. So sometimes it’s more sort of introduction to partnerships. So they’re building, they’re there, but they still need that extra lift.

Going back to emotions as I already mentioned. But I do think that’s very important. They do play a key role in developer experience and I just wanted to illustrate a few examples of what those emotions could be. So we’ve got positive ones such as satisfaction, relief, excitement, pride, when they’ve built something and it is working. And on the negative side, we’ve got boredom, anxiety, confusion, sometimes even impostor. So these are all very useful thoughts to have in mind when you design your developer experience. And the way the easiest, this is a very easy framework. There’s literally four questions to answer, but it would really help you to build a roadmap for evaluating and making that experience better for your audience. So the first question to ask is what are the developers feelings? So remember, it’s all about the feelings. Why the feeling that way? What do you want them to feel instead and how are you going to get there?

So the main three components in Web3 developer experience to me are ecosystem, technology and community. And we’ll dive in all these components deeper. But before that, I would just like you to show how you evaluate the developer experience that you’ve got and the feelings that developers experience at this particular moment and to make sure your strategy takes them from where they are to where they want to be. So we evaluate and answer all those questions that I’ve just mentioned across ecosystem, technology and community. I’ve put a couple examples here. So we’ll start with a positive. So for example, developers are feeling intrigued about your protocol, your tech, your project, why perhaps you capture their attention in one way or the other. Maybe it was a Twitter space for somebody with a partner. So you kind of tapped into new developer communities, now they know about you, now they’re excited.

So from there, from atric, you want them to take them to be enthusiastic, to actually get closer to your community and perhaps you start building relatively soon. A way to get them from Atric to enthusiastic would be provide more inspiration. And an example of that would be organize perhaps an online event and invite your ecosystem projects that are already building and have done something successfully so that they can showcase what they’ve done and then that way newcomers would get more enthusiastic and hopefully will stick and become a part of your community. Another example for technology. So confused is a very common emotion that developers experience in Web3. I see that a lot. And that could be actually nothing to do with your particular technology. It actually could be insufficient technical background in general when it comes to Web3 from Confused, let’s say you want to take them to confidence so they’re ready, they believe that they can do it and they’re excited about building.

So one of the ways to do that could be assisted learning paths. As an example, we’ll take Academy and I’ll talk about academies later. And the way you evaluate it, you look at successful academic graduates. The final example I’ve got here is community. Again, a very common emotion experienced by developers when they get dropped to the discord server of a protocol or a project for the first time. Overwhelmed. Why is that? Because there’s too much noise and it’s really hard to navigate. So developers feel lost. So instead of overwhelmed, you’d like to get them to welcomed. And a way to do that could be structure your communication channels better and enhance the onboarding so they know exactly where to go, who is who, et cetera. And the way to measure that could be stickiness. Okay, now let’s dive in into the three main components I mentioned before, and I’ll start with the ecosystem.

I think actually ecosystem is probably one of the most used terms in Web3, maybe decentralized, but actually, and we really get accustomed to really quite quickly. But for newcomers it could be a bit confusing. What is this all about? And it doesn’t get easier when you look up ecosystem maps for Web3. So I’ve got three examples here. The first one is we see a Web3 ecosystem by functionality. The next one is also about functionality, but that’s just New York. Look at that. And then I’ve also included Cosmos Network as an example. Here it’s a bit easier to read, but imagine as a newcomer you’re trying to figure out what Web3 ecosystem actually is and then that’s what you see.

But it is a very, here we go, it is a very important nation though, and that’s why I started talking about the ecosystem first because this could be controversial, but I do believe that technology will become commoditized and ecosystem is actually the differentiator. And it’s very important to make sure that the first encounter with your ecosystem is positive. There are absolutely a few examples already in the Web3 space of when the culture goes sour within a certain particular ecosystem and then the amount of developers joining or the entry is just plummeted just because they don’t agree with values or the project is going and it happens all the time. So it’s very important to make sure that you’ve got a strong system with strong culture. And actually I do believe that develop experience in what? Three stats with non-technical questions. And that’s when developers are violating your system. So this is some of the examples that they could be asking before they actually even get to see your technical product, the documentation or whatever that might be. So can I trust this tech? Who are the people behind this? Have others already been successful? So you do need to make sure that you’ve got strong answers for all those questions before developers even get to your tech stack.

When it comes to Web3, ecosystem in general also. And when developers are evaluating whether they would like to join and be a part of it, a very important nation is interoperability. Why? So the Web3 ecosystem is growing and expanding really, really at fast paced. And we do see all those blockchain networks protocols emerging, but there’s so much difference between languages that smart contracts are written in consensus mechanisms, et cetera. And then it really becomes hard for developers to navigate and something to really pay attention to within your ecosystem is the interoperability where the notion of when the protocols, decentralized applications, blockchain networks can seamlessly interact with each other and communicate. So a few things there the Interability helps you solve is fragmentation, medication, ecosystem, growth, standardization and governments. Very important in Web3, scalability, resource optimization. I want to invent a login again that kind of do you need to provide the office with multiple choices of whatever stack they’d like to use. And of course there’s global accessibility.

Let’s move to technology. So from personal experience for developers to justify the time and efforts they spent learning about your tech and actually becoming a part of your community, the technology needs to be feasible, reliable, scalable, secure, and decentralized. And I’ll start with the docs, which is part of your technical offering. So the documentation is not a learning resource. I see this a lot in Web3. I think a lot of think protocols and projects confuse the documentation with learning resources. And I think the reason for that is that as we mentioned, there’s a lot of developers who actually do need additional context on how the whole web stack works within the Web3 and how all the different pieces fit together and the background, but it shouldn’t really and see all that information being dumped into the docks and then the dogs become very cluttered. Whereas I do encourage you to think of documentation as reference rather than a learning resource and keep it nice and clean.

I do remember I was talking a lot previously about actually when we provide information externally. So when we link from our docs elsewhere onto our blog or I dunno, maybe even like a blog on a third party platform, that we lose our developers because in their journey they kind of leave the docs, they go somewhere else and then they never come back. But I think in Web3 in particular, as long as the journey is clear, this is actually a better way of presenting that additional context. Some of the other common challenges with the documentation in Web3 space as rapidly evolving landscape fragmentation information when it’s all a bit messy, lack of standardization, assumption of prior knowledge missing practical examples, developers do learn by doing and understand obviously better when there is a clear example of how something works. Lack of interactive learning. Another one, overwhelming technical details. The other flip side of the coin here, and limited contribution and collaboration. So to make our docs better, we do need feedback from developers, whether it’s through pull requests or you actually actively collecting feedback with other service.

A few ideas on how to make sure your docs are great, identify your audience at the start. And we did talk about, so you do really need to provide a clear structure for all those developers or the developers that you particularly targeting in that the access that we were looking at. Start with the basics, define the scope. And when I say start with the basics, I don’t necessarily mean explain what a blockchain is, but do you start with the basics of your protocol projects, define the scope of that interactive content. And visuals always go a long way. External resources and references, this is what I mentioned before. So absolutely the extra context does help just not within the docs and feedback and engagement, right? Moving on to education. So whenever we’re building educational path as part of developer experience, I think one of the most important things to remember is that time as developers most precious resource.

And it is really important to try and adjust and make that learning journey for them as quick as possible with providing all the information they need. And we’ll start with a few self-paced learning journeys, tutorials and walkthroughs as the basics we always had them. Podcasts I think is really quite something important for Web3 in particular because when developers learn about a new protocol or maybe a new interrupt solution, scaling solution, quite often podcasts is where they turn to learn about it because I guess it’s interesting to hear maybe the founders of the projects talk about what they’re trying to take it, what the goals are. There’s some really great ones. I think one of my favorite examples is bear chain really quite entertaining also. But yeah, highly recommended video content is another one. So YouTube is the king. So again, a lot of developers would turn to YouTube to find out about the projects before they actually dive into your docs and your properties on their website.

And it’s a more traditional self based journeys such as code snippets, sample projects and ecosystem projects. So if you do have projects that are already successfully built with your protocol or with your technology, do create content about it. So develops also will learn from somebody else’s journey. Assisted learning paths. So we have academy very popular in the web, three virtual classrooms Quest. So if the zombies and things like that really work a trait again, so I remember we always used to say that when we create educational content for developers, it needs to be entertaining and educational, so entertainment.

So something to have in mind there. Video series, project-based learning. So developers actually get to build something and in real light workshops, I just realized when I started doing this presentation, I was like, I’ll avoid any bullet points. And I think I did the first third of it and then sadly, I apologize for all the bullet points. I’ve got some always had some weird fascination with another list I think. All right, I did say talk a little bit in academies in particular because I do think in Web3 they go a long way because there’s so much additional context and then it’s a really great way to take developers from zero to hero by providing structured learning course, but also helps you to create a strong brand presence and community around the tech.

So why would developers join academies? The curriculum is comprehensive, expert interaction, experience, community interaction, all the great things that come when you learn something in a community way as part of a cohort. Something important here is also certifications in portfolio buildings. For those developers focused on career, that is very important to be able to show their achievements and demonstrate that they know how the tech works. A few suggestions with academy. So curriculum, it really depends on the technology and I guess the volume of information you want to fit into the course. But generally I think if it’s a online sort of remote learning path, so maybe about between seven and 10 hours a week that you can assume the developers can spend screening highly recommended. But I do encourage you to not dwell too much on the prior knowledge of Web3 because you’re eliminating a lot of developers that way.

Interactive learning of course. So it’s not going to just sitting through lectures or white papers of how things work, but they do really need to build things. Progress tracking, support channels. Support channels is actually a very interesting one. I do recommend. I think it’s really, really important to set expectations for developers, how and when you can support them because there’s nothing worse than frustrated developers and you’re waiting for the question to be answered and then you’re out of office until Monday. And certification I mentioned is really quite important for developers who are learning in particular tech with a goal to perhaps start a career working as a Web3 developer in that particular system. A few examples of really good academies, it might be a bit bias here, but we’ve got the bulk of Blockchain academy near and customers. Intertainment Developer Academy is also a great course.

It’s kind the best I’ve seen across the industry so far. Alright, moving on to support. Support infrastructure is crucial and to be very honest with you in Web3, what I’ve seen so far, support is actually a mess In the majority of cases. I think there’s just a rich desire to get the tech out, then projects get excited and protocols like come and build with our stuff. But the most common kind of mistake I’ve seen is projects providing support on a discord. But what they do, basically there’s a channel for every single project building with your tech and then the engineering team or technical support team have those personal conversations and there’s a lot of handholding that is all great, but something to remember that is absolutely not scalable. But also what I’ve seen there, same questions being asked over and over and over again in this private channels and it’s just a waste of time repeating and repeating the answers.

So something to have mind. Sometimes it helps especially at the very early start of your development to have that one-on-one conversation. But those are all the things to have in mind. But the best way to avoid a lot of questions on whatever channels you’re using for a support discord or anything else is actually to provide as much passive support as possible. So a few ways of doing that is knowledge based tutorials, video resources, we’ve talked about third party sites also because developers would still when the troubleshooting, that’s still search for answers. So that’s a good one to look at. Screencast video walkthroughs if keys, disco got resources, sometimes it helps actually on the server to have resources and break them down. So developers, if the developers are hanging there anyways, that’s an easy way for them to find what they’re looking for. Change lock release notes, user generated content.

So developers trust developers. So if you’ve got a way to encourage those who are successfully building to create some content that then could be a learning support resource for others, by all means this will go a long way. Sample code and templates and troubleshooting guys also part of that, there’s a few things you can also do proactively. So organizing, for example, regular AMAs so that the developers within your community know that they can expect on this particular date. And then if you’ve got a bunch of questions, they can expect having a conversation with you. Technical office hours is a similar thing. Resource bundles, community incentives, personalized recommendations, a bit harder to get but still are there and develop a service and feedback collection. So continuously getting the feedback of what’s wrong will help you to curate your support resources better. And we have reactive support.

So this would be through a channel you provide. So dedicated support channels for developers, especially if your Discord community is shared by maybe end users and developers needs to be very clear a space for developers to go and ask those questions to also make them feel welcoming so they don’t feel like they’re not going to get their questions answered. It’s actually interesting. So from what I’ve seen so far across the Discord service, about two thirds of questions I would say either just get one line answer or actually don’t get answered at all. So there’s no active conversation there whatsoever across multiple projects ton system. I do strongly encourage to still use Ton system and mainly because it’s probably the easiest way for you to evaluate what questions are being asked, what questions are being answered, how long it takes so that you can really get better at it. Peer to peer say this is the best way to scale your reactive support is to engage your community members to help with answering those questions for those who have them. And bots, it is an interesting one.

I think we’ll probably see this getting better. And I’ve got nothing against bots, it’s just I’m sure we’ve all had a not so pleasant experience. It doesn’t even need to be Web3 or anything to do with development just generally in life and it can really get frustrated. So if you are using bots to do, highly recommend you update your knowledge base with answers are coming from on a regular basis and really keep a pulse on it because it is super frustrating and you really want to avoid to create that frustration experience for your developers. And finally, we get to community. So community has been a very important part of developer relations for a very long time. So we’ve been building developer communities ever since. But I would just like to emphasize I think that the decentralized nature and also the ownership of assets and data, really the whole notion of a three really just puts the community there on the pedestal and it’s very important to get it right. So for developers to stick around, the community needs to provide continuous engagement and also operational support.

So the community help us to elevate developer voices, motivational engagement, seeing from others, feedback loops, focus system development, mentorship, support your community members, help each other. A few ideas on how to build a strong community. So welcoming environment, very important, engage in conversations. So this is more sort of, we’ll see examples on still a lot actually on platforms such as Twitter or I shouldn’t say Twitter anymore, should I? So yes, X, where there’s the way of communicating it in this broadcasting manner. So oh, we announced new partnerships with Project X or check out our new blog posts and there’s not enough engagement in conversations. So that’s something I my mind. Active communication channel. So this is something relevant to Discord surveys and I’ve seen sometimes you join and channels and channels and channels and it’s all dead and that’s not a good look given up the stage.

So given the words to community members so they can showcase where they’re building, recognize the effort of those community members who help each other, listener adapting. And of course your system is evolving. So evolve with ecosystem, a few community programs that are pretty successful within the web, three World Bounty programs. So it could be back bounty, but just generally. And there’s a bunch of different platforms for that now, which is great. Grants and funding again. So very relevant how we spoke about those who maybe already are successful and they’ve got something going, those developers would need a bit of an extra push with helping them to take their project. A Level Up ambassadors very relevant to Web3 still content contributions. So that’s kind of the user generated content, our participation and partnership facilitations partnerships of extreme importance in general to help to minimize the whole fragmentation of things and bring everything together.

So having spoken about the three main components, something I’d like to go onto afterwards is great. So once you’ve done the evaluation where you want to take your developers and you take your initiatives, this is what I’m going to do. It’s very important to measure so you see your results. So I was going to say measure all the things, but then I thought they did not say measure all the things because if we start measuring all the things, we’ve got too much data, too much information, and it will be really hard to focus on what we are actually trying to achieve. So instead of trying to measure all the things, focus on your story. So coming back to when we looked at different emotions and how you want the developers to feel, there were only a few initiatives and only a few ways of measuring that. So focus on that for the time being. And then at the end of the period reevaluate and go back to, okay, how developers feel now. And then perhaps you’ll need to pivot, you’ll need to do more of one thing, less of the other thing. And as a result of that review, you’ll probably have different things to measure for the next cycle.

All right, so what’s next in developer experience In Web3, a few trends that pop in automated core generation, natural language interfaces, person has learning path. So this is kind of something I was talking about at the various start. It’d be absolutely amazing if technology could help us to create that particular journey for that particular developer with those skills and motivation that’s very relevant to them. Quantum summarization and extraction that will help produce the precious developer time that they spending. Trying to understand your docs, intelligent search and discovery and autonomous agents and bots. I’ve actually recently had conversation with three different projects that are building, let’s call it a developer relations LLM tool. So this is where with implement a bot, let’s say within a discord channel. And then the data that we get will help us to understand what FAQs are missing or what blog posts we need to, or tutorials we need to add because that’s what’s being asked. But then on top of that, there is a promise that there’d also be an automated pull request and if not updated your docs automatically. It sounds very exciting. We’ll see.

So that was pretty much it. So I do think that the development of tech will help us to create better experiences for developers and help them on their journey within Web3. But something I would like to leave it with is that develop experience. At the end of the day, it is still human experience and we do need to be welcoming for developers and take care of the emotions that they have. And that was pretty much it. Thank you. Rate your experience. I will be here until the end of the day, so if you’d like to discuss anything that I’ve covered so far, I’d be more than happy to enjoy the rest of your day.

Ben Greenberg:

Thank you.

 

 

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.