Elevating Developer Experience(DX) in Web3: A Framework

Transcript

foreign [Music] so good to see so many friendly faces um I'm Sasha tanase I'm a designer and a researcher I am one of the co-founders of web3 ux that's a user research panel dedicated for web3 I'm also leading the ux and design research for the threshold Network which is the first hard merger between keep and new Cipher Network and I am part of the team who is building

tbtc the first fully decentralized Bridge from Bitcoin to ethereum and I like to say that my job is to transform extremely complex products into palatable bits hello I'm Daniel I started working in the Space full time in 2017. I was part of consensus building an analytics platform I moved to consensus diligence so still consensus but doing security research I helped found a stable coin I took a short break and now I'm Tech lead at edenblock VC okay so today we're going to learn about uh what is DX we're going to see what's

the impact of DX and then we're going to learn about the great guideline so um developer experience is the equivalence of user experience when the primary user of the product is a developer a developer is a highly technical user profile so sometimes this might become an excuse for having overly complicated user Journeys and this actually leads to traumatic experiences so due to the fact that developers are more of a technical Persona the products ux owners end up considering developers are power users well power user is a deceitful term that makes you forget

that developers are normal users too and they will actually appreciate and benefit from Simple Solutions just like anyone else so let them understand a few things first they have the potential to become power users but they are not power users when you first present a tool an SDK a library to them it actually takes time so in order to build a developer-centric product you need to make sure that your product is taking into account the following you need to have best practices take care about the user experience and actually be mindful of the developer needs

so why should we care about the X well first of all we need not to forget that developers are at the core of our ecosystem and ethereum constantly attracts 20 to 25 percent new developers coming to web3 so this means that ethereum is onboarding more developers and the need for straightforward processes might be the highest ever so a positive DX which is developer experience can increase adoption and retention and the growth of chains developer communities Daniel can you tell us more about the importance

okay so over time we kept saying that we have to improve ux because that was kind of stopping the blockchain adoption but I think we have to realize that we first have to onboard developers because most of the time developers are building things on top of our protocol and they allow for more adoption this is not necessarily like kicking the can down the road or moving the responsibility to other developers but we do have to think those about those first developers and those first integrators first there are a few areas in which developer experience is relevant and it can have a huge impact people can build sdks those

usually provide abstractions on top of smart contracts or complex systems there that allows the user which is usually the dev to build something on top of the current system without the need to know about how things work underneath this could like an example this is the periphery unit swap contracts which you can integrate easily or for example with bichonomy you can do account abstraction and use their SDK without building the whole stack other things are you know smart contracts if you are kind of starting up it might be difficult to build everything you need right from the get-go so the way that you design the smart contracts will have a high impact

on your product adoption um in terms of blockchains you have to think about how people will integrate how people will extract information from your blockchain so be mindful about that another thing which is less popular but still exists is web widgets you can have small pieces of web on top of your application and this type of effort should be done as soon as possible so during the design process instead of doing it after you you you deploy and after trying to integrate users this allows you to focus on bringing features instead of fixing the design decisions that you made in

the beginning so it helps with more adoption um so it's important to say that this framework is not a GitHub framework at least not yet it is not a template you can copy and paste into your project but it's more like a guideline that helps you plan your whole project with the developer in mind as the first user it's a set of principles and ideas that kite that guide you throughout the whole process so it starts with G from good documentation everything starts with good

documentation if the documents are bad nobody can check out that great piece of technology you actually built so you have to be mindful of your audience what is their background what questions will they have do they need help installing tools the developer space is very vast so if your tool needs rust to run don't just assume that your developer knows how to use rust don't assume that they have rust installed and they know how to use cargo similarly if your tool is python help them set up a virtual environment and you know download every all tools and all of that each tool has its own ecosystem and its particularities

it has to be clear and simple in the first stage you want to guide your audience to achieve something that initial hello world will pay for the more advanced and more difficult Integrations you will help them make along the way but help help them get to a first success and that will help them like um a lot during the whole process have examples and tutorials developers you know especially Engineers learn by doing so help them provide some examples for them which they can copy paste and modify and try to organize them as well

as possible organize your documentation so when you create documentation think about different sections like you know getting started tutorials reference guides FAQs and so on it's also important to understand that you might have two types of users you will have a developer who will try to integrate your tools but you will have another type of developer who wants to contribute to your product so be like understand that you need to talk to them in different ways the next part is robustness so in software development a robust system has to function correctly even in the press the presence of a stressful

environment this can refer to the system being interacted with if you have an API make sure the API is up it responds quickly and consistently if this is related to the code that has to write you need to protect the user from themselves so you have some principles think about paranoia and Parana is like very easy to understand in the web 3 world because everybody is trying to destroy our product so assume everybody wants to destroy your protocol wants to steal your money do all of that the second thing is stupidity it actually helps if you think about your user not being super super smart so

that means you can repeat some things they will try incorrect inputs they will try running methods in an incorrect order the third thing is dangerous implements so users should not have access to things they should not interact with think about libraries Properties or structures part of your classes um another thing is can happen won't happen shouldn't happen you have a case where that some things are very unlikely to happen so have some code and have some errors that protect you from um bad um bad behavior and I do have an example let's look at

this class we have the RPC client class and to the right and to the left we have how um user a Dev interacts with it in this case they need to instantiate it they need to call connect and after that they can get some information you can do a small change to it like what if you connect it right away so then they won't forget to write the connect line it's much easier to to get things right you can also do like if you want optionality you can add on an argument that is by default true so it tries to connect right away but you have to you don't have to

um if you can you can disable that so now to um error handling yeah so whenever you do error handling and error messaging make sure you label them correctly so the error message will communicate to the user how important the error is if you label a fatal error as an info well you will mislead the user and they might suffer great consequences and this might lead them to lose trust and actually stop using your product you have to be specific so the error messages will tell the user exactly what is wrong and should also guide the user towards a solution it needs to be verbose verbose error

message will describe in detail what is the issue the user encounters and will have a hold hand approach it should tell the user what are the next steps they need to take to solve the error it has to be non-blaming write your error messages in a friendly manner it's not the user's fault that you did a very bad job and you also have to use plain languages because even though the error is addressing devs explaining an issue in plain language will go a long way then using terms that you've coined and nobody else understands them and also a very good thing is to add severity grades it's important to label

the error so the user understands what is the impact within the system and also I think it's important to handle errors in a definitely manner if the language language supports exceptions throw them if the language like go returns errors return errors so it's natural for the developer to integrate your product errors it doesn't really matter because you get the same error whatever the problem is how about this error you need to change

this one well I will tell you this one is better but it can still be improved the good parts are that it has a severity grade it describes what the problem is you know where the problem originated however it doesn't say what the address needs to be registered and it doesn't provide the threshold dashboard link so about accessibility you think about it you need to have it Community First so invite the developers to be part of the community as soon as possible if you have a GitHub repo add links to your Discord to your telegram group to your

Slack you have to support your community and your developers so make sure that issues um issues open to the repo are taken care of you have PRS you you check them you help them integrate code and have low or ideally no barriers to entry so permissions permissions access test net availability and if possible no email confirmations and also you should be mindful of accessibility this is actually very useful for some of the users but mandatory for others so impairments can be temporary or permanent and for example a temporary impairment is when

your user has a broken arm or is drunk or is high or just tired like Daniel and the permanent impairment is when your user has for example color vision deficiency or astigmatism like myself and no matter the duration of the impairment you should be inclusive and make sure you accommodate any type of user okay so the last part testable yeah so tested ability is a critical aspect of the developer experience because it impacts maintainability reliability and overall quality of software so you need to make sure you're testing the

documentation you the easiest way is to do a diary study we have linked at the end some ways you can do that and you can learn more about them and I think we need to be mindful of the time we have one more minute it's also important to have your code to be modular so you can test parts of it without going through the whole process so instead of doing 20 steps to get to the part that you actually want to test have a way to fast forward state it has to be deterministic so can you reproduce your user Journeys are they always the same can you freeze the state and reuse it and if possible provide the testing

environment for your developer so like a testing Network or on easy to set up um way like GitHub code spaces where with one click you create the whole environment and people can use it right away so we learned about what is the X we learned about the importance of DX and we learned about the great guideline which is good documentation robustness error handling accessible and testable and um we also added these links for you so you can check to see how actually diary studies are conducted and also we created this QR code to the presentation

containing the links the framework and everything else so thank you very much [Applause] thank you [Music] [Music]